One of the first things that's becoming obvious to me in playing with
Rakudo's rules is that parsing strings isn't always what I'm going to
want to do. The most common example of wanting to parse data that's
not in string form is the YACC scenario where you want to have a
function produce a stream
Aaron Sherman wrote:
> One of the first things that's becoming obvious to me in playing with
> Rakudo's rules is that parsing strings isn't always what I'm going to
> want to do. The most common example of wanting to parse data that's
> not in string form is the YACC scenario where you want to have
Sorry, I accidentally took the thread off-list. Re-posting some of my
comments below:
On Wed, Oct 7, 2009 at 6:50 PM, Moritz Lenz wrote:
> Aaron Sherman wrote:
>> One of the first things that's becoming obvious to me in playing with
>> Rakudo's rules is that parsing strings isn't always what I'm
On 2009-Oct-7, at 5:18 pm, Aaron Sherman wrote:
This should be powerful enough to match any arbitrarily nested set of
iterable objects. I think it will be particularly useful against parse
trees (and similar structures such as XML/HTML DOMs) and scanner
productions, though users will probably fin
On 2009-Oct-5, at 3:41 pm, Jon Lang wrote:
Concerning that last one: would it be reasonable to have a Discrete
role
that provides a .succ method, and then overload the Range role?
I think a type needs to be Discrete and Ordered for successors to make
sense (e.g. consider a discrete unordere
On Thu, Oct 8, 2009 at 12:57 AM, David Green wrote:
> I agree that being able to parse data structure would be *extremely* useful.
> (I think I posted a suggestion like that at one time, though I didn't
> propose any syntax.) There is already a way to parse data -- Signatures,
> but not with th