<raeda>
Is github.com/symbolics on here? I'm doing some statistics work and think Lisp-Stat would be a great way to consolidate existing stats code, but registering a new company with the name Symbolics and requiring a contributor license agreement are worrying signs
<White_Flame>
wat
<hayley>
IIRC using the GitHub name Symbolics doesn't really mean you are founding Symbolics 2 (for that see ##symbolics2)
<raeda>
They've registered Symbolics PTE LTD in Singapore
<hayley>
Okay, that's weird.
<hayley>
But I'd wager the name is generic enough that you might get away with it.
<moon-child>
they also opened a PR to some random github project purporting to make it work on genera
<raeda>
I'm sure there aren't any legal problems, it's just weird to see someone setup an account / company with a well known name and then require that open source contributors sign an agreement
<White_Flame>
and it's MSPL, which is a bit weird
<raeda>
You know, instead of just licensing the project under MIT / BSD / GPL and being done with it
karlosz has joined #commonlisp
<raeda>
I'll try emailing the address in the asd file
kakuhen has joined #commonlisp
Oladon has joined #commonlisp
nature has quit [Read error: Connection reset by peer]
nature has joined #commonlisp
pranavats has left #commonlisp [#commonlisp]
pranavats has joined #commonlisp
CptKirk49 has joined #commonlisp
<CptKirk>
@loke are you here?
<loke[m]>
Hello CptKirk
<CptKirk>
ohi
<CptKirk>
I pinged you in aplfarm, since it isn't cl related
<loke[m]>
Yeah, I saw it :-)
CptKirk49 has quit [Quit: Client closed]
lad has joined #commonlisp
karlosz has quit [Quit: karlosz]
char has joined #commonlisp
beach` is now known as beach
<beach>
Good morning everyone!
<CptKirk>
hello
nature has quit [Ping timeout: 265 seconds]
<CptKirk>
in a macro, how do I define a name which is defined in the macro, but available to users of the macro?
<CptKirk>
and if that's bad, how would I do that in another way?
<CptKirk>
like, pass an unbound symbol to be used to define something I need the value of
<beach>
You can introduce any symbol in a macro and it can be used by the caller of the macro. But it is best to avoid that and instead have the caller put a symbol in there, as in WITH-OPEN-FILE for instance.
<CptKirk>
so maybe...
<beach>
`(let ((thing ...)) ,@body) and THING is available in the body.
<CptKirk>
(defmacro m (arg1 artg2 symbol-do-use) `(let ((,symbol-to-use ,@body)) ...))
<beach>
Anaphoric macros use this technique to bind IT around the body, for instance.
<beach>
Yes, that's the better way.
<CptKirk>
ok, body isn't really body, but parser of input
<CptKirk>
becuase (first input) is trying to evaluate now
<CptKirk>
not later
<CptKirk>
that's no good
<Bike>
this is unrelated, but i wanted to ask before: why (eval '(april:april-load #p"./15.apl")) instead of just (april:april-load #p"./15.apl")
<CptKirk>
because that's a compiler macro
<CptKirk>
and during development to save double the amount of effort, it is evaluated every time I call into the expression rather than only once at the beginning
<Bike>
huh. odd macro
<CptKirk>
i'm talking with phantomics about it
<CptKirk>
but how do I avoid (first input) from being evaluated inline?
<Bike>
I don't know what you mean by evaluated inline
<Bike>
What you should generally do with macros is compare how they expand to what you want
<Bike>
do (macroexpand-1 '(defsolution 1 input (first input))) and see what looks wrong
<Bike>
right. i just want to be clear about the problem
<CptKirk>
so sym is a symbol
<CptKirk>
this lets me do
<CptKirk>
(defsolution 1 input (aref input 0))
<CptKirk>
and (defsolution 2 input)
<CptKirk>
because day 2 needs no parsing
<beach>
CptKirk: Please use a paste service for more than a line or so of code.
<Bike>
please do multiline pastes in pastebin or something, by the way. i know it's going a bit out of your way, but it clogs up the irc
<CptKirk>
sorry :C
<Bike>
also, you seem new to the language, so #clschool might be good
<beach>
Yes, I don't think this is the right way to learn a language, but then, learning Common Lisp may not be a goal for CptKirk.
<Bike>
eh, going through apl is kind of wacky, but they're doing alright
<CptKirk>
what do you think is not the right way to learn a language?
<beach>
Starting with the use of a nontrivial library like April.
<CptKirk>
I should clarify, my first exposure to common lisp was 5 years ago now. I've been through a laundry list of books
semz has quit [Ping timeout: 268 seconds]
<CptKirk>
But all of my time with Common Lisp has been toy problems all done in the repl, using only basic list structures
<beach>
The standard language has a lot more than lists to offer though.
<CptKirk>
I'm not claiming expertise or experience, but I wouldn't say I'm starting from the beginning
<beach>
OK.
<CptKirk>
@beach I know there are a lot of features, but I never did bother with asdf, or importing libraries until this week :/
<CptKirk>
haven't really had the need
<Bike>
i don't mean to sound like an elitist, but repl exercises don't really compare to actually writing programs. I mean, I could probably take a few minutes and write matrix multiplication or something in APL, but i'd hardly say I know it
<Bike>
(well, actually i bet apl has that built in, whatever)
<CptKirk>
my use case can maybe elucidate further. I'm professional applicaiton developer in C#/python/angular/react/node with loads of backend tools etc. I was a full time APLer for 2 years, and now host a discord for all array languages. The issue for me is that all the existing FOSS array languages are limited in their library vocabulary, and seeing the
<CptKirk>
relative maturity of april and the library list of Common Lisp, I'm thinking it would be good to have CL as the driver that talks to the outside world, ffi, libraries, rest, sockets, etc, and APL can do all the pretty logical stuff
<Bike>
sounds neat.
<CptKirk>
which is a very similar pattern to the unix design pattern, using lisp to orchestrate c libraries
<CptKirk>
at least... in theory
<CptKirk>
and I aim to test that theory
<CptKirk>
I don't think you sound elitist, I really am a novice
<beach>
That does sound good.
<CptKirk>
from where I'm sitting, I'm not going to learn much more about modern CL reading the classic books. I've learned academic CL, but I have never had an application to build with it, so its all been relatively novice level activities
<CptKirk>
And I have always had a soft-spot for LISP and its dialects
<CptKirk>
So this is the perfect moment for me to really dig in and jump in the deep end
<beach>
Excellent!
<CptKirk>
so thanks to everyone for their patience and helpfulness :)
<CptKirk>
I've learned a lot these past few days
<Bike>
yeah, books are useful but only get you so far
<CptKirk>
I've actually done some more than once
<CptKirk>
land-o-lisp was so fun I did it twice
<CptKirk>
er... 3 times actually :P
<beach>
It may be fun, but it is badly written and I don't recommend it.
<beach>
The author uses incorrect and inconsistent terms.
<beach>
I really should start my page about Common Lisp book reviews, but I am too busy with other stuff at the moment.
semz has joined #commonlisp
<CptKirk>
I did notice the poor writing the more time I spent with it
<CptKirk>
and the terms
<CptKirk>
PAIP is much more profesionally written, though the density took me a while to get throught it
<beach>
Yes, Norvig is a good author.
<beach>
s/author/writer/
<dualinverter[m]>
I started with Land of Lisp because I had a copy of it lying around; it was a fun read until actual lisp learning started. After a couple of chapters, I found it disorienting.
<dualinverter[m]>
I am now reading "Practical Common Lisp"; so far it has been wonderful.
<dualinverter[m]>
<beach>
Yes, Seibel writes well too.
brettgilio has quit [Quit: Ping timeout (120 seconds)]
brettgilio has joined #commonlisp
Bike has quit [Quit: Lost terminal]
<loke[m]>
Didn't he mention the possibility of a new edition of PCL?
<hayley>
I think so.
<beach>
That would be good.
Oladon has quit [Quit: Leaving.]
karlosz has quit [Quit: karlosz]
<dieggsy>
is there some kind of compilation reader macro shorthand in the style of #+ for if a symbol is unbound
<dieggsy>
...by chance lol
<dieggsy>
i can just (when (not (fboundp ..) ...)
Inline has quit [Quit: Leaving]
rain3 has joined #commonlisp
CrashTestDummy3 has joined #commonlisp
CrashTestDummy has joined #commonlisp
CrashTestDummy2 has quit [Ping timeout: 268 seconds]
CrashTestDummy3 has quit [Ping timeout: 268 seconds]
<lisp123>
I liked CLtL2e a lot, suprised it doesn't get more love from newbies
gaqwas has joined #commonlisp
<lisp123>
I guess its a bit lengthier read, whereas PCL does good summaries for each section
doyougnu has quit [Ping timeout: 268 seconds]
<beach>
Also, it was written before the standard was voted, so it differs in some places.
<beach>
I think what we need is a Common Lisp reference, probably in the form of a web site. I think this could be done by starting with the dpANS and adding more material.
<beach>
No, that's not good enough. It is a document primarily meant for creators of Common Lisp implementations.
<beach>
moon-child: ^
Nilby has joined #commonlisp
<lisp123>
HTML version of the draft
<beach>
Yes, I saw that. We also have the fantastic work by scymtym to parse the dpANS into various formats.
<moon-child>
eh, I have no intention of creating a common lisp implementation, and I have always found it adequate. It could perhaps be made more approachable in some respects, but not majorly so
<moon-child>
imo
<lisp123>
Nice, I will check out his/her work
<beach>
moon-child: OK, example: Read the page on AREF and tell me what happens if you give it an object that is not an array.
<beach>
moon-child: You need to know that the information is to be found in...
<beach>
moon-child: Most newbies, and many experienced Common Lisp programmers don't know that. For example, jmercouris was convinced that an error would be signaled.
Nilby has quit [Ping timeout: 240 seconds]
Nilby has joined #commonlisp
taiju has quit [Remote host closed the connection]
taiju has joined #commonlisp
defaultxr has quit [Ping timeout: 265 seconds]
defaultxr has joined #commonlisp
<lisp123>
I just noticed that Elisp passes parameters by value
<lisp123>
Is there a reason that CL passes by reference? Is that for optimisation reasons?
<lisp123>
(excluding small integers and other potential items that are passed by value)
jmhimara has joined #commonlisp
<moon-child>
lisp123: what do you mean by that?
<moon-child>
as far as I know, there is no semantic difference between the way parameters are passed in elisp and cl. This snippet has the same behaviour in both, for instance https://0x0.st/-3ZM.txt
<lisp123>
I have some buffer-local-variables in elisp, I think that's what is throwing it up
<lisp123>
Will investigate
<lisp123>
Thats a useful link - thanks!
pve has joined #commonlisp
shka has joined #commonlisp
rgherdt has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 265 seconds]
santiagopim has quit [Remote host closed the connection]
<phantomics>
Hey moon-child, I figured out what was wrong with {⍵{2÷⍨⍵+⍺÷⍵}⍣≡⍵}12345678 in April
<phantomics>
It needs to be {⍵{2.0÷⍨⍵+⍺÷⍵}⍣≡⍵}12345678
<phantomics>
Because the 2 is handled as a rational number, the numerator and denominator get huge and the comparison tolerance doesn't work. A consequence of supporting ratios in April
<moon-child>
ah!
CptKirk has quit [Ping timeout: 256 seconds]
<pjb>
emacs lisp passes parameters exactly like any other lisp, by value ! Always. CL passes parameters by value too.
<moon-child>
in raku, rational numbers will get automatically promoted to floats once the numerator/denominator exceed some threshold, unless you explicitly request otherwise. Such behaviour might be worth considering
<pjb>
(for the innocent bystanders)
<beach>
pjb: Exactly.
<moon-child>
(perhaps the threshold might be when the denominator exceeds ÷⎕ct. That way rational comparisons can always be exact, with no semantic drawbacks)
<moon-child>
(rather than 'with no semantic drawbacks', I should say 'in a semantically consistent manner'. Except that that is not right...)
<beach>
moon-child: Also, the "Examples" section of many Common Lisp HyperSpec dictionary entries contains non-conforming code. For a creator of a Common Lisp implementation, it is known that these sections are not normative, but it is embarrassing that newbies are given such examples.
<beach>
[referring to the Common Lisp HyperSpec as a reference document]
<moon-child>
beach: fair enough. What you point out about type mismatches I think is the sort of minor augmentation I mentioned would be helpful but not essential. In that it still describes correct usage of the function. But the non-conforming examples are more egregious (and identifying them is far harder to automate!)
gaqwas has quit [Ping timeout: 252 seconds]
<moon-child>
I encountered one just the other day
<beach>
Sure, nothing is essential, but I think we can do much better than the Common Lisp HyperSpec in a reference document. For the AREF case, I could see the phrase "If an argument of a type other than an array is given, then the consequences are undefined" explicitly inserted.
<beach>
And when there is a phrase such as "an error should be signaled", at least making that phrase a link to the meaning of the phrase would be useful.
lisp123 has joined #commonlisp
<beach>
lisp123: If you read the link you were give, you will see that Common Lisp, just like most modern languages (Haskell excluded) use call by value.
<beach>
*given
<moon-child>
why haskell excluded?
amb007 has quit [Read error: Connection reset by peer]
karlosz has joined #commonlisp
amb007 has joined #commonlisp
<lisp123>
beach: the tricky part is this "So, although values are copied before passed to the function, what is copied here is a reference."
<beach>
Because it does not use call by value, and instead "lazy evaluation".
<beach>
lisp123: But that has nothing to do with the phrase "call by value".
<moon-child>
right
<hayley>
I guess lazy evaluation is considered "call by name".
<beach>
hayley: As I recall, it's not quite the same.
<beach>
lisp123: Call by value just means that arguments are evaluated before a function is called. Nothing else. It says nothing about the nature of those arguments.
amb007 has quit [Read error: Connection reset by peer]
OlCe has joined #commonlisp
amb007 has joined #commonlisp
<moon-child>
wiki says 'if [a parameter] is used several times, it is re-evaluated each time it appears'
<beach>
I am sorry if the C++ people attempt to change established terminology, and I won't grant them that pleasure.
<Nilby>
The CL spec examples reinforce my belief in thinking for yourself and being skeptical of authority.
<lisp123>
beach: Yes that part is clear. Its more around 'parameters passed by value'
<moon-child>
(regarding call-by-name)
<hayley>
Well, given that evaluation of Haskell code is more or less deterministic, I think avoiding re-evaluation would be an optimization.
<beach>
lisp123: Again, "pass by value" = "call by value" means that they are evaluated before passed. Nothing else.
<lisp123>
As I understand, the value passed is a copy of the reference? Is that correct?
<beach>
lisp123: In all modern languages, when call-by-value is used, a copy of the value is passed, no matter the nature of that value. In certain languages, like C++ and Pascal, and Algol, you can change that by &name, var name, etc.
<beach>
lisp123: In early implementations of Fortran, this was not the case, so you could say f(1) and f could be defined with parameter x and then x = 2 in the body, and then subsequently, references to 1 would be 2.
<beach>
That's not a good idea if you ask me.
<lisp123>
beach: Thanks for the explanation
scymtym has quit [Ping timeout: 252 seconds]
<lisp123>
That link also is very helpful, with a bit more time I should be able to internalise the concepts
<beach>
Sure. It's all in the page of that link.
<moon-child>
hayley: no, because if you never evaluate an effectful form, the effect will not happen. For instance, this snippet prints nothing http://ix.io/3z7s
<moon-child>
AIUI
<beach>
hayley: Call by name, as I recall, is so weird that it was never implemented even in Algol.
<hayley>
Evaluating an effectful form in Haskell does not cause effects; the effect only occurs if it appears in the value bound to main in Haskell.
<beach>
I believe what Haskell does is called "call by need".
<hayley>
Right, yes.
pillton has quit [Quit: ERC (IRC client for Emacs 27.2)]
<phantomics>
moon-child: automatic float promotion may be worth considering
Duuqnd has joined #commonlisp
attila_lendvai has joined #commonlisp
notzmv has quit [Read error: Connection reset by peer]
selwyn has joined #commonlisp
<beach>
I often want to say something like "there is no experiment the application programmer can conduct in order to determine whether some objects are not really references to memory, and are instead encoded in the pointer itself", but...
<beach>
Then I think about EQ, so I haven't said that. However,
<beach>
Now that I think about it, an implementation can decide to "intern" certain numbers, and so the EQ experiment won't work.
<beach>
pjb: So we can be really nasty to people who try to exploit EQ-ness by having all integers and characters be real references, but we intern, say only odd numbers, and lower-case letters.
<beach>
pjb: In BOCL I mean.
<OlCe>
Hi beach. You are touching on the reason of EQL's existence versus EQ I guess.
<Duuqnd>
What's BOCL?
<beach>
OlCe: Indeed. But it is mostly the fact that, whenever I use the term "uniform reference semantics", some people like to point out that the implementation could be optimized in some ways, so that not all objects are references.
<beach>
Duuqnd: BOotstrap Common Lisp. A project to create a conforming Common Lisp implementation meant only for bootstrapping others.
<beach>
Duuqnd: It would be the only Common Lisp implementation optimized for maintainability rather than performance.
<Duuqnd>
I see. I've found two different repos, one is yours and the other is on gitlab. Which one are you referring to (I'd assume it's yours)?
<beach>
Duuqnd: To me, it is partly an argument against writing Common Lisp implementations in some language other than Common Lisp, for various reasons. Though I know perfectly well that jackdaniel prefer for ECL to be bootstrapped from C for other reasons.
hendursaga has joined #commonlisp
<beach>
Duuqnd: It is complicated. I started mine, and then pjb started his own, and worked faster for some time, so I gave up. But then pjb got a full-time job...
<beach>
So I guess both are stalled right now.
<beach>
It is an amusing project to think about, in that it is really hard to avoid thinking in terms of performance.
<Duuqnd>
Writing a CL implementation in C sounds pretty painful
<beach>
Well, some things would still be Common Lisp, like the full reader.
<OlCe>
beach: Sounds amusing, indeed.
<beach>
The purpose is that it can be built using C only.
hendursa1 has quit [Ping timeout: 276 seconds]
<beach>
OlCe: Exactly. Feel free to contribute. :)
saturn2 has quit [Ping timeout: 260 seconds]
<OlCe>
beach: Ha ha. I would love to, but I have no time...
<beach>
Welcome to the club.
<Duuqnd>
That's (a Lisp in C only) certainly useful to have. Is there a reason why ECL doesn't cut it (I'm not very familiar with ECL)?
<beach>
No, no reason. ECL is fine. But it is less maintainable than it could be, simply because performance is taken into account.
<OlCe>
Duuqnd: Was going to ask more or less the same question.
<hayley>
ECL is designed to run relatively fast, and not just as a bootstrapping tool.
<OlCe>
So BOCL is indeed written in CL itself (I had guessed, but now I'm sure).
<beach>
No, in C for the "core".
<hayley>
BOCL is written in C.
<OlCe>
Ha no, I misread.
<OlCe>
Yes.
<beach>
It can't be written in CL, because of the bootstrapping argument.
<jackdaniel>
ecl features two runtimes: one is inside a bytecode vm (and its a very trivial target without many optimizations) and one is compiled to C and then to native
<OlCe>
Mmm... It could be written in CL, and then compiled to C with ECL, no? :-p
<OlCe>
jackdaniel: Interesting.
<beach>
OlCe: No, because of the FSF definition of "source code".
<jackdaniel>
but then you defeat the purpose of having it as a bootstrapping tool - if you depend on ecl to bootstrap then you may stop at ecl right away
<jackdaniel>
OlCe: ^
<OlCe>
jackdaniel: Not necessarily. You can compile an old version once and for all, and use that as bootstrap for newer versions, which are themselves bootstrap for whatever other compiler.
<OlCe>
But yes, this becomes complicated.
<jackdaniel>
the point is to have it bootstrappable from C, not from the previous version of the same implementation
<beach>
OlCe: The use case is what I said. Some Unix distributions want every program to be possible to build using only C.
<jackdaniel>
fwiw ccl and cmucl depend on the "previous" version of the same implementation
<jackdaniel>
and sbcl depends on /any conforming/ common lisp implementation
<Nilby>
I could just slow down ECL for you? I think it's unlikely, given various examples from history, for a full CL in C to be practically any more maintainable than say ECL.
<jackdaniel>
my personal opinion is that the problem is already solved having both clisp and ecl, but the argument of better maintainability of bocl as the prime goal is a sound one regardless
<OlCe>
You are bootstrappable from C if starting with some fixed version (of say, BOCL) pre-compiled to C. You just distribute this C code as the first bootstrap.
<beach>
Nilby: You have no idea what kind of tricks we have planned. :)
<jackdaniel>
i.e ecl could be stripped from: networking, threading, native compiler, dlopen and various other extensions
<jackdaniel>
and that would improve the maintainability
<OlCe>
jackdaniel: Yes.
<Nilby>
beach: Tricks sound less maintaible than more. e.g. CLisp's wacky macro preprocssing.
<beach>
Nilby: Sure, you don't have to take my word for it.
<jackdaniel>
at the cost of performance, features and general usability. so that would be the primary difference between them: bocl would be only for boostrapping (because it would be rather useless in practice due to lack of common extensions); while ecl is meant to be used as the environment to write applications in
<Nilby>
beach: I think you write more maintaible code than most, but code has a way of developing it's own inertial momentum.
<beach>
Nilby: Imagine, for instance, every object being heap allocated, with a separate "header", so that CLASS-OF can be the same operation no matter what object type it is.
<OlCe>
Then, if you not only want a C bootstrap but also that such codeis easy to understand, pre-compiling to C might not be the best option.
<OlCe>
I've never looked at ECL-produced code up to now personally.
<jackdaniel>
ecl produces fairly readable code
<beach>
OlCe: Again, it also does not qualify as "source code" so can not be used in those Unix distributions.
<OlCe>
beach: I hear you. But what's the problem exactly? Licenses?
<jackdaniel>
OlCe: it is a computer-generated code, so it is not the source, only an intermediate form
<beach>
No. "source code" is defined to be the "preferred version for modification by maintainers".
<jackdaniel>
and intermediate code is prone to trustuing-trust issues
<OlCe>
jackdaniel: Sure. And?
<OlCe>
jackdaniel: Ok. Does ECL restrict the produced code in any way?
<jackdaniel>
and since it is not a source code, then it is not considered a source code?
<OlCe>
beach: I understand that.
<jackdaniel>
restrict how?
<Duuqnd>
Yeah, "restrict" seems a bit vague here
<OlCe>
Restrict the use, distribution, or whatever else you can do with the code.
<Duuqnd>
I don't think a compiler can legally do that to its output
<jackdaniel>
no it doesn't, but the produced code depends on the ecl runtime
dtman34 has quit [Ping timeout: 265 seconds]
<jackdaniel>
hence it requires ecl present that is a subject of its licensed
<OlCe>
Duuqnd: I think you could do that legally, but that's another problem (and discussion).
<jackdaniel>
Duuqnd: of course it could, but foss licenses does not imply such restriction (result of running the program is not the subject of its license)
<OlCe>
jackdaniel: Yes, this is what I had in mind. ECL runtime can be linked-in statically, but it can dynamically as well I think?
<jackdaniel>
yes
<OlCe>
jackdaniel: In the second case, there is no restriction on the produced code I guess.
<Duuqnd>
I was under the impression that a compiler's author couldn't claim any copyright on the code the compiler generates
<jackdaniel>
fasl files are in case of the c compiler in fact .so objects (with extra sauce)
<jackdaniel>
bytecodes compiler is a different story
<OlCe>
beach: I'm very much interested in bootstrapping techniques, especially from C, but I'm not very sensitive to the "source code" argument.
<OlCe>
beach: Can we know which distributions you are talking about?
taiju has quit [Ping timeout: 240 seconds]
<jackdaniel>
the point is that many people are sensitive to it. I believe that debian requires all software to be boostrappable from C (even indirectly, like C -> ECL -> SBCL)
<jackdaniel>
as of why C has such prominent position as "granted" - perhaps it had its merit 20y ago
<OlCe>
jackdaniel: But again, this is the case in all proposals above. What is not the case is bootstrap from true "source code", as mentioned by beach.
karlosz has quit [Quit: karlosz]
<OlCe>
jackdaniel: I couldn't agree more on C.
<jackdaniel>
I don't think that they would accept a C source code that is transpiled from something else (in a form that is not meant for maintanace)
<jackdaniel>
like the publisher would not accept a book translation being a result of putting the original in google translate
<OlCe>
jackdaniel: Especially since the C standard says "undefined behavior" in so many not-that-obvious cases, and most compilers viciously take advantage to optimize code away. And when you start doing nonsense, then it's best to optimize to the point where there is no more program at all.
<jackdaniel>
beach mentioned that there is a foss definition of the source code, so that would be the criteria for inclusion
<OlCe>
jackdaniel: I'm not in their heads, so I don't know for sure what they actually want behind this kind of restrictions, but
<jackdaniel>
as of undefined behavior there are various strategies to take advantage of it - and that depends on the compiler and on the platform
<jackdaniel>
i.e casting the function pointer to the data pointer makes perfect sense in a system where both are in the same address space, while it should result in an error otherwise
<OlCe>
jackdaniel: IMPOV, you want bootstrapping for reproduceability and security
<OlCe>
jackdaniel: and for this code transpiled once and for all is as good as it gets.
<OlCe>
jackdaniel: You don't have to update it to new versions of BOCL or others. You just bootstrap the new versions on top of it.
<jackdaniel>
well I can tell that your mind is set on certain ideas, so I'll leave the discussion at that
<OlCe>
jackdaniel: If it has flaws, you correct them by hand in C (if readable). In case of a big problem, you transpile again, but this should be fairly rare.
<OlCe>
jackdaniel: I'm exposing my assumptions and needs, in order to clarify where they differ from what you (and beach) are stating, nothing more. I'm not necessarily "set" as you say. And I perfectly understand and appreciate what you are saying. There is no contradiction.
<jackdaniel>
I'm not saying that you're not appreciating it. I'm saying that we've exchanged views and there is nothing to add ,)
<OlCe>
Ok, then. I just find the reasons behind, e.g., Debian's requirements unclear.
<OlCe>
jackdaniel: Entirely expectable from the FSF. This binds several distributions that absolutely want to abide by this definition and obtain or keep the FSF clearance. It's a problem I personally don't have.
<OlCe>
But I guess it's the problem beach is having.
taiju has joined #commonlisp
<OlCe>
And this has not much to do with reproduceability, nor security (directly at least). It's a matter of ideology for those groups.
* jackdaniel
shrugs
<jackdaniel>
this gets offtopic
dtman34 has joined #commonlisp
<pjb>
beach: it's even worse, since nothing says that implementation defined behavior cannot change over time.
<pjb>
(as long as it's documented).
<pjb>
but randomness can be documented!
<jackdaniel>
#+random (random 5) #-random 42
<hayley>
I disagree that it is "a matter of ideology", given the damn point is to have usable source code.
lisp123 has quit [Read error: Connection reset by peer]
fengshaun has joined #commonlisp
fengshaun has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
<hayley>
Having a solid definition of useful source code is how we don't consider, say, all front-end code to be "free or open source software", or even anything distributed in machine code form only.
<jackdaniel>
if someone disagrees with the fsf point it is easy to look at it as ideology;; there is nothing wrong with that - opposite stance "I don't care" is also an ideology;; associating negative meaning with the word "ideology" is just a matter of sophistry
<pjb>
Duuqnd: writing C code is "painful" for anything. Only with time, C programmers become masochistic enough to bear it. Now when you're both a lisper and a C programmer, of course, you don't write the painful C code: you generated it with some lisp code! :-)
<hayley>
Perhaps I am still eating out of the trash can of ideology, by considering having access to useful source code to a good idea.
<OlCe>
hayley: That's why I asked about readability of ECL-produced C code.
<OlCe>
hayley: C code can be produced mechanically and still be useful.
<jackdaniel>
well, I'm sold to fsf ideology too, it is very practical
<OlCe>
hayley: That's why I'm talking about ideology.
<OlCe>
hayley: But surely there are other concerns and forces yes.
<pjb>
Let's say the difference between bocl and clisp, is that bocl aim to use standard C without using C implementation defined behavior or extensions, so that it can be compiled and run on all platform with a standard C compiler.
<jackdaniel>
OlCe: code may be readable, but it is also more verbose and harder to change by hand
<hayley>
OlCe: My non-normative opinion is that the C code produced is reasonable. But I would prefer to modify the Lisp code that it was generated from.
<jackdaniel>
i.e you can't read it but you can't easily write it correctly by hand
<OlCe>
hayley: I don't dispute that. On the contrary, I agree with you.
<jackdaniel>
s/can't read it/can read it/
lisp123 has quit [Ping timeout: 240 seconds]
<OlCe>
hayley: But I'm very much separating the matter of modifying source code and the matter of bootstrapping.
<hayley>
I think my prior example of "all front-end code" is more illuminating though, particuarly with compressed JavaScript code.
<OlCe>
hayley: Indeed.
<jackdaniel>
if it is the lisp code that you develop (say bocl) with, then this lisp code is the source code
<hayley>
While I get some source code, it is not useful for much one would want to use source code for.
fengshaun has joined #commonlisp
<hayley>
OlCe: Okay then. But remember one approach for bootstrapping is to start with a pre-compiled Lisp image, and we have to determine why starting with C source code is better.
<OlCe>
hayley: Sure. I don't think bootstrapping with C is better in general. But in environments where only a C compiler is available, it's tremendously useful...
<hayley>
Oops, I said source code. "we have to determine why starting with mechanically generated C code is better."
<OlCe>
hayley: Same reason. ;-)
<OlCe>
And, true, as jackdaniel says, ECL may already fit the bill quite well.
<hayley>
Yes, I agree. So I guess the proposal for a bootstrapping Common Lisp is not too practical from this point of view. But it would be easier for the implementors to write the simplest code in C and then never touch it again.
<OlCe>
hayley: And for security matters, I prefer to be able to access as much source code as I want, a property I have with a C bootstrap (and open-source libc and compilers). I have absolutely no guarantee on this, nor practical and reliable means to verify it with a pre-compiled Lisp image.
<OlCe>
hayley: Yes. C reduced to a minimum.
<beach>
OlCe: I am personally not at all interested in bootstrapping Common Lisp from C. But BOCL to me is an argument against most "Debian" type arguments, since it would suffice for a pure Common Lisp implementation of Common Lisp (like SICL) to include BOCL in the distribution in order to qualify.
<beach>
Plus, BOCL is, like I said, a very rewarding mental exercise.
<OlCe>
beach: Ok, I see.
<OlCe>
beach: Surely. ;-)
<beach>
And we had problems using SBCL for SICL bootstrapping in the past, because of decisions made in the name of SBCL performance. BOCL would not have any such restrictions due to performance compromises.
<beach>
We have not tried any other host Common Lisp implementation for bootstrapping SICL, but it would not surprise me the least if we ran into restrictions of this type in other Common Lisp implementations too.
<OlCe>
beach: Without taking too much of your time, out of curiosity, may I ask for types or examples of such restrictions? If you have pointers to web pages or papers instead, that's more than welcome as well.
<beach>
Well, first we created too many FUNCALLABLE-STANDARD-OBJECTs, because those used to all be allocated in something called "immobile space" (I think) and the size of that space was not increased by any arguments to the system.
<beach>
Then, we generated too big host functions, exposing some super-linear behavior of the SBCL compiler, so what now takes less than a minute used to take the better part of an hour.
scymtym has joined #commonlisp
<beach>
stassats kindly fixed the first problem.
<beach>
But we had to reorganize SICL bootstrapping to solve the second one.
waleee has joined #commonlisp
<beach>
OlCe: Does that give you an idea of the problems?
<OlCe>
beach: Yes, thanks.
<OlCe>
beach: The super-linear problem was an algorithmic mistake or oversight, or the consequence of a problem intrinsically hard to solve?
<jackdaniel>
OlCe: some clever compiler tricks have some upper limit before they give up
<OlCe>
beach: Because in the second case, you would have the same problem with BOCL compiling SICL. Anyway, now that you've fixed it in SICL, it doesn't matter much.
<jackdaniel>
taking inlining - you can't inline mutually-referring functions ad infinitum
<jackdaniel>
so there is the inlining depth parameter for the compiler
<jackdaniel>
s/for/in/
<jackdaniel>
same may go for other characteristics - the compiler may give up on analyzing too long function (because i.e compilation time grows exponentially with the function length)
lisp123 has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
kakuhen has quit [Quit: Leaving...]
<beach>
OlCe: It is not uncommon for optimizing compilers to have some quadratic algorithms, by necessity.
<beach>
And I can very well imagine the maintainers of some Common Lisp implementation being unwilling to fix such issues, citing the unusual use case.
<OlCe>
Yes, it's true when you're trying to optimize. A problem you won't have with BOCL.
<OlCe>
Yes.
<beach>
So I fear a situation where one day I add some feature to SICL, start the bootstrapping procedure, and I will run into some arbitrary restriction that can't easily be fixed.
<beach>
So, yes, I think those are restrictions that were introduced for reasons of performance. Which won't be a problem with BOCL.
<OlCe>
Mmm, yes. But some are more or less unavoidable. Plus, I assume you also expect SICL to compile SICL (same or other version), which may trigger quadratic (or worse) behavior as well, don't you? The host functions' size seems to be a problem that had to be fixed in SICL anyway.
<OlCe>
But at least you'll be in full control of the whole chain.
<beach>
Exactly.
<jackdaniel>
some compiler optimizations may be necessary to make a certain code compilable - i.e for deeply recursive functions a tail recursion may be necessary
<jackdaniel>
so either bocl will need to have certain optimizations or you may need to avoid certain constructs in the compiled code
<OlCe>
jackdaniel: Also true yes.
<jackdaniel>
(that said I'm aware that you can't expect tail recursion in CL:)
<OlCe>
Most of the time, I consider deep recursion to be a bad idea, and I make the effort to rewrite the code into non-recursive form.
<beach>
Yes, if I write SICL to expect tail-call optimization, that's bad.
<OlCe>
jackdaniel: ;-)
<beach>
Also, I think BOCL would be an amusing community project. Most people here seem to know some C.
<jackdaniel>
well, this is just one example; another would be a function length - I remember we've hit a certain issue with C compilers when using ECL to compile magicl
<jackdaniel>
if the file is too long then gcc/clang goes belly up
<beach>
It would be easy to add some C code for a yet-unimplemented Common Lisp feature.
<beach>
jackdaniel: Right, C compilers have such issues as well.
<OlCe>
jackdaniel: In practice, don't all reasonably alive CL implementations implement tail-recursion?
<jackdaniel>
the answer was to split the function into number of smaller functions spread in files
<jackdaniel>
if I remember correctly
<jackdaniel>
OlCe: tail recursion is not always desired - i.e it makes debugging harder; so that would depend on the optimization settings
<Nilby>
The old lispers didn't have this problem. They had already first written a slow lisp, in a crap language.
<jackdaniel>
ecl native code depends on the underlying c compiler (but it makes a certain effort to make the tail recursion possible for the c compiler)
<jackdaniel>
I don't know about abcl
<beach>
OlCe: Maybe not. If you have a Common Lisp implementation that is compatible with the C calling convention, tail-call optimization is very hard.
<jackdaniel>
there is a certain trick called cheney on the mta: https://plover.com/~mjd/misc/hbaker-archive/CheneyMTA.html it utilises a certain trick to make it work (but it requires certain decisions to be incorporated in the implementation)
<hayley>
Nilby: Then they have the problem of having only a slow Lisp, and recovering from headaches induced by writing in crap languages.
<beach>
jackdaniel: Indeed.
<jackdaniel>
uh oh, I've used the word "certain" three times and "trick" twice:)
<Nilby>
hayley: Indeed. But I think they already recoverd by when CL came about.
<jackdaniel>
gimp devs started with common lisp but deemed it slow and bloated
<Nilby>
The evolution of Dylan is also intersting. The people a with lot of resources wrote the proprietary Dylan in CL. Then the free community wrote a slow one first in C, than transpiling to C.
<Nilby>
Then finally the CL Dylan was re-written in Dylan.
<beach>
jackdaniel: Oh, wow! I had no idea. What a mistake.
<jackdaniel>
hm, since the program they wrote in cl was way too slow I guess that switching the language was the right choice
<jackdaniel>
it might be because they had no good implementation at hand or hardware was too slow or that they were poor cl programmers
<beach>
Yeah.
<jackdaniel>
regardless which that was, the pivot seems to be a correct choice
<hayley>
"Something that did not rely on nested lists to represent a bitmap." Excuse me what the fuck
frgo has joined #commonlisp
<OlCe>
jackdaniel: Interesting.
<OlCe>
hayley: Exactly.
<jackdaniel>
mind that they were students on whom lisp was forced on :) still core dump at 17mb in cl is a bad taste, a sensible restart sounds better ,)
<jackdaniel>
also that might be an exaggeration after being frustrated with cl, they could actually have used arrays
<Nilby>
somehow the scheme in gimp doesn't make me so happy
<jackdaniel>
well, it is just a "scripting plug"
<hayley>
An array would be, say, four times as small at least.
<jackdaniel>
otoh extending the array (i.e resizing the image) could be a copying operation
attila_lendvai has quit [Read error: Connection reset by peer]
<hayley>
I heard that Photoshop uses some kind of persistent data structure, funnily enough.
<OlCe>
jackdaniel: Yes, but you would have the same problem in C, which could as well be solved in CL.
attila_lendvai has joined #commonlisp
<jackdaniel>
I'm not going to take a bait and discuss whether C or CL was more practical on machines with 32MB ram ;) I'll be back later
<hayley>
Using nested lists to represent a bitmap in C would be equally dumb.
<jackdaniel>
(and noticeably harder, mind that)
<OlCe>
:-)
<Nilby>
I can say from experience a Lisp GUI running on 32MB on CMU lisp was so slow it could barely trace my mouse.
<beach>
jackdaniel: I see. Though "Common Lisp" does not dump core. Some implementations might, of course.
<beach>
hayley: Yeah, it looks like incompetence was a factor.
<rain3>
yeah. but it's easier to say "it's because of lisp"
<beach>
Indeed.
<jackdaniel>
beach: sure; but it is very likely that what they had was an ancient hardware (compared to today) and imlementation that was inferior if you compare results of writing the same program in C and CL (performance-wise) on said hardware
<jackdaniel>
ditto Nilby testimony
<Nilby>
Sadly, I can still get any lisp on unix to dump core. Recently I made sbcl wedge the kernel.
<lisp123>
Why do people choose to use scheme as their scripting language for their applications? Is it because it is "smaller" than CL? Is it worth having a subset of "CL" for quick use
<beach>
Fair enough.
<jackdaniel>
lisp123: people with the same idea as yours standardized the programming language interlisp
<beach>
What ideas are they?
<jackdaniel>
notably the interlisp project (supposedly) drained the project eulisp from competent developers (and eulisp was more interesting than internlisp)
<hayley>
lisp123: Well, there was a Usenet thread called "Ousterhout loses the plot" or something, where it is more or less argued that CL was deemed doubleplusungood due to 1. having long names and 2. having implementation authors who thought they could write fast implementations.
<jackdaniel>
beach: that having a subset of common lisp is a good thing for slower hardware
<beach>
Ah, OK.
<jackdaniel>
whew, not interlisp
<jackdaniel>
the other name (/me tries to remember)
<lisp123>
hayley: Oh I see
<Nilby>
eulisp?
<beach>
Islisp? PSL?
<beach>
NIL
<jackdaniel>
islisp, yes
<jackdaniel>
beach: thanks
<beach>
Sure.
<jackdaniel>
none of what I've said above applies to interlisp of course
<beach>
lisp123: What is interesting, though, is that they choose a static language for the core application, citing performance. Then they include a scripting language in the form of an interpreter. Then people start writing code using the scripting language, because they can't do it in the static language. Then the combination is much slower than if they had chosen a dynamic language for both.
<lisp123>
I might sound out of line, but that John Ousterhout fellow doesn't sound too smart..
<beach>
Oh, I think he is smart. But he wasn't very knowledgeable in the past, like when he wrote TCL.
<lisp123>
beach: lol - based on how they wrote the starting notes to the GIMP history, it seems logical they went down that route
<beach>
Yes.
<hayley>
There is a smattering of familiar names in that thread, oddly enough, including Robert Virding, Rainer Joswig, Henry Baker, Doug Lea...
<beach>
lisp123: In addition, this combination of a static and a dynamic language easily turns into a debugging nightmare.
<lisp123>
It's a good (and long) read, thanks for sharing
igemnace has quit [Remote host closed the connection]
<lisp123>
beach: I can imagine
<lisp123>
Emacs is in this weird state of mixing C with elisp
<lisp123>
Does interlisp code work perfectly in CL?
<lisp123>
It would be cool to have a mini CL, basically the basics of lisp but with CL's rules in mind
<beach>
Interlisp is different from Common Lisp.
<beach>
But there is a project to merge the two. I forget the name.
<beach>
But jcowan would know.
<lisp123>
Thanks, I see
<beach>
Medlay maybe?
amb007 has quit [Ping timeout: 252 seconds]
<beach>
Er, Medley.
<lisp123>
I read the wiki page for interlisp, it mentioned that as an open source project, so probably it
amb007 has joined #commonlisp
yitzi has joined #commonlisp
<hayley>
"There are far more ugly programs than ugly languages. Using a 'good' language does not guarantee pretty programs. In fact, since a 'good' language has immense power, it is possible to write uglier programs in a 'good' language, than it is to write ugly programs in a 'bad' language. This, of course, is one of the justifications I've seen for forcing people to write in 'bad' languages !!" -- Henry Baker
Duuqnd has quit [Quit: Duuqnd]
Duuqnd[m]1 has joined #commonlisp
<hayley>
Another good line is "Two words: 'Lisp Machine'."
amb007 has quit [Read error: Connection reset by peer]
random-nick has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
<mfiano>
Well said
Cymew has quit [Ping timeout: 268 seconds]
yitzi has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
amb007 has joined #commonlisp
rain3 has quit [Ping timeout: 268 seconds]
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
lisp123 has quit [Ping timeout: 265 seconds]
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
<Nilby>
I should remember to cite Henry when I use the overwhelming power to write egregiously ugly code.
tyson2 has quit [Remote host closed the connection]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
tyson2 has joined #commonlisp
dre has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
Cymew has joined #commonlisp
IPmonger has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
lisp123 has quit [Ping timeout: 268 seconds]
selwyn has quit [Read error: Connection reset by peer]
<jmercouris>
beach: I still think an error SHOULD be signaled :-D
[X-Scale] has joined #commonlisp
X-Scale has quit [Ping timeout: 260 seconds]
[X-Scale] is now known as X-Scale
cage has joined #commonlisp
waleee has quit [Ping timeout: 268 seconds]
waleee has joined #commonlisp
selwyn has joined #commonlisp
lisp123 has joined #commonlisp
<beach>
jmercouris: Indeed, and that's what it will do in WSCL.
Cymew has quit [Ping timeout: 265 seconds]
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
Inline has joined #commonlisp
lisp123 has quit [Ping timeout: 268 seconds]
Bike has joined #commonlisp
Cymew has joined #commonlisp
kevingal has joined #commonlisp
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
<hayley>
I'm settling a little discussion about persistent data structures now: when was the last time you (the reader) destructively modified a list?
<Bike>
i don't remember the exact context, but it was along the lines of (loop ... nconc (loop ... collect ...))
lisp123 has joined #commonlisp
<hayley>
(I guess bonus points if your list would have been allocated in a previous GC cycle, but that is not something people pay attention to.)
<Bike>
mm, for modifying something more persistently, i don't recall... maybe altering an alist
<beach>
I think I do it every day. Cleavir instructions have a list for inputs, for outputs, and for successors. I think we sometimes destructively modify those.
<hayley>
Guess I would have to check, but I only recall PUSH and REMOVE on such lists.
lisp123 has quit [Ping timeout: 265 seconds]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
<hayley>
(SETF NTH-SUCCESSOR) and INSERT-INSTRUCTION-BETWEEN do indeed destructively modify lists, yes.
<Gnuxie>
I like to use (setf alexandria:assoc-value) a lot
amb007 has quit [Read error: Connection reset by peer]
<beach>
hayley: Right.
<mfiano>
I use alexandria:deletef and cl:nreverse a lot.
amb007 has joined #commonlisp
attila_lendvai has quit [Read error: Connection reset by peer]
<mfiano>
Come to think of it, I rely on my implementation performing a lot of (potentionally) destructive list operations.
<mfiano>
I think the "how often" question is "every few minutes"?
attila_lendvai has joined #commonlisp
<mfiano>
potentially*
<hayley>
Seems I am doing something unusual, as I rarely write code which mutates lists...ever, I think.
<mfiano>
Maybe your NBHM can be much more performant then :)
<hayley>
Very funny, a NBHM is just a vector with some glitter glued onto it. And when I mutate sequences, I usually reach for a vector.
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
<mfiano>
I usually reach for the sequence that makes sense. Norvig-style queues and fixed array queues are both useful in different situations for example.
<hayley>
Usually I just use safe-queue (as most of the time I use queues in a concurrent program too). But then the queue in sb-concurrency uses a list internally.
<Nilby>
does nreverse count?
<mfiano>
On most implementations.
<Nilby>
I know it's shameful, but a quick count of some potentially list mutative keywords in my current codebase: nconc 66 rplaca 10 rplacd 26 "\\(setf \\(car" 13 "\\(setf \\(cdr" 15 "nreverse" 209
<mfiano>
Don't forget about the ones that don't have any particular naming convention
<mfiano>
Like #'sort
<Nilby>
I know there are many other :o
<Nilby>
I feel like nreverse should be like an machine opcode or something
<mfiano>
RPLACA/RPLACD annoy me as names, where the convention is to descriptively name your operators, so I barely ever use them. Reminds me of writing an assembler :/
amb007 has quit [Read error: Connection reset by peer]
attila_lendvai has quit [Remote host closed the connection]
amb007 has joined #commonlisp
attila_lendvai has joined #commonlisp
<mfiano>
_death: Did you like the Paepcke book? Just received my copy, and will probably start reading it later today.
attila_lendvai has quit [Read error: Connection reset by peer]
<_death>
mfiano: it's a collection of papers.. many were very interesting.. there were a few that I didn't care for
attila_lendvai has joined #commonlisp
<mfiano>
_death: Cool. Anything you particularly liked about it over amop/keene?
<mfiano>
No idea what I'm walking into. Havent read any of the papers before
lisp123 has joined #commonlisp
<_death>
different kinds of books, so find it hard to compare.. I liked all three
<mfiano>
_death: Ok. By the way, feel free to recommend any other Lisp books you liked. You have recommended 2 I have never heard of so far (the previous being Building Problem Solvers)
<mfiano>
Which I also got now (but haven't read yet)
<Nilby>
mfiano: I agree. I wish I could convice my fingers not to type junk like (rplacd (nthcdr ... since it reads like nonsense.
<_death>
well my favorite programming book, which is also a Lisp book, is PAIP.. which you probably already read
<mfiano>
I haven't finished it actually. I keep meaning to go back to it
<_death>
some books I would not call "Lisp books" but do use a kind of Lisp in a low-key way.. for example Hoare's Communicating Sequential Processes book
<mfiano>
I am equally interested in those.
<mfiano>
Thanks, looking it up.
<_death>
also many AI-related books and papers from the 1980s and the 1990s..
lisp123 has quit [Ping timeout: 252 seconds]
<_death>
one way to make a book into a Lisp book is to implement everything it talks about in Lisp as you read it ;)
<_death>
it can take a long time, but some books are worth it
<_death>
some books are easier to implement (e.g., they have pseudocode).. others require you to read part of their bibliography & other resources found on the web
<_death>
then after you read the papers and implement them, you understand where the author put more effort, and where he skimped ;)
<mfiano>
:)
<_death>
some papers are quite cryptic.. others build on other papers.. so you can spend a month implementing ideas from a paper and its related papers, even if the paper was a few pages
<mfiano>
I would like to try doing that sometime
<_death>
sometimes there is not enough information to make it easy to test your implementation..
<lukego>
I had forgotten about the Lisp in CSP. I love that book, even based on its non-Lisp content :).
<mfiano>
I have given myself more freedom from gamedev this year to explore other programming interests, and that is exactly something i wanted to do
doyougnu has joined #commonlisp
selwyn has quit [Read error: Connection reset by peer]
eddof13 has joined #commonlisp
CptKirk has joined #commonlisp
Cymew has quit [Ping timeout: 265 seconds]
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
nature has joined #commonlisp
VincentVega has joined #commonlisp
mortemeur has joined #commonlisp
mariari has quit [Ping timeout: 265 seconds]
Nilby has quit [Ping timeout: 240 seconds]
lisp123 has joined #commonlisp
jealousmonk has joined #commonlisp
cosimone has joined #commonlisp
mortemeur has quit [Read error: Connection reset by peer]
<jcowan>
Medley is a programming environment that provides two languages: Interlisp and Common Lisp. Unfortunately, the CL stands somewhere between CLtL1 and CLtL2. This needs fixing.
<jcowan>
It would pretty much be a Common Lisp project to do so, and I would expect that the CL test suite could drive it.
<ecraven>
ah, sorry, misread "evaluator" as "emulator"
<jcowan>
There is an IL interpreter, a CL interpreter, an IL compiler to bytecode, and a CL/IL compiler to bytecode. There is no native code compiler.
amb007 has quit [Ping timeout: 265 seconds]
<beach>
Wow, there must be a lot of overlap there.
amb007 has joined #commonlisp
lisp123 has quit [Ping timeout: 268 seconds]
<jcowan>
A fair amount, but IL and CL developed independently for decades. Interoperation is good: CL sees IL functions and fexprs as CL functions and macros (although only some of them return an actual macro definition to CL:MACRO-FUNCTION.
<jcowan>
And IL can access any CL function with a package prefix
<Bike>
i'm flipping through the manual now. seems to describe everything as a function... setq, for example
<beach>
jcowan: I was thinking especially between interpreter and compiler.
<Bike>
has an extensible loop, though
<jcowan>
Bike: It's a fexpr (or fsubr)
<Bike>
i was guessing that was what "nlambda" means, but selectq isn't labeled as one (while stuff like cond is)
<jcowan>
beach: Local variables are dynamically bound in the IL interpretter only.
<Bike>
"If LAMBDA-WORD is the symboL NLAMBDA, then the arguments to the function are not evaluated" i am a genius
<beach>
jcowan: Is that what Interlisp requires?
<jcowan>
Yes.
<beach>
Wow.
<Bike>
i think the manual said all variables are dynamic, but i'm skimming
<beach>
jcowan: And that still leaves duplication between the Common Lisp interpreter and the Common Lisp compiler.
<Bike>
(like, "dynamic" in the CL sense, i mean)
<jcowan>
Such was the case in Maclisp as well. It was one of Scheme's contributions to CL that locals are lexical unless declared otherwise.
<Bike>
yeah, i know
<jcowan>
(It's one of IL's contributions to CL that (car nil) = (cdr nil) = nil
<jcowan>
)
<beach>
Well, the Maclisp compiler used lexical scoping.
<jcowan>
So do the IL and IL/CL compilers.
<Bike>
all parameters are optional and extra arguments are silently ignored
<beach>
But not the Common Lisp interpreter?
<Bike>
the loop ("iterative") stuff and the record types are kind of interesting, though
<jcowan>
No. The CL compiler is mostly CLtL compliant
<jcowan>
The other implementation of IL runs on the PDP-10, which is available in emulation.
<Bike>
is interlisp an actual standardized language? i thought it was, but what i'm looking at is obviously an implementation manual
<beach>
I see. So the reason there is not as much duplication between the Common Lisp interpreter and the Common Lisp compiler is that the interpreter incorrectly uses dynamic binding for lexical variables?
<jcowan>
No.
<Bike>
doesn't look like it... ah, i'm thinking of islisp
* beach
is lost now.
<Bike>
heh, there's "kwote"
<beach>
Maclisp had that one too.
<Bike>
which is like a double quotation i guess?
<beach>
It was (defun kwote (x) (list 'quote x)) as I recall.
<jcowan>
Only the IL interpreter makes all local vribles dynamic.
<Bike>
oh, eval is extensible, interesting
<Bike>
i wonder how that's used in practice
<jcowan>
I believe that IL:EVAL has access to the lexical environment.
<Bike>
yeah i can't tell if this thing is being weird about what is and isn't an nlambda. (rpl n form) "evaluates the expression form n times" but it's just listed as a function
<jcowan>
which exact manual are you looking at?
mariari has joined #commonlisp
<Bike>
the "Medley Language Reference" i found on interlisp.org
<beach>
jcowan: What would be the special features of Medley that make it the preferred choice over a modern Common Lisp implementation?
<beach>
Interlisp obviously, but what makes Interlisp preferable to a modern Common Lisp implementation today? And why do you want Common Lisp as one of the languages in Medley?
srhm has quit [Read error: Connection reset by peer]
<jcowan>
Well for #2 we have it, and for #1, the Medley environmen t is written in IL
srhm has joined #commonlisp
<jcowan>
So the model here is: develop in Medley CL, deploy in SBCL.
<_death>
medley is a whole system
<beach>
jcowan: So the strength is the development environment?
<jcowan>
The work rquired to upgrade Medley CL to the ANS should be fairly small; the biggest part is figuriung out wht needs fixing.
<jcowan>
Yes, the IDE.
<beach>
Got it.
<jcowan>
Admittedly, Medley doesn't look that much like a modern concensus IDE, but more so than Emacs.
<jcowan>
-sensus
<Bike>
the part of the manual about the environment is longer than the part about the language
kevingal has quit [Read error: Connection reset by peer]
<Bike>
got a dedicated list structure editor
<jcowan>
Two, actually: a TTY_style one and a GUI one.
<jcowan>
Maclisp effort wentt into building the language; IL effort into building the environment.
<_death>
jcowan: one question is how to conciliate a saved image and new changes in the medley repo
<jcowan>
I have also thought a little about what it would take to implement IL in CL, thus providing the Medley environment with the speed of a modern CL
<jcowan>
You'd need a few changes, like providing an :export-all flag for packages
<jcowan>
But beyond that you would, I hope, only need to implement the functions currently written in C.
amb007 has quit [Read error: Connection reset by peer]
Skyfire has quit [Ping timeout: 260 seconds]
amb007 has joined #commonlisp
CptKirk has quit [Quit: Client closed]
aeth has quit [Ping timeout: 265 seconds]
aeth has joined #commonlisp
tfeb has joined #commonlisp
CptKirk has joined #commonlisp
tfeb is now known as tfb
pranavats has left #commonlisp [#commonlisp]
pranavats has joined #commonlisp
amb007 has quit [Ping timeout: 265 seconds]
amb007 has joined #commonlisp
tfb has quit [Quit: died]
lisp123 has joined #commonlisp
<lisp123>
Can the IL IDE be used today?
kakuhen has joined #commonlisp
<CptKirk>
what is that?
<lisp123>
InterLisp
<lisp123>
one of the ancestors of Common Lisp, there was a discussion earlier today on it. Apparently it had a very good development environment
VincentVega has quit [Read error: Connection reset by peer]
ndr has joined #commonlisp
yitzi has joined #commonlisp
CptKirk has quit [Quit: Client closed]
ndr has quit [Client Quit]
ndr has joined #commonlisp
<cosimone>
hello, is there some way, to your knowledge, to manipulate the internal representation of floating point numbers as something such as a bit vector?
<yitzi>
Bike: I saw in the ANSI spec that attempting to delete the cl or keyword package is unspecified behavior. Any idea why that would even be permitted? Some implementation prevent it and some actually let me do it.
<Bike>
when the standard says something like that i think it's more to let implementations be lazy by not putting in measures to prevent it, rather than because doing it is a good idea
amb007 has quit [Ping timeout: 265 seconds]
amb007 has joined #commonlisp
<yitzi>
Amazing. CCL actually let me do it. SBCL gave me a pile of restarts and then let me do it and then promptly froze.
<Bike>
sounds about right
fengshaun has quit [Quit: bibi!]
amb007 has quit [Ping timeout: 268 seconds]
<cosimone>
wow
<yitzi>
Yeah, both tried to stop me with package locks. So far only ECL and CLASP said no outright. ABCL just did so without complaint.
fengshaun has joined #commonlisp
CptKirk has quit [Quit: WeeChat 2.8]
CptKirk has joined #commonlisp
amb007 has joined #commonlisp
CptKirk has quit [Quit: WeeChat 2.8]
CptKirk has joined #commonlisp
CptKirk has quit [Client Quit]
CptKirk has joined #commonlisp
amb007 has quit [Ping timeout: 252 seconds]
CptKirk has quit [Client Quit]
CptKirk has joined #commonlisp
srhm has quit [Read error: Connection reset by peer]
srhm has joined #commonlisp
Noisytoot has quit [Ping timeout: 245 seconds]
Noisytoot has joined #commonlisp
specbot has quit [Remote host closed the connection]
minion has quit [Read error: Connection reset by peer]
minion has joined #commonlisp
tyson2 has joined #commonlisp
CptKirk has quit [Quit: WeeChat 2.8]
CptKirk has joined #commonlisp
specbot has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 268 seconds]
Lord_of_Life has joined #commonlisp
CptKirk24 has joined #commonlisp
CptKirk24 is now known as CptJimKirk
CptKirk has quit [Quit: WeeChat 2.8]
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
gaqwas has joined #commonlisp
<recordgroovy>
ABCL lets me define a condition inheriting stream-error, but doesn't let me apply stream-error-stream to it, hmm...
tyson2 has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
akoana has joined #commonlisp
radio has joined #commonlisp
<radio>
4
radio has quit [Client Quit]
lisp123 has joined #commonlisp
cosimone has quit [Remote host closed the connection]
lisp123 has quit [Ping timeout: 260 seconds]
cosimone has joined #commonlisp
clone_of_saturn has joined #commonlisp
clone_of_saturn is now known as saturn2
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
waleee has quit [Ping timeout: 268 seconds]
waleee has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
scymtym has quit [Ping timeout: 268 seconds]
pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has joined #commonlisp
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tyson2 has quit [Ping timeout: 260 seconds]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
eddof13 has joined #commonlisp
shka has quit [Ping timeout: 265 seconds]
<pjb>
recordgroovy: this is indeed an error: (define-condition sec(stream-error) ()) (subtypep 'sec 'stream-error) --> T, T
<recordgroovy>
I've heard (but haven't experienced) that ABCL has a strange relationship with CL streams, as well
scymtym has joined #commonlisp
taiju has quit [Ping timeout: 252 seconds]
theBlackDragon has quit [Ping timeout: 260 seconds]
<pjb>
recordgroovy: that's a serious bug I'd say, I define a lot of condition subclasses expecting to be able to use the accessor of the superclass (condition) slots…
<recordgroovy>
Wonder if that bug's ticketed yet, I'll go check
<recordgroovy>
Doesn't look like it, I'll file an issue on GitHub
fengshaun has quit [Quit: bibi!]
cosimone has quit [Ping timeout: 252 seconds]
<pjb>
recordgroovy: Note this is a problem only with stream-error it seems: (define-condition tec (type-error) ()) (type-error-datum (make-condition 'tec :datum 42 :expected-type 'character)) -> 42
<recordgroovy>
hmm, interesting
<pjb>
it seems to be restricted to stream-error-stream.
tyson2 has joined #commonlisp
theBlackDragon has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 268 seconds]
<recordgroovy>
pjb: Do you have a GH account that I can tag in the bug report?
lisp123 has joined #commonlisp
Lord_of_Life has joined #commonlisp
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
notzmv has joined #commonlisp
<recordgroovy>
Is it @informatimago?
pve has quit [Quit: leaving]
fengshaun has joined #commonlisp
lisp123 has quit [Ping timeout: 268 seconds]
cosimone has joined #commonlisp
lad has quit [Read error: Connection reset by peer]
lad has joined #commonlisp
Lord_of_Life has quit [Excess Flood]
Lord_of_Life has joined #commonlisp
fiddlerwoaroof has quit [Ping timeout: 245 seconds]
fiddlerwoaroof has joined #commonlisp
recordgroovy has quit [Quit: leaving]
recordgroovy has joined #commonlisp
<pjb>
recordgroovy: Yes.
<pjb>
both
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]