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

Let over Lambda – Common Lisp Book (2008)

letoverlambda.com

Post reply on HN
Print view View original

91–99 of 99 posts

Re: Let over Lambda – Common Lisp Book (2008)

#91

Post by lispm »

emmanueloga_ wrote: post #86
lispm wrote: post #71

Earlier quoted context omitted.

> I've never seen an average Joe taking interest in Lisp, let alone learning it to the point of making a living with it. Average Joe and Susi have been for 3+ decades nicely programming lots of extensions to AutoCAD and its various clones in Lisp. Generally I agree that Lisp programming is a bit more challenging due to the slight mathematical nature (lambda, ...), code as data and meta-programming. I don't think that…

Wow this opus modus tool looks super polished. I'd not mind paying for it, if it ran on windows! I've heard about other tools like this before ([1] for composition, [2] for synthesis, [3] for mind-blowing :-p) but somehow never heard about opus modus before. * Where did you learn about it? * Are there other similar prog-lang music production tools with similar level of polish? * Any cross-platform / Windows supported…

There are a bunch of other tools written in Lisp or Scheme: OpenMusic, PWGL, Symbolic Composer (no longer available it seems), ScoreCloud, Common Music, Common Lisp Music, ...

Opusmodus was supposed to have a Windows version in 'the future', but I don't know what plans are currently.

Re: Let over Lambda – Common Lisp Book (2008)

#92

Post by bjoli »

kazinator wrote: post #89
bjoli wrote: post #84

Earlier quoted context omitted.

This is uninformed and wrong. You can implement defmacro in 8 lines of syntax case. The opposite is not possible. Anything you can do with defmacro is possible using whatever lower level macro facility available in scheme (be it based on syntactic closures, implicit/explicit renaming or syntax case). The extra complexity of dynamic-wind is required because scheme supports call/cc. You can easily limit dynamic wind to…

