On Thu, Mar 27, 2008 at 01:01:27PM +0100, TSa wrote: > HaloO, > > Larry Wall wrote: >> I deem that to be an unlikely failure mode, however. So maybe .++ >> is just gone now, and you have to write \++ instead. Any objections? > > Please keep .++ as outlined below. Does the degenerate unspace not > collide with &prefix:<\>? That is does foo\bar() not mean to capture > the result from bar() and call foo with it unflattened?
No, listops require a space after if there are any arguments. >> I'm not sure that's a great loss. It does suggest an alternate >> approach, though, which is to keep the .() forms with forced method >> precedence, and only require \x form for alpha postfixes that want >> to keep their own precedence. Not sure if I like that entirely, >> but it could fall out naturally from the definition of unspace in >> the current scheme of things, so maybe it's a non-issue. > > As it stands the .() forms are a great way to stack ops after > a term. Together with knowing about the ops on the symbolic unary > level you can easily read expressions from the terms outwards. > Good practice would then be to join these extended terms by an > obvious set of infix ops---usually one. The only twists to learn in > this scheme would be ++, -- and **. I don't follow that. Example? > Another good use of the dot forms is to get a single character > form to tighten precedence: $x**3! != $x**3.! == $x**(3!). This > is kind of reverse visually, though. Unless you count precedence forcing as "more work" in some sense. :) > So one might be tempted to > make ! tighter than ** and get the looser meaning with $x**2\! > which wouldn't be a degenerate unspace but a special form to > unbind a tight op as in $x**$y\++ == ($x**$y)++ disregarding the > fact that $x**$y is no lvalue. That seems unnecessarily convoluted for a rarely used item. > BTW, are there still the * and ** prefix ops for list flattening? > Or are these superseded by prefix |? The * and ** prefixes are gone. We have * and ** as bare terms now, which precludes their being used as a prefix. Lists may be dereferenced into capture context with |, or into list context with @ or @@. >> and maybe even >> >> &circumfix:<| |> ::= &prefix:<abs>; >> |$x| >> >> except for the fact that that would collide with prefix:<|>... > > So no whitespace dwimmery here? I.e. one would need |$x | to > force the second | into infix? But eventually the parser has > to give up when the same symbol is overloaded as prefix, postfix, > infix and symmetric circumfix anyway. We don't do that kind of lookahead, nor should we force the reader to do it. Circumfixes are recognized only by their initial token, and therefore live in the same slot as prefixes. The final token is used only to validate the termination of the inner expression. Any other approach is likely to confuse both the compiler and the user. Note that the human brain is not well wired to do lookahead in linguistic processing, since you'd have to know what was not yet uttered by the speaker. N-token lookahead schemes are good for academic papers but not so good for users. You can cheat a bit visually, but it's not terribly efficient to have to glance ahead in any case. Larry
