On Sat, Jan 22, 2022 at 7:08 AM Elijah Stone <[email protected]> wrote:
> > I have not been able to construct any examples which illustrate the
> > execution order ambiguity which you alluded to
>
> a=: 0
> f=. {{ a=: 1 }}
> g=. {{ a }}
> h=. {{ a=: 2 }}
> (f g h) ''
This gives me a domain error. It's easy to remedy:
g=. {{ a[x }}
(f g h) ''
1
> If h is executed before f, the result will be 1. If f is executed
> before h, the result will be 2. I assume an operational model
> under which such assignments can be ordered.
>
> I am unable to find the original reference for (f y) g (h y)'s removal
> from the dictionary, but Roger Hui alludes to it in exercise 30 at
> https://www.jsoftware.com/papers/APLDesignExercises1.htm#30
That exercise 30 was not specifically about J, but about the
application of J's design concepts to various APL implementations.
That said, it does illustrate a problem in distinguishing formal
specification from language implementation.
> A related issue: (f y) g (h y) evaluates y multiple times.
I think you mean "... resolves the name y multiple times".
And, yes, this is true. For example:
f=: ([ ".@'y=:1')
g=: ([ ".@'y=:2')
h=: ([ ".@'y=:3')
(f g h) y=:4
4
(f y) g (h y=:4)
3
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.)
But also, that kind of change (making name assignments "permanent")
would break quite a lot of existing code, which was written in J.
You're well on your way to specifying a different language if you
want to change this characteristic.
> > As for the rank issue, that was described (albeit in a formal fashion)
> > in the dictionary. https://www.jsoftware.com/help/dictionary/dict3.htm
> > gives an overview, and rank is described in further detail in various
> > parts of the dictionary.
>
> That is true, but it does not change the fact that the dictionary claims
> that 'x u&v y ↔ (v x) u (v y)', and that that is not correct.
I disagree.
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.
> > Language standards are indeed formal statements, but they cannot be
> > entirely independent of the machine implementation(s).
>
> I disagree. Standards may be _informed_ by implementations (or, more to
> the point, implementation concerns), but they exist independently of them.
> Case in point: the dictionary does not give an evaluation order for fork,
> but JE does.
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.)
> > Here, some relevant abstractions include:
> > (1) functional vs. machine state semantics
> > (2) parallel vs. serial implementation
>
> I do not see the significance of these. The machine is not 'special'; it
> is simply another set of semantics. We express one set of semantics in
> terms of another; that is what compilation means.
The machine is special because it implements the semantics.
> > (3) current vs. future versions
>
> A future implementation version may implement a different language. Which
> must be specified differently, but there is no problem with that.
You might be underestimating the problems involved in implenting a
different language.
Anyways... understanding why we get such quirks is an interesting
and sometimes useful exercise. But that does not mean that eliminating
such quirks is useful. Fun, yes. But any working language is going
to have quirks (which, generally speaking, require a deep understanding
of the language to appreciate).
Thanks,
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
