Self Contained Namespaces
15 posts
• Page 2 of 2 • 1, 2
Re: Self Contained Namespaces
the only way that springs to mind is to pass back an ignored result from the recursion and call SelfContain via a (⊢⊣ ...) fork.
I knew sooner or later I was going to have to learn about forks!
- paulmansour
- Posts: 420
- Joined: Fri Oct 03, 2008 4:14 pm
Re: Self Contained Namespaces
paulmansour wrote:I knew sooner or later I was going to have to learn about forks!
:-) OK, just for you:
SelfContain←{
⍝ ⍵ ←→ Namespace
⍝ ←→ ⍵ self contained
n←⍵.⎕NL ¯9
0=≢n:42 ⍝ (result ignored by below operator)
v←⍵.⎕NS¨⍵⍎¨n
∇¨n ⍵.{⍎⍺,'←⍵'}¨v ⍝ look, no ⍵⊣
}{⍵⊣⍺⍺ ⍵}
- JohnS|Dyalog
Re: Self Contained Namespaces
paulmansour wrote:I wonder if the new @ operator could do the job of injecting values v with names n into space s:(v@n)s
It seems to fit.
If the result was the space itself, which seems only natural (and what else would it be?), then we could create and populate a space in one go:s←(v@n)⎕ns ''
which I don't think we can do now.
Now all I need is a primitive to replace the offending ⎕NS ''!
Looks good to me, and would nicely complement my two ideas for populated namespaces, namely generating them as the result of a function (⎕NS), and a literal representation. I hope to publish my ideas as soon as 16.0 is released, but in short:
s←'foo' 'goo' 'hoo' ⎕NS ⍳3
and
s←(foo:1;goo:2;hoo;3)
and the empty namespace (i.e. the result of ⎕NS '') would of course be
()
so combined with your idea, we have
s←(v@n)()
s←v@n⊢()
-
Adam|Dyalog - Posts: 135
- Joined: Thu Jun 25, 2015 1:13 pm
Re: Self Contained Namespaces
I'm joining this a bit late in the game, but here goes:
@JohnS: I tested defining your suggested fork in a script and it failed to fix. Should that work? (works fine if I name the dfn first and then use it in a fork)
@paulmansour: I like the (v@n)s syntax!
I tried SelfContain on one of my cases and it failed because the children are vectors of namespaces (NC 2). I can of course extend this to cover my scenario, but in general I don't agree with the restriction introduced in v16.
I would prefer if the interpreter converted the namespace to be self contained when serialised (as it used to?). There is no such restriction in ⎕JSON so why enforce it in APL?
@JohnS: I tested defining your suggested fork in a script and it failed to fix. Should that work? (works fine if I name the dfn first and then use it in a fork)
@paulmansour: I like the (v@n)s syntax!
I tried SelfContain on one of my cases and it failed because the children are vectors of namespaces (NC 2). I can of course extend this to cover my scenario, but in general I don't agree with the restriction introduced in v16.
I would prefer if the interpreter converted the namespace to be self contained when serialised (as it used to?). There is no such restriction in ⎕JSON so why enforce it in APL?
- gil
- Posts: 71
- Joined: Mon Feb 15, 2010 12:42 am
Re: Self Contained Namespaces
SelfContain ← ⊢⊣{
⍝ ⍵ ←→ Namespace
⍝ ←→ ⍵ self contained
n←⍵.⎕NL ¯9
0=≢n:42 ⍝ (result ignored by above ⊢⊣ fork)
v←⍵.⎕NS¨⍵⍎¨n
∇¨n ⍵.{⍎⍺,'←⍵'}¨v ⍝ look, no ⍵⊣
}
@JohnS: I tested defining your suggested fork in a script and it failed to fix. Should that work? (works fine if I name the dfn first and then use it in a fork)
Apologies, this was wishful thinking on my part. As you say, unless you're defining this inside a containing capsule, you'll need to name the function and then bind it as a fork.
- JohnS|Dyalog
15 posts
• Page 2 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 1 guest
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group