On 3/20/06, Miller, Raul D <[EMAIL PROTECTED]> wrote:
>
> p j wrote:
> > References would be a useful feature
>
> J has references -- names are references.
I will disagree (slightly) with this. Names are a _for_ of "reference", but
do not infact match precisely what most 3GL languages define and use as
'references'.
Please refer to HOPL (History of Programming Languages) and look up the
exact semantics of the various "pass by" (parmeter) mechanisms:
pass by name
pass by reference
pass by pointer
pass by value
and note that 'refrences' are closer to 'pointers' than "references" (Algol
58/60)
Please note I am not in favor or against any particular flavor or savor;
rather, I would prefer to have J refer to (sic) and use a method that more
flexibly allows accurately the encapsulation of _all_ characteristics
__any__ such form would allow, depending on the desires of the programmer.
Both directly, as if a primitive, as well as by overloading, as is present,
as well as by abstraction, as by representation of the concept.
Each has its place.
Please note that, depending on which form of ``reference`` you prefer,
equality/define/assign all differ intheir response to the exact definitions
used.
This seems to be tangling in he area most calculus of satement issues refere
to as the difference between shallow and deep identity.
Unfortnautrly, resolving the ambiguities _requires_ an eact PRK in orde to
communcate them precisely.
Please refer to Lessniewski and his protothetic, ntology, and mereology.
It is easy to get lost in the differences and bat them around forever.
One of the nice things about J is that, since it is iherently _based_n_
English conourse/discourse denotationally/connotationally,
it is very easy (albeit one heckuvalotta work) to actaly constuct and exact
discourse which actually _does_ form a PRK __between__ the two languages
(English and J); which in turn may be used to bootstrap a PRK between the
preferred (various one, remember this, one for each alternative being
examined)
older verson of J (as defined by Jsotware) and thenewer one (as defined by
the communicant defining the prefered alternativ to consider).
At that poit, each one of _those_ may be used to define a PRK considering
them _all_ for comnparison and inclusion.
This dicussion is a small portion of such a sequence.
If not for the relative expertise of the participants and originators of J<
... it would be nearly hopelessly lost ...
NOT in terms of actually resolving the ambiguities among the participants,
BUT:
in terms of atually definng a _new_ version of J that proerly, formally,
correctly, consideredly, and _metrfiedly_ (wuith verity verifiedly
verifiably reverfiable) so re-cognized.
Without actually _performing_ this, what will likely occur/accrue is a drift
from one form (older J) to another (new practices and new vrsion
WITHOUT actually metrfying the results for future re-examination.
Nothing _wrong_ with this; most math and sciece actually is _done_ this way
(without fully using previous existing science and math);
and it often leads to valid new results.
But it would appear to be indictaive of:
(a) laziness or lack of flexibility/formality the part of the communicants,
(b) lack of facility or flexibility on the part of the math or science
involved,
(c) the need to include newwr features and result so fsuch type into to
formal math or science involved
FORMALLY done, UNTIL it is in fact easier to do so FORMALLY than
INformally;
or at least until a better balance is achieved
(d) an ongoing problem in the area of cognitive drift and unfixed semantic
loss (or de-based semantic loss)
Not that such is the _only_ mechanism available; in fact,
I will note that the opposite and apostate mthod is also actually formally
in practice
(but not yet recognized my many as such, and not being explicitly or
consciously
[[or at least publically so]]) by members of Jsoftware or (less reliably so
IMOHO) by members of JForum.
It just seems to b a shame that the best of the last 5,000 years of human
science
(simle methods such as catrgorical clean\ving and Venn diagramming)
are so easily being lost: witness JForum's ongoing lack of appreciation of
the simple concept of "undefined" and how central it actually is as a pivot
to avoid semantic and cognitive metric loss of significance (extended
concepts of numerical/semantic analysis).
IN all: referecnes oukld be a useful adition to J< but only with a mechanism
thatallows a more flexible (apparently) primitive definition of them, with
full flexibility as to what is exactly _meant_ by <reference>.
Cheers.
|As an added bonus, values in memory mapped files are treated in a
> reference-like fashion.
>
> > lets define r: as a monad to return a reference to its
> > right argument ...
>
> If you want a reference rather than a value, why not simply quote
> the name?
>
> Put differently, in verb :'x+y', x and y are references to the right
> argument. That's probably not the reference you were thinking of, but
> J isn't so good at mind reading. At least, not in this version...
>
> A bit more seriously, here are some cases to consider:
>
> [1] The right argument is calculated on the fly.
>
> [2] and then a name is assigned this value.
>
> [3] and then another name is assigned this value
>
> [4] and then the value referred to by a name is used in another
> locale.
>
> (etc.)
>
> > r: could be an adverb or conjunction.
>
> You have this for verbs:
>
> ref=: `''
> a=+/%#
> a ref
>
> Doing this for nouns would essentially mean that nouns are just
> another flavor of verb (one that takes no arguments). One problem
> with this approach is that a combination of nouns and verbs would
> form a train rather than causing the verbs to be executed. On the
> one hand, this would solve an earlier problem (where irrational
> results are not represented exactly), on the other hand you'd have to
> do something like fix each such train before you could see the result.
>
> Of course, other possible implementation strategies are possible...
> but one of them is already implemented: quote the names you want to
> serve as references.
>
> > I guess it can be defined now without language support
> > as long as you are willing to call it with variables
> > inside quotes.
>
> Yes.
>
> And the `'' method seems to work just fine for verbs.
>
> > An unrelated seemingly small touch that could be
> > helpful is letting the explicit define process handle
> > nested definitions by having a definenested enum.
> > myverb=: monad definenested NB. 3 : 1
> > myprivateverb=. 3 : 0
> >
> > )
> >))
>
> Hmm... I've been thinking about such things too, but have yet to come
> up with what I think is a significant reason to use them.
>
> > This could hopefully let us define multiple classes
> > inside general files, as well as private explicit
> > verbs only useful in narrow scopes.
>
> Of course, both are already possible.
>
> --
> Raul
>
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
--
Roy A. Crabtree
UNC '76 gaa.lifer#11086
3012B Mornstar Place (legal)
Greensboro, NC 27406-6220
336-340-1304 (office/home/cell/vmail)
USPS POB 9001 (mail/permanent)
Chapel Hill, NC 27515-9001
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.authorsden.com/royacrabtree
http://skyscraper.fortunecity.com/activex/720/resume/full.doc
--
(c) RAC/IP, ARE,PRO,PAST
(Copyright) Roy Andrew Crabtree/In Perpetuity
All Rights/Reserved Explicitly
Public Reuse Only
Profits Always Safe Traded
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
