#21

agreed. having DEF #THING could be a good way to do it.

or just inside F,

#DEC
X ADD X 1
BRK

where #DEC gets assigned whatever line number it’s at

and then

F #DEC effectively calls the function

we could then build UI to list # def’s and jump between them.

4 Likes
#22

I run through the exact same thing all the time. What starts as a well defined set of scripts ends in a mess of lots of unrelated commands crammed together in every script.

#23

Expanding on this, consider:

#DEC
Q ADD Q 1
#INC
Q SUB Q 1
#WHAM
TR.P 1
[ … note absence of explicit break or return var commands … ]

… where “Q” is a local variable that is passed as an optional argument and returned to the calling code, like so:

TO.CV 1 V F #DEC TI.PRM 1 // one less than telex param 1
F #WHAM // nothing sent so “Q” is 0 in #WHAM (avoiding null values), return goes to bit bucket

#24

variable args aren’t in the TT engine, so without a hack and a divergence from syntax, we could do this but maybe split it into F for no args and FA or call with args.

but we also need some sort of return specification, or does Q just get returned also?

also keep in mind the idea is that calling F can be multi-line. it should keep running until hitting BRK

#EXTENDEDINIT
A 1
B 2
C 3
BRK

then inside init:
F #EXTENDEDINIT

2 Likes
#25

This makes the implicit return and single local arg/variable problematic–debugging would be unintuitive. I think the named entry points you propose (versus the line number prefix) is a pretty big win.

#26

number of parameters could be specified when defining a function, but i think this would require a significant change in parsing engine… so likely not that feasible.

the easiest is probably having a fixed number of parameters (one or two), or just using other variables. using this example:

#DEC
X SUB X 1
BREAK

if you want to run this function on variable A you would have to call it like this: X A; F #DEC
what i don’t like about this approach is that you are losing a variable, and unless you use same variables all the time you’d need to remember which variables were used in which function.

for return i don’t think we need to do anything, consider:

#DEC
SUB X 1
BREAK

called like this: X A; A F #DEC

if we were to use a fixed number of parameters, say, two, it could look like this:

#DEC
SUB P1 1
BREAK

which would make for a more elegant A #DEC A 0 (using 0 as a 2nd parameter since it expects two).
also, do we need F when calling a function? we do need to distinguish between when a function is defined vs when it’s called (since functions could call other functions), we could do that by adding : in definition:

#MIN:
IF LT P1 P2: P1
ELSE: P2
BREAK

Z #MIN X Y

#27

I don’t see a reason why not. We’re creating a special branch in the parser to accomplish #ANYTHING anyway, so I think the ‘F’ could be dropped.

I edited the thread title to reflect the conversation.

2 Likes