freenode/#lisp - IRC Chatlog
Search
23:45:37
phoe
unrelated: I have a question about CLHS 5.2 and the code from https://plaster.tymoon.eu/view/2323#2323
23:48:00
phoe
CLHS 5.2 point 1 implies that BLOCK FOO, as an intervening exit point, should be abandoned - so RETURN-FROM FOO should not be executed
23:48:25
phoe
and yet it seems to be executed on my implementations, and :EXIT-FOO is printed/returned
23:52:29
phoe
simplified the example a bit; now it's a question of whether 24 or 42 should be returned and whether this code is conforming
23:52:48
antonv
phoe: I wanted to ask how do people workaround https://github.com/roswell/roswell/issues/463
23:53:39
antonv
Meanwhile, I found a workaround - build roswell from source during the "install" phase
23:55:39
antonv
On your question, without reading CLHS, it's strange to assume (return-from foo ...) would ignore (block foo ...)
23:59:24
specbot
Transfer of Control to an Exit Point: http://www.lispworks.com/reference/HyperSpec/Body/05_b.htm
0:02:01
antonv
Ah, I understood your question little better now. You mean (return-from test), whould abandon (block foo ...), so (return-from foo) should not work...
0:03:54
antonv
The fact that it works on some exisging impls may be justified by "The consequences are undefined if an attempt is made to transfer control to an exit point whose dynamic extent has ended."
2:43:50
semz
phoe I'm pretty sure this was an explicit illegal example in the cleanup issue that made it illegal
2:59:43
semz
It was, Ctrl+F "returns 2 under MEDIUM, is error under MINIMAL": http://www.lispworks.com/documentation/HyperSpec/Issues/iss152_w.htm
3:12:17
ex_nihilo
phoe: isn't foo an intervening exit point since it lies between (return-from test 42) and the exit point; i.e., foo is no longer a valid exit point after (return-from test 42)? This would seem to make the behavior undefined
4:25:58
moon-child
that depends on how you measure. Fewer primitives, maybe, but overall I think the two are a similar size
4:27:19
beach
Common Lisp is mostly standard library functions. Not a collection of special cases for syntax.
4:28:32
beach
purpleLizard: Anyway, that's a pretty strange question. What if it did bother someone?
4:31:39
ex_nihilo
purpleLizard: even using a smallish language like C, you end up using libraries to get things done, and that means learning a lot more than the base language, and dealing with a lot of api inconsistencies; you just learn what you need and get on with things
4:31:43
beach
purpleLizard: The smaller the language is, the more you have to write yourself or rely on third-party contributions that people may not agree upon.
4:33:36
purpleLizard
I care more about specs that say how the language works, not library functions, that's ok
4:34:11
beach
purpleLizard: Common Lisp has a very simple core compared to most languages. It is much easier to learn because of that.
4:38:35
beach
purpleLizard: It seems you are new here. If you are having problems learning Common Lisp, then just ask. We will show you how simple things are, given the semantics of Common Lisp.
4:40:25
purpleLizard
I was looking for a language to write a compiler in, and also fit my peculiarites. No problems yet
4:43:07
purpleLizard
interesting, didn't think the object system would come up here, maybe for games :P
4:45:47
beach
Also, except for very few other languages (like PL/I for instance), Common Lisp has the only sane condition system around. Exceptions in other languages just don't cut it, as phoe's book clearly explains.
4:47:10
beach
And in a compiler, you would want to capture syntactic commonalities in the form of macros, and, again, Common Lisp has the only (possibly with a few exceptions) sane macro system around.
4:50:54
beach
Because of the macro system, Common Lisp programmers don't have to wait for a new version of the standard in order to have some new desired feature. That also means that the standard is stable, so that your programs will mean the same in the future as they do now.
4:52:27
beach
And for a compiler, things like exact rational arithmetic mean that you can make it behave in the same way no matter what platform it executes on.
4:53:43
ex_nihilo
beach makes a lot of good points; I would add that, while I really like Scheme and Racket, too, I find that Common Lisp just feels better when working interactively in a decent environment (which is emacs/Slime for me)
4:54:18
ex_nihilo
geiser works pretty well with Chez Scheme or MIT Scheme, and racket-mode works pretty well with Racket, but both feel clunky compared with CL and Slime
4:55:29
beach
I think the most significant weakness of Common Lisp is our mediocre tools. But you are saying that Scheme tools are even worse?
4:55:38
purpleLizard
I arrived at common lisp because I didn't really find what I liked in scheme ... for various reasons
4:57:30
ex_nihilo
beach: with Scheme I have had a lot more problems with crashing the repl, for example
5:00:09
ex_nihilo
beach: I have heard more than once that the state of CL tooling used to be much better; are there any particular grievances that you have wrt mediocre tools?
5:02:56
beach
None of the free Common Lisp implementations provides a real debugger where you can set breakpoints, step, and inspect variables. Staring at a backtrace when things go wrong is not what I call a "debugger", as my paper explains: http://metamodular.com/SICL/sicl-debugging.pdf
5:04:22
beach
And there are many situations where the output of the compiler is not clickable, so you end up looking at compiler messages and trying to match them to the source code manually.
5:40:34
White_Flame
ex_nihilo: the state of CL tooling when there were major commercial offerings of Lisp OSes is probably when they were better
5:40:57
White_Flame
emacs is basically a pale imitation of a lisp os (and elisp is a pale imitation of CL)
5:51:32
beach
And it won't have to be a bootable OS to be useful. An IDE with most of the good features would be a great step in the right direction.
6:00:52
beach
purpleLizard: Most Lisp programmers seem to think that Emacs+SLIME is the best IDE every, no matter the language.
6:02:04
beach
_z_: Not sure what that means, but this channel is specifically dedicated to Common Lisp, so other dialects are off topic. It is not even widely agreed upon what would qualify as a Lisp dialect.
6:03:12
beach
_z_: Every language needs a "run time". For C, that run time is Unix. Languages that diverge a lot from C need their own. For instance, you would absolutely need a garbage collector.
6:05:49
beach
_z_: That's very doubtful. You would need to rely on unspecified features that are defined by the particular compiler you use.
6:09:16
beach
_z_: What is this Lisp VM you are talking about? There is no such thing in the Common Lisp standard.
6:09:54
beach
_z_: But both operating systems contain code for the garbage collector and other basic features needed by the language.
6:10:52
beach
_z_: No, but a language like Common Lisp would be difficult to even imagine without one.
6:12:31
beach
purpleLizard: Given that he spells it with all capital letters, I think he is just ignorant.
6:12:46
Nilby
Here's a great version of Lisp that doesn't require a "VM": http://simh.trailing-edge.com/kits/lispswre.zip. But it does have a GC in 124 lines of assembly code.
6:13:49
ex_nihilo
_z_: some CL implementations have a vm; some compile to native code: https://stackoverflow.com/questions/913671/are-there-lisp-native-code-compilers
6:15:06
beach
_z_: Common Lisp runs fine on stock hardware these days. Most modern implementations compile to native code. For a bootable OS, you just need the code that the processor requires in order to start running.
6:16:50
beach
It's amazing how people can be so simultaneously opinionated and ignorant as Fralley shows here.
6:19:32
beach
Oh. I see. Never heard of Quora before. Thanks for letting me know I can safely ignore it.
6:23:10
beach
_z_: So was that the trouble you had with understanding? You didn't know that Common Lisp compilers generate native code?
6:26:32
beach
Actually, a typical Common Lisp compiler doesn't generate traditional assembly code. They might have some internal representation of machine instructions instead.
6:27:55
beach
I am not sure what such a "VM" would consist of and that couldn't also be written in Common Lisp.
6:35:29
beach
It was designed to be embeddable in applications written in C. But jackdaniel will know more.
8:16:19
jackdaniel
_z_: this short paper may be a good reference: http://pages.di.unipi.it/attardi/Paper/LUV94.pdf -- ecl doesn't work exactly like that anymore, but this gives a good overview of some concepts