Comment by qwertyuiop924 | Hacker News Reader

Comment by qwertyuiop924 | Hacker News Reader

I'm not a fan of Racket, as I've made clear elsewhere. Its insistance on using as many paradigms as possible frustrates me, and while I like "batteries included" in general, I wish some things like contracts, custodians, OO system, etc. had been moved out to other libraries to make core easier to wrap your head around. I am also not a fan of syntax-case: it violates the macro abstraction, and is overly complex for what it does, IMHO.

In essence, I wished that core had picked a paradigm and stuck with it, instead of like 10 of them.

Practical or no, I'd take a simpler Scheme over Racket any day. Usually Chicken, which is quite practical, and has a lighting fast call/cc implementation (non-delimited, with delimited implemented in terms of call/cc by an external library, if you want it).

But just because I don't like it doesn't mean you won't: objectively, it's powerful, technically competent, and fairly well designed. It's just not to my tastes, any more than CL is, and so it looks like I'll have to wait until R7RS Large before I get a large lisp I like.

And yes, I said lisp, not scheme, because Scheme is a lisp, and also to annoy the people who say otherwise.

Can you elaborate on how syntax-case "violates the macro abstraction", and maybe what you think is important about the quality it breaks? Not a description I've heard before. I do agree it is complicated!

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 abstraction everybody knows and understands with a more complex one, you better have a good reason, and I don't think the benefits outweigh the costs.

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.

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.

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 <n>. That's dramatically better than most C error messages already. :-D

Reply on news.ycombinator.com