Notices by WimⓂ️ (wim_v12e@merveilles.town)

Finally, my #Funktal compiler can emit correct #Uxntal for some simple examples.

The first one shows named functions, lambda functions and primitive types:

functions {
sq = (\Int <- x:Int. x x *)
}

main {
6 7 (\ Int <- x:Int <- y:Int . x y * sq )
print
}

Funktal uses postfix notation for expressions and types. In Haskell, the sq function would be

sq :: Int -> Int
sq = \x -> x*x

The second example shows the use of an algebraic data type, a tuple:

types {
Tup = Int Int MkTup
}

main {
6 7 MkTup (\ Int <- (x y MkTup): Tup . x y * )
print
}

MkTup creates a tuple of two integers. In Haskell this would be

data Tup = MkTup Int Int

The lambda function pattern matches on the type, so x and y bind to the stored values.

#Funktal

Currently, there is no type checking. It's all very bare bones, an awful lot is still missing. There isn't even a compiler executable yet. But I think progress should be a bit faster now. #Funktal

@neauoire 😊 The main difference with those languages is I think that I use the type system to create data structures.
Without the algebraic data types, it maps quite directly to Uxntal: the lambda arguments are just memory locations. And the postfix notation makes everything very easy.

The problem with #Funktal, my functional language for #Uxn, is that very likely, nobody will want to use it because it lacks features. You know how this goes: if I release it bare-bones, a few people try it, they will be put off because of the lack of what they consider essential features, and that's it, as you have only ever one chance.

Also, implementing syntactic sugar is a lot of work, and from my perspective, not a lot of fun. The fun bit is cracking the problem of creating a proper statically typed language in an ultra-low-resource environment like Uxn. I don't think I will be able to motivate myself to implement all these additional features.

So I guess I will focus on the bare bones, and the value in it will be that I will be able to explain how to create something like this.

@neauoire And for someone like me, this language, Theseus, is even more interesting:

https://github.com/chessai/theseus

The paper is more detailed:

https://cs.indiana.edu/~sabry/papers/theseus.pdf

@neauoire @d6 @alderwick It's not specific to quantum computing. If we want super-low-energy computing, we need reversible computing. Quantum computing is reversible, but there are other ways, for example ballistic deflection transistors. They use the same set of reversible gates. See e.g. https://research.ijcaonline.org/ncict/number8/ncict058.pdf

@neauoire @d6 @alderwick For CMOS, the overhead means you don't actually save any energy. It's one of the candidates for "beyond CMOS" technologies.
Another problem is that the one you have been discussing: if your algebra has an annihilator, your computation is not reversible. So basically we would need to compute and program in quite a different way.

@neauoire I was thinking about the problem with the actual mathematical operation. But I think that is a false problem in this context. I think that is not what is meant by reversible.
I found an interesting programing language that implements time-reversible computation:

http://revcomp.info/legacy/mpf/rc/janus.html

Training GPT-3 generates 550 ton of CO2.
To put this in perspective, if you had a wood-burning stove, you'd need to burn logs of wood continuously for more than 10 years to produce the same amount of CO2.
#FrugalComputing