Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XL: An Extensible Programming Language

xlr.sourceforge.io

Post reply on HN
Print view View original

1–10 of 87 posts

Re: XL: An Extensible Programming Language

#4

Post by netbioserror »

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. Lisp feels like aesthetic perfection to me. Languages like Haskell and XL here just look like line noise to my brain.

Re: XL: An Extensible Programming Language

#5

Post by throwaway17_17 »

I 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, which is a change from the more common complaints of inherent complexity and compilation time. I’d love to see more discussion of this, and maybe, see a focus on smaller backends and code generation tools for compilation, like QBE.

Anyone with recommendations for reading would be welcome to dump those here.

Re: XL: An Extensible Programming Language

#8

Post by thechao »

I'd like C, but where I could use some syntax like:

   typedef _Load("libvector.so")(int) vector_int;
to add arbitrary "builtin" types to the language. The idea being that "libvector.so" would use some spec-defined API to extend the core C language with the new features. This would replace a slew of features in the core C++ language (templates, classes, any sort of reflection, etc.), with some sort of 3rd party dylib you load. The idea is to keep the core language simple in the sense that it doesn't contain its own extension mechanism as syntax.

I think my only worries would be how to handle life-time analysis, i.e., the moral equivalent of destructors, copy constructors, move-semantics, etc; maybe the dylib ('libvector.so', in this case) has to register stack-clean-up, copying, and move-semantics code-generation for the compiler?

Re: XL: An Extensible Programming Language

#9

Post by mapcars »

bradrn wrote: post #3
tempodox wrote: post #2

This seems to be Prolog with a large dose of syntactic sugar.

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 }

Re: XL: An Extensible Programming Language

#10

Post by mapcars »

netbioserror wrote: post #4

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
Post reply on HN