Re: Regular expression functions (Was: Re: [xsl] comments on December F&O draft)

Subject: Re: Regular expression functions (Was: Re: [xsl] comments on December F&O draft)
From: David Carlisle <davidc@xxxxxxxxx>
Date: Sat, 12 Jan 2002 21:11:19 GMT

> Seriously? You write an extension function to create the relevant XML.
> Or you do it in a pre-processing step.

Maybe but as I'm offering the browser as essentially an "instant
preview" I'm trying to avoid extensions (to give mozilla/netscape a
chance). Anyway I could do it in perl or emacs (and that's what the
omnimark that started the thread was doing) but the idea is to see where
to put the boundary of what can be done in xslt...


> Honestly, I can't see much difference between having to handle this
> syntax and having to handle:
ah that's easy I just use d-o-e for that:-)

> But anyway, I like the LEX/YACC idea, and think it might be the way to
> go. You basically create a grammar for the structure, using regular
> expressions to represent the component parts.

I'm not convinced yet actually, I think it duplicates too much existing
xslt functionality. It's clear that lex/yacc accepts a larger class of
grammars than regular expressions (I see Dimitre's already supplied the
details), but I think (somehow) the extra functionality (which basically
just always comes down to nesting, counting and storing information for
look-ahead) is already present in xslt so the trick is to add regexp
support (only) in a way that the extra arithmetic functionality can be
pulled from xpath/xslt for those occasions when you need it.  Since we
argued a long time ago that xslt was turing complete (given an
approximation to an infinite tape) everything's possible anyway so it's
only a matter of convenience.

Basically while doing regexp-replace (even extended ones where the
replacement is a tree fragment) you are editing documents.
If however you start writing LALR(1) Grammars for yacc then you have
left document editing and become a parser-implementer (ie you've become
a computer scientist, a terrible fate to befall anyone:-).

> I am fairly convinced that it's possible to create an implementation
> to do this,

but given there's some resistence to extending Xpath with a parser for
one fixed language, xpath (the evaluate function) you might find there's
some resistence to adding a parser generator:-) (given a lex
implementation you could (I think, haven't checked) implement an Xpath
parser if you wished... 

David


_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread