On 9/21/07, neville holmes <[EMAIL PROTECTED]> wrote:
> > What would +(NAME=: {.[.}) mean?
> >
> I assume, } being a conjunction, that you mean }. rather.
Oops, yes -- I messed up with copy and paste.
> After
> a=. +(NAME=: {.[.}.)
> same as above
Ok. I was asking those questions, because I could imagine any of
a variety of possibilities. Now that I think I understand your
proposal, I now know the right questions to ask.
So... what would the result be from
+(NAME=: {.[.}.) 3 4
?
> By the by, having taught tacit J to students for many years, my
> experience is that the good students are fascinated by tacit J,
> but they become confused and put off when they get in deeper
> and you have to tell them they now have to learn explicit J.
> That's a hell of a put off, I found.
Well, the thing is -- explicit definitions in J build on tacit
definitions. For example, let's take the case I just asked
about and treat it explicitly:
+(NAME=: 1 :'{.u}.')3 4
First off, notice the differences:
[a] There's some added decoration -- the added characters are
1 :''
[b] The "pattern part" is delimited by single quotes, so it should be
obvious to the parser (and the student) what part of the line gets
special treatment, and what part gets normal treatment.
In other words, with J's current approach, you can provide a complete
example and test on a single line and expect it to work reasonably.
I cannot see how you can make that work with [. without changing
some of the answers you gave me for other cases I asked about.
But,
+(NAME=: 1 :'{.u}.')3 4
follows all the tacit rules -- it doesn't replace them, it builds on them.
Anyways, we have used a new conjunction ( : ). And, +1 :'{.u}.' produces
the fork {.+}. This is radically different from what you get in many other
programming languages, where definitions must be separated out
from the code which uses the definitions.
An advantage of tacit programming, in my mind, is conciseness -- it
lets you express ideas compactly which would require much more
work without tacit expressions. It also tends to guide you towards
simple approaches, and as a general rule, simplicity is good.
But a bigger advantage of tacit programming is that it rather transparently
helps you test your work, and helps you get in the habit of testing
your work. J's explicit programming follows the rules of J's tacit
programming (it's just another conjunction in the J language), so it
retains this advantage.
Now, granted, the : 0 definitions do not in and of themselves retain
this advantage -- you need to treat them as part of a script to get
that capability back.
But, to my mind, J's tacit and explicit programming do not conflict
with each other so much as they complement each other.
That said, J does provide a third approach (gerunds), which complements
both tacit and explicit grammar.
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm