Discussion on the new Let block

I've got the new Let block
mqtt_10_1b script pic
in a project but I now can't remember where I found it :frowning:
Where is it stored ?

It's in the new "Declare & Initialize Script Variables" library. :slight_smile:

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 :slight_smile:

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:

variable creation benchmark script pic 4

variable creation benchmark script pic 5

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 :frowning:

I've just past two days changing a lot of my blocks to use it :frowning:

[edit] Actually - the blocks I've changed wouldn't normally be used in time-sensitive loops so the extra time isn't an issue :slight_smile:

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.

Relative performance of the "run" and "this(caller)" alone

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 :wink:)