Re: [ANNOUNCE] Ajla: a new purely functional programming language

On Mon, 27 May 2024, [email protected] wrote:

> On 26.05.24 23:57, Mikulas Patocka wrote:
> > Hi
> > 
> > I'd like to announce the release of Ajla - a new purely functional
> > programming language that looks like traditional procedural languages.
> > 
> > If you are interested, see https://www.ajla-lang.cz/
> 
> Just one thing that caught my eye:
> 
> > Ajla has efficient mutable arrays - if an array's reference count is one,
> the array is modified in place. If not, a copy of the array is created and
> modified.
> 
> That design decision restricts you to reference-counting garbage 
> collectors. These have multiple problems and restrictions, such as:
> - Inability to deal with reference cycles.

You can create circular lists in Haskell, but not in Ajla. I.e. the 
statement "var cycle := [ 1, 2, 3 ] + cycle;" won't compile, because the 
variable cycle is not known.

> - Assigning to a reference means TWO additional write operations to keep 
> the reference counts up-to-date; this means your programmers will try to 
> minimize allocation, which tends to restrict the design space so the 
> code gets worse.
> - Reference counting is less efficient than copying collectors for most 
> cases.
> - Being restricted to one GC algorithm means the language cannot improve 
> on that front, the GC approach is baked into the language semantics and 
> cannot be changed if it turns out it was an unlucky choice.

Ajla has possibility to bypass the reference counting - if the refcount is 
-1, it means that the object is stored in a read-only memory-mapped file 
and the refcount won't be updated at all.

So, if I find some workload where there would be many threads massively 
thrashing on the same reference count, I could set it to -1 and let some 
primitive GC free it. So far, I haven't found such a workload, so I 
haven't implemented it.

> I'd recommend doing something like the borrowing semantics in Rust, or 
> uniqueness typing of Clean: Some language mechanism that makes sure that 
> all mutable data is only accessible through a single reference at any 
> one time.

If you use arrays in the same way as unique types, there would be no 
refcount modification. I.e. if you pass an array to a function and stop 
using it in the parent function, there is refcount increment followed by 
refcount decrement - and the optimizer will fuse these two refcount 
operations into nothing.

> This will also allow compilers to aggressively optimize, since if a 
> language enforces a one-reference-to-mutables-only, there can be no 
> aliasing, and that's a huge win as any even merely potential aliasing 
> prevents a whole host of important optimizations.

I've written SSA-based optimizer for Ajla (see the file 
newlib/compiler/optimize/ssa.ajla) and it was surprisingly easy because 
there is no aliasing. From the user's point of view, every variable can be 
modified independently. Modifying a single variable doesn't modify any 
other.

Mikulas

> Just my 2c :-)
> 
> Regards,
> Jo
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.