Good point. But execution of J verbs in parallel is a hard problem, one
that will probably be solved by a mechanism to allow the user to call
for it. In that case u"n can be specified to execute in order, but u
will create a new task for the execution.
In general if your verb has side effects it is advantageous to know the
order of execution on cells.
Henry Rich
On 1/22/2022 11:09 AM, Elijah Stone wrote:
I meant the execution order guarantee, not the execution repetition
guarantee.
On Sat, 22 Jan 2022, Henry Rich wrote:
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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
