Oops, almost forgot, some other cases to consider: ": on a boxed array which contains verbs -- does it respect 9!:3?
3!:1 on a boxed array which contains verbs -- how are verbs represented here? And, what about the case where the left argument to BV is a gerund which represents an adverb or conjunction? (Or when 3!:2 or 15!:0 produces a boxed adverb or conjunction?) Anyways... it's not that this is impossible, it's that it's currently inadequately specified (and documented, etc.) for a variety of general cases. Thanks, -- Raul On Thu, Dec 30, 2021 at 12:04 PM Raul Miller <[email protected]> wrote: > > 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
