I’ve just finished up a rewrite of the parsing code in teletype. It still needs testing and (very probably) some bug fixes, but once it lands I’d like to start taking advantage of it as soon as possible.
To wit, I plan on adding some aliases to existing ops…
eg. add + as an alias of ADD, thus:
ADD 1 1
can also be written as
+ 1 1
(note that the + must still go at the beginning, you can’t type 1 + 1.)
So far I have the following in mind:
+ for ADD
- for SUB
* for MUL
/ for DIV
% for MOD
<< for LSH
>> for RSH
== for EQ
!= for NE
< for LT
> for GT
<= for LTE (and new op!)
>= for GTE (and new op!)
! for NZ
&& for AND (or & which is traditionally bitwise and)
|| for OR (likewise for |)
PRM for PARAM
TR.P for TR.PULSE
We don’t have to do all of them, and it’s important to remember that it’s easy to add new ops / aliases, but it’s much harder to remove them or rename them.
There will also be a PN.* op for every P.* op
I’m a programmer by profession (or I used to be anyway), so all of this makes perfect sense to me. But I want to make sure everyone else is okay with it. (The original ops will continue to work along with their aliases.)
I can’t say I like using infix operators at the beginning, but I guess it makes sense to add them as an alternative, to save some space potentially. not sure about &&,|| and ==. might be weird to use single characters yes, but then again its also weird to use them in the beginning (without paranthesis). wondering what others opinions are on this.
Just to play devil’s advocate - I remember speaking with @tehn about this way back when the language was being designed and it was a conscious decision not to use these.
The principle justification being that by using words it made people think less of the scripts as ‘equations’ in the way one learns in school, and instead a ‘tt command’. It was thought the prefix notation might be more difficult when using the same operators we know as applying to infix.
Perhaps the language is established enough now that we can live with it, or perhaps all of us need to think more about what it’s like for a brand new user to get on board. Obviously having them as aliases means the existing tutorials and info still applies, but I’d bet most shared examples moving forward will use the aliases and thus could be potentially confusing.
The simplicity of the syntax initially drew me to the TT as well, but within a few hours of owning it, the line character limit frustrated the hell out of me. If scrolling or wrapped lines can’t be added then I’m all for the short aliases.
I definitely qualify as a non-coder new user of TT. For me, any change to the syntax that makes building a patch more efficient while retaining creative restraints and functional transparency (as in, I can understand what is happening and how to control it) is positive! In response to @Galapagoose, I think that as long as the tutorials teach and guide a new user to understand how everything works and then reveals the op aliases as a convenience, that would be easy enough to follow and a delightful treat at the end of rigorous learning.
to clarify, and point out that this isn’t a big issue all around, bothADD and + would work interchangeably. no fork needed, no alternative firmware needed.
the only issue is that if someone shares a script here that has + in it and the uninitiated get confused.
