another programming language
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Hazel Levine 0171f9cab0 i am naive 4 years ago
.gitignore Initial commit 4 years ago
LICENSE init commit 4 years ago
README.org i am naive 4 years ago
x.png init commit 4 years ago

README.org

The Tent(ative) Programming Language

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.

https://git.qtp2t.club/hazel/tent/raw/branch/master/x.png

Why Tent?

Fuck, iunno.

Design goals

Syntax as a high priority

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.

Functional

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.

Strict typing

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.

Expressible as a context-free grammar (mostly)

Self-explanatory. CFGs are far easier to parse. This also goes hand-in-hand with quality syntax.

Target Racket

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.

Syntax (ideas) and rationale

Explicitly declaring mutability

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.

No shadowing

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.

Separation of the type definition

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.