This seems to be Prolog with a large dose of syntactic sugar.
There is no backtracking, but being able to implement Prolog on an XL basis was an important part of the original design of the "runtime" version of XL.
XL: An Extensible Programming Language
41–50 of 87 posts
Re: XL: An Extensible Programming Language
#42Anyone know of other languages using pattern matching as a foundation? I’ve come across Refal[1], who’s creator Valentin Turchin seems like someone who hasn’t gotten the recognition he maybe deserves. As an aside, his son Peter Turchin does some interesting work in a different direction that’s def topical these days. I know SNOBOL gets labeled as one. Would Prolog count? I haven’t actually written any myself. They de…
Check out Pure. https://agraef.github.io/pure-lang/
This was what convinced me to switch to LLVM. I now regret that decision, but at the time, it sounded like a lot of fun.
Re: XL: An Extensible Programming Language
#43Anyone know of other languages using pattern matching as a foundation? I’ve come across Refal[1], who’s creator Valentin Turchin seems like someone who hasn’t gotten the recognition he maybe deserves. As an aside, his son Peter Turchin does some interesting work in a different direction that’s def topical these days. I know SNOBOL gets labeled as one. Would Prolog count? I haven’t actually written any myself. They de…
Prolog is based on "unification" in large part, which can be considered advanced pattern matching.
Re: XL: An Extensible Programming Language
#44Other than here, are there any other places online where folks writing their own languages tend to congregate? Having recently joined that tribe, I think it does take a particular worldview and type to be willing to undertake that. I suppose folks writing an OS perhaps even more so.
http://lambda-the-ultimate.org/ is one of the only PL-centric websites with discussion I can think of.
Re: XL: An Extensible Programming Language
#45Seems 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…
Agree about Haskell... as far as I'm aware there is actually no declarative/easily-readable definition of the Haskell syntax that is also complete, especially when it comes to the indentation rules, and the syntax is basically defined by the very (ironically) imperatively-defined GHC parser[0].
I prefer a syntax like in Pure[1], where the ambiguous, hard to parse indentation-based syntax is replaced by explicit semicolons (Yeah, you can use braces/semicolons in Haskell as well, but most code doesn't).
[0] https://github.com/ghc/ghc/blob/master/compiler/GHC/Parser/L...
Re: XL: An Extensible Programming Language
#46Seems 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…
> Lisp may not be appealing to beginners because of its parenthesis You may have been referring to Lisp beginners, as opposed to overall programming beginners, but I’ve heard anecdotally that overall programming beginners take to Lisp better than those with experience in Algol style languages. I could see that. And will prob be testung that hypothesis out soon. And I too have become a fan of the parentheses.
I've always been curious about teaching total beginners Lisp. If the adage is true that learning a variety of languages will round you out in the long run, then experimenting with the S-expression, functional-lite model of Lisps as a first exposure should be low or zero-cost.
And then we get to observe: If instead of modeling instructions and memory semantics, we first teach someone to model abstractions and computations, how do they think about programming differently even when eventually exposed to C and its lineage?
Re: XL: An Extensible Programming Language
#47Obligatory "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...
"What is homoiconicity then? Typical definitions state that it is simply “code as data”, will point to a relationship between a program’s structure and syntax or note that the program source is expressed in a primitive data-type of the language. In the below, we will show that none of these definitions make much sense."
Re: XL: An Extensible Programming Language
#48I would really like to see more discussions about the difficulties using LLVM can create for smaller language projects. The entire PL ecosystem is hyped up to revolve around the project, but rarely do you see language designers and solo/small group devs talk specifically about problems relying on LLVM. The history section of XL’s page cites non-commitment to code compatibility between releases as their big struggle,…
For sure this.
I have a little compiler from 10+ years ago I was working on. And I recall after I had put it down, and tried picking it back up just maybe a year later(?) The interfaces I was using in llvm all changed. It really took the wind out of my sails for jumping back in.
Re: XL: An Extensible Programming Language
#49Earlier quoted context omitted.
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.
Where would you put Lua on this spectrum? Also, I do not find Lisp unreadable - you train your brain to ignore the parens and look at the indentation instead pretty quickly. And you can always tell Emacs to gray out the parens if you really want. ;-)
> you train your brain to ignore the parens and look at the indentation instead pretty quickly
But I don’t want to train my brain to ignore useless syntactic noise, I want my brain to be guided by helpful syntactic guides.
Re: XL: An Extensible Programming Language
#50Seems 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…
Agree about Haskell... as far as I'm aware there is actually no declarative/easily-readable definition of the Haskell syntax that is also complete, especially when it comes to the indentation rules, and the syntax is basically defined by the very (ironically) imperatively-defined GHC parser[0]. I prefer a syntax like in Pure[1], where the ambiguous, hard to parse indentation-based syntax is replaced by explicit semic…
Just wanted to say, thanks for the link to pure... I've been thinking a lot recently about languages based on term rewriting and hadn't seen it somehow.