DEF #THING could be a good way to do it.
or just inside F,
X ADD X 1
#DEC gets assigned whatever line number it’s at
F #DEC effectively calls the function
we could then build UI to list # def’s and jump between them.
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.
Expanding on this, consider:
Q ADD Q 1
Q SUB Q 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
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
then inside init:
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.
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:
X SUB X 1
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:
SUB X 1
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:
SUB P1 1
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:
IF LT P1 P2: P1
Z #MIN X Y
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.