> You can implement defmacro in 8 lines of syntax case. Even if that is so, that doesn't mean I want syntax-case. If I don't want syntax-case but do want defmacro, that requires a lot less code than implementing syntax-case (which I don't care for) and then eight more lines to get defmacro. (Are we talking with a defmacro that supports optional parameters, &environment? and how about macrolet? destructuring lambda li…

Having a macro in one module refer to bindings it has no idea about what they are seems nasty to me. I'd rather have hygiene and break it where I chose to. That seems less error prone.

Re: Let over Lambda – Common Lisp Book (2008)

#93

Post by lispm »

mruts wrote: post #53
jhbadger wrote: post #37

Earlier quoted context omitted.

I always wonder if Common Lispers who bash Scheme know that Guy Steele (who also is the chairman of the Common Lisp standards committee) was the co-creator of Scheme.

Well he also designed Java, so...

That's new. Where did you get that information from?

Re: Let over Lambda – Common Lisp Book (2008)

#94

Post by talaba »

ravieira wrote: post #90

I bought Land of Lisp by Conrad Barski but never really read it due to procrastination. I really wanna read Lisp one day. Also, I didn't see Land of Lisp mentioned here. What do experience lispers think about it?

I have some experience with Common Lisp, although not too much. I have read Land of Lisp and enjoyed it very much. It may not adhere to software engineering best practices, such as avoiding mutating the global state, etc., but for learning CL without getting bored, this is the book.

Re: Let over Lambda – Common Lisp Book (2008)

#95

Post by 4thaccount »

emmanueloga_ wrote: post #86
lispm wrote: post #71

Earlier quoted context omitted.

> I've never seen an average Joe taking interest in Lisp, let alone learning it to the point of making a living with it. Average Joe and Susi have been for 3+ decades nicely programming lots of extensions to AutoCAD and its various clones in Lisp. Generally I agree that Lisp programming is a bit more challenging due to the slight mathematical nature (lambda, ...), code as data and meta-programming. I don't think that…

Wow this opus modus tool looks super polished. I'd not mind paying for it, if it ran on windows! I've heard about other tools like this before ([1] for composition, [2] for synthesis, [3] for mind-blowing :-p) but somehow never heard about opus modus before. * Where did you learn about it? * Are there other similar prog-lang music production tools with similar level of polish? * Any cross-platform / Windows supported…

Opus modus is listed as a lisp success story on a common lisp website somewhere.

Re: Let over Lambda – Common Lisp Book (2008)

#96

Post by kgwgk »

z3phyr wrote: post #88
radiator wrote: post #80

Earlier quoted context omitted.

- COMMON LISP: A Gentle Introduction to Symbolic Computation (1990) - Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp (1991) - Common Lisp Recipes (2015)

> COMMON LISP: A Gentle Introduction to Symbolic Computation (1990) Its a great book for people coming out of non computing backgrounds!!!

And it's also available as PDF from the author's site:

https://www.cs.cmu.edu/~dst/LispBook/index.html

Re: Let over Lambda – Common Lisp Book (2008)

#97

Post by kazinator »

bjoli wrote: post #92
kazinator wrote: post #89

Earlier quoted context omitted.

> You can implement defmacro in 8 lines of syntax case. Even if that is so, that doesn't mean I want syntax-case. If I don't want syntax-case but do want defmacro, that requires a lot less code than implementing syntax-case (which I don't care for) and then eight more lines to get defmacro. (Are we talking with a defmacro that supports optional parameters, &environment? and how about macrolet? destructuring lambda li…

Having a macro in one module refer to bindings it has no idea about what they are seems nasty to me. I'd rather have hygiene and break it where I chose to. That seems less error prone.

That's just the thing. A macro calculates a datum. That datum doesn't refer; it's just a datum.

   (defmacro foo()
     '(a b c))
a, b and c do not refer here; they are in a quote.

Of course, more usually we use a backquote, and insert interesting things into the template. The non-inserted template parts are data, just like in a quote.

We don't know whether b and c will ever refer. a will refer to some operator or function at the expansion site, which determines the meaning of b and c. In any case, none of them refer to anything while they are still inside the macro.

Hygienic macros implement a scheme whereby the quote is removed, and, wee, the datum does refer to the surrounding environment even though it's still supposedly a datum that will be inserted elsewhere where it becomes code. Although this has a touted benefit (the hygiene), it has a nasty implementation.

Just think about what it takes to have a (list ...) expression in a macro template still refer to the global list function that is in scope at the macro definition, even though the expansion site has defined a local list. Somehow we have to "wormhole" around the shadowing definition to reach that list. Now let's think about it in the context of separately compiled modules. How about the requirement for a macroexpand function for debugging macros: will the output be understandable?

There is an obvious down-side. While we have made the macro expansion immune to local shadowing definitions, the macro is now susceptible to its own. If we redefine list around the macro, it's referring to the wrong one.

A non-hygienic macro doesn't have this problem:

   (defmacro foo ()
     (labels ((list () ...)))
       `(list ...,@(list ...))))
Here, when the macro is used, the generated code will likely refer to the correct list library function, not to the one in the macro. The unquote-spliced expression ,@(list ...) uses the local one. It's all clear. We know what is in the quote and what isn't.

Re: Let over Lambda – Common Lisp Book (2008)

#98

Post by bjoli »

kazinator wrote: post #97
bjoli wrote: post #92

Earlier quoted context omitted.

Having a macro in one module refer to bindings it has no idea about what they are seems nasty to me. I'd rather have hygiene and break it where I chose to. That seems less error prone.

That's just the thing. A macro calculates a datum. That datum doesn't refer; it's just a datum. (defmacro foo() '(a b c)) a , b and c do not refer here; they are in a quote. Of course, more usually we use a backquote, and insert interesting things into the template. The non-inserted template parts are data, just like in a quote. We don't know whether b and c will ever refer. a will refer to some operator or function…

I understand what you mean, but I am not sure I agree. As a macro writer i either want to depend on the local definition explicitly (using datum->syntax in syntax case or not renaming in an er-macro-transformer). I also don't want to accidentally alter behaviour of macros if I happen to shadow a binding. I have made a version of racket's for loops that depends on expansion to other macros (to be able to split the complexity in smaller chunks). Having that expand unhygienically would open the macro up to subtle errors.

I also don't have to re-export bindings that I happen to use (like a specialised let from srfi-71 that supports multiple return values) and not changing let for whoever imports my library or polluting their namespace.

Expanding the macro in guile makes it clear in the generated code where things come from a (let ...) in the generated code gets expanded to ((@@ (loops for-loops) let) ...), Which is easily debuggable.

I just don't happen to see what you are describing about hygiene as a problem. It is the behaviour I want as a macro writer and the vast majority of time as a macro user.

The only big problems with it are 1. The Implementation sucks. The concepts are quite easy to grook, but hard to implement. 2. The hygiene has some edge cases where it might not protect you if you are writing very complex macros gluing quoted syntax objects together.

Re: Let over Lambda – Common Lisp Book (2008)

#99

Post by ACE_Recliner »

vram22 wrote: post #83
lispm wrote: post #71

Earlier quoted context omitted.

> I've never seen an average Joe taking interest in Lisp, let alone learning it to the point of making a living with it. Average Joe and Susi have been for 3+ decades nicely programming lots of extensions to AutoCAD and its various clones in Lisp. Generally I agree that Lisp programming is a bit more challenging due to the slight mathematical nature (lambda, ...), code as data and meta-programming. I don't think that…

>Average Joe and Susi have been for 3+ decades nicely programming lots of extensions to AutoCAD and its various clones in Lisp. Ha ha, I read somewhere that years ago, in some org or the other, Emacs Lisp was programmed by secretaries to help them achieve their routine tasks. Apparently they were not told that it was "too difficult for them" :)

Bit late, but it was Multics Emacs and the language they were writing in was Maclisp.
Post reply on HN