I'm working on implementing a programming language all my own(eli.li)
eli.li
I'm working on implementing a programming language all my own
https://eli.li/to-the-surprise-of-literally-no-one-im-working-on-implementing-a-programming-language-all-my-own
51 comments
I love that you are using colon for the assignment operator. This is absolutely correct. Most languages use the equal sign as the assignment operator in most contexts and then the colon in limited contexts. This comes from Fortan and its just wrong. The equal sign should be reserved for comparisons, because that is what it means in mathematics.
> The equal sign should be reserved for comparisons, because that is what it means in mathematics.
This is touching on a pet peeve of mine: Mathematics and programming are similar in many aspects, but this is not one of them. In mathematics = is not a comparison, but a statement.
More generally, mathematics is about tautologies, that is statements that are always true. In programming, a comparison is evaluated to either true or false.
That doesn’t mean that there’s no room for conditionals in mathematics (one example is piecewise function definitions). But it’s not the same. Heck, even the definition of “function” is different between mathematics and programming.
This is touching on a pet peeve of mine: Mathematics and programming are similar in many aspects, but this is not one of them. In mathematics = is not a comparison, but a statement.
More generally, mathematics is about tautologies, that is statements that are always true. In programming, a comparison is evaluated to either true or false.
That doesn’t mean that there’s no room for conditionals in mathematics (one example is piecewise function definitions). But it’s not the same. Heck, even the definition of “function” is different between mathematics and programming.
That's why procedure is so much better of a name. It's not a hill I'm willing to die on but I think it's correct.
And let's use the keyword "go-to" to run a function, back to the basics basically ಥ ‿ ಥ
ok maybe not that, that was awful.
Seconded. Languages could even use "function" only for pure functions and "procedure" for everything else. Pascal uses "procedure" for things that don't return a value, but I think the pure vs. side effect distinction is more useful.
In languages that have block scope a procedure is that block. It’s a boundary but receives no input and does not return output. Functions do allow input and do return output. This distinction is clear in C lang that has both functions and procedures.
As a new language design feature procedures could be assigned to references for reuse in the same way as calling a function by name/variable.
As a new language design feature procedures could be assigned to references for reuse in the same way as calling a function by name/variable.
I've never heard of blocks in block-scoped languages being called procedures. I feel like the word "block" is well understood and serves the purpose fine. In lots of other languages, things called procedures do take input, like Ruby, which has first-class Procs like you mentioned.
I'd like to see language designers make function calls happen in the order you read them.
For example, in most languages you have a notation like f(g(h(x))) which calls the functions in the exact opposite order of reading which is unnecessarily confusing.
For example, in most languages you have a notation like f(g(h(x))) which calls the functions in the exact opposite order of reading which is unnecessarily confusing.
You would probably enjoy the UFCS https://en.wikipedia.org/wiki/Uniform_function_call_syntax of Nim, D, etc. Basically `h.g.f(x)` or in Nim you can drop the parens and say `h.g.f x` { but it may not scale past a single argument }. This tends to be only "an option" - more on the "allow/enable" side than the "force them" to do it side, though.
Even this is wrong. Programming should be explicit and easy for anyone to read.
Nope, make it explicit. You're moving the value of an expression to a placeholder. The only sensible way to write that would be
c = a + b;
Nope, make it explicit. You're moving the value of an expression to a placeholder. The only sensible way to write that would be
ADD a TO b GIVING c
> because that is what it means in mathematics
Personally, I think this argument only holds water for languages that are rooted in mathematics (e.g. Haskell, Lean, Rocq, F*, ...). If your computational model comes from a place of physical hardware, instructions, registers, memory etc. you're going to end up with something very different than an abstract machine based on lambda calculus. Both valid ways to design a PL.
Personally, I think this argument only holds water for languages that are rooted in mathematics (e.g. Haskell, Lean, Rocq, F*, ...). If your computational model comes from a place of physical hardware, instructions, registers, memory etc. you're going to end up with something very different than an abstract machine based on lambda calculus. Both valid ways to design a PL.
[deleted]
what about:
f(x) = x * 2
Thats what the parent said, shouldnt be used for assigment
It's not a comparison either. OP's statement is just wrong; the obvious meaning of = is equality. For the definition of a pure function, = is the obvious symbol to use since the RHS can be substituted in for the LHS in any context.
-> for definition is just annoying. On every keyboard layout, it takes two strikes to type, possibly with shift involved.
-> for definition is just annoying. On every keyboard layout, it takes two strikes to type, possibly with shift involved.
Use ≟ for comparison. I don't know where to find it on my keyboard, though. Maybe language designers should invent a keyboard along with their language.
Yes. I too thought it was this. It is equality, and thereby lets you rewrite one side into the other side.
Then again I quite like rewriting languages like Mathematica and lean
Then again I quite like rewriting languages like Mathematica and lean
I’d argue there’s a very big difference between “x: y” and “x : y”. I can only see the former as assignment and the latter as the has-type relation.
(I find it baffling in the extreme that in many mainstream languages the convention is to write type annotations as “x: T”, both prima facie and because in those languages the notation then collides with field assignment!)
(I find it baffling in the extreme that in many mainstream languages the convention is to write type annotations as “x: T”, both prima facie and because in those languages the notation then collides with field assignment!)
> The equal sign should be reserved for comparisons, because that is what it means in mathematics.
"let x = 1" has the same meaning in mathematics as well as JavaScript and Rust.
"let x = 1" has the same meaning in mathematics as well as JavaScript and Rust.
To push back a little: Designing the syntax of a programming language always involves tradeoffs; nothing is "just wrong". For better or worse, equal sign as assignment has become widely used and understood. I think the author's use of colon is neat, but it is confusing if you're used to seeing that as the type indicator; again, a tradeoff. I like the look of := as the assignment operator but it adds another shifted key to type, which can push you that much closer to RSI for such a common operation.
> I love that you are using colon for the assignment operator. This is absolutely correct.
Historically, distinguishing an equality operator from an assignment one has existed for many decades. Whether using colon for the latter is "absolutely correct" is the subject of valid debate.
An equally compelling case could be made for any of the following assignment operators as well:
Historically, distinguishing an equality operator from an assignment one has existed for many decades. Whether using colon for the latter is "absolutely correct" is the subject of valid debate.
An equally compelling case could be made for any of the following assignment operators as well:
foo <- 42
foo -> 42
foo <= 42
foo => 42
foo <-> 42 if expressing substitutability is important
foo := 42 Pascal lives!
(foo 42) so does LISP!
foo is 42 for those who prefer English operators
f(foo) = 42 for mathematically inclined languages
Mathematics, famous for consistent readable notation. Next idea should be to just stop declaring variables at all assuming they mean what they usually mean in similar programs.
Starting array indexes from 1 instead of 0 is another one although that was already tried :)
Awesome, I've been doing the same thing for the past 15 years. It's one of the most stimulating activities I've found within software.
I recently sat down and put together the beginnings of a framework to play around with or use as a starting point.
https://github.com/codr7/shi
I recently sat down and put together the beginnings of a framework to play around with or use as a starting point.
https://github.com/codr7/shi
Also check out the small wonder currently not trending: https://news.ycombinator.com/item?id=45062168
This is great! I love projects like this! I have a hobby of making toy programming languages. (Not arguing that's what yours is.) I once made a compiler, but lately I'm satisfied with making interpreters. Executable asts with moderate rearranging capabilities. It is an addictive thing. It started when I wrote a query language for my graph database server back in 2006. I didn't know about property graphs when I started, but that's what it ended up being, and I had to make a query language for it. (I wanted to call it AQL for "associative query language" but turns out that acronym was already taken. I can't remember by what.) I learned how to do it from the dragon book -- cuz I'm old. Anyway, you struck a chord with me. Making a syntax highlighter that's able to resume on errors is an interesting challenge that teaches you a lot about both sides, the front end and the back end.
Very cool. I think everyone should try making all of these foundational technologies themselves: A programming language, an OS, a bootloader, etc.
It's one thing to read about them in books, but you learn so much nuance by actually stepping through the inherent problems and difficulties in actually making them work.
It's one thing to read about them in books, but you learn so much nuance by actually stepping through the inherent problems and difficulties in actually making them work.
This sounds good in theory, but a jack of all trades is a master of none. I once spent a semester building an interpreter compiler for very simple LR(1) parsable languages. I learned a lot, but that knowledge fades rather quickly and even despite this significant investment of time, I never came close to being able to touch anything production worthy.
Modern tech is too advanced to meaningfully learn about it by tinkering with small toy projects. These "foundational technologies" are gigantic specializations that require an extraordinary investment of time to master.
Looking back now over the years, I wish I tinkered less and narrowed my focus more.
Modern tech is too advanced to meaningfully learn about it by tinkering with small toy projects. These "foundational technologies" are gigantic specializations that require an extraordinary investment of time to master.
Looking back now over the years, I wish I tinkered less and narrowed my focus more.
Rawk deserves it’s own HN post: https://eli.li/make-awk-rawk
Fun, nice work. Side comment, but it feels like this would make a nice match with Jade/Pug[0] HTML syntax for a clean front end experience
[0] https://github.com/pugjs/pug?tab=readme-ov-file#syntax
[0] https://github.com/pugjs/pug?tab=readme-ov-file#syntax
It has the best license[0] I've ever had the pleasure to read!
...where is the source code?
[0]: https://smallandnearlysilent.com/baba-yaga/LICENSE.txt
...where is the source code?
[0]: https://smallandnearlysilent.com/baba-yaga/LICENSE.txt
That's neat! But please kill the semicolon if you can. It's too 20th century already.
Why? It's a good grammatical equivalent to the full stop for the programmer. It can serve as useful context for the compiler. And it's only one character. Antagonism over semicolons is another strange symptom of conciseness at all costs. If you want APL, just use APL.
I always thought ending programming statements with a period '.' like in Prolog was more elegant.
> If you want APL, just use APL.
Or Python, Go, or Typescript.
Or Python, Go, or Typescript.
A counter argument is It’s meaningless for the developer and high level programming is writing for people not things.
That’s why when we write, we use commas and periods. It tells the reader when a thought ends and the next begins. A semi-colon is the traditional period in programming. Not everything fits on one line. Python managed to pull it off and now everyone thinks it’s the right way… it’s just “a way” but by no means modern or right. JavaScript made them optional, but it results in ambiguous parsing sometimes, so it’s not a good idea there either.
In any case, I doubt a run on sentence is “meaningless” but it is hard to parse.
In any case, I doubt a run on sentence is “meaningless” but it is hard to parse.
Is it generating wasm/wasi ?
looks just like Haskell
Terry Davis reincarnated
Good luck on the continued progress of your project; it can be deeply satisfying!