On Thu, Jul 30, 2009 at 7:51 AM, neville holmes<[email protected]> wrote: > Raul Miller wrote: >> To be fair, this will be different from $. >> >> t= $. >> >> t is a verb -- albeit, a verb without a domain. >> >> This means that the cost of implementation would be significant. > > This loses me completely. I don't know enough even > to work out whether this is meant to be amusing.
My primary meaning -- that this would be something systematically and structurally different from anything currently in J, was not meant to be amusing. However, my choice of phrasing did have a touch of humor. >> If he were to implement this, I think Roger would >> have to introduce up to six new classes of parsing >> tokens. > > Maybe so. I wouldn't know. But if the introductions > were systematic would this necessarily make it > expensive to do ? Yes. The first part is easy -- you build a verb train which has these new verbs in it. But, at some point, something needs to do something special with this new verb train -- it needs to know to turn it into a new adverb or a new conjunction. So a new adverb has to be written, to interpret this new kind of verb train, and a new conjunction has to be written, to interpret this new kind of verb train. One problem, here, is that we would be introducing objects which turn themselves from verbs into something else. Consider: 1 + 2 + [. [. is a verb 2 + [. is a verb 1 + 2 + [. is a verb 1 + 2 + [. is an adverb When do we decide 1 + 2 + [. is not a verb and is now an adverb? We can not make this decision right away. If we did, we would have problems with 0 >. 1 + 2 + [. In other words, since we are hiding these new interpreters from the user, we have to find some place to hide them. The logical place would be in the current parser, but where in the current parser? Do we make every rule other than the train building rules know about these special trains so they can be auto-converted when we have finished building our train? This could work but seems inefficient. Do we change our train building rules so they treat these kinds of adverbs and conjunctions specially? This seems difficult to get right, because in some parsing contexts they need to be verbs and in other parsing contexts they need to be adverbs, and the same code must deal with both contexts. Do we change J's parser so it is not table driven, but does something special part way through what had previously been a table lookup? This approach suggests, to me, to indicate a bad design concept. That's certainly a solvable problem. But if it makes the current parser more complicated, it would incur some kind of on-going cost for all of J. > After all [ and ] required similar parsing modifications > (I think someone said in this thread) and it was done > and it's very useful. No. [: required a new parsing rule, but it was a simple change -- the part of the parser which assembles new forks checks if the left tine is [: and does something special for that case. I hope you can see how that is different from sometimes changing verbs into adverbs on an "as needed" basis? > I would suggest that implementing [. and ]. would prove just > as useful. The usefulness springs in both cases from > providing a a very simple, very basic, and very useful > facility. It seems to me that these new interpreter would be less capable than the current explicit parsers. They would be serving essentially the same role. But, instead of parsing a compact string of characters and creating a new object, they would be parsing an internal train representation and creating a new train. > All I can say is that I taught tacit J for quite a few > years and every time students came to me with problems > in their projects and I had to teach them how to code > explicitly [. and ]. would have avoided that every time. > Back then (in the last millennium I think) was when > I suggested [. and ]. as verbs in this forum. Yes... well... I guess I am still not convinced that entirely eschewing explicit J is a worthy goal. Avoiding explicit J seems analogous to avoiding the use of the character data type. Yes, I can get a lot of useful things done without using character data. But why should I? Let us suppose I had grown up without screwdrivers, and someone gave me a toolkit that had screwdrivers and also gave me a good supply of screws. This would be valuable for me, and I could do a lot with it. But are screwdrivers so valuable that I should entirely give up on hammers and nails? Why? -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
