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

81–87 of 87 posts

Re: XL: An Extensible Programming Language

#81

Post by samatman »

diggan wrote: post #80
samatman wrote: post #59

Earlier quoted context omitted.

> Are there any that come close to the usage of lisps with proper s-expressions? If you consider Julia a Lisp, which I would argue you should, it may be the most widely-used Lisp currently. The only way you'll see an s-expression is is to call Meta.show_sexpr. If you consider Dylan a Lisp, you should consider Julia a Lisp as well. If you don't consider Dylan a Lisp, I have to conclude that you consider the s-expressi…

> If you consider Julia a Lisp Maybe, but would you consider Julia a Lisp without parentheses, which was the context here? Because after looking at their documentation ( https://docs.julialang.org/en/v1/manual/methods/ for example), it seems to have as many parens as any other lisp, just postfix notation rather than prefix notation, `f(Float32(2.0), 3.0)` vs `(f (Float32 2.0), 3.0)`. Arguing about what makes or doesn…

Given you said

> lisps with proper s-expressions

It's off-putting for you to fly in and pretend to be surprised that Julia uses parentheses in a way consistent with other languages which are syntactically Algolic. Apologies for expecting a serious conversation, didn't know who I was dealing with.

Re: XL: An Extensible Programming Language

#82

Post by thechao »

5- wrote: post #63
thechao wrote: post #8

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 yo…

take a look at https://pdos.csail.mit.edu/archive/xoc/

Hey, neat! However, this line of research (which I'm passingly familiar with) is about extending the grammar of the host language (for Xoc: C), along with the semantics (for Xoc: the Zeta interpreter). I think I'm interested in a slightly rotated design space: the C grammar is left alone[1]; instead, an extension of the C spec defines a specific API for (effectively) code injection; and, finally, we limit ourselves to new types and functions, possibly with non-standard sizing (`sizeof`/`alignof`/...) information.

[1] Modulo the introduction of `_Load("...")(__args__)`, and a few other function-like invocations.

Re: XL: An Extensible Programming Language

#83

Post by c3d »

mapcars wrote: post #58
c3d wrote: post #29

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 ;-) An interesting derivative of XL is Tao3D, which shows what you can do with it. https://tao3d.sourceforge.net A FOSDEM workshop about Tao3D (which includes initiation to XL): https://www.youtube.com/watch?v=uE9LwSuZD64 The design philosophy, and why it…

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?

The current state is "on backburner by lack of time". Projects like https://grenouillebouillie.wordpress.com/2022/03/07/a-theory... and https://github.com/c3d/DB48X-on-DM42/tree/stable have been consuming most of my spare time cycles.

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.

Re: XL: An Extensible Programming Language

#84

Post by mapcars »

c3d wrote: post #83
mapcars wrote: post #58

Earlier quoted context omitted.

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?

The current state is "on backburner by lack of time". Projects like https://grenouillebouillie.wordpress.com/2022/03/07/a-theory... and https://github.com/c3d/DB48X-on-DM42/tree/stable have been consuming most of my spare time cycles. 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…

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.

Re: XL: An Extensible Programming Language

#85

Post by TOGoS »

dkjaudyeqooe wrote: post #24

I've been working on something centered around extensibility, or metaprogramming, coming from a strictly imperative angle, with the belief that anything else (functional, relational/logic based, whatever) can be built on top of that. A few guiding principles are: - simplicity above all, with as few fundamental elements as possible - the parser is a separate issue, just write your own syntax to avoid the most divisive…

That's interesting, because I've been 'working on' something with all those same bullet-points. I'd be interested to hear more about your take on this!

Some notes on my lack of progress: http://www.nuke24.net/plog/43.html

Re: XL: An Extensible Programming Language

#86

Post by Nevermark »

bradrn wrote: post #12
mapcars wrote: post #9

Earlier quoted context omitted.

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.

It's just a case of a pattern definition including references to itself, which are then linked to its definition before use. In the same way function definitions often contain reference themselves, which are linked to complete the definition.

   uint64_t alignBitsLeft(uint64_t x) {
      return ((x >> 63) == 1)) ? x : alignBitsLeft(x
The pattern "alignBitLeft(uint64_t)" definition starts in line 1, but is not completed until line 3. Yet line 2 references that pattern, before the definition is complete.

This works, because of a linking step at definition completion, where the "alignBitsLeft" reference gets linked to the now complete "alignBitsLeft" definition.

Similarly for:

> loop Body is { Body; loop Body }

The "loop Body" definition beings, including a reference to itself. Once the whole definition has been built up, the "loop Body" reference gets linked back to the "loop Body" definition. Ready for use.

--

Another way to look at this is memoization (at compile or run time). When you evaluate the second line of this:

  n is 1;
  loop { print n; n is n + 1; }
You get this:

  { print n; n is n + 1; loop { print n; n is n + 1; }}
If we cache that definition before evaluating it, when we get to the embedded loop clause, we don't need to compute it again. We have already computed that exact loop pattern before and can reuse the result (over and over).

Re: XL: An Extensible Programming Language

#87

Post by diggan »

samatman wrote: post #81
diggan wrote: post #80

Earlier quoted context omitted.

> If you consider Julia a Lisp Maybe, but would you consider Julia a Lisp without parentheses, which was the context here? Because after looking at their documentation ( https://docs.julialang.org/en/v1/manual/methods/ for example), it seems to have as many parens as any other lisp, just postfix notation rather than prefix notation, `f(Float32(2.0), 3.0)` vs `(f (Float32 2.0), 3.0)`. Arguing about what makes or doesn…

Given you said > lisps with proper s-expressions It's off-putting for you to fly in and pretend to be surprised that Julia uses parentheses in a way consistent with other languages which are syntactically Algolic. Apologies for expecting a serious conversation, didn't know who I was dealing with.

The root context of the conversation you injected yourself into, was about lisps without parens. It's OK to misunderstand, but please don't blame me for your own misunderstanding.

Have a nice day!

Post reply on HN