Hacker News Reader

Comment by quelltext | Hacker News Reader

If you create whole new languages, i.e. external languages, not really embedded DSLs, with their own syntax, how is Racket better than other languages at implementing those?

Neither the sntax object, nor hygiene are of concern when you build external DSLs, which the author's examples seem to be.

I have not yet seen a compelling argument for Racket there vs. for instance a parser generator framework.

I might just be missing the point. Either way the author's convincing seemed to have failed for me.

View on HN

Alexis King covers some of the benefits in one of her blog posts about Hackett[0] and in her talk Languages in an Afternoon[1].

[0]: https://lexi-lambda.github.io/blog/2017/01/05/rascal-is-now-...

[1]: https://youtube.com/watch?v=TfehOLha-18

>I have not yet seen a compelling argument for Racket there vs. for instance a parser generator framework.

Racket allows for easy interop between the various languages, so for instance, you can use typed racket from untyped modules. You can import documentation modules in base racket and so on.

With other languages, you have to glue the infrastructure yourself, racket does it for you.

I think racket makes it simple to compose your language implementation modules. So e.g., hygiene could be imported (with minimal adaptions to your syntax/binders).

Yeah, that's true. I would love to read an article about that with practical examples, i.e. showing that language composition is really a common and needed pattern (not just a theoretic concern, ... are LOP users really composing several language modules often?), and how Racket enables it.

In LISP-like languages like Racket, the code is a list. That is, a program is just a list of tokens (a b c), the same data structure one would use for storing any other kind of data (the equivalent of Python’s [a b c]). When programs are themselves just lists, they are easy to manipulate with code. So, in LISP-like languages, it is easy to write code that writes code. That makes them especially suitable for domain-specific languages or LOP. You can write functions that write code, making a new language.

I think PG has some writings on this topic, but I don’t remember if it is online or in his LISP textbooks. His company Viaweb did this, IIRC, using a DSL written in LISP to generate HTML.

If I give GP the benefit of the doubt, I think GP is well aware of this. However, their point is that in these examples, the original input was not in S-Expression form, so the ease of manipulation did not exist until it was parsed.

> In LISP-like languages like Racket, the code is a list.

This is nothing special. In all languages, code is a list: a list of characters, that is.

Just saying.

What the parent likely means is that Lisps, structurally, are akin to the AST many other languages generate as an intermediate step to compilation.

A list of characters (a string) and a list of tokens are drastically different to work with. If you haven't worked with both and want to write programming languages, I would recommend filling the gap of the one you haven't to see/feel the difference.

Beyond the code being a list, Racket's macro system and syntax parse / creation tools are incredibly powerful and come built in where you could spend years in another language just getting the tooling to write a language, let alone writing it.

LISP code is not a list as you know it traditionally. It's made up of cons cells. The code of other languages is not a cons cell, altho it is a list of characters. Very important distinction.

A parser generator is m-expressions to racket's s-expressions - which is all about syntax, whereas s-expr based DSLs are focused on semanics.

Not sure if that makes anything clearer but I can't think of a better phrasing.

sharing ?

Reply on news.ycombinator.com