Let's add some op aliases to the Teletype!

#1

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.)

Teletype 2.0 beta (release candidate 2 released 13th July 2017)
Teletype firmware 2.0.0 (released 18th July 2017)
#2

just to be clear either would work, right?

if so I have no problem with any of these

#3

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.

very excited about this…

There will also be a PN.* op for every P.* op

once again thanks a lot for your contributions!

#4

[quote=“sakul, post:3, topic:5540”]
to save some space
[/quote] this is what excites me

#5

Yes.

In Lisp (prefix notation) (+ 1 1) would be perfectly valid, likewise in Forth (postfix), you can also type 1 1 +. So there is plenty of precedence.

But yes, they can be weird if you’ve only used them infix. It took me quite a while to get used to it in Lisp.

#6

100% onboard for all of these.

i’d do && and || as the comparisons aren’t bitwise (from memory, i may be wrong)

#7

Yes please! I’d already implemented a few of these myself and I love using them. Clean and simple.

#8

What about shortening ‘PULSE’?

#9

As in TR.PULSE? How about TR.P?

#10

Yes, that’s what I was thinking.

#11

I’ve added it to the list at the top

#12

From a non-programmer, looks great! More room for stuff.

#13

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.

Just some thoughts! Please disagree with me!

#14

+1
the use of words is one of main reasons i dove into TT

#15

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.

#17

Excited for these simple, but thoughtful and useful tweaks!

#18

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. :icecream:

#19

i have no intention to update the tutorials.

“words” will be standard, but these aliases would be great optimizations for those who want them.

#20

As a coder I would like some fork of TT firmware or possibility to enable these aliases, but arguments for not having them totally make sense also :cat:

#21

to clarify, and point out that this isn’t a big issue all around, both ADD 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.