I was just reading about hypothetical variables in Apocalypse 5.

I told a friend why Perl 6 Rules, and he wasn't impressed. It's easy enough to do something like that in C++, and usually we don't bother with anything that elaborate: just assign to temporaries and copy it home to "commit".

So that got me thinking... why limit hypothetical scope to regex?

Have something that works like temp (nee local) that resets the old value only if the block fails, but keeps the current value if the block succeeds.

Also, I don't like something Larry said:

if the variable is not pre-declared, ... the let also serves to declare the variable as lexically scoped to the rest of the regex
Hmm, isn't this going to cause the same surprises as auto-declaring in local (not global) scope that he doesn't like in an earlier installment?

Specifically, declaring a variable in an outer scope that happens to have the same name as my regex-local variable will suddenly change the behavior of the program, with no indication where in the code the meaning changed.

We need, instead, a proper way to declare variables within the regex if that's what's wanted.

—John

Replies are listed 'Best First'.
Re: hypothetical variables
by Elian (Parson) on Jul 09, 2002 at 21:49 UTC
    The only problem with extending hypothetical variables out past regexes is the expectations they'll raise in people who use them. They'll be, for all intents and purposes, transactional variables that'll get rolled back on error exit. Unfortunately there are a number of things (filehandles, sockets, tied variables) that are somewhere between really tough and totally impossible to undo. People'd get bitten by non-undoable things and, well, that'd be bad.
[reply]
      The general UNDO block mused over in passing could push-back read data, etc.

      You imply that this generalizes to rolling back over function calls. Perhaps a function can have a property that states it is undoable and returns an undo closure corresponding to the call.

[reply]
        You can't reliably push back data on file handles, nor can you reliably undo writes to file handles, nor can you take back accesses to tied data. That's where things get tough, and you don't need function calls involved, at least not explicitly--you just need to access some external resource or active data and hypothetical variables fall flat. Which is a shame, as it's a nifty idea.
[reply]
Re: hypothetical variables
by SteveRoe (Novice) on Jul 10, 2002 at 16:06 UTC
    On your point I told a friend why Perl 6 Rules, and he wasn't impressed. It's easy enough to do something like that in C++, and usually we don't bother with anything that elaborate: just assign to temporaries and copy it home to "commit".
    • I am struggling to find the C++ syntax/grammar that provides for rx in C++/Stroustrup - is this a new addition to the language (C#)???
    • One thing that really struck home in Apolcalypse 5 was that an rx spec is a program, not a string. And Perl 6 is the first language to comprehend this important distinction.
    • Having a clear role for ()[]{}<> gives an amazingly compact syntax...program blocks in a few chars, not a few lines.
    • Oh, and the ability to create and override grammars as though they were classes, and yet use them in familiar-ish rx s.
    I think this will keep Perl 6 way ahead of C++...
[reply]
      Sorry, I didn't mean to imply that C++ had an integrated rx syntax. Rather, that general-purpose speculative assignments/transations were possible with existing features.

      I think Perl5 "comprehended" this with the qr// syntax. It's obvious in languages where rx is an ordinary function or class, since backslashes for literal strings are totally independant from metacharacters seen by the function.

      Having callable subrules as predicates is something I've waited a long time for. That was the natural idea for me in the late '80's when I played with some ideas. And grammar-writing languages that don't separate yacc and lex concepts work that way.

      Having written recursive parsers in C++, Perl, Pascal, and others, it's clear that a "rule" is just a function that consumes input and returns true on a match. Writing that as a sub or a re doesn't matter, and is an intuitive way to do it once re becomes an object that is the "this" of embedded code like we see in P5.

      I think it's good when language design progress resonates with common practice. Just let the compiler support it rather than just permit it, and give it awareness of the concepts of our current patterns.

      I think Perl 6 will totally displace yacc/lex and other tools for writing grammars.

[reply]

Back to Meditations