Meaning of META-BLOCK! ^[...]

Development Datatypes
1

META-GROUP! takes the evaluative behavior of GROUP! and metas the product:

>> (1 + 2)
== 3

>> ^(1 + 2)
== '3

>> (find [a b c] 'd)
== ~null~  ; anti

>> ^(find [a b c] 'd)
== ~null~

That makes sense. But what should META-BLOCK! do?

META-BLOCK! actually does something parallel to the evaluator's META-GROUP! in PARSE. Because in PARSE, the blocks are not "inert". It means give back the meta form of what the block rule synthesizes.

>> parse "aaab" [some ^["a" | opt "b"]]
== ~null~

So there you got a quasiform and not an antiform of null (from the match of the optional "b" not being there).

But in the main evaluator, it currently just quotes the block:

>> ^[a b c]
== '[a b c]

A synonym for quote [a b c]. Pretty useless, right?

Maybe Not Useless...

Consider my desire to have a proper FOR dialect.

 >> for x [1 to 3] [print x]
 1
 2
 3

And then, the concept of "going meta" struck me as interesting:

 >> for x meta [1 to 3] [print x]
 1
 to
 3

Which would mean that FOR when given a quoted block would enumerate its contents vs. run the dialect. Then you could also write that as:

 >> for x ^[1 to 3] [print x]
 1
 to
 3

It would even be semantically different if it did not bind the block, e.g. acted as a synonym for meta '[1 to 3]

Cute, but we don't want to generalize it to groups, ^(...) needs to evaluate the group and give the meta result. So this would be specifically for taking blocks up a meta level.

I guess we'll have to see how it plays out. I can't think of another behavior at the moment.

2

I put forth one theory for what META-BLOCK! might do... to produce a quoted block, and maybe capture a binding or not:

>> ^[1 + 2 10 + 20]
== '[1 + 2 10 + 20]

But what if ^[...] would reduce the block and meta each item?

 >> ^[1 + 2 find [a b c] 'd]
 == ['3 ~null~]

That's half the behavior of what we call PACK today. If you make it an antiform, you can use it with multi return:

 [a b]: anti ^[1 + 2 find [a b c] 'd]

What good is half the behavior? Well, it's more about the idea of having a REDUCE parallel that can actually reduce anything and put it in "suspended animation". Packs are one place this has become useful, but other places could use it too.

It came up when I was thinking about what a META-FENCE! might do:

>> ^{a: 3 b: null}

I was wondering if quoted-bound-fence made sense, and wondered if making all the assignments meta would make more sense.

Anyway, behavior of ^[...] is something I'm rethinking.

1 Like
3

So one thing to mention here is that there's also the behavior of branch slots.

Branches are literal slots and can have behavior different from that in the main evaluator. I've considered the idea that saying @word or @tu.p.le in a branch slot would be a fast way to get the variable.

>> x: 10

>> if 1 = 1 @x
== 10

Building in such shorthands has the advantage of being able to avoid spawning an evaluation level, the way that [x] would. Such efficiency might be interesting for certain kinds of code. And just for a shorthand it might be interesting for certain kinds of code.

In any case, the behavior of META-BLOCK! in branches would pretty clearly be useful to meta the branch product.

This is contentious with the behavior of [2] being either the meta-reduced block or the quoted block. But there is no fundamental reason why branches have to do the same thing.

Anyway, I think the branch product being meta is probably the most useful of the three behaviors, so maybe the focus should be kept on that.

  1. ... ↩︎

  2. ... ↩︎