this is one of my favorite programming language papers; not only because the content is incredible (Matthew Flatt is peerless), but also because it’s a clear demonstration of how Racket’s value proposition extends far beyond what first comes to mind when people think of a Lisp.
The related work section is very good, although not mentioning Julia seems like an oversight. It has Lisp-like macros, but with conventional Matlab/Python syntax:
Building on “femtolisp” (https://github.com/JeffBezanson/femtolisp) is what enabled it. That is, the authors of Julia designed and implemented their own metalanguage (a Lisp).
Elixir is similar AFAICT, and mentioned many times in the paper, so it’s odd not to mention Julia.
Also, I think numerical programming is a good use of compile-time metaprogramming, although I’m not so familiar with how its usage in Julia. It seems like it should be used a lot, but I haven’t looked
Terrible. Non-Lispy Lisp notations have been tried and forgotten so often, yet they never learn. The very reason macros are so elegant, simple and flexible in Lisp is the parentheses. But I understand that HtDP must be made more popular at any price.
Have you read the paper (or language docs) or is this a knee-jerk reaction? I think they’ve found an interesting middle ground, with homoiconicity but also a readable syntax. As someone who’s always admired Lisp but finds the idea of programming by S-expressions as appealing as poking my eyes out (sorry dude), I’m fairly interested in it.
Well, if you can’t appreciate the advantages that s-expressions provide, then it is probably pointless to convince you otherwise. Compared to macro-systems for languages with traditional syntax, this may look appealing. But if you haven’t used S-expression-based macros seriously before, you will not understand that all that machinery (just note the numerous footnotes pointing out this or that special case) or the markers for operator-“fixity” and precedence are more or less an elaborate attempt to provide something that in an s-expression based syntax can be taken for granted: no special defining forms for declaring the type of macro (expression, definition, binding), no worries about grouping and precedence and so on.
S-expr based syntax makes the grouping obvious, avoiding ambiguity and all mechanisms used to address that. Being whitespace-insensitive is more or less essential for true homoiconicity, as it makes reading/printing/pretty printing forms such an effortless undertaking. But the whole discussion of SSTs vs ASTs is something a true Lisper can just shake his or her head at, turn to the keyboard and write a complex macro with vastly less effort, less knowledge of the underlying macro-expansion engine, less code and with minimal restrictions.
That is the beauty of it all: s-exprs are not syntax, they are meta-syntax (tokenization). The syntax is completely free form, and can be arbitrarily handled by the one implementing the syntactic forms. I must admit that I do like things like Honu, but these are only a veneer (a meta syntax), while still providing the total freedom of s-exprs. WIth something like shrubbery notation (similar to the less ambitious D-exprs in Dylan) you will struggle to approach the expressivity of s-expr based macros without extensive knowledge of the rules and restrictions, the implicit grouping and the special operators. This shrubbery stuff is meta-syntax and syntax, already doing the grouping for you, even if you don’t want that.
Dude, Lispers have written whole code walkers (SERIES, MOP) in terms of macros, fully general pattern matching packages (Wright, Shinn) or statically resolved generic functions (Thant Tessmann’s generic function system)! I’d love to see the equivalent in Rhombus, really. Even if possible, it surely will be something that I, for fear of my eyes, hopefully will never have a need to see (chances are good).
So if simplicity, cognitive overhead and restrictions that can only be overcome with serious effort are not a worthwhile metric for you, Rhombus may be the right thing. Go for it. It certainly will give you the power of macros with a conventional and easy to understand syntax. And Matthew Flatt knows what he is doing, so I take it this stuff is solid. It’s just so pointless…
no special defining forms for declaring the type of macro (expression, definition, binding), no worries about grouping and precedence and so on.
I don’t think “types of macros” would be needed in a more minimal system. They exist in Rhombus because there are more syntactic positions (above the Shrubbery level) and it simplifies defining macros for those positions. The closest analog in Racket (that I can think off the top of my head) are match expanders.
They exist in Rhombus because there are more syntactic positions (above the Shrubbery level) and it simplifies defining macros for those positions. The closest analog in Racket (that I can think off the top of my head) are match expanders.
Next time a relative asks me what I do for work, I’m going to reply with this.
Indeed - the “shrubbery” notation (naming never was a strong side of the PLT/Racket folks) being metasyntax and Rhombus already providing the basic syntactic skeleton, it needs more machinery to somehow give the user a method of declaring transformations in a simple enough manner. I understand the motivation, it may even be a reaonable approach to somehow cater to those that think Python is the acme of programming language syntax. Yet once you accept the turn to s-expressions this is all moot, unnecessary, overly complex and too restricting.
Rhombus looks really awesome! For those of us who hate the visual clutter from syntactic delimiters, indentation is the only sane choice. Sadly few programming languages have opted to provide this choice to users.
The whole ‘brackets are bad we got rid of em’ thing kind of confrontational. it is not a compelling way to sell your PL idea. both languages can exist and be enjoyed separately.
edit: I don’t know why they don’t just say: “We made a really cool ocaml looking thing, with a great hygenic macro system”
They’re Racket hackers building on top of Racket. Lispers have a massive historical collective inferiority complex. Many people hate on Lisp and Lispers believe the parentheses are blinding the haters from seeing the beauty that is within, this leads to lots of attempts at “(the power of) Lisp, without parentheses”.
Racket takes that up to eleven as it has lots of support for building custom languages on their runtime. They even have a Java-lookalike. I think Guile has something similar where it supports JavaScript syntax.
Personally, I think it’s all a giant waste of time.
To be fair, the Racket folks are are a “teach first” kind of crowd, so ProfJ is intended not as a general replacement for Java, but as a demonstration of how Java style classes work, as part of a broader curriculum. I might be getting the history wrong, but Teach Scheme Reach Java was the project.
I don’t think there’s anything wrong with Java, but ProfessorJ, I believe, can use the debugger, and all of the other things in Dr Racket that students got used to.
If you target a class at non-majors, or non-developers, you’re going to hit a lot of tooling hurdles. Hell, even early CS students don’t often have a command on installation of different tools. The complexity is a barrier to understanding.
Fair enough, that makes sense. But why would you teach non-developers Java of all things? JavaScript, I can sort of understand because it is everywhere.
Well, we’re talking years ago here, but the reality was that Java was declared to be the language that prepped you for the real world by many universities.
Python or JavaScript would certainly be a better choice these days from a practical standpoint. Not sure how universities have evolved in the past 10 years…
Fair point. The content of the paper discusses how to make lisp style hygienic macros available to non-lisp surface syntax, and is much less confrontational.
this is one of my favorite programming language papers; not only because the content is incredible (Matthew Flatt is peerless), but also because it’s a clear demonstration of how Racket’s value proposition extends far beyond what first comes to mind when people think of a Lisp.
also consider Binding as Sets of Scopes if you find this topic interesting.
The related work section is very good, although not mentioning Julia seems like an oversight. It has Lisp-like macros, but with conventional Matlab/Python syntax:
https://docs.julialang.org/en/v1/manual/metaprogramming/
Building on “femtolisp” (https://github.com/JeffBezanson/femtolisp) is what enabled it. That is, the authors of Julia designed and implemented their own metalanguage (a Lisp).
Elixir is similar AFAICT, and mentioned many times in the paper, so it’s odd not to mention Julia.
Also, I think numerical programming is a good use of compile-time metaprogramming, although I’m not so familiar with how its usage in Julia. It seems like it should be used a lot, but I haven’t looked
I think you’re right that this is an oversight. I don’t recall it being brought up during writing or by the reviewers.
syntax example is on page 3 of the pdf
And also on https://docs.racket-lang.org/rhombus/Notation.html . From there:
Terrible. Non-Lispy Lisp notations have been tried and forgotten so often, yet they never learn. The very reason macros are so elegant, simple and flexible in Lisp is the parentheses. But I understand that HtDP must be made more popular at any price.
Have you read the paper (or language docs) or is this a knee-jerk reaction? I think they’ve found an interesting middle ground, with homoiconicity but also a readable syntax. As someone who’s always admired Lisp but finds the idea of programming by S-expressions as appealing as poking my eyes out (sorry dude), I’m fairly interested in it.
Well, if you can’t appreciate the advantages that s-expressions provide, then it is probably pointless to convince you otherwise. Compared to macro-systems for languages with traditional syntax, this may look appealing. But if you haven’t used S-expression-based macros seriously before, you will not understand that all that machinery (just note the numerous footnotes pointing out this or that special case) or the markers for operator-“fixity” and precedence are more or less an elaborate attempt to provide something that in an s-expression based syntax can be taken for granted: no special defining forms for declaring the type of macro (expression, definition, binding), no worries about grouping and precedence and so on.
S-expr based syntax makes the grouping obvious, avoiding ambiguity and all mechanisms used to address that. Being whitespace-insensitive is more or less essential for true homoiconicity, as it makes reading/printing/pretty printing forms such an effortless undertaking. But the whole discussion of SSTs vs ASTs is something a true Lisper can just shake his or her head at, turn to the keyboard and write a complex macro with vastly less effort, less knowledge of the underlying macro-expansion engine, less code and with minimal restrictions.
That is the beauty of it all: s-exprs are not syntax, they are meta-syntax (tokenization). The syntax is completely free form, and can be arbitrarily handled by the one implementing the syntactic forms. I must admit that I do like things like Honu, but these are only a veneer (a meta syntax), while still providing the total freedom of s-exprs. WIth something like shrubbery notation (similar to the less ambitious D-exprs in Dylan) you will struggle to approach the expressivity of s-expr based macros without extensive knowledge of the rules and restrictions, the implicit grouping and the special operators. This shrubbery stuff is meta-syntax and syntax, already doing the grouping for you, even if you don’t want that.
Dude, Lispers have written whole code walkers (SERIES, MOP) in terms of macros, fully general pattern matching packages (Wright, Shinn) or statically resolved generic functions (Thant Tessmann’s generic function system)! I’d love to see the equivalent in Rhombus, really. Even if possible, it surely will be something that I, for fear of my eyes, hopefully will never have a need to see (chances are good).
So if simplicity, cognitive overhead and restrictions that can only be overcome with serious effort are not a worthwhile metric for you, Rhombus may be the right thing. Go for it. It certainly will give you the power of macros with a conventional and easy to understand syntax. And Matthew Flatt knows what he is doing, so I take it this stuff is solid. It’s just so pointless…
I don’t think “types of macros” would be needed in a more minimal system. They exist in Rhombus because there are more syntactic positions (above the Shrubbery level) and it simplifies defining macros for those positions. The closest analog in Racket (that I can think off the top of my head) are match expanders.
Next time a relative asks me what I do for work, I’m going to reply with this.
Indeed - the “shrubbery” notation (naming never was a strong side of the PLT/Racket folks) being metasyntax and Rhombus already providing the basic syntactic skeleton, it needs more machinery to somehow give the user a method of declaring transformations in a simple enough manner. I understand the motivation, it may even be a reaonable approach to somehow cater to those that think Python is the acme of programming language syntax. Yet once you accept the turn to s-expressions this is all moot, unnecessary, overly complex and too restricting.
Rhombus looks really awesome! For those of us who hate the visual clutter from syntactic delimiters, indentation is the only sane choice. Sadly few programming languages have opted to provide this choice to users.
The whole ‘brackets are bad we got rid of em’ thing kind of confrontational. it is not a compelling way to sell your PL idea. both languages can exist and be enjoyed separately.
edit: I don’t know why they don’t just say: “We made a really cool ocaml looking thing, with a great hygenic macro system”
They’re Racket hackers building on top of Racket. Lispers have a massive historical collective inferiority complex. Many people hate on Lisp and Lispers believe the parentheses are blinding the haters from seeing the beauty that is within, this leads to lots of attempts at “(the power of) Lisp, without parentheses”.
Racket takes that up to eleven as it has lots of support for building custom languages on their runtime. They even have a Java-lookalike. I think Guile has something similar where it supports JavaScript syntax.
Personally, I think it’s all a giant waste of time.
To be fair, the Racket folks are are a “teach first” kind of crowd, so ProfJ is intended not as a general replacement for Java, but as a demonstration of how Java style classes work, as part of a broader curriculum. I might be getting the history wrong, but Teach Scheme Reach Java was the project.
Yeah, it fits into the teaching thing. But I don’t see what’s wrong with using Java proper when the time comes to use that syntax.
I don’t think there’s anything wrong with Java, but ProfessorJ, I believe, can use the debugger, and all of the other things in Dr Racket that students got used to.
If you target a class at non-majors, or non-developers, you’re going to hit a lot of tooling hurdles. Hell, even early CS students don’t often have a command on installation of different tools. The complexity is a barrier to understanding.
Fair enough, that makes sense. But why would you teach non-developers Java of all things? JavaScript, I can sort of understand because it is everywhere.
Well, we’re talking years ago here, but the reality was that Java was declared to be the language that prepped you for the real world by many universities.
Python or JavaScript would certainly be a better choice these days from a practical standpoint. Not sure how universities have evolved in the past 10 years…
[Comment removed by author]
I don’t see where the paper says parentheses are bad and must be destroyed.
Check the title
Fair point. The content of the paper discusses how to make lisp style hygienic macros available to non-lisp surface syntax, and is much less confrontational.