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
