Re: XL programming language

[Christophe de Dinechin]

Hi Matthis,




> On 10 Sep 2021, at 16:36, Mathis De Witte <math...@icloud.com> wrote:
>
> Hello Christophe
>
> I’ve been checking out your programming language XL lately, and I think that the design is super elegant!

Thanks.

>
> I also have 2 questions which I couldn’t find an answer to:
>
> 1) Is there any place for a community around XL? Like she online chat group or something?

Well, besides the git repository, where you can file issues, there is also a Google group, xlr-talk, here: https://groups.google.com/g/xlr-talk. It is not very active, however.

>
> 2) How would scopes be implemented in XL?

This is explained here: https://xlr.sourceforge.io/#scopes-and-maps.

I assume you are talking about the internal representation of scopes, not the scoping rules?

There has been a few implementations. Right now, a scope like (X is 3; Y is 6) is implemented as a balanced version of the above, where branches can be rearranged to improve performance. It is otherwise a completely regular source tree.

> How would I make patterns with the `is` operator that are bound to scopes?

The usual way. For example, a compilation function could be written as:

compile(Source: parse_tree; Context: scope) as parse_tree




> Or: how would i declare variables that are only visible inside a certain scope?

I do not think that I understand the question.

If you are talking "at compile time", then a function like "compile" could presumably modify the scope, although that part of the compiler "framework" does not exist in XL yet (the compiler still being written in C++ at this point). In the old self-compiling implementation, that would be this code: https://github.com/c3d/xl/blob/master/xl2/native/xl.symbols.xl#L421, but I expect the interface in the upcoming native compiler to be markedly different.

If you are talking about the scoping rules in XL itself, they are quite similar to what you see in other languages, except that (at least for the moment) I am considering treating an internal exact overload to be an error.

For example:

Example is // Outer "Example"
Value is 3 // Inner "Value"
Thing is "A" // Inner "Thing"

but this would not be correct

Example is // Outer "Example"
Example is "A" // Inner "Example"

This is likely to be rejected at some point, but I'm still evaluating the implications.

>
> Maybe you could enlighten me? I hope you get to read this and respond to this mail.
>
> Kind regards,
> Mathis