Literal Arguments As Proxies For Dialects

Domains Dialects/DSLs
1

I was looking at this detail in FOR-EACH and realized it was a kind of general question... in parameter slots that take dialects, how often should we take that argument literally in order to make it easier to have it act as a dialect?

We can kind of clearly see here that the decorators belong on the variables "doing the picking", not the material being iterated or picked from...

This makes me think I may have erred in switching FOR-EACH variables to be not-taken literally.

I switched:

for-each x [...]

To:

for-each 'x [...]

I thought it was justified by the fact that @x would bind and keep the binding, and the decorator. That allowed for-each @x [...] to do the right thing, even with a non-literal slot for the @x.

But with $x becoming a "thing", if you let that evaluate it loses the $. So FOR-EACH wouldn't know you wanted the picked thing to be bound. You'd have to remember to write:

for-each '$x [...]

But that pattern simply wouldn't work with:

for-each '@x [...]

You can't "reuse the binding" of something you quoted that has no binding. :frowning:

Switch It Back?

If it changes back, you get uniform behavior:

for-each whatever [a b c]

for-each [whatever] [a b c]

That means you can just write:

for-each $x [...] [...]

for-each @x [...] [...]

And it will work.

I can certainly see how it's nicer in the long run to use the literal parameter. But it throws you a bit of a curve-ball educationally.

Consider also 'x being able to have its own dialected meaning in a block or not.

for-each 'x [...]

for-each ['x y] [...]

That's more powerful. But it's also in some pretty confusing territory for beginners, having to deal with that slot being literal.

I'm torn about it, but this for-each $x [...] case does really have me thinking that it should be changed back. Seeing that you'd have to write for-each '$x [...] but then for-each '@x [...] wouldn't work makes me think it's just healthier for that parameter slot to be dialected, and you use a GROUP! if you need to escape it... which is very rare.

3

As I've turned this over in my head a bit, I think that the best answer is likely to take the variable(s) argument literally, but require the quote on ordinary variables.

This means a helpful error can be delivered on for-each x [...] telling you to use a GROUP! if you meant to evaluate it (if x is a variable holding the name of the loop variable) or to use a quote mark (if you intended x as the name of the loop variable).

We can then make for-each @x [...] and for-each $x [...] and for-each ^x [...] work with the decoration guiding the process.

for-each [x] [...] would remain a synonym for for-each 'x [...]

It's Wired Into A Bit Of A Pretzel... But A Good One

:pretzel:

Yes, FOR-EACH is "sneakily" seeing things it would not see if the slot were evaluated... (the $, the ^).

One might complain that the quote mark gives the impression that you're suppressing an evaluation... and the rug is pulled out from under you conceptually when you find out it's not evaluating.

I think that's looking at it the wrong way... the quote mark is a way of communicating that you understand the nature of the slot.

My gauge for these things tend to be: is it motivated? is it learnable? does it do more good than harm?

Since the switch, I've found the quote mark does more good than harm. But we want to see other decorators, and that's more important than being able to pass a variable that is looked up to be the name of a loop variable.

We get kind of the best of both worlds by being able to give you an error if you use a plain WORD!/TUPLE!/etc. in that slot.

So the quote mark stays. :+1:

1 Like