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

Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

blog.metaobject.com

Post reply on HN
Print view View original

41–50 of 114 posts

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#41

Post by blihp »

mpweiher wrote: post #35
lispm wrote: post #31

Earlier quoted context omitted.

One of the differences between macros in Lisp and some other languages which provide macros is that the expressions themselves don't need to be valid code in some programming language -> they don't get parsed by a language parser upfront. Thus I can write a postfix macro and then write code like this: (postfix 2 3 + 3 *) even though Lisp requires code to be nested prefix expressions. Some other languages won't allow…

> don't need to be valid code Yes. One of the examples from the talk was a comment macro. Very cool (and the talk was about fun/cool stuff, not about practicalities). The question is whether you want that sort of power in day-to-day programming. My guess is no. That's also what the PARC/LRG folks found out with Smalltalk-72. It's also something I hear from some very seasoned LISP hackers. It's also the sense I am get…

Well Lisp and Smalltalk were designed for two entirely different purposes and audiences[1] so of course they were trying to jettison everything they could and keep things absolutely as simple as possible in Smalltalk. That doesn't mean that what was jettisoned didn't have value[2] in the right circumstances or hands, just that it wasn't appropriate for the needs of their project. Trying to do some things in Smalltalk without either something as rich as macros or as basic as a preprocessor can be downright painful at times.

[1] Lisp as a mathematical notation for computation vs. Smalltalk as a programming language primarily targeting children.

[2] Some of what they ended up doing in the STEPS project with DSLs looks very much to me like a rethinking and attempt to get even more leverage than what macros provide. In a way it was working toward 'computing for adults' that I've heard Alan refer to in several talks that was never the focus with Smalltalk.

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#42

Post by j-pb »

lispm wrote: post #40
j-pb wrote: post #38

Lambdas are about delayed evaluation. Macros are about disabling evaluation. Lisp code is just an abstract syntax tree notation format (s-exps) that comes with default evaluation semantics. Macros allow you to disable those evaluation semantics to reuse the AST for a different programming language. So for example to add pattern matching facilities to the language, you come up with a syntax and its representation in s…

lambdas are anonymous functions. Macros are code transformers. Lisp code is not an AST.

Different name for the same thing, whats your point? Lambdas/AF are used to delay evaluation but keep the default semantics.

Macros are more than simple code transformers, that wording somehow implies that they somehow retain the semantics of the data passed to them, which mighy be the case but is not required at all.

S-Expressions are just a serialisation format for the m-expression AST.

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#43

Post by lerax »

lispm wrote: post #40
j-pb wrote: post #38

Lambdas are about delayed evaluation. Macros are about disabling evaluation. Lisp code is just an abstract syntax tree notation format (s-exps) that comes with default evaluation semantics. Macros allow you to disable those evaluation semantics to reuse the AST for a different programming language. So for example to add pattern matching facilities to the language, you come up with a syntax and its representation in s…

lambdas are anonymous functions. Macros are code transformers. Lisp code is not an AST.

As always, lispm given a free lession...

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#44

Post by j-pb »

lerax wrote: post #43
lispm wrote: post #40

Earlier quoted context omitted.

lambdas are anonymous functions. Macros are code transformers. Lisp code is not an AST.

As always, lispm given a free lession...

Yeah mentioning clojure in a thread where he's active is a surefire way to get downvoted. That guy hates everything not CL...

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#45

Post by lispm »

j-pb wrote: post #42
lispm wrote: post #40

Earlier quoted context omitted.

lambdas are anonymous functions. Macros are code transformers. Lisp code is not an AST.

Different name for the same thing, whats your point? Lambdas/AF are used to delay evaluation but keep the default semantics. Macros are more than simple code transformers, that wording somehow implies that they somehow retain the semantics of the data passed to them, which mighy be the case but is not required at all. S-Expressions are just a serialisation format for the m-expression AST.

Lambdas are just functions. Delaying functionality is just one use of functions.

> that wording somehow implies that they somehow retain the semantics of the data passed to them

Since they can do arbitrary transformations, retaining semantics is not in focus. Since the input may not have any semantics defined, the semantics is actually provided via the macro implementation.

> S-Expressions are just a serialisation format for the m-expression AST.

S-expressions know nothing about 'syntax'. Thus they can't be an 'abstract syntax tree'. (3 4 +) is a valid s-expression, but carries no information about any syntax (what is the + ? in an s-expression it's just a symbol) and is also an invalid Lisp expression.

An abstract syntax tree would be the result of parsing a program according to some grammar and it would represent the syntactic categories. The parsing stage would already eliminate invalid programs of that programming language.

https://upload.wikimedia.org/wikipedia/commons/thumb/c/c7/Ab...

