Feature: scoped_dictionary #71
Comments
|
Additional thought: at least in the current implementation, juggling values on the stack is somewhat more efficient in terms of allocations required. Values moving around stack aren't allocated, just referenced. Words are based on code injection which requires some allocation |
|
An important downside of this feature: one won't be able to retrieve a bunch of definitions from the storage and EVAL them to define a number of words |
|
PR has been updated to reduce the scope and implement a new word called |
|
Gated feature merged |
|
While playing further with it, I discovered one more edge case that's not great about it. Let me think about it a bit more. Basically, there's a situation when we pass closures between scopes. This is sneaky: will fail on this: However, if I change the then everything is fine: It basically comes down to one very interesting question: how do we pass scoped words inside of closures... because once we pased from ?CURSOR/DOWHILE to CURSOR/DOWHILE, CURSOR/DOWHILE overrode 'closure |
|
What can we do about this?
|
|
I think have a decent solution for this. Just like we have EVAL that evaluates in the curren scope, EVAL/SCOPED evaluated in a new scope, we should have EVAL/UNSCOPED that evaluates in the parent scope. It's not perfect though, as (I think) if an interim scope just passes the closure through, then it might not work. Need to check |
|
I am still not 100% happy with EVAL/UNSCOPED as this would require a ceremony to pass closure by names. I am leaning towards stating that the only safe way to pass a named closure is to get its value first, so it can be passed by value. |
|
Current idea: enable |
Basically, there's a situation when we pass closures between scopes. This is sneaky:
```
CURSOR/DOWHILE : ['iterator SET 'closure SET 'c SET
[c closure EVAL [c iterator EVAL] [0] IFELSE] DOWHILE] EVAL/SCOPED.
?CURSOR/DOWHILE : ['iterator SET 'closure SET 'c SET
c [?CURSOR/CUR closure EVAL] iterator CURSOR/DOWHILE] EVAL/SCOPED.
```
will fail on this:
```
PumpkinDB> [CURSOR 'c SET c "testkey" CURSOR/SEEK? DROP c [UNWRAP 1]
'CURSOR/NEXT? ?CURSOR/DOWHILE] READ Error: "Invalid value"
0x1a17746573746b65790000000014a454200eded6f0000000000101 0x03
```
However, if I change the closure name like this:
```
?CURSOR/DOWHILE : ['iterator SET 'closure_ SET 'c SET
c [?CURSOR/CUR closure_ EVAL] iterator CURSOR/DOWHILE] EVAL/SCOPED.
```
then everything is fine:
```
PumpkinDB> [CURSOR 'c SET c "testkey" CURSOR/SEEK? DROP c [UNWRAP 1]
'CURSOR/NEXT? ?CURSOR/DOWHILE] READ
0x746573746b65790000000014a454200eded6f000000000 0x01
0x746573746b65790000000014a454200f336b4800000000 0x02
0x746573746b65790000000014a454200f79af9000000000 0x03
0x746573746b65790000000014a454200fb5513000000000 "Hello"
```
(See PumpkinDB#71)
It basically boils down to the fact that `closure` here is passed
by name, not by value and is being subsequently shadowed with
another `closure`
Solution: add syntax sugar for "unwrapping" word values from
closures:
```
[?CURSOR/CUR `closure EVAL]
```
Basically, there's a situation when we pass closures between scopes. This is sneaky:
```
CURSOR/DOWHILE : ['iterator SET 'closure SET 'c SET
[c closure EVAL [c iterator EVAL] [0] IFELSE] DOWHILE] EVAL/SCOPED.
?CURSOR/DOWHILE : ['iterator SET 'closure SET 'c SET
c [?CURSOR/CUR closure EVAL] iterator CURSOR/DOWHILE] EVAL/SCOPED.
```
will fail on this:
```
PumpkinDB> [CURSOR 'c SET c "testkey" CURSOR/SEEK? DROP c [UNWRAP 1]
'CURSOR/NEXT? ?CURSOR/DOWHILE] READ Error: "Invalid value"
0x1a17746573746b65790000000014a454200eded6f0000000000101 0x03
```
However, if I change the closure name like this:
```
?CURSOR/DOWHILE : ['iterator SET 'closure_ SET 'c SET
c [?CURSOR/CUR closure_ EVAL] iterator CURSOR/DOWHILE] EVAL/SCOPED.
```
then everything is fine:
```
PumpkinDB> [CURSOR 'c SET c "testkey" CURSOR/SEEK? DROP c [UNWRAP 1]
'CURSOR/NEXT? ?CURSOR/DOWHILE] READ
0x746573746b65790000000014a454200eded6f000000000 0x01
0x746573746b65790000000014a454200f336b4800000000 0x02
0x746573746b65790000000014a454200f79af9000000000 0x03
0x746573746b65790000000014a454200fb5513000000000 "Hello"
```
(See PumpkinDB#71)
It basically boils down to the fact that `closure` here is passed
by name, not by value and is being subsequently shadowed with
another `closure`
Solution: add syntax sugar for "unwrapping" word values from
closures:
```
[?CURSOR/CUR `closure EVAL]
```
|
#108 would resolve this issue |
|
Graduated the feature in #103. Still tracking as the feature gate hasn't been dropped, simply moved to |
|
I suggest keeping this feature-gated until we see what the future compilation technique will bring in in terms of scoping. Thoughts? |
Introduced through #67
Problem: implementing words without subwords is difficult
Technically speaking, loaded words can define their own
words but they will leak into the remainder of the program,
which less than ideal.
Using stack alone requires a significant amount of juggling
that makes writing code incredibly frustrating. I personally
believe that the value of stack based programming languages
is in concatenative abilities (composition via stack), not
just being able to do everything by juggling items in the
stack.
Solution: make all SETs and DEFs done within any closure
local to that closure.
This means that if eventually we'll need to do code injection
that's not injecting what effectively amounts to closures,
we'll need to have a separate pass result type that can
indicate that.
The text was updated successfully, but these errors were encountered: