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

Reply via email to