Raul Miller wrote (Dec 28):
> Anyways one basic problem is that J needs to know the
> part of speech represented by [. and ]. before it
> can parse expressions containing them.
> For example, consider
> -&*~ 9
> 0
> 3&*~ 9
> 177147
> If you can figure out what these two examples do, you should
> also see that the underlying meanings for some of the words
> are entirely different, based on the parts of speech involved.
I'm afraid I don't see what you're getting at. Given that
f =. 1 : 'u&*~'
-f 9
0
3 f 9
177147
then
f =. [. & * ~
shouldn't present a problem.
> Another contradiction for expressions involving
> [. would be that we do not know if the line represents
> an adverb or a conjunction.
> f=:[.
> Did you mean
> f=: 1 :'u'
> Or did you mean
> f=: 2 :'u'
> ?
I would apply the simple rule that ]. always gives
a conjunction whether [. appears or not, but
otherwise [. gives an adverb.
Is there a problem here that I don't see ?
Jose Mario Quintana wrote (Dec 28):
> . . . Incidentally, I do not consider myself an expert, not even
> close (to put it mildly), in GUI explicit programming which is the
way jijs.ijs is
> written,. However, I program by looking at patterns and modifying
them to get
> what I want and I have added items to the jijs.ijs menu with very
little
> effort. Look at jijs.ijs; you might be pleasantly surprised.
I'm afraid I haven't made my purpose very clear to you. I was
wanting to write, indeed I had partially written, a book to
introduce tacit J to ordinary people with a mild or greater
interest in numbers and no programming experience. For
this reason my description was of J as in effect a splendid
and simple calculator: a .ijx window and a simple alternation
of user keying in an expression and the J interpreter putting
back a response.
In this approach there is no place for diversions into compilation
or to jijs.ijs. The user needs only J primitives and tacit
definitions. At least such was my intention. That was why
the incompleteness of tacit J was so frustrating.
> Writing the compiling verb might be another matter depending on what
your
> proposal really means. It seems to me that when you talk about a
simple
> way to do simple things you actually mean some way very similar, if
not
> exactly, to the enhancements that you have proposed. I whish you
plenty of luck
> waiting for the mountain to come to you, so to speak (if you decide
to do so); I am
> afraid you will need it, partly because I (as Raul) also think that
they do
> not seem to conform to the J framework properly. Hence my suggestion
to try to
> implement them instead by preprocessing chunks code. Again, I would
be
> interested to see them in action.
Well, there's another example above. But really my basic
reasoning is that [ and ] are great as verbs that in effect
bring into a function (verb) expression the arguments of
that function; the user controls where the arguments are
used by placing [ or ] where those arguments are needed.
Therefore it is a simple analogy that [. and ]. could be used
to bring into an operation (adverb or conjunction) expression
the operands of that operation, the user controlling where the
operands are used by placing [. or ]. where those operands
are needed.
Is there some problem with this that I can't see ? It looks
straightforward to me.
Neville Holmes, P.O.Box 404, Mowbray 7248, Tasmania
Normal e-mail: [EMAIL PROTECTED]
Make the switch to the world's best email. Get the new Yahoo!7 Mail now.
www.yahoo7.com.au/worldsbestemail
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
