Comments on this entire thread:
1. If NuVoc ever makes a false statement for pedagogic reasons, there
should be a note inline to indicate that; please add as needed. NuVoc
is intended as a language reference.
2. The order of evaluation of (f g h) y is not defined. You can be sure
if the parts are executed in the same thread that the order is h f g.
Since JE is currently single-threaded, you can take h f g as the order.
I would like to leave this as an implementation fact rather than a
language spec unless there is strong reason to make it explicit.
3. Similarly with x u&v y, where v y is executed before v x, in the
implementation. The language spec is silent. FWIW, I rely on the order
of execution of (f g h) and u&v in my own code.
4. When a verb is executed multiple times in a single execution from the
parsing stack, for example in u"n, x u/. y, or other modifiers, the verb
may be executed multiple times on the same data unless there is an
explicit guarantee otherwise. Currently such guarantee has been made
for u"n, u/ y, [x] u/. y, [x] u;.1/2 y .
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.
6. The definition (f g h) y <-> (f y) g (h y) is NOT an
implementation specification. It says that if the left side is
evaluated, it gives the same result as the right side. How many times y
is stacked is not defined.
Henry Rich
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
