I'm really annoyed when lisp languages use infix operators. Is it really so hard to write (= (f a) b) over (f a = b)? In fact, can you even call it lisp if the first element of the list isn't the operation of that list? Perhaps if they had a special bracket type for definitions I would be more amenable to it, but the idea that a symbol half way through a list completely changes its meaning simply doesn't sit right with me. Isn't this just a term rewriting system with an extra pair of parentheses?
Looking at BNF, "=" is not an infix operator here, it's syntactical separator between part describing a function input, and resulting expression. Though I agree it looks a bit foreign anyway
Agreed. This reminds me – and I wonder if it could be applied – to Computational Type Theory, which relies on a similar concept of "reducing" types to their primitive forms, actually taking computation into account (something type theories normally do not!)
I watched all 5 videos a few years ago. And if I understand it correctly "Computational Type Theory" basically defines a type as describing the behaviour of a computation.
Which is really interesting but kinda hard for me to wrap my arms around compared with Martin Loff type theory. It looks as if type checking will have to be done manual, using N axiomatic rules for how you can prove A from B.
Is that your understanding as well?
Also, there doesn't seem to be much material on Computational Type theory online. Any good references? (Except for the nuPrl book of course).
Here's a little zine on multiset rewriting(unordered term rewriting), John Conway said(about Fractran in The Book of Numbers) that it is such a simple paradigm of computation that no book is needed to learn it, and it can be taught in 10 seconds.
I would argue that it is more "primordial". After all, computation is first and foremost a human activity, generally performed using pen and paper, which involves a good deal of rewriting (computers were originally people). The machine only came later as a way to simulate this human activity. Its meaning is entirely contingent on the primordial notion. It have no meaning on its own.
This is very cool! I'm actually working on something very similiar, as I wanted a scripting language with very robust pattern matching and macro-like capabilities with term rewriting for writing DSLs. Seeing this project is very inspiring, nad it seems we have very similiar ideas, my original idea was also that undefined terms would just be the way to construct data types. However, I want the lazyness to be optional in my language, and for completely undefined terms to throw errors as I think the ergonomics of just treating undefined terms as valid data would be a bad programming experience. In my (upcoming language, hopefully), data would be constructed like this:
pair a b = '(pair a b)
where ' is shorthand for quoting, like in lisp. If you want to explicitly define datatypes on demand, you can just manually quote and not use the pair function constructor. One thing I thought about to was smart constructors, like say if you want to define the mod 3 group:
zero = 'zero
s (s (s x))) = x
s x = '(s x)
if values are always constructed with either "s" or "zero", the smart constructor of s enforces you can't create any terms with an s-chain of 3 or higher, IF the function arguments are eagerly evaluated.
Yes, in term rewriting systems the only thing that matters is the lexical structure of the "program" you're running on top of the transform rules. A simple example of running a TRS is a term of a BNF grammar, a less simple one is a symbolically expanding a term in a computer algebra system.
Readit News
Also, why is this needed over the second line?
It completely abstracts away the concept of a machine, and it's simply translation as computation - but equally as powerful.
This lecture series goes into how it works: https://www.youtube.com/watch?v=LE0SSLizYUI
Which is really interesting but kinda hard for me to wrap my arms around compared with Martin Loff type theory. It looks as if type checking will have to be done manual, using N axiomatic rules for how you can prove A from B.
Is that your understanding as well?
Also, there doesn't seem to be much material on Computational Type theory online. Any good references? (Except for the nuPrl book of course).
A little book for term rewriting would be a great new addition.
https://wiki.xxiivv.com/site/pocket_rewriting