11–20 of 24 posts
FWIW, "chata" in Portuguese means something like "boring" and "annoying". But at least it's not vulgar or obscene. Naming for an international audience is hard.
FWIW, "chata" in Portuguese means something like "boring" and "annoying". But at least it's not vulgar or obscene. Naming for an international audience is hard.
Interesting project :). > 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 triv…
That's from Adam Savage on Mythbusters. Here's the exact wording and where he got it: https://imgur.com/1h3K2TT/
this is a very interesting feature: 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.
The proposed mechanism is only equivalent to a saturating add when you add 1
FWIW, "chata" in Portuguese means something like "boring" and "annoying". But at least it's not vulgar or obscene. Naming for an international audience is hard.
FWIW, "chata" in Portuguese means something like "boring" and "annoying". But at least it's not vulgar or obscene. Naming for an international audience is hard.
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.
There is also https://github.com/mimium-org/mimium
And: https://github.com/digego/extempore
Disclosure: I am the developer of Glicol.
I'd love to see a comparison between Chata and Glicol ( https://glicol.org/ ) There is also https://github.com/mimium-org/mimium And: https://github.com/digego/extempore Disclosure: I am the developer of Glicol.
I'd love to see a comparison between Chata and Glicol ( https://glicol.org/ ) There is also https://github.com/mimium-org/mimium And: https://github.com/digego/extempore Disclosure: I am the developer of Glicol.
What about supercollider?