|Hazel Levine 0171f9cab0||3 months ago|
|.gitignore||4 months ago|
|LICENSE||4 months ago|
|README.org||3 months ago|
|x.png||4 months ago|
The Tent(ative) programming language is a language that doesn't exist and probably never will. Any questions?
In short, this is a research project for myself, and an effective playground for PLT. I do not expect anyone to use this, and frankly I do not expect to finish this. I hope this helps me to retain my sanity over a summer in quarantine.
When reading through the specifications for other programming languages, the "softer" elements of language design very rarely get brought up, nor does accessibility. Take the example of Rust, which is a language whose semantics fail to line up with its syntax, which leads to line noise. (I like Rust, but…)
Furthermore, one of the things that nearly never gets brought up in language design is that of accessibility. Namely, I know multiple dyslexics who are effectively left unable to read Lisp due to the syntax giving them a literal headache. If the language is unable to be readable, it needs to be redesigned.
This has a double meaning. The language must be Turing-complete, and it has to work. Given my own inability to finish projects, this one will be difficult.
Furthermore, the language should generally follow a functional paradigm. Unlike Haskell and the like, I expect mutability to be rather common, and have no intent of implementing means of reducing side-effects such as the IO or State monad. However, whenever purity is possible, it should be used.
I haven't decided exactly what this means in the context of this language yet, as I have very little idea as to the language's semantics.
Self-explanatory. CFGs are far easier to parse. This also goes hand-in-hand with quality syntax.
Racket is a wonderful language for writing other languages. Namely, Racket
grants the ability to entirely avoid details like file I/O. This allows me to do
very little more outside the language itself aside from facilitating
#lang tent. It also means interoperability with Racket code, ideally, which
if this project is ever finished would make it far more useful.
Rust had it right with
let mut for explicitly declaring variables as mutable.
Given that no direct restriction on side-effects will be given in this language,
explicitly declaring mutability is a fair compromise.
The Haskell/F# and like way of doing:
x = some_func 2 x' = some_transform x
is in my mind far superior to shadowing. In many contexts, shadowing is sometimes more obtuse than mutability, and reduces readability of a language.
In Haskell and Typed Racket, the type definition of a given function largely serves as a form of documentation – you can often determine what a function does at a glance by reading its type. I want this to be applicable to Tent.