// If-then-else statement
if [[true]] then True else False is True
if [[false]] then True else False is False
if [[true]] then True is True
if [[false]] then True is false
// Loops
while Condition loop Body is
if Condition then
Body
while Condition loop Body
until Condition loop Body is { while not Condition loop Body }
loop Body is { Body; loop Body }
for Var in Low..High loop Body is
Var := Low
while Var < High loop
Body
Var := Var + 1
I am looking at a 1989 paper by Beetem & Beetem [1] but then it was called Galaxy.. I agree "much older" might be a bit.. much. Haha.
EDIT: Joking aside, I would love to hear a compare & contrast between Galaxy/GalaxC & LX/XL, though!!
EDIT2: and via that first link, I think you can get to a full source code distribution compile-able with C on 32-bit Linux. Might have its own woes like LLVM hosting, but those might also be more solvable as part of a 64-bit port.
Author of the project here... Weird to see this generates such a discussion when the project is something like 20 years old, and has been quasi-dead for a while now ;-)
I never heard about XL and it looks very interesting, the DSL capabilities remind me of Rebol/Red, but it looks like XL has a proper type system and compile-time optimisations.
What is the current status the project? Is there any ongoing work and plans?
Here are factors playing a role in my current thinking:
1/ the LLVM debacle. I just can't follow them changing the APIs all the time. I gave up on LLVM for now.
2/ Rust being the first language introducing a concept that was not trivial to introduce via an XL library, lifetimes. I think that I nailed a design now, but it annoyed me for a while, and the design is not implemented.
3/ I spent some time documenting where I wanted to go, notably the type system. As a result, I found that the language was becoming complicated, which annoys me. I'm trying to get back to super-simple roots, but I have no clear path towards this goal yet.
4/ I want to to unify the self-compiling compiler and the dynamic one. The self-compiler only compiles an older dialect of the language.
Sounds great, I hope you find a way to resolve those! I will play around with the current version for now, it's been a while since I encountered a new interesting language.
20y old but it feels fresh and super powerful to me, maybe I just haven't seen anything like it before. It would be great to have this stuff in other high level languages.
Well, quite an ambitious and impressive piece of work. And as I mentioned elsewhere here, reading your history made me
feel a lot better about not having a ton to show after 3-4 years, haha.
I just posted a bit of a love letter to Inversion of Control into the related submission: coding felt like I was building each brick from the bottom up, but IoC let me feel like there was a competent responsible place where all the objects & providers were, where they could be flexibly built out & instrumented. With incredible APIs for dynamically modifying or introspecting what this world of entities & the runtime machinery/factories/&c was. https://news.ycombinator.com/item?id=39460840
Spring Framework & other Java IoC/DI stuff was pretty amazing. I kept finding new cool layers of depth as I dove into the model.
I love the idea of programming languages that might better integrate some of these ideas, of instrumentability. I'm not sure if it's actually necessary though; maybe having all these code assemblers living in userland libraries is fine.
Thanks for the link! Not sure if I've run into this VPRI / Warth combo paper, & worth revisiting either way.
I don't know if you are aware of that, but at the time Pascal started emerging, the exact same arguments were presented by foiks used to BASIC that having the ability to add your own "words" to the language would inevitably lead to a mess.
Why didn't it happen? Because programmers overall are reasonable folks. So, yes, in theory, you can define a factorial function and call it "Not_a_Cat" (technically, it is true), but nobody does that.
Similarly, giving the ability to define `X in Y..Z` makes code more readable if you use it right, not less.
I'm not too sure about the dates, but the rough history is this:
LX: Langage expérimental (~1992) Ada like with "pragmas" extending the language
LX: Langage extensible (1998): Rewrite with documented object-oriented parse tree
LX/XL: Extensible language (2000) based on object-oriented parse tree, cross-language framework called Mozart, that also had a Java front-end called Moka
XL2: Extensible language (2002) based on simple parse tree, 8 node types, Ada-like in syntax
XL2: Self compiling compiler (2005?) with same 8-node parse tree, Ada-like
XLR: LLVM-based functional variant (2008-2009), same parse tree, functional, very simple, library-defined if-then-else
Tao3D: real-time 3D graphics running on XLR (2010-2015)
ELiOT / ELFE: Distributed programming (2015?), based on interpreted version of XLR
XL: Reconvergence of all of the above (WIP), all merged, implemented as a library with a tiny front-end.
To be honest, the real issue with LX / XL / Tao3D is that I never ever really "finished" any implementation. By the time things were working, I had new ideas and broke things again. So except for Tao3D, I never really delivered a version of the language that was solid enough.
I'm trying to work on that now, which is why I'm presently spending so much time on documenting where I want to go. The idea is that if I first write a "spec", then a community can build to implement it, and it's not just my own (limited) time.
So if you are interested in helping right now, I'd say: read the doc (in progress) and send comment / doc fixes.
What you did there is very cool! I am speaking for both LX as presented in the old link and the new work that you are doing.
Personally I have given up creating a new programming language about a decade ago because I realized no matter what language I create, people will not use it, it it comes from a random github page.
Also, existing languages cover almost all business needs and while languages like LX provide a lot of improvements, the cost of change seems to be greater than the cost of not having these improvements.
As for ideas, what I'd like to see in a programming language is signal-based programming: the execution flow of a program is not 'one instruction after the other' but reactions to signals. A program shall be built by wiring output signals to input signals.
I'd also like to see types morph based on run-time conditions.
The most fundamental problem of all the current programming languages is that types are too rigid and don't allow for catching all the possible outcomes. For example, a File morphs between a closed file and an opened file, however in current systems any operation can be applied to a file, irrespectively of whether the file is actually opened or closed.
I believe that the combination of signal-based programming and type morphing will increase the reliability of programs, leaving only bugs that cannot be proven to be solved due to their nature (aka like the halting problem).
I may not be necessarily correct, but I have a strong belief in the above.
> no matter what language I create, people will not use it, it it comes from a random github page.
Speaking as a fellow sufferer, how did perl, python, php, lua, ruby start getting used? They were pre-github, but jq really did start that way: https://github.com/stedolan/jq.
The key to being used is a usage: a problem to apply it to. If there's a problem that people need solved, and your language is much better than the alternatives, then people will use it, post about it, rave about it. If JSON wasn't popular, jq wouldn't be popular.
OTOH your actual interest is in more abstract ideals. This is crucially important work, but you may be right that no one will use it... instead, they'll be interested in the ideas you are interested in. Finding a needed application of your ideas will generate use.
'Random github page' means there is a plethora of new programming languages to chose from (due to easiness of sharing projects that github allows) and studying of them all to see if they solve any new issues or improve things so much that it makes economic sense to work on this new language becomes increasingly more difficult.
In the pre-github days, candidate programming languages were fewer and solved yet-almost-unsolved important problems. The more you go into the past, the easier it is to get your foot in the door.
> studying of them all to see if they solve any new issues
But you don't find them that way - you look for a solution to your problem, and you come across them. That's why they say "scratch your own itch"; someone else might have that itch too.
You search for JSON transformation, you get jq (that's how I found it, some years ago).
You're right that it was easier earlier. But there are new-unsolved-important problems all the time --- and "solutions to problems" radically narrows the search space.
>> For example, a File morphs between a closed file and an opened file, however in current systems any operation can be applied to a file, irrespectively of whether the file is actually opened or closed.
But not in Rust. As a matter of fact anything based on intuitionistic logic could do that for you (e.g. use-only-once, must-use, etc).
My own realization that I'll probably never do anything on the frontier of language design hasn't killed my interest in designing a language, but redirected it.
These days my thoughts drift towards novelty and niche domains. What would be the most interesting way of describing a subset of things? The most fun? The most intuitive? What's a way to break a specific domain down into a vocabulary that lets you populate it while forgetting you're even using a computer?
I think there's still a lot to explore even if you aren't shooting for maximum productivity or even general-purpose programming.
others say typestates, but Scala and Haskell have had IndexedStateT for the purpose of typelevel-state-machinery and it works really well with (somewhat lesser) boilerplate and semantics + FP. To me, it's particularly useful for anything resembling a protocol.
Signal based processing is Observables/reactive streams, which provide a sane interface to use.
This is (one of) the problem with new languages: library ecosystem access. It's why Scala/Clojure/Kotlin is one camp of languages and Zig/Rust is in another - both Java and C have a ton of great libraries written in them, with ones that add signals-first approaches via libraries.
You can look into SIGNAL, esterel, lustre, Céu... dataflow programming has been developped since the 80s and has some markets where it is extensively used (avionics, digital audio and digital art, simulation...)
Having played around with XL, Tao3D and Elfe, I have to say there was/is a lot of fun to be had and some very compelling concepts and unique ideas in these projects. Its great to see them mentioned on HN. I found the parse tree approach very educational and its a very nice and powerful alternative to S-expressions. Tao3D was an very quick way to build simple interactive graphics apps and a lot of fun. ELFE has some interesting concepts for distributed computing. While I ended up using Erlang and LISP rather than ELFE it was defintely eye opening in a good way and reminded me of the fun and creativity to be had - - so a huge thank you for the past projects and good luck with the next evolution.
But I'm reading the whole thing now. Very interesting language! I don't see myself using it in production any time soon, but it looks like a wonderful tool for programming languages research. Thank you again!
So I was thinking about something similar to this in the sense of a language where syntax was extendable but with making different choices. I was interested in forming some sort of base lingua franca with additional composable dialects that are available per translation unit. Imagine if you could take go know for sure you don't have any concurrency in a section or the memory management section is missing so no worries about memory management. Increasing expressiveness but also reducing cognitive load to the calling code and its interfaces and nowhere else. Want to run very complicated domain specific code and not have the guy who designs the webserver know anymore than what is nessecary to rout it great. Want to add hot code,io, complexity annotations in the code, Great(Obviously this isn't free you need good tooling and to do sampled profiling and for complexity you need to make choices about what code is complex, etc.But if we're dreaming why not dream big.). Metrics,Explicit resource bounds etc. In this context for the things most people would want i.e. concurrency you would have a readily available dialect that fits 80% of use cases which would be infrequently changed. I don't know if that makes much sense in what you have in mind but I did find what you're doing interesting.
I have some hopes that Red Hat has a strong-enough future value for IBM that we end up redefining IBM rather than the other way round. There are precedents, notably the Apple/NeXT merger. Today's Apple is 95% NeXT and 5% old Apple. Can this happen here? Time will tell.
An an IBM employee, I definitely hope that some of the RH culture rubs off on us, but I also hope that RH retains its own distinctive identity and isn't altered very much by the deal aside from having access to IBM's resources such as the scale of the sales organisation.
Definition of 'if' statement: https://github.com/c3d/xl/blob/fast/src/builtins.xl#L155
Definition of loops (https://github.com/c3d/xl/blob/fast/src/builtins.xl#L222)