Raul Miller wrote (inter alia):
> Consider:
> 1 + 2 + [.
>
> [. is a verb
> 2 + [. is a verb
> 1 + 2 + [. is a verb
> 1 + 2 + [. is an adverb
>
> When do we decide 1 + 2 + [. is not a verb and
> is now an adverb?
This, and I think all the other contentious examples,
relate to trains or expressions like the above.
My original suggestion/request of years ago was
only for bringing in operands. Then [. and ]. would
only be valid juxtaposed to an operation. The example
above would in that case be an error in syntax.
My early comments, as far as I can remember, noted
that operands could be nouns or verbs. The case of
nominal operands then would be a little like extra
arguments to the user, though in fact they could
only be validly used as operands.
The discussion of [. and/or ]. used as verbs in trains
arose in the present thread, I believe. Not having
thought of this before, I imagined that the rank operator
might be used automatically on any isolated [. or ].
to make a verb of it, a point taken up by Dan Bron.
Raul Miller's discussion, and his earlier examples
convince me that [. and ]. should only be valid when
juxtaposed to (primitive or defined) operators.
Also, if a coder wanted to have a noun brought into
a train then an expression like [."_ or ]."0 could
be used to convert it to a verb. This would have
an advantage over a default suffix of "_ in allowing
the coder to deal with the right operand of the " as
the case requires.
Otherwise, if a coder wanted to have a verb brought
into a train then an expression like [.^:1 or ].^:1
could be used to avoid the syntax error.
> Yes... well... I guess I am still not convinced
> that entirely eschewing explicit J is a worthy goal.
My point of view is that eschewing explicit J is a
simplification, for both teaching and using. When
I was trying to get APL/J into teaching in a
conventional computing degree, I was able to portray
tacit J successfully as the purest form of functional
coding available. In that light I was able to get
leave to teach it, albeit at an honours level.
If I had had to confess that I would be teaching
something with if/then/else and like constructs
(which I don't like anyway) I would have failed.
As it was I had to teach some explicit J to some
students for their projects (all had to do a project
in the second half of the semester: again, see
www.vector.org.uk/archive/v233/tji.htm) and in every
case my suggested [. and ]. would have avoided this.
I don't remember any case needing a [. or ]. in
a train, but it's quite a while ago.
Tacit J may be different, but it's better because
it's simpler, somewhat in the way that APL was
better than FORTRAN.
Further more, I have a strong belief that tacit J
could be taught to the numerically minded part of
the general public. After all it doesn't look at
all like programming as it usually appears to such
people.
I started writing a book "The Joy of Sequences"
when I was running down my teaching to start
bringing this about but I kept having to go
explicit, again where [. would have helped.
Raul Miller helped me around an early case of this
when I raised the matter here, but his solution
was far from simple and anyway cases kept coming,
so I gave it away.
I also believe tacit J could be taught in schools,
and it would make a great basis for a calculator
for school and popular use. A tacit only interpreter
would, I fancy, be simpler than a full-blown one.
But this is wild speculation.
> Avoiding explicit J seems analogous to avoiding the
> use of the character data type. Yes, I can get a
> lot of useful things done without using character
> data. But why should I?
See above. But by this argument the fixed/floating
type distinctions should be brought back. I have
argued elsewhere that this distinction is one of
the greatest flaws in present computer architecture,
and has long been so (see eprints.utas.edu.au/2003
and eprints.utas.edu.au/2478).
Neville Holmes, P.O. Box 2412, Bakery Hill 3354, Victoria
____________________________________________________________________________________
Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
Show me how: http://au.mobile.yahoo.com/mail
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm