Hi Raul,
I liked your good definitions:
"One entity is a "sentence". A "sentence", in essence, is a
single line of executable code. Sentences follow J's
grammatical rules, and may be evaluated. When evaluated,
they produce either a noun, verb, adverb or conjunction."
I agree. You said:
"And the third entity is a "block". A "block" is somewhere
in between a sentence and a script. It is a sequence of
sentences and is delimited by control words (such as
if. while. do. or end.) Blocks may be nested. Since
control words may not be a part of a legal sentence,
any legal sentence may be contained
in a block, without conflicting with any control words."
We are cobbling together a mixture of components
from different sources. The blocks and control words
we are using are relics of the beginnings of batch
processing - around 50 years old, whereas sentences
and the use of parentheses comes more from
Mathematics, interactive computing and perhaps
Artificial Intelligence. They don't look well together, but
I accept their combination as a pragmatic approach.
However, I am interested in your statement that:
"control words may not be a part of a legal sentence".
Since we are mixing oil and water, this definition is not
part of history, but a definition of J. I must admit that I
did not think enough about placing control words in a
sentence and just threw them in for luck. What would
help me is an explanation of why the creators of J
decided not to allow control words in sentences.
You said:
"If the script terminator could be a part of a legal
sentence, we would have problems.Since a line beginning with
a left parenthesis can not be a legal sentence, any
legal sentence may contained in a script, without
conflicting with the terminator."
I was trying to be consistent with the rest of J and use
parentheses as delimiters. My definition of a block was
a sequence of sentences with a parenthesis to the left of
the first sentence and a right parenthesis to the right of the
last sentence (except where only one sentence was needed).
I looked upon the complete definition as a block within which
there might be other blocks. Therefore there was no need
for a final delimiter. For example:
sumint=:
(k=.0
s=.0
while. k<: ] do.
(s=.s+k
k=.k+1)
s)
While there may be good reasons not to do this that
I do not know, it is always possible to change borrowed
ideas, however old they are.
You said:
"Another entity is a "script". A script is preceded by a
sentence and thus represents a noun, verb, adverb
or conjunction.
example=: 0 :0
This is an example script,
which is being used in a sentence
which produces a noun
)"
I am in total agreement with your definition of what a
script is. My problem is with using it as a primary means of
definition. There are circumstances in which definition
through script helps, but it does not make sense to add
this unnecessary complexity for a primary definition.
I found the contrasting responses from two other J
experts in this discussion revealing. "Packrat" said:
"Frankly, what bothered me most when I first encountered J (and still
does) is that the whole shebang is far too disorganized and "geeky" to
attract a popular following. New users simply MUST be able to find
information easily--in today's J environment, this is virtually
impossible. . . . . Presentation is everything if you want to attract
more users. . . . . Or is there a subconscious desire NOT
to attract more people but to keep J "elite"?
I am trying hard in my little part of the world to turn people on to J,
but I have to do all the persuasion myself--the current J environment
won't do it."
Here we have a real J champion, still full of the energy that could
really expand J, but he's not getting much help from the
documentation and learning environment. User produced
documentation is a good idea for environments, like, say, the
development of Unix, where everyone is experienced, but if
Jsoftware wants to expand its customer base (which it may not),
it needs to hire some professional documentation expert(s) -
expert not in J, but in writing documentation.
This is not a criticism of those who have dedicated effort
to producing the present documentation, but a recognition that
it is time to translate that documentation to a professional
level. The only documentation I have really found really useful is:
"A Brief J Reference".
By contrast we have:
"I don't want a language that's easy to learn. We have plenty
of those already."
This is consistent with: "Or is there a subconscious desire NOT
to attract more people but to keep J "elite"?"
From my limited experience in business courses, I seem to
remember that any smallish company has a point when it faces
the question: "Do we want to remain a smallish and friendly
company or do we want to expand and spend our time
as businessmen rather than participants?" There is no right
answer to this question - it depends on the interests of the
owner(s). However, I seems unclear to me whether the
answer is known.
Don
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
