So here's the deal with Henry's point 3:
Cxmny=: 2 :'x+m+n+y'
(>: i.3) Cxmny (*:9)
(1 2 3) (2 : (':'; 'x+m+n+y')) 81
Here, m .and n have been evaluated, but are represented as nouns, not
as text. You see a formatted representation but the internal
representation is binary
(>: i.3) Cmn (*:9)
82 83 84
Here, there is no pending evaluation. This operation is basically the
same as addition (except with different syntax so -- hypothetically --
it might happen earlier during parsing, which might effectively give
you an implied set of parenthesis.
Now, your expression is a bit different -- you've other verbs which
will not be evaluated inside your conjunction. But what you're not
seeing is the tree structure of the partially evaluated expressions
(which, in turn, reflects the syntax of the language).
To accomplish what you were suggesting, as a general operation, the m
and n nouns would have to be represented as text within a copy of the
conjunction. Like this:
(>: i.3) Cxmny (*:9)
2 :'x+1 2 3+81+y'
Now... it's true that this particular example could instead be
represented as something like:
(>: i.3) Cxmny (*:9)
[ + 1 2 3 + 81 + ]
But that's because this is a simple example -- this kind of
transformation won't work for the general case. It could be attempted
for simple cases, but the attempt isn't free, so we'd want something
like 12 :'x+m+n+y' for that feature, instead of hijacking (2 :)
expressions, and no one has implemented that yet. (It might be worth
the effort though -- mostly it's about taking the (13 :)
implementation and getting it to treat m and n the intended way.)
Anyways... the hardest parts to understand, when using english, are
the unstated assumptions. I am hoping this helps by stating one of
those that I think cropped up here.
Or, put different: am I making sense to you?
Thanks,
--
Raul
On Mon, Feb 17, 2020 at 2:13 AM Hauke Rehr <hauke.r...@uni-jena.de> wrote:
>
> All my fault :/
> In the sentence that didn’t behave as expected,
> I used a variant of my conjunction that actually
> wasn’t defined tacitly: there were references to y
> which kept m and n (and thus constant expressions
> they were occurring in) from being evaluated when
> the derived verb was built.
>
> Sorry for the noise …
>
>
> @Henry Rich
> I disagree with your point 3.
> The verb (? 1e9 1e9)&(+/ . *) has that large matrix inside.
> Why would verbs be allowed to know about a large constant
> when conjunctions are not?
>
> this has to stay the programmers’ responsibility
> the language should provide the means to do what
> might be desirable (and J does so when used tacitly);
> if anyone abuses these possibilities
> they’ll have to bear the blame for the consequences
>
> All I wanted was subexpressions being evaluated,
> and that I got when I turned my code tacit.
> for reference:
> essentially what I wanted (and got) is this behaviour:
> (apologies for another not very useful example)
>
> con =: 2 : '((>./ m) * (>: m) #~ (# n) <. ])'
> (i. 3) con (i.5)
> 2 * 1 2 3 #~ 5 <. ]
>
> I didn’t use (>./ * >:) for in my actual expression I wound up
> with a more complicated structure where it wouldn’t have
> been that easy to mention m just once – it was hard enough
> getting rid of those references to y
>
>
> Am 16.02.20 um 16:39 schrieb Henry Rich:
> > Several misconceptions.
> >
> > If the body of c refers to y, m c n produces a verb that operates on a
> > subsequently-given [x]/y. I will assume that is what you are using,
> > since the only way to produce a modifier is using an explicit definition.
> >
> > In this case, you must distinguish between the execution of c, in m c n,
> > and the execution of the /derived verb/ (m c n) in the later x (m c n) y.
> >
> > The execution of c does very little: it remembers the values of m and n
> > and packages them with the body of c into the derived verb. m and n are
> > not 'evaluated', because by the time they get to c they have already
> > been reduced to a single noun value.
> >
> > When the derived verb is executed, it refers to m and n by name, which
> > is quite efficient.
> >
> > It sounds like you expected the words m and n to be replaced in the body
> > text of c by the value when the derived verb was created. This would
> > have ill effects:
> >
> > 1. m and n are allowed to be redefined during execution of the derived verb
> > 2. there is no word that can replace m/n to define a general noun value
> > - an expression would be required
> > 3. J doesn't know about named constants; it knows only nouns. m and n
> > could be megabytes in size. Installing them into a sentence would be
> > inefficient.
> >
> > Henry Rich
> >
> > On 2/16/2020 3:05 AM, Hauke Rehr wrote:
> >> Hello everybody,
> >>
> >> I recently stumbled upon some at least
> >> for me counterintuitive (read: puzzling) behaviour:
> >>
> >> In a verb like (>: X) {~ ], when X is a defined constant,
> >> the constant expression (>: X) is substituted in the verb (as expected)
> >> but in a conjunction M c N, when M and N are defined constant nouns,
> >> constant expressions are not substituted in c’s body (not expected)
> >>
> >> I would not want m c n to be evaluated time and again
> >> when some part of it, just like in the case of the verb above,
> >> could be evaluated once when defining the derived verb.
> >> This should result in major savings of computational
> >> resources so I’d have expected J to do this.
> >>
> >> could anyone tell me why this is different from verbs?
> >>
> >> kind regards,
> >> Hauke Rehr
> >> (Jena, Germany)
> >>
> >>
> >
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
>
> --
> ----------------------
> mail written using NEO
> neo-layout.org
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
