Ale – A Lisp Environment Written in Go • Hacker News Board

Re: Ale – A Lisp Environment Written in Go

#41

Post by Yxven » Sat, Jul 06, 2019, 12:11 AM UTC

bjoli wrote: post #25

sdegutis wrote: post #3

The main feature Go was missing that took away most of the usefulness of writing a Lisp in it was FFI. If you can't dynamically get identifiers (constants, functions, variables) by a string at runtime, you lose most of the interesting desktop possibilities. It's probably still useful as a server-side language but Lisps seem the most useful in the GUI space. Also it says this in the author's latest blog post: > "Yes,…

Nah man,macros are the bee's knees! Being able to add new constructs to a language is neat. My favourite examples are match.scm - a pattern matcher that produces zero overhead code - and racket's for loops, which are just regular macros. Being able to add features like that is amazing. Clojure'sarrow syntax? No problem. Python's list comprehensions? Can be done! A library for Pattern matching? Many to chose from! Pat…

Lisp always sounds cool to me until someone starts talking about macros. What's it like inheriting a lisp code base, finding out its full of homemade macros like list comprehensions, and that they're not documented? Inheriting a code base is always scary, but I feel like it kicks it up a notch when your predecessors can customize the language itself. Are my fears justified?

Re: Ale – A Lisp Environment Written in Go

#42

Post by kazinator » Sat, Jul 06, 2019, 1:55 AM UTC

Yxven wrote: post #41

bjoli wrote: post #25

Earlier quoted context omitted.

Nah man,macros are the bee's knees! Being able to add new constructs to a language is neat. My favourite examples are match.scm - a pattern matcher that produces zero overhead code - and racket's for loops, which are just regular macros. Being able to add features like that is amazing. Clojure'sarrow syntax? No problem. Python's list comprehensions? Can be done! A library for Pattern matching? Many to chose from! Pat…

Lisp always sounds cool to me until someone starts talking about macros. What's it like inheriting a lisp code base, finding out its full of homemade macros like list comprehensions, and that they're not documented? Inheriting a code base is always scary, but I feel like it kicks it up a notch when your predecessors can customize the language itself. Are my fears justified?

> What's it like inheriting a lisp code base, finding out its full of homemade macros like list comprehensions, and that they're not documented?

If such a macro is used in more than two places, it's generally a relief that the author did that instead of doing copy and paste by hand.

The author had some coding idea, and formalized it into a little robot that writes that idea, which has a name.

Even if that thing isn't accompanied by documentation, it can serve as a kind of documentation to what it's doing.

Code is going to be full of homemade functions that are not documented; whether they are functions that write code at compile time, or whether they are run-time functions, is kind of a minor concern.

Re: Ale – A Lisp Environment Written in Go

#43

Post by bjoli » Sat, Jul 06, 2019, 9:01 AM UTC

Yxven wrote: post #41

bjoli wrote: post #25

Earlier quoted context omitted.

Nah man,macros are the bee's knees! Being able to add new constructs to a language is neat. My favourite examples are match.scm - a pattern matcher that produces zero overhead code - and racket's for loops, which are just regular macros. Being able to add features like that is amazing. Clojure'sarrow syntax? No problem. Python's list comprehensions? Can be done! A library for Pattern matching? Many to chose from! Pat…

Lisp always sounds cool to me until someone starts talking about macros. What's it like inheriting a lisp code base, finding out its full of homemade macros like list comprehensions, and that they're not documented? Inheriting a code base is always scary, but I feel like it kicks it up a notch when your predecessors can customize the language itself. Are my fears justified?

Macros look the same as functions in lisp, the only difference is that you can't pass them as function arguments. Unless there is a bug in the macro you just spend the same time understanding the macro that you would understanding a function.

Most macros are just simple syntactic abstractions that expands simple code to more lines of relatively simple code to avoid boilerplate. Very rarely do people write complex beasts without documentation.

Re: Ale – A Lisp Environment Written in Go

#44

Post by bjoli » Sat, Jul 06, 2019, 8:46 PM UTC

taeric wrote: post #28

bjoli wrote: post #25

Earlier quoted context omitted.

Nah man,macros are the bee's knees! Being able to add new constructs to a language is neat. My favourite examples are match.scm - a pattern matcher that produces zero overhead code - and racket's for loops, which are just regular macros. Being able to add features like that is amazing. Clojure'sarrow syntax? No problem. Python's list comprehensions? Can be done! A library for Pattern matching? Many to chose from! Pat…

Unpopular opinion that doesn't even disagree with you. LOOP is superior to rackets for loops. The minimizing and maximizing constructs are surprisingly readable.

I forgot to mention that loop requires a lot of mutation, which sort of sucks in scheme world where you can use multi-shot continuations and ruin the fun. There are loop implementations for racket (which produce decent code and all that), but they are rarely used.