On Mon, Jun 1, 2009 at 8:07 AM, Don Watson <[email protected]> wrote: > I liked your good definitions:
Thank you. > 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. And numbers themselves have a multi-source history. However, remember that I was using the words "sentence", "script" and "block" in the technical J sense -- these technical meanings for these words might be similar to meanings you would encounter in other contexts but please do not confuse them. > 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. All three of the words used J-specific definitions. Looking quickly, here are some pages which use these words in the way I have defined them (except, of course, for potential defects in my definitions): sentence http://www.jsoftware.com/help/dictionary/dicte.htm script http://www.jsoftware.com/help/dictionary/dx000.htm block http://www.jsoftware.com/help/primer/control_structure.htm That said, there might be a better word for what I have called a "script"? But I do not know what it would be. > 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. Because control words control the execution of sentences? > 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. One problem, here, is that the system can not report an error if you fail to close your parenthesis. Instead, it must "hang" and wait for you to supply the closing parenthesis. What would you think of a computer system which just stopped working, for no apparent reason? > 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. You can write arbitrarily complex J applications without using scripts. > I found the contrasting responses from two other J > experts in this discussion revealing. "Packrat" said: ... > 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. And I think I agree with Packrat's point of view, at least in general terms. J could use some UI polish. Specifically: F1 should behave somewhat like Control-F1 currently does (but always opening a browser -- for example, falling back to its current behavior in contexts where Control-F1 would give the "Help topic not found" popup). I should be able to easily build UIs driven from the data which they interact with. I would also like "easy" support for tooltips and context specific interaction. (And by "easy" I mean easy to develop against -- obviously, developing such facilities would be difficult.) > 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"?" I believe this was a statement of priorities -- he does not want useful features removed from the language in an effort to make the language easier to learn. -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
