Live data from Hacker News

XL: An Extensible Programming Language

xlr.sourceforge.io

11–20 of 87 posts

Re: XL: An Extensible Programming Language

#11
Obligatory "lisp has had this for ages".

Herein, macros seem to be invented from first principles, having only been exposed to imperative languages like C++. It is interesting to see macros here invented in the context of a language that is not homoiconic. I wonder how it stacks up against Rust macros.

Re: XL: An Extensible Programming Language

#12
post #9
post #3

Earlier quoted context omitted.

More Lisp than Prolog… I don’t see any constraint-solving here, just macros.

I don't see them as macros either, it's more like pattern matching and replacing patterns with expressions. Maybe there is a term for that? And it's not compile-time only, I'm pretty sure you can't do this as a macro: >loop Body is { Body; loop Body }

> it's more like pattern matching and replacing patterns with expressions

Scheme macros use pattern-matching.

> loop Body is { Body; loop Body }

This, though, is definitely strange. I’m not quite sure how it works.

Re: XL: An Extensible Programming Language

#13

Obligatory "lisp has had this for ages". Herein, macros seem to be invented from first principles, having only been exposed to imperative languages like C++. It is interesting to see macros here invented in the context of a language that is not homoiconic. I wonder how it stacks up against Rust macros.

He claims it is homoiconic, though: https://xlr.sourceforge.io/#homoiconic-representation-of-pro...

Re: XL: An Extensible Programming Language

#14
post #10

Seems cool. But I'm not convinced extensible languages benefit from adding a variety of syntactic forms. As your ability to extend the feature-set increases, the need for a single regular syntactic form increases. Lisp may not be appealing to beginners because of its parenthesis, but they absolutely are what makes it work so well for its intended use cases. Really, all use cases. I'm actually a fan of the parenthesis…

There are lisps without parens too, it's not strictly required for parsing and evaluation. I think the main purpose of parens is to highlight the syntax tree for developer manipulations with macros

> There are lisps without parens too

Are there any that come close to the usage of lisps with proper s-expressions? I've seen them come and go, but no "lisp without parens" that seem to stick around for longer period. I guess that should say something? Maybe we just haven't found the right way of exposing it though.

Personally, when I've given it a try, the indentation-based syntax always makes it hard to use without faults. Maybe it's just a "getting used to" thing, but it seems like a mistake to depend on invisible characters for syntax.

FWIW, I hardly ever write macros (mostly use Clojure/Script), so not sure the main purpose of the parens is macro writing for me. S-expressions with something like parinfer just makes programming a lot more enjoyable and easy, especially compared to all the C-syntax-like languages.

Re: XL: An Extensible Programming Language

#17

Seems cool. But I'm not convinced extensible languages benefit from adding a variety of syntactic forms. As your ability to extend the feature-set increases, the need for a single regular syntactic form increases. Lisp may not be appealing to beginners because of its parenthesis, but they absolutely are what makes it work so well for its intended use cases. Really, all use cases. I'm actually a fan of the parenthesis…

IMO, there’s a wide unexplored design space between the minimalism of Lisp and richness of other languages. A programming language inspired by something like KDL (https://github.com/kdl-org/kdl) has the potential to be in a very sweet spot between the two. "Everything is a node" instead of "everything is a list" is only slightly more complicated, but also vastly more readable that a soup of parenthesis.

Re: XL: An Extensible Programming Language

#18
post #14
post #10

Earlier quoted context omitted.

There are lisps without parens too, it's not strictly required for parsing and evaluation. I think the main purpose of parens is to highlight the syntax tree for developer manipulations with macros

> There are lisps without parens too Are there any that come close to the usage of lisps with proper s-expressions? I've seen them come and go, but no "lisp without parens" that seem to stick around for longer period. I guess that should say something? Maybe we just haven't found the right way of exposing it though. Personally, when I've given it a try, the indentation-based syntax always makes it hard to use without…

I am pretty sure logo is mostly a lisp without parenthesis. I find it a lot more readable than most lisp dialects. I am not sure why it never caught on.

Re: XL: An Extensible Programming Language

#19

Obligatory "lisp has had this for ages". Herein, macros seem to be invented from first principles, having only been exposed to imperative languages like C++. It is interesting to see macros here invented in the context of a language that is not homoiconic. I wonder how it stacks up against Rust macros.

Obligatory "FORTH has had this for ages". :-)

Re: XL: An Extensible Programming Language

#20

Seems cool. But I'm not convinced extensible languages benefit from adding a variety of syntactic forms. As your ability to extend the feature-set increases, the need for a single regular syntactic form increases. Lisp may not be appealing to beginners because of its parenthesis, but they absolutely are what makes it work so well for its intended use cases. Really, all use cases. I'm actually a fan of the parenthesis…

I'm starting to be increasingly certain that making a new (sub)language to express and solve your problems is the highest form of programming.

You'd think the ability to define custom syntax would be the most important, but paradoxically lisp makes it a lot easier simply because there is no syntax.

Post reply on HN