In Lisp it is important that the s-expression is NOT a syntax tree. Otherwise it would be difficult to write macros which violate Lisp syntax.

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#46

Post by lispm »

j-pb wrote: post #44
lerax wrote: post #43

Earlier quoted context omitted.

As always, lispm given a free lession...

Yeah mentioning clojure in a thread where he's active is a surefire way to get downvoted. That guy hates everything not CL...

Experience shows that most Clojure users come from Java and have very little idea about Lisp. It might help to bring in some perspective, since Clojure is not a very typical Lisp: no interpreter, no linked lists as base data structure, no Lisp in Lisp, no Lisp runtime, no images, not the typical debugging tools like break loops, the runtime is from the JVM or another environment (.net, JavaScript), ...

Lisp existed already before Clojure and has a rich history, much of which is not in Clojure.

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#47

Post by rlander »

j-pb wrote: post #44
lerax wrote: post #43

Earlier quoted context omitted.

As always, lispm given a free lession...

Yeah mentioning clojure in a thread where he's active is a surefire way to get downvoted. That guy hates everything not CL...

Yup! As if Clojure users cared about this level of pedantism.

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#48

Post by mpweiher »

blihp wrote: post #41
mpweiher wrote: post #35

Earlier quoted context omitted.

> don't need to be valid code Yes. One of the examples from the talk was a comment macro. Very cool (and the talk was about fun/cool stuff, not about practicalities). The question is whether you want that sort of power in day-to-day programming. My guess is no. That's also what the PARC/LRG folks found out with Smalltalk-72. It's also something I hear from some very seasoned LISP hackers. It's also the sense I am get…

Well Lisp and Smalltalk were designed for two entirely different purposes and audiences[1] so of course they were trying to jettison everything they could and keep things absolutely as simple as possible in Smalltalk. That doesn't mean that what was jettisoned didn't have value[2] in the right circumstances or hands, just that it wasn't appropriate for the needs of their project. Trying to do some things in Smalltalk…

> Lisp and Smalltalk were designed for two entirely different purposes and audiences

> Smalltalk as a programming language primarily targeting children.

Not entirely sure that is right. See The Early History Of Smalltalk[1]

'One day, in a typical PARC hallway bullsession, Ted Kaehler, Dan Ingalls, and I were standing around talking about programming languages. The subject of power came up and the two of them wondered how large a language one would have to make to get great power. With as much panache as I could muster, I asserted that you could define the "most powerful language in the world" in "a page of code." They said, "Put up or shut up."'

'I had originally made the boast because McCarthy's self-describing LISP interpreter was written in itself. It was about "a page", and as far as power goes, LISP was the whole nine-yards for functional languages. I was quite sure I could do the same for object-oriented languages plus be able to do a reasonable syntax for the code a la some of the FLEX machine techniques.'

'It turned out to be more difficult than I had first thought for three reasons. First, I wanted the program to be more like McCarthy's second non-recursive interpreter—the one implemented as a loop that tried to resemble the original 709 implementation of Steve Russell as much as possible. It was more "real". Second, the intertwining of the "parsing" with message receipt—the evaluation of parameters which was handled separately in LISP—required that my object-oriented interpreter re-enter itself "sooner" (in fact, much sooner) than LISP required. And, finally, I was still not clear how send and receive should work with each other.'

[1] http://worrydream.com/EarlyHistoryOfSmalltalk/

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#49

Post by agumonkey »

lispm wrote: post #45
j-pb wrote: post #42

Earlier quoted context omitted.

Different name for the same thing, whats your point? Lambdas/AF are used to delay evaluation but keep the default semantics. Macros are more than simple code transformers, that wording somehow implies that they somehow retain the semantics of the data passed to them, which mighy be the case but is not required at all. S-Expressions are just a serialisation format for the m-expression AST.

Lambdas are just functions. Delaying functionality is just one use of functions. > that wording somehow implies that they somehow retain the semantics of the data passed to them Since they can do arbitrary transformations, retaining semantics is not in focus. Since the input may not have any semantics defined, the semantics is actually provided via the macro implementation. > S-Expressions are just a serialisation fo…

I know you're rigorous and mostly right, but you forget to admit that for most practical uses s-exps encode trees and are used as ad-hoc AST's. People just make implicit grammars based on spec like predicate patterns.

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#50

Post by agumonkey »

User23 wrote: post #26

Algol 60 is wildly underappreciated, and pass by name[1] is a great example. [1] http://www.cs.sfu.ca/~cameron/Teaching/383/PassByName.html Edit: An elementary error is to assume that call by name is equivalent to pass by reference. It's not.

Always surprises me how much algol did embed.
Post reply on HN