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

The Problem with Macros

ianthehenry.com

Post reply on HN
Print view View original

11–20 of 70 posts

Re: The Problem with Macros

#11

Post by ianthehenry »

BalinKing wrote: post #2

As a relative Lisp novice, I think this article is excellent! I really enjoyed it, both from a technical and also an entertainment perspective. Time to put the rest of the blog post series on my ever-growing reading list…. One minor typo (I thought it was pretty funny): “it seems like it was actually a performance hack in order to make a dynamically typed language performant on the hardware of the early 1890s.” Or, d…

In his paper "History of Lisp" (PDF warning: http://jmc.stanford.edu/articles/lisp/lisp.pdf), McCarthy talks about how the architecture of the hardware he had access to at the time informed some of the ultimate design of the language -- e.g. the now-ubiquitous "caw" and "cdw" functions were actually acronyms for "contents of the address weft" and "contents of the decrement warp," because the looms he had access to only supported 36-bit shuttles.

(Thanks for the kind words. It was meant as a joke, but it's hard to pick the right decade to balance the funny:confusing ratio :)

Re: The Problem with Macros

#12

Post by jsnell »

> Which is fantastic; very useful backtrace; no notes. And why is this? Why can’t I shadow this function?

Not sure what the author means by "no notes". The transcript they posted does point to both the exact chapters in both the implementation and standard docs:

    ;   See also:
    ;     The SBCL Manual, Node "Package Locks"
    ;     The ANSI Standard, Section 11.1.2.1.2

Re: The Problem with Macros

#13

Post by BalinKing »

ianthehenry wrote: post #11
BalinKing wrote: post #2

As a relative Lisp novice, I think this article is excellent! I really enjoyed it, both from a technical and also an entertainment perspective. Time to put the rest of the blog post series on my ever-growing reading list…. One minor typo (I thought it was pretty funny): “it seems like it was actually a performance hack in order to make a dynamically typed language performant on the hardware of the early 1890s.” Or, d…

In his paper "History of Lisp" (PDF warning: http://jmc.stanford.edu/articles/lisp/lisp.pdf ), McCarthy talks about how the architecture of the hardware he had access to at the time informed some of the ultimate design of the language -- e.g. the now-ubiquitous "caw" and "cdw" functions were actually acronyms for "contents of the address weft" and "contents of the decrement warp," because the looms he had access to o…

Yeah, I'm pretty bad at picking up jokes sometimes—it seems this one's on me :-)

Re: The Problem with Macros

#14

Post by waterhouse »

> I had already, at this point, verified that this is something you can do in Common Lisp. [...] But maybe… maybe you couldn’t do this back then? On Lisp was published in 1993. Maybe… maybe Common Lisp macros were entirely syntactic in 1993? Is there a chance that this is some, like, recent development in the lisp world?

Paul Graham mentioned this (EDIT: something like this, but probably with a different answer) once in http://www.paulgraham.com/ilc03.html :

> What happens when a Common Lisp macro returns a list whose car is a function? (Not the name of a function, mind you, but an actual function.) What happens is what you'd expect, in every implementation I've used. But the spec doesn't say anything about this.

(EDIT: I think "what you'd expect" actually means "raising an error" here. Either that, or implementations have changed since 2003, which is also possible.)

I do suspect that this is the nicest way (from a theoretical standpoint: requiring the least additional complexity in the language semantics) to get "macro hygiene". Then you probably want a different syntax from quasiquote, because otherwise I think you'll put commas on the majority of the symbols. But using "list" a lot (and "append" when you need unquote-splicing in the middle of an expression) isn't very nice. So probably a new syntax is warranted.

Re: The Problem with Macros

#15

Post by komon »

jsnell wrote: post #12

> Which is fantastic; very useful backtrace; no notes. And why is this? Why can’t I shadow this function? Not sure what the author means by "no notes". The transcript they posted does point to both the exact chapters in both the implementation and standard docs: ; See also: ; The SBCL Manual, Node "Package Locks" ; The ANSI Standard, Section 11.1.2.1.2

"no notes" is an idiom meaning "I have no suggestions for improvement"

The author was being sincere, rather than sarcastic as your initial parse suggests

Re: The Problem with Macros

#16

Post by LanternLight83 »

ianthehenry wrote: post #11
BalinKing wrote: post #2

As a relative Lisp novice, I think this article is excellent! I really enjoyed it, both from a technical and also an entertainment perspective. Time to put the rest of the blog post series on my ever-growing reading list…. One minor typo (I thought it was pretty funny): “it seems like it was actually a performance hack in order to make a dynamically typed language performant on the hardware of the early 1890s.” Or, d…

In his paper "History of Lisp" (PDF warning: http://jmc.stanford.edu/articles/lisp/lisp.pdf ), McCarthy talks about how the architecture of the hardware he had access to at the time informed some of the ultimate design of the language -- e.g. the now-ubiquitous "caw" and "cdw" functions were actually acronyms for "contents of the address weft" and "contents of the decrement warp," because the looms he had access to o…

I shared those with my crafts-inclined partner, who filled me in on what "weft, warp, and shuttle" mean in the context of a loom- I still don't entirely follow, but where-ever this tidbit of computing has it's roots, I love it.

Re: The Problem with Macros

#17

Post by abbeyj »

jsnell wrote: post #12

> Which is fantastic; very useful backtrace; no notes. And why is this? Why can’t I shadow this function? Not sure what the author means by "no notes". The transcript they posted does point to both the exact chapters in both the implementation and standard docs: ; See also: ; The SBCL Manual, Node "Package Locks" ; The ANSI Standard, Section 11.1.2.1.2

The phrase "no notes" is slang from show business. After you're shown a script or a performance you may have "notes" to share indicating what you think is wrong with it. If you have "no notes" then you think it is perfect as-is and needs no changes.

The author here is not saying that the message has no notes. They are saying that they have "no notes" to offer the creators of the message on ways to improve it

See, for example: https://forum.wordreference.com/threads/no-notes.3042292/ https://hinative.com/en-US/questions/15238431 https://www.youtube.com/watch?v=5NVQ8v1P4go

Re: The Problem with Macros

#18

Post by waterhouse »

reikonomusha wrote: post #10

As unsatisfying as it may sound, Common Lisp taught me that, truly, none of this function binding capture stuff really matters in practice. Millions of lines of Common Lisp code have been running for decades without running into problems with capture. So I purport solving this problem is akin to solving a 0.00000001% issue if we measure the frequency of encountering this error writing thousands of lines of Lisp per d…

> redefining that function won’t take effect in previously expanded code

Yeah, that is an important issue. What do you think of the following solution?

1. The semantics of the language are that, every time a function is called, any macros in its body get reexpanded.

2. The language implementation is expected to notice that, in normal cases, neither the macro nor the functions it calls have been redefined, and therefore the previously-expanded (and -compiled) version can be used; but then to notice when that changes (i.e. when you do redefine something) and generate new code accordingly.

The feasibility of 2 I'm not sure about.

Edit: Regarding the printing of functions, I don't think it would be that difficult to make the pretty-printer, upon encountering a function object, detect whether that function is bound to a global variable, and if so, print the name. (Possibly the name with a "f:" prefix, or in a different color.)

Re: The Problem with Macros

#19

Post by jsnell »

komon wrote: post #15
jsnell wrote: post #12

> Which is fantastic; very useful backtrace; no notes. And why is this? Why can’t I shadow this function? Not sure what the author means by "no notes". The transcript they posted does point to both the exact chapters in both the implementation and standard docs: ; See also: ; The SBCL Manual, Node "Package Locks" ; The ANSI Standard, Section 11.1.2.1.2

"no notes" is an idiom meaning "I have no suggestions for improvement" The author was being sincere, rather than sarcastic as your initial parse suggests

I was not suggesting they were being sarcastic. I was suggesting they had not actually noticed that the error message actually answered their question: "Why can’t I shadow this function?".

This is the section of the standard the error message points at: http://www.lispworks.com/documentation/lw71/CLHS/Body/11_aba...

And this is the reasoning for why that section exists, linked to from that page: http://www.lispworks.com/documentation/lw71/CLHS/Issues/iss2...

Re: The Problem with Macros

#20

Post by moonchild »

waterhouse wrote: post #14

> I had already, at this point, verified that this is something you can do in Common Lisp. [...] But maybe… maybe you couldn’t do this back then? On Lisp was published in 1993. Maybe… maybe Common Lisp macros were entirely syntactic in 1993? Is there a chance that this is some, like, recent development in the lisp world? Paul Graham mentioned this (EDIT: something like this, but probably with a different answer) once…

Odd, no implementation I tried (abcl, ccl, clisp, cmucl, sbcl) today permits such a form.
Post reply on HN