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?
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.
No, it can operate on a data structure as well. There's string rewriting which does operate on text (but this can be stored in a structure amenable to applying rewrite rules versus brute force copying it or something silly). For term rewriting, there are plenty of efficient ways to store and operate on the information besides just textually.
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.
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.
ok. sorry, so the issue is not that some of the runtime data is being interpreted as types, its that decisions are being made based on the data and not solely on the structure of the program.
In the most general sense yes. However you can encode whatever you want on top of a trs, just like how you can encode any computer language in lambda calculus because both are Turing complete models of computation.
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
Similar to LISP in that sense.
https://maude.lcc.uma.es/maude-manual/maude-manualch1.html#x...
Mathematica is at least semi-mainstream. Not sure of any other examples though.