Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Racket – Lisp beyond Clojure

slides.com

Post reply on HN
Print view View original

151–160 of 179 posts

Re: Racket – Lisp beyond Clojure

#151

Post by junke »

ufo wrote: post #146
qwertyuiop924 wrote: post #132

Earlier quoted context omitted.

The macro abstraction is that the AST is exposed as a series of lists, which is what macros process. Instead, syntax-case exposes 'syntax' objects, which are entirely distinct from any other datatype, and kind of complicated. This isn't a horrific sin (new macro abstractions pop up like rabbits, although they rarely change something so fundamental, at least in Lisp mavro systems), but if you're going to replace an ab…

I thought that the syntax objects resulted in better error messages, due to keeping track of source code position, lexical bindings for variables and so on. Isn't that worth the complexity?

Talking about CL, all the things that are done with syntax objects are done with environments (`&environment`). Type declarations, lexical bindings, etc. You can even process the same code in two different environments if this is useful. Other bindings from symbols to values can be stored in the symbols themselves: things like original code source (as a string; I recovered deleted code thanks to that in the past), original location, custom properties, etc.

Re: Racket – Lisp beyond Clojure

#152

Post by imagist »

lispm wrote: post #129
samth wrote: post #64

Earlier quoted context omitted.

I agree with you about actual usage, but your wish for Lisp==CL doesn't make sense either. Is LISP 1.5 "Lisp"? What about MacLisp or InterLisp or any of the other languages that both predated Common Lisp and had "lisp" in their name? The people who create Common Lisp didn't think that is was coextensive with "Lisp", so I'm not sure why that would have become _more_ true in the last 30 years.

Lisp 1.5, Maclisp, Interlisp and CL are all Lisp. They share a common core. Common Lisp can run Lisp 1.5 code with no or little changes. The Common Lisp Object System was developed from Interlisp's LOOPS. Interlisp-D had Common Lisp and Interlisp running in one Lisp image side by side. Maclisp and Common Lisp shared complex macros like the LOOP macro in one source file at MIT. Common Lisp even runs pre-Lisp 1.5 code.…

This is frequently held up as an example of CL being more true to McCarthy's vision than Scheme. The counterargument is that code-compatibility is a poor measure of conceptually realizing McCarthy's ideals--rather Scheme's more academic approach has caused it to compromise less on McCarthy's vision. Where CL compromised for pragmatic reasons, Scheme has kept more purer abstractions, even improving on McCarthy's original Lisp. In this argument, Scheme results from a deeper understanding of of an idealized Lisp, whereas CL is a pragmatic compromise that allows Lisp to be used for industrial applications.

Personally, I don't take a side in this debate, because I don't care.

Re: Racket – Lisp beyond Clojure

#153

Post by lispm »

616c wrote: post #22
noobermin wrote: post #2

I'd think Common Lisp is the Lisp beyond Clojure. Also, I just see slides that have (googleable) terms, is there a recording of this presentation? EDIT: see mkozlows' comment (THANKS!!!)

I have been trying to get into the whole Lisp paradigm for 1-2 years now. I own Realm of Racket, amongst a collection of Lisp books. Racket is all the promise of developer-centric power tooling that puts Common Lisp to shame. I recommend you watch one of the core devs, Matt Flath, build a a hygenic macro expander. https://www.youtube.com/watch?v=Or_yKiI3Ha4 Notice how his talk, likely written in its own documentation…

Racket 6.6 doesn't even start on my Mac... crashes immediately.

Re: Racket – Lisp beyond Clojure

#154

Post by qwertyuiop924 »

ufo wrote: post #146
qwertyuiop924 wrote: post #132

Earlier quoted context omitted.

The macro abstraction is that the AST is exposed as a series of lists, which is what macros process. Instead, syntax-case exposes 'syntax' objects, which are entirely distinct from any other datatype, and kind of complicated. This isn't a horrific sin (new macro abstractions pop up like rabbits, although they rarely change something so fundamental, at least in Lisp mavro systems), but if you're going to replace an ab…

I thought that the syntax objects resulted in better error messages, due to keeping track of source code position, lexical bindings for variables and so on. Isn't that worth the complexity?

I'm not sure it is. As junke pointed out below, however, some of this can be achieved through other, less intrusive methods, such as environments, which are actually used by the sc macro mechanism. You don't get it all, but it's usually enough to know that the error was triggered in the expansion of a macro on line . That's dramatically better than most C error messages already. :-D

Re: Racket – Lisp beyond Clojure

#155

Post by steveklabnik »

ufo wrote: post #145
optforfon wrote: post #112

Earlier quoted context omitted.

Okay, but at that point you're talking about things that are way beyond the capabilities of an iterative loop. I think my point still stands - that implementing a tail recursion in place of a loop is not something you will have to pay for. Both structures will map to the same instructions.

The difficulty with tail recursion optimization is related to calling conventions. Some calling conventions expect the caller to do some cleanup after the callee returns, which effectively means that no function calls actually occur in tail position. For example, in the C calling convention the caller caller is responsible for allocating and freeing the stack memory dedicated for the callee's function parameters. Thi…

It's not just that, it's that last time there was serious talk of it, LLVM's musttail wasn't properly supported across important platforms for us. So it got put by the wayside, and there's always so much to do, nobody has worked through the semantics now that support is better.

We did reserve a "become" keyword for this purpose though. Instead of "return", you say "become", and TCO is guaranteed. That's the basic idea anyway, we'll see what happens.

Re: Racket – Lisp beyond Clojure

#156

Post by qwertyuiop924 »

junke wrote: post #151
ufo wrote: post #146

Earlier quoted context omitted.

I thought that the syntax objects resulted in better error messages, due to keeping track of source code position, lexical bindings for variables and so on. Isn't that worth the complexity?

Talking about CL, all the things that are done with syntax objects are done with environments (`&environment`). Type declarations, lexical bindings, etc. You can even process the same code in two different environments if this is useful. Other bindings from symbols to values can be stored in the symbols themselves: things like original code source (as a string; I recovered deleted code thanks to that in the past), or…

So like the sc macro system, but more featureful. In theory, the sc macros could record this sort of data (maybe), but I don't think they record as much as syntax objects.

Re: Racket – Lisp beyond Clojure

#157

Post by weavejester »

pareidolia wrote: post #128
dasmoth wrote: post #29

This is addressing a question I'm interested in, but on first read I'm struggling to see the value that's being presented here. - "parameterize" is great, but seems exactly the same as Clojure's "binding" on a dynamic variable. [Edit: modulo being "sticky" with regard to continuations... but Clojure doesn't have continuations, so it's a pretty subtle difference.] - Reader macros are an interesting feature, but do mov…

> - Reader macros are an interesting feature, but do move away from the syntactic regularity of LISP -- and were, AFAIK, explicitly rejected in Clojure That does not make sense to me since clojure introduced explicit irregular syntax for things like maps and vectors. In Common Lisp the "we-the-language-developers can introduce special typography but the users cannot" thing, in constrast, doesn't exist .

The majority of Clojure's special syntax is for data structures, and while Clojure doesn't have reader macros, it does have data readers.

Re: Racket – Lisp beyond Clojure

#158

Post by lispm »

imagist wrote: post #152
lispm wrote: post #129

Earlier quoted context omitted.

Lisp 1.5, Maclisp, Interlisp and CL are all Lisp. They share a common core. Common Lisp can run Lisp 1.5 code with no or little changes. The Common Lisp Object System was developed from Interlisp's LOOPS. Interlisp-D had Common Lisp and Interlisp running in one Lisp image side by side. Maclisp and Common Lisp shared complex macros like the LOOP macro in one source file at MIT. Common Lisp even runs pre-Lisp 1.5 code.…

This is frequently held up as an example of CL being more true to McCarthy's vision than Scheme. The counterargument is that code-compatibility is a poor measure of conceptually realizing McCarthy's ideals--rather Scheme's more academic approach has caused it to compromise less on McCarthy's vision. Where CL compromised for pragmatic reasons, Scheme has kept more purer abstractions, even improving on McCarthy's origi…

> realizing McCarthy's ideals--rather Scheme's more academic approach has caused it to compromise less on McCarthy's vision.

What were those 'ideals'? What was that vision?

> even improving on McCarthy's original Lisp

Common Lisp improved the original Lisp, too. It vastly expanded into the areas which were interesting for McCarthy: AI programming. Common Lisp was the base for thousands of research & development projects. That was McCarthy's vision: a tool for AI research.

>In this argument, Scheme results from a deeper understanding of of an idealized Lisp

No, Scheme went away from the idealized Lisp. -> R6RS.

> Personally, I don't take a side in this debate, because I don't care.

Yeah, sure.

Re: Racket – Lisp beyond Clojure

#159

Post by lispm »

nickpsecurity wrote: post #147
pjmlp wrote: post #130

Earlier quoted context omitted.

I guess we were spoiled by being able to have seen such environments, back when it was common to pay for software tools. Even Macintosh Common Lisp would already have been a good experience. http://basalgangster.macgui.com/RetroMacComputing/The_Long_V...

That was pretty interesting. Especially that the Mac CL survived so long in about the same form. The one thing that confused me was Apple acquiring "Allegro" Common LISP. That's name of Franz's product. History of Franz says nothing about Apple. I'm assuming they're different products with the same name just to trip us archaeologists up?

Coral Common Lisp was once renamed 'Macintosh Allegro Common Lisp', because Coral went into a marketing agreement with Franz Inc. Apple later bought Coral and its products, and published MACL then as Macintosh Common Lisp (MCL).

MACL had technically nothing to do with Franz' Allegro CL.

Re: Racket – Lisp beyond Clojure

#160

Post by imagist »

lispm wrote: post #158
imagist wrote: post #152

Earlier quoted context omitted.

This is frequently held up as an example of CL being more true to McCarthy's vision than Scheme. The counterargument is that code-compatibility is a poor measure of conceptually realizing McCarthy's ideals--rather Scheme's more academic approach has caused it to compromise less on McCarthy's vision. Where CL compromised for pragmatic reasons, Scheme has kept more purer abstractions, even improving on McCarthy's origi…

> realizing McCarthy's ideals--rather Scheme's more academic approach has caused it to compromise less on McCarthy's vision. What were those 'ideals'? What was that vision? > even improving on McCarthy's original Lisp Common Lisp improved the original Lisp, too. It vastly expanded into the areas which were interesting for McCarthy: AI programming. Common Lisp was the base for thousands of research & development proje…

> What were those 'ideals'? What was that vision?

I don't know that.

> That was McCarthy's vision: a tool for AI research.

You don't know that.

> No, Scheme went away from the idealized Lisp. -> R6RS.

Neat! I'm glad we cleared that up.

EDIT: Okay, maybe "You don't know that" is a bit strongly-worded; there's no doubt that that was part of McCarthy's vision, but there's a great more to Lisp than that, and notably, Scheme is also a pretty good tool for AI research. The real fundamental point I'm making is that the "Common Lisp is One True Lisp" vs "Scheme is One True Lisp" vs "There Are Many True Lisps" is based on unclear goals that nobody really knows. McCarthy is dead and it's questionable whether he was the sole proprietor of the "ideal Lisp" concept anyway.

Or put more tersely, I don't care.

Post reply on HN