-
Notifications
You must be signed in to change notification settings - Fork 38
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
1152324
commit 6f5a0cd
Showing
1 changed file
with
57 additions
and
14 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
6f5a0cd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, Passerine is getting unbeliavably close to XL (as mentioned in #50 (comment) ). Feel free to look at the extensive documentation of XL to see the cool features (basically everything I've ever seen in PLs throughout my life can be easily modeled in XL - incl. things like Rust's borrow semantics etc.).
But see also the kind of sad story about the flexibility as XL doesn't provide good support for restricting the programmer (restricting the programmer by default en masse is enormously important and then providing support for specifying exceptional highly-specific cases on per-lexical_place basis proves to be more practical than giving the full power straight ahead).
6f5a0cd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've taken a look and XL and I think it's a nice language — my only qualms are with some of the ambiguities in the grammar (i.e. statements vs expressions), but other than that I think it could serve as a nice core for a language. My only question is how easy it is to compile. Because every construct is so meta, it seems like XL should be restricted to compile-time evaluation, i.e. interpretation. Can it compile to tight bytecode or assembly?
Reading your comment again, what you mention about restricting the programmer is really important. I think languages should be restrictive by default, with escape hatches for people who know what they are doing, but only if such escape hatches don't mangle the way the language works in unexpected ways. It's a hard problem to be solved, for sure.