I think it's more about scope than namespaces, though namespaces are relevant.
Correct me if I'm wrong, but currently we run into problems when
dealing with locals in adverbs and conjunctions:
(a) We cannot see locals in a calling environment, and
(b) constructed verbs may refer to names in the called environment
which would no longer be valid in the calling environment.
Namespaces are relevant here, because we can often work around both of
these issues using namespaces. We can export local names to a
namespace and once we have a namespace references to it remain valid
for as long as that namespace exists.
That said, the introduction of namespaces creation creates a new
problem which is: when do we dispose of that namespace? In some
contexts this is an easy problem. In other contexts it can become an
obscure and/or difficult problem.
--
Raul
On Tue, Jan 17, 2023 at 10:30 PM Henry Rich <henryhr...@gmail.com> wrote:
>
> Is it about namespaces then? That is indeed a vexed question. I will
> take this under advisement. I will need more help I'm sure.
>
> Henry Rich
>
> On 1/17/2023 10:15 PM, Elijah Stone wrote:
> > It is the other way around--lack of closures means we must write
> > _more_ tacit code, not less. E.G.:
> >
> > {{
> > a=. something
> > {{ something referring to a }} A y NB. doesn't work
> > }}
> >
> > Whereas:
> >
> > {{
> > a=. something
> > (something referring to a) A y NB. works
> > }}
> >
> > I am proposing a mechanism to make the former work (among other things).
> >
> > On Tue, 17 Jan 2023, Henry Rich wrote:
> >
> >> I don't follow any of this thread, because I don't understand what is
> >> missing from standard J. I find J adequate for everything I want to
> >> do. What am I missing?
> >>
> >> I can see that if you want to write all-tacit code you have trouble
> >> if you need to feed a verb result into a modifier.
> >>
> >> Suppose though that I am content with writing explicit definitions.
> >> What do I need beyond the standard language, and for what use case?
> >>
> >> Henry Rich
> >>
> >> On 1/17/2023 9:23 PM, Elijah Stone wrote:
> >>> (Curried modifiers, as you say, are a solution, but, again, another
> >>> half-solution.)
> >>>
> >>> On Tue, 17 Jan 2023, Raul Miller wrote:
> >>>
> >>>> Here, I suspect that you're only getting noun values in your closure
> >>>> -- you'll have to sprinkle those noun references with something like
> >>>> `:6 if you want anything else. That's probably not a huge problem.
> >>>>
> >>>> But, thinking about this, personally I'm not seeing a lot of
> >>>> motivation for this approach, either. (What problems would this solve?
> >>>> I'm sure there are some great motivating examples out there. And
> >>>> closures certainly have a lot of popularity. But... position in a list
> >>>> can be thought of as being conceptually analogous to a variable, so it
> >>>> should be apparent that we already have some support for the
> >>>> algorithmic role of closures.)
> >>>>
> >>>> (I should perhaps also note, here, that conjunctions and adverbs which
> >>>> have verb results are self-currying.)
> >>>>
> >>>> Anyways... I'm not thinking particularly deep thoughts here -- I'm
> >>>> just reflexively reaching for motivating examples (which might assist
> >>>> in forming some of those sorts of thoughts).
> >>>>
> >>>> Thanks,
> >>>>
> >>>> --
> >>>> Raul
> >>>>
> >>>>
> >>>> On Tue, Jan 17, 2023 at 7:01 PM Elijah Stone <elro...@elronnd.net>
> >>>> wrote:
> >>>>>
> >>>>> I suggest:
> >>>>>
> >>>>> [x] u &:: (k;v;k;v...) y
> >>>>>
> >>>>> Will evaluate u with bindings kvkv... (raveled) active. Should
> >>>>> work for both
> >>>>> explicit and tacit. Implementation is allowed to coalesce; e.g.,
> >>>>> u &:: (k;v)
> >>>>> &:: (k;v) `'' may be rendered u &:: (k;v;k;v), deduplicated, &c.
> >>>>> Substitution also ok; eg (f%#) &:: ('f';+/`'') becomes +/%#.
> >>>>>
> >>>>> I would like for verbs defined inside of explicit verbs to be
> >>>>> implicitly
> >>>>> closed; this is obviously a compat break, but.
> >>>>>
> >>>>> On Tue, 17 Jan 2023, Elijah Stone wrote:
> >>>>>
> >>>>> > I don't love the proposal, as I think a conception of verbs as
> >>>>> first class
> >>>>> > should involve _less_ hackery with representations, not more.
> >>>>> But I don't
> >>>>> > feel that strongly either way.
> >>>>> >
> >>>>> > More fruitful, IMO, would be to work out how to add closures, as
> >>>>> I think
> >>>>> > there
> >>>>> > is a more urgent need for that (u./v. is a band-aid). Perhaps
> >>>>> taking
> >>>>> > inspiration from kernel (but skipping the mutation!).
> >>>>> >
> >>>>> > On Mon, 16 Jan 2023, Henry Rich wrote:
> >>>>> >
> >>>>> >> I have never understood the zeal for having verbs return verbs,
> >>>>> but it
> >>>>> >> must be real if some are willing to use dangerous backdoor
> >>>>> hacks into JE
> >>>>> >> to achieve it. ARs make it possible to pass verbs around, but
> >>>>> executing
> >>>>> >> them requires dropping into explicit code. To remedy this, I
> >>>>> offer a
> >>>>> >> proposal, backward compatible with older J:
> >>>>> >>
> >>>>> >> 1. (". y) and Apply (x 128!:2 y) to be modified so that if the
> >>>>> result of
> >>>>> >> execution is not a noun, it is replaced by its AR (instead of
> >>>>> '' as
> >>>>> >> previously).
> >>>>> >>
> >>>>> >> 2. (". y) and Apply to be modified so that if y (for ".) or x (for
> >>>>> >> Apply) is boxed, the sentence is executed as usual except that
> >>>>> each box
> >>>>> >> is converted using (box 5!:0) before being put onto the
> >>>>> execution stack.
> >>>>> >>
> >>>>> >> The idea is that you can execute (".
> >>>>> >> expr-producing-AR,exp-producing-AR,...) without having to get any
> >>>>> >> modifiers involved.
> >>>>> >>
> >>>>> >> Sentence execution can produce ARs, and can take ARs created by
> >>>>> verbs to
> >>>>> >> represent verbs and modifiers. That sounds pretty classy to
> >>>>> me, but I
> >>>>> >> don't know whether it's first-class.
> >>>>> >>
> >>>>> >> Henry Rich
> >>>>> >>
> >>>>> >>
> >>>>> >>
> >>>>> >>
> >>>>> ----------------------------------------------------------------------
> >>>>>
> >>>>> >> For information about J forums see
> >>>>> http://www.jsoftware.com/forums.htm
> >>>>> >>
> >>>>> >
> >>>>> ----------------------------------------------------------------------
> >>>>>
> >>>>> > For information about J forums see
> >>>>> http://www.jsoftware.com/forums.htm
> >>>>> >
> >>>>> ----------------------------------------------------------------------
> >>>>>
> >>>>> For information about J forums see
> >>>>> http://www.jsoftware.com/forums.htm
> >>>> ----------------------------------------------------------------------
> >>>> For information about J forums see http://www.jsoftware.com/forums.htm
> >>> ----------------------------------------------------------------------
> >>> For information about J forums see http://www.jsoftware.com/forums.htm
> >>
> >> ----------------------------------------------------------------------
> >> For information about J forums see http://www.jsoftware.com/forums.htm
> >>
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
