> First, let's write a standard that's as polished as it can be. Then, once the standard is ready, we can start making it real.
I've learned on several occasions that things don't actually work that way. Writing the actual code and running/testing it is the only way to ensure that your ideas will indeed work and that you didn't miss corner cases. Except of course if the problem at hand is trivial, but that's clearly not the case here, and I feel like trial and error will be much necessary.
Note that this isn't only true for code. It's about writing in general, even when doing theoretical science that doesn't translate to code in the end.
There is a PhD Comics, I think, where a character says something like "remember kids, the only difference between fooling around and doing science is writing it down". Exactly.
---------------
From the todo list:
> procedural, functional, imperative?
Authors should probably also look into reactive programming and dataflow languages such as Lustre, Esterel, ReactiveML, etc. Probably some good inspiration there for this kind of tasks :).
That's from Adam Savage on Mythbusters. Here's the exact wording and where he got it: https://imgur.com/1h3K2TT/
When you are doing a second system you've already experienced the architecture you get when you explore by the seat of your pants. You've built some intuition, but you've hit the point when you need larger and more formal plans.
In this case the designer may not have previously even wanted or considered writing a programming language, but realized the generality and complexity of their ambitions required the very formalism of a programming language, and then that the plan was a real part of the finished product.
It might work (maybe) if your goal is "reimplement a popular language but fix the mistakes". Eg "we're gonna build on [langA] but allow breaking changes and call it [langB]".
Lots of examples where that hasn't worked, but then there's lots of examples where new languages just fail regardless of pedigree.
Chata probably needs to work out roughly what the semantics of the language should be. Its good to know what the library support is intended to be as that informs language design (assuming the library is to be implemented in chata anyway). Quite a lot of this page is about syntax.
There are some design decisions that have deep impact on programming languages. Reflection, mutation, memory management, control flow, concurrency. There are some implementation choices that end up constraining the language spec - python seems full of these.
Echoing p4bl0, implementing the language will change the spec. Writing a spec up front might be an interesting exercise anyway. I'd encourage doing both at the same time - sometimes describe what a feature should be and then implement it, sometimes implement something as best you can and then describe what you've got.
Implementation language will affect how long it takes to get something working, how good the thing will be and what you'll think about along the way. The usual guidance is to write in something familiar to you, ideally with pattern matching as compilers do a lot of DAG transforms.
- I'd say that writing a language in C took me ages and forced me to really carefully think through the data representation.
- Writing one in lua took very little time but the implementation was shaky, probably because it let me handwave a lot of the details.
- Writing a language in itself, from a baseline of not really having anything working, makes for very confusing debugging and (eventually) a totally clear understanding of the language semantics.
Good luck with the project.
8<------------------
If adding a value to a type where the result exceeds the type's maximum capacity in either the positive or negative direction, the type must remain at its previous value.
Note
This means that if you add 1 to an int at value 2^31, it will stay at 2^31. This is also called "saturating" a value.
Naming for an international audience is hard.
There is also https://github.com/mimium-org/mimium
And: https://github.com/digego/extempore
Disclosure: I am the developer of Glicol.
Noise cancelling works by emitting a synchronised inverse of the sound wave to cancel.
