Since perhaps I am being too negative here, let me at least the cases
I do not adequately understand here.
Let's say that we have an adverb BV which creates a boxed verb from
its left argument.
The simple case does not seem particularly bothersome:
(> +/BV) 1 2 3
6
But what happens when we put these verbs into an array, perhaps using:
genExample=:{{
r=.i.0
for_j.,m do.
if. (*j)*(j=<.j)*(j>:_12)*j<:12 do.
r=. r,j&o. BV
else.
r=. r,<j
end.
end.
}}
A=: genExample =i.3
B=: genExample i.3 3
C=: genExample 1 p: i.3 3
D=: genExample i.3 3 3
With these examples, how do we reason about sentences like
1+;A
or
B *S:0 C
?
Or with A, B, C or D freely used as alternatives here.
It's also worth thinking about sparse boxed arrays of such verbs
(including the case of a sparse boxed array where a verb is the fill
value).
...
It's not that I think this is impossible to implement. Far from it.
What bothers me is that the answers to some of these questions seem to
be not particularly obvious (but the implementation would still have
to deal with them).
Do you see why I tried to phrase the discussion here in terms of costs
and benefits?
Thanks,
--
Raul
--
Raul
On Wed, Dec 29, 2021 at 8:25 PM Raul Miller <[email protected]> wrote:
>
> On Wed, Dec 29, 2021 at 8:09 PM Jose Mario Quintana
> <[email protected]> wrote:
> > > My stance here is that *any* tool set necessarily is limited (aka
> > > "weak") outside of a limited range of targets. For example:
> > > ...
> >
> > Yes, I have known for many years that you feel very constricted when you
> > are asked to use only tacit tools when entertaining a nontrivial
> > programming exercise. There is really no need for you to emphasize it.
>
> But there is when we are discussing the topic and my reasons for that
> stance are relevant to the current discussion.
>
> > > But you're probably also not tracking orbital debris.
> >
> > Are you tracking orbital debris with explicit J?
>
> No more than I am chopping down trees with explicit J. Well, maybe
> slightly more -- but only in toy problems.
>
> > > > I would accept that as a tacit admission that the j903 tacit tools are
> > > > weak.
> > >
> > > Sure, and I also think that that's what makes them desirable.
> >
> > So, we agree! (That j903 tacit tools are weak.)
>
> And that's not necessarily a bad thing:
>
> The point I have been trying to express here is that "weak for a task
> that the tools were not designed for" is a necessary characteristic of
> any useful tool set.
>
> Boxed verbs come with costs: Documentation costs, implementation
> costs, maintenance costs (in the J implementation), debugging costs
> (in code which did not intend to use the feature but erroneously used
> it), opportunity costs (time that could have been spent on other
> things). To make a decent decision here one has to be aware of both
> the value and the costs of that decision (and someone has to step up
> to cover those costs).
>
> I understand that you have been supporting an implementation with
> boxed verbs, so you seem motivated there. But "tacit is weak" does not
> adequately express the costs vs the benefits of this approach,
>
> Am I making sense to you?
>
> Thanks,
>
> --
> Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
