Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!newstop!sun!amdcad!dgcad!dg-rtp!sheol!throopw From: throopw@sheol.UUCP (Wayne Throop) Newsgroups: comp.os.misc Subject: Re: shell with da Silva lining Summary: ding! round 2 Message-ID: <1639@sheol.UUCP> Date: 8 Apr 91 00:26:01 GMT References: <1563@sheol.UUCP> <60GAP=D@xds13.ferranti.com> Lines: 92 > peter@ficc.ferranti.com (Peter da Silva) >> throopw@sheol.UUCP (Wayne Throop) >> 1) Lexical parsimony. > Yes, I like this. > [...] I'd only use *one* metasequence [...]. The [...[...]...] would nest, > but that's that. [set name] would expand to a variable (taken from TCL). And I like *this*. (Though, see some reservations below.) >> 2) Lexical universality. > Wouldn't that conflict with [glob *.c], which expands into multiple tokens? Yes... *if* each token must map onto an argument. More on this in the "lexical locality" issue, below. >> 3) Lexical locality. The whole distinction between $foo and "$foo" >> should simply not occur in the way it now does. > I'm not sure this is a good idea. I would want [glob *.c] to mean something > different than '[glob *.c]'. But now you run into the question of just how you would utter the string "[glob *.c]". The quotation convention shouldn't have such simplistic exceptions, because this is the road to multiple conflicting quotation conventions, some of which mean *really* quote, and others mean quote *this* but not *that*, and so on and on. Yuck. There are many ways to solve this problem. The way I was thinking of was to have an intermediate rule-based or hook-based layer for mapping tokens into argument lists, but perhaps that's a bit too complicated a mechanism for this context. There's also saying "foo [glob *]" vs "eval foo [glob *]" for this distinction, but that's perhaps a bit too verbose for this context. In which case (I think) the "right" way to proceed is to have some qualifier in the [] syntax to state whether the result should be rescanned for argument breaks or not. The default (in view of the normal use of globbing and argument expansion) would be to rescan, but (say) [=...] (as opposed to [...]) would be presented as a single token (that is, would "be born quoted"). In fact, special treatment of various kinds could be tied into special [] subsequences... one could even do line continuation and the like. But the wisdom of this latter overloading is getting questionable. Finally, in a user-command-oriented shell, using [] for invocation might be alright... but while (as I said above) I like it, I'm bound to point out that it conflicts with globbing syntax of [a-z], and with regular expression syntax. Perhaps {} or `[] might serve better? > I want [glob *] to generate > the equivalent of 'baz' 'da foo bar' 'fido'. I presume this means that the *output* of glob should be specified in this way for reparsing, not that argument boundaries found in any old []-invoked thing are to be frozen by some heuristic... that is, that glob should supply this smarts, not the shell. This seems very good. > I was thinking of defining three explicit phases of translation: This is related to what I'd like to avoid by keeping to the rule of lexical locality. Multiple passes of lexical examination become confusing, and each stage so often consumes some special characters or requires an escape or quote convention. It is, I think, possible to interweave function evaluation with statement and token boundary processing in such a way as to avoid distinct passes and the problems I see related to them. If there's interest along these lines, I can go into further detail. I realize that Peter leans the other way on this issue of translation phases, for other reasons, so unless there's interest, I'll not pursue it. >> 4) Syntactic simplicity. > For sure! But I wasn't going to implement much of this stuff... > [..if you want TCL, you know where to find it..] Ok. >> 5) Semantic explicitness. > Hmmm... >> 6) Orthogonality. > Hmmm... Hmmm... yourself :-) I hope those "hmmmm"s were indicative that what I had to say was interesting, and not that it gave you reason to question my sanity... -- Wayne Throop ...!mcnc!dg-rtp!sheol!throopw