The goal is to execute each verb only once. In Roger's original JE there
were many places where the code would start with the hope that all
results would be conformable, and then after a few cells a result would
come back with a different type or shape, at which time Roger would
restart the whole operation using a slower path that collected boxed
results and then opened them.
At my request, Roger put in a special case for u"n that boxed up the
previous results so that the cells would be evaluated only once. In my
application execution of the verb on a cell sent a BUY or SELL order to
my broker, a 'side effect' that made it very important not to repeat on
a cell!
When I started work on JE a few years ago, I created a single
result-collection template to use for all cases where a verb is executed
multiple times. This template guarantees no re-execution, and got rid
of most of the restarts in the old code. There are still a few left, in
odd corners.
I can guarantee no re-execution on all modifiers that use the new result
template.
Henry Rich
On 1/22/2022 10:54 AM, Elijah Stone wrote:
On Sat, 22 Jan 2022, Henry Rich wrote:
3. Similarly with x u&v y, where v y is executed before v x, in the
implementation. The language spec is silent
5. When a verb is executed multiple times in a single execution from
the parsing stack, the order of the executions is undefined unless
there is an explicit guarantee otherwise. Currently such guarantee
has been made only for u"n.
Thank you for clearing this up. Why is an exception made for u"n? I
am surprised by that--it seems like a natural place to take advantage
of parallelism, or even just an alternate traversal order.
-E
On 1/22/2022 10:01 AM, Elijah Stone wrote:
On Sat, 22 Jan 2022, Raul Miller wrote:
domain error
Oops. In my defense, testing would not have proved much, since
there is no j implementation which applies fork tines in parallel :)
That exercise 30 was not specifically about J, but about the
application of J's design concepts to various APL implementations.
The exercise had broader implications, but the question as stated
relates directly to J semantics, viz:
_J_ defines fork, (f g h), a train of 3 functions in isolation, as
follows: [diagram]. Why is this [definition in _J_] not equivalent
to the following?
(emphasis mine)
That said, it does illustrate a problem in distinguishing formal
specification from language implementation.
What is the problem?
A related issue: (f y) g (h y) evaluates y multiple times.
I think you mean "... resolves the name y multiple times".
I was using shorthand, and did not explain it. My bad. Suppose we
provided a reduction rule defining the behaviour of fork: for (f g
h) y we may substitute (f y) g (h y), whenever f, g, and h are
verbs, and y is a noun. This is a syntactic rule; it is not a
lexical one, so we may treat all of our variables as terms, but it
is not a semantic one either, so we must concern ourselves with
evaluation.
In context of this definition, whatever expression we substitute for
y will be evaluated multiple times. We might prefer to define a
semantics in which that expression is not evaluated multiple times.
That semantics is incompatible with the previously-given reduction
rule.
This difference could be prevented by preventing names from being
updated. And, languages have been implemented with that
characteristic (for example, Haskell). (And, of course, quite a lot
of work has gone into bringing re-implementing having names refer
to sequentially new values in Haskell.)
Everybody draws a line somewhere. J only permits mutation of global
variables but retains referential transparency; bqn adds mutable
closures. Some people (myself included) think that this is a bad
idea but agree with you that mutation of global variables is
pragmatic and, in the balance, good.
That said, if your concept of ↔ does not allow for machine
constraints, and requires non-contextual understanding of
definitions, I can see how you would reach that conclusion.
My conception of ↔ pertains to substitutability. That is how I
observe the symbol to be used. I do not object to the existence of
other equivalence relations with different meaning, but ↔ is not
generally understood as one such.
Application at rank is not a machine constraint, it is a semantic;
an example of a machine constraint is a limit on the maximum array
size.
I disagree. Standards may be _informed_ by implementations (or,
more to the point, implementation concerns), but they exist
independently of them.
How is this a disagreement? (It seems to me that a standard which
is informed by an implementation is necessarily not completely
independent of that implementation.)
A standard does not _depend upon_ a language implementation.
And I said: a standard _may_ be informed by an implementation. It
does not have to be. I may specify a language but never use it; it
still exists. The lambda calculus is one example: it was described
in the 1930s, and not implemented until much later.
Hauke said more regarding this point, so I will not bother expanding.
The machine is special because it implements the semantics.
J is a language, with some semantics. The most popular
implementation of those semantics is an interpreter which expresses
them in terms of C. C is a language with some semantics, which are
defined according to the C standard. There are many implementations
of C, most (but not all) of which target various forms of machine
code. These machine codes, too, have semantics; they are generally
defined by manuals available from their vendors, and often also by
computer-readable specifications. These machine codes are generally
implemented using transistor logic in terms of physics.
Physics, we presume, has semantics. We do not know what those
semantics are, if indeed they exist. But we have a fairly good idea
of what they might be; good enough that we can generally make
passable implementations of various programming languages. So it is
that, in its most popular implementation, j's semantics is usually
(_usually_) related to three others; which of those is 'the machine'?
But the more pertinent point is that J semantics exist, even if _no
one_ implements them. Recall that APL was originally conceived as
mathematical notation. Does mathematics not exist, even if no one
executes it on a computer?
You might be underestimating the problems involved in implenting a
different language.
Hauke addressed this point too. Much appreciated :)
-E
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
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
