I've got the new Let block
in a project but I now can't remember where I found it
Where is it stored ?
It's in the new "Declare & Initialize Script Variables" library.
I love that library! Especially its application of the input groups mechanism.
Besides I propose it be extended with a (non-variadic) reporter-let
(similar to Scheme's let
).
@tethrarxitet Thanks
Why non-variadic? Or do you mean that just the expression input at the end be non-variadic?
The point setting a reporter-let
apart from command-let
is not only does it declare and initialize a variable, but it reports its value as well. A “variadic” version would report merely the latter of the relevant variables, and even though that’s exactly what Scheme’s let
does, it wouldn’t make much sense in a language such as Snap!, featuring both command
and reporter
type blocks.
maybe it reports a key value pair of the var names and the values that they were set to.
I made something like that as part of my Lisp library: here's the link.
Oh! Sure. You confused me by bringing up Scheme's LET, which is nothing like that. It doesn't report the value of a variable; it has an explicit body that gets evaluated in an environment that includes the bindings it creates.
You’re right, of course - I was the confused one. Does Scheme actually have anything like a reporter-let
?
And BTW I think the let
from the new library is much like Scheme’s let*
, isn’t it?
Not that I know of.
Yeah. Arguably we should introduce LETREC...
The new library’s let
block (similar to Scheme’s let*
) may be very flexible in that it allows a newly declared-and-initialized variable to be used immediately, but this comes at a price: its execution is much slower than that of a simple let
, script variables
+ set
, or reporter-let
, as demonstrated below:
, with definitions:
So I think we can agree the new library could do with some “flavours” (perhaps even letrec
, which I presume is even more flexible, but probably also even slower).
Oh dear
I've just past two days changing a lot of my blocks to use it
[edit] Actually - the blocks I've changed wouldn't normally be used in time-sensitive loops so the extra time isn't an issue
I feel like part of why it's slow, is because it's doing more than just setting a single upvar, it's setting many upvars inside a for each loop.
Plus, I don't think the very tiny amount of extra time matters in the long run, since if someone needed micro optimizations, they would just use the regular script variables block.
Far from generally denouncing the new library’s let
block because of the extra runtime required - in many cases the extra runtime doesn’t matter, in others it does; conversely, in many cases its functional flexibility is useful, whereas in others it’s not - I am saying I’m happy with the library and its (for now) only block and (not “but”) IMO extending the library with additional flavours of let
, with different combinations of functionality and speed (just like Scheme has let
, let*
, letrec
, and letrec*
), would make another useful addition to Snap!
Ah, ok.
I wonder what point you’re making?
I was surprised by the enormous overhead associated with such fundamental constructs.
Ah, I see.
BTW may I suggest @cymplecy change this topic’s title to “New let block”, or something? (so as, for later reference, it better reflects the content of the topic as it has developed after the initial post) (sorry for hijacking it )