Re: rx_compile and FSAs

Leo~

I am of the opinion that we should treat regular expression as simply
another language.  Thus one can register different compilers for
different regex syntaxes and we do not need to add more opcodes for
them.  This also has the advantage of placing their internals in a
black box off to the side.  So, the regex compiler can choose to
agressively compile and optimize from the start or do it lazy at its
whim while hiding behind the interface that the compile opcode already
presents.

Matt


On Wed, 13 Oct 2004 16:29:07 +0200, Leopold Toetsch <lt@xxxxxxxxxx> wrote:
> Aaron Sherman <ajs@xxxxxxx> wrote:
> > I've done quite a lot of thinking about Parrot's rx_compile op, as I was
> > thinking about implementing it.
> 
> Given that rx_compile syntax and semantics aren't really final and
> second that compiling a rx takes substantial time, I'd do something like
> this:
> 
>   # classes/rx_compiler.pmc
>   #
>   pmclass Rx_Compiler extends Compiler need_ext {
>       ...
>       METHOD rx_to_fsa(){...}   # as discussed today - NCI method
>       ...
>   }
> 
> Then cou can
> 
>   Px = new Rx_Compiler
>   foo = Px."rx_to_fsa"(bar)
>   ... whatever is appropriate
> 
> You can experiment with needed methods, implement new ...
> You can subclass the Rx_Compiler, implement it in PIR and what not.
> 
> Eventually for gaining the last bit of speed, we could make opcodes for
> the methods.
> 
> leo
> 
> 


-- 
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???