Re: fast question
On Wed, 7 Jul 2004, Luke Palmer wrote: Are there others, aside from these: ? prefix: a unary prefix operator infix: a binary infix operator postfix:a binary suffix operator circumfix: a bracketing operator Tons. From A12: [snip] On the wild side of things, could there be the possibility of even defining new ones? Michele -- DAX ODIA ANCORA - Scritta su diversi muri milanesi
Re: fast question
Michele Dondi writes: On Wed, 7 Jul 2004, Luke Palmer wrote: Are there others, aside from these: ? prefix: a unary prefix operator infix: a binary infix operator postfix:a binary suffix operator circumfix: a bracketing operator Tons. From A12: [snip] On the wild side of things, could there be the possibility of even defining new ones? That's what I meant by: grammatical_category:postcircumfix Though it wouldn't be so magical as to just know what you mean. If your mucking with the grammar, though, you should be able to insert hooks. After all, the writers of the perl 6 parser have to do it. rule prefix_op() { (@(%Perl::guts::grammatical_categoriesprefix)) prefix_op | term } Or something. Luke Michele -- DAX ODIA ANCORA - Scritta su diversi muri milanesi
Re: fast question
On Thu, Jul 08, 2004 at 04:49:33AM -0600, Luke Palmer wrote: : Michele Dondi writes: : On the wild side of things, could there be the possibility of even : defining new ones? : : That's what I meant by: : : grammatical_category:postcircumfix : : Though it wouldn't be so magical as to just know what you mean. If your : mucking with the grammar, though, you should be able to insert hooks. : After all, the writers of the perl 6 parser have to do it. : : rule prefix_op() { : (@(%Perl::guts::grammatical_categories«prefix»)) : prefix_op : | : term : } : : Or something. I like it when someone says or something about the same place I'd say or something. :-) However, in the interests of dewaffling, I have a couple of quibbles. I don't know what that @() is doing there--I presume you meant @{}. Also, it's not clear that you want an array there, but I understand you're indicating that the tokens have to be matched in some particular order that is unspecified but not arbitrary (presumably longer tokens preceding any shorter prefixes of those tokens). As I said in another message, though, we might want to force hashes to automatically tokenize in a longest-token-first fashion (or at least have the option of doing so), and using a hash would allow the keys to be the strings and the values to be individual actions to be taken. With an array match, you might find yourself redispatching individual operators in a switch statement to provide that kind of specificity. For efficiency, either an array or a hash would want to be preprocessed into some other kind of trie or other data structure for fast tokenizing anyway, so it's not like doing it with an array is buying you much unless you really need to specify the order of matching. You might think we need to specify order so that lexicalized operator definitions can override more global ones, but I suspect we actually have to copy the array or hash into the derived grammar in any event to properly emulate method overriding for things that aren't really methods, so that when we revert the grammar it reverts the user-defined operators as well. Or something... My other quibble is that I hope this level of operator can be parsed with operator precedence rather than rules. Higher level rules drop into the operator precedence parser when they see things like expr, and the operator precedence parser drops into lower level rules before returning a term token (or if a macro specifies a particular followup parsing rule). Of course, it's possible that our tokener is just a fancy rule, in which case it would strongly resemble what you have above, only maybe with more alternatives, depending on where we decide to recognize the various kinds of terms. Oddly, depending on how we decide to do operator precedence, we might not do the conventional thing of treating parenthesized expressions as terms, but just make parens into pseudo operators that jack up the internal precedence and return the parens as individual tokens. But maybe we should stick with the ordinary recursive definition--it might give better error messages on missing parens, and we've already eliminated the 20-odd recursion levels that a strict recursive descent parser would impose on parentheses anyway. Or something. :-) Larry
Re: fast question
On Thu, Jul 08, 2004 at 11:46:25AM -0700, Larry Wall wrote: : With an array : match, you might find yourself redispatching individual operators in a : switch statement to provide that kind of specificity. In particular, macros with is parsed will want to have a place to hang their special parse rules without having to look up the macro name twice. And when you think about it, maybe ordinary left parenthesis is just stored as a circumfix macro with an is parsed rule of expr. Then circumfix:() and postcircumfix:() can automatically dispatch to different locations. Likewise for {} and []. Larry
Re: fast question
On Tue, Jul 06, 2004 at 06:39:07PM -0600, Luke Palmer wrote: Matija Papec writes: Would there be a way to still use simple unquoted hash keys like in old days ($hash{MYKEY})? Of course there's a way to do it. This is one of those decisions that I was against for the longest time, until one day something clicked and it made sense. Out of curiosity, can you articulate what clicked? This one still doesn't make sense to me, and I'd like to get it. You might do it something like this: macro postcircumfix:{} ($base, $subscript) is parsed( / $?subscript := (\w+) /) { return { $base.{$subscript} } } I don't recall seeing postcircumfix before, nor can I find it in A6...did I miss something? Are there others, aside from these: ? prefix: a unary prefix operator infix: a binary infix operator postfix:a binary suffix operator circumfix: a bracketing operator --Dks
Re: fast question
David Storrs writes: On Tue, Jul 06, 2004 at 06:39:07PM -0600, Luke Palmer wrote: Matija Papec writes: Would there be a way to still use simple unquoted hash keys like in old days ($hash{MYKEY})? Of course there's a way to do it. This is one of those decisions that I was against for the longest time, until one day something clicked and it made sense. Out of curiosity, can you articulate what clicked? This one still doesn't make sense to me, and I'd like to get it. I don't know, actually. Some of Larry's ideas have a tendency to do that with me. It felt wrong, and then after that short painful time, it felt very right. Sort of like... um... nevermind. You might do it something like this: macro postcircumfix:{} ($base, $subscript) is parsed( / $?subscript := (\w+) /) { return { $base.{$subscript} } } I don't recall seeing postcircumfix before, nor can I find it in A6...did I miss something? Are there others, aside from these: ? prefix: a unary prefix operator infix: a binary infix operator postfix:a binary suffix operator circumfix: a bracketing operator Tons. From A12: CategoryExample of use -- coerce:as 123 as BigInt, BigInt(123) self:sort @array.=sort term:...$x = {...} prefix:++$x infix:+ $x + $y postfix:++ $x++ circumfix:[][ @x ] postcircumfix:[]$x[$y] or $x .[$y] rule_modifier:p5m:p5// trait_verb:handles has $.tail handles wag trait_auxiliary:shall my $x shall conformTR123 scope_declarator:hashas $.x; statement_control:ifif $condition {...} else {...} infix_postfix_meta_operator:= $x += 2; postfix_prefix_meta_operator: @array ++ prefix_postfix_meta_operator: - @magnitudes infix_circumfix_meta_operator: @a + @b Though I have a suspition that those are just examples, and some of them won't make it. Plus, he forgot: grammatical_category:postcircumfix :-) This is one of those things that isn't going to be so much designed into the language but defined by the implementation. Where can we fit grammatical hooks? in addition to Where are they most useful? Luke
Re: fast question
Matija Papec writes: Would there be a way to still use simple unquoted hash keys like in old days ($hash{MYKEY})? imho %hashMYKEY at first sight resembles alien ship from Independence day. :) Of course there's a way to do it. This is one of those decisions that I was against for the longest time, until one day something clicked and it made sense. So I can certainly understand why you don't like it. You might do it something like this: macro postcircumfix:{} ($base, $subscript) is parsed( / $?subscript := (\w+) /) { return { $base.{$subscript} } } Whether that actually works depends on whether macros are applied until one Cis parsed matches. If not, then you'll have to do it some other way: macro postcircumfix:{} ($base, $subscript) { if $subscript.text ~~ /^ \w+ $/ { return { $base.{$subscript} }; } else { no macros 'postcircumfix:{}'; # make sure this isn't # interpreted by the macro return { $base.{$subscript} }; } } Luke