If a sentence is something that can produce a result then multiple sentences can appear on a line. A line like if. a=1 do. b=.2 else. b=.3 end.
contains three sentences. It also contains two blocks. Not trying to confuse things. But maybe the definition of a sentence as a line is not sufficient. On Mon, Jun 1, 2009 at 7:07 AM, Don Watson <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
