do we think the op is close enough to the original DEL for this to be okay? I thought you had expressed being against DEL.X unless I misunderstood.

i’m advocating consistency - XDEL and XDEL.R combo is inconsistent but DEL.X and DEL.R combo is not. don’t really have a preference between XDEL and DEL.X otherwise (other than DEL.X taking 1 more char…)

3 Likes

It feels greedy to suggest additions to what is already a beautifully poised language whose simplicity is its greatest strength. But…

I’d love to be able to pass an argument to a script. I’m imagining a version of SCRIPT with a second argument, and an extra local variable that would be set to that argument in the receiving script. So, e.g. SCRIPT 2 4 would run script 2 with the ā€œargumentā€ variable local to script 2 set to 4. This would allow for some nice recursive algorithms that I’m not sure would be very easy to do otherwise.

I know it’s not as nice, but is there a reason one of the global variables wouldn’t suffice for this?

1 Like

even better, use I - it’s local to each script (so you don’t really lose a variable), but it gets passed into a called script from the caller script.

7 Likes

Brilliant! That reveals my embarrassing teletype naĆÆvetĆ© as a new user… I didn’t know I was initialised from the calling script. That allows for ā€œproperā€ recursive algorithms (in a way glabal variables would not). Thanks! :slight_smile:

i’ve been exploring turtle a lot lately and have been wondering if it would be possible to add additional separate turtle scripts. maybe it would be possible by adding the turtle operator number at the end of each function? so:

@F2 x1 y1 x2 y2
@MOVE2 x y 
@SHOW2 1

i’m still relatively new to TT, so if this is already possible and i didn’t know about it i apologize!

it’s a recent change (was only added in 3.0). this allows to simplify doing something like this:
L 1 4: SCRIPT 5 where you need to use the current iteration number in the called script, before you had to use a global variable to pass it in: L 1 4: A I; SCRIPT 5.

not sure it’ll work for recursive purpose though, if you call a script from itself it won’t restore the previous I value once it returns.

this would require a separate set of ops, similar to pattern ops, where the turtle number would be one of the parameters.

sorry, maybe i misunderstood the purpose of the thread - i thought this was a place to request possible future features. this is the first time i’ve had something to request - let me know if there’s a better place for me to file it!

no, this is the right thread. what i meant was - instead of adding 2 to existing ops it would need to use something similar to pattern ops, where the bank can be specified as a parameter. so then there would be separate turtle ops that would take the turtle number as a parameter.

1 Like

Ok after some years of using these are the little things that i miss every time:

  1. More variables (even 2 or 3, but the whole alphabet could be nice).
  2. A simple way to do stuff like ā€œIF … then PROB … to do ā€¦ā€. This kind of stuff would take 2 pages at the moment.
  3. I always liked the TIMELINE idea or at least the possibility to globally stock blocks (or lines) of code and easily recalling them (in a script way like $1). Maybe with another available symbol?
  4. Longer INIT script.
5 Likes

Could we have a way of calling the metronome and init scripts programmatically with variants of the SCRIPT or $ commands? Would be handy to be able to trigger extra metronome pulses and/or initialise a scene on trigger input. $ I makes sense but wouldn’t work because I is a variable, so maybe just $M and $I? (At this point I’m braced for someone telling me this is already possible of course - in which case, thank you!)

yep, M and I are 9 and 10 respectively

2 Likes

right now SCRIPT op will only execute if the script number is between 1 and 8. agreed we should extend it so that you can also use 9 and 10 for metro and init.

2 Likes

yea didn’t know you couldn’t use them w the SCRIPT command, just assumed you could because that’d be more consistent w being able to manually trigger them w F9 and F10.

cool, so if we’re agreed I’ll go with DEL.X and DEL.R. possibly could be changed before release if someone comes up with something better. I’ll get a pull request out tonight.

pull request

bonus DEL.X sound clip
https://soundcloud.com/alphacactus-111884871/delx

4 Likes

will take a look tomorrow!

1 Like

Just a thought. Wondering if the addition of 2 local variables might make a big difference in preserving globals for a more global purpose.

A pretty common construct for me, due to max line length:

Global1 [expr]
Global2 [expr]
IF [conditional] Global1 Global2: [expr]

Right now I think the only local is ā€œIā€, which may already be set and in use if the script is invoked from the loop op of another script.

5 Likes

additional temporary/local variables is something I’d really like. from what I know this seems okay. I could start looking into implementing this if there aren’t any concerns.

3 Likes