Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #26557

Re: EuroForth 2013 proceedings available

Show all headers | View raw

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>I read the "Standardize Strings Now!" paper with interest and broadly 
>agree with the contents.  The bit on regular expressions (RE) is a bit 
>weak

Yes.  The main point here was that, looking at awk, that's the main
feature that was missing (apart from string construction words).

>and as I've developed a RE package which I've used quite a lot I 
>offer the following comments:
>
>I found it best to always compile a RE before using it with one of the 3 
>words (all self-explanatory I hope):
>
>regex ( "ccc..." -- rgx ) where rgx is a RE identifier
>regex$ ( caddr u -- rgx )
>parse-regex ( char "ccc<char>" -- rgx ) char is a terminating delimiter

Looks reasonable.  If we get recognizers before regexps, we could
avoid the parsing word (especially REGEX, which is probably intended
to be a combined word).

>For matching, the word SEARCH-REGEXP suffers from the problem mentioned 
>about too many stack parameters.

Possibly.  There's also the idea of having a version that works on the
input stream and thus avoids one input and one output string on the
stack.

For SEARCH-REGEXP, I have been thinking about arranging the results in
reverse order, i.e. the non-matching prelude on top, then the match,
then the stuff after the match.  Would make it relatively
straightforward to write a loop that processes the non-matching
prelude and matches one after the other; that would be useful for
implementing splitting and substitution.

>match ( caddr1 u1 rgx -- caddr2 u2 -1 | caddr1 u1 0 ) where (caddr2 u2) 
>is the rest of the input string (caddr1 u1) *after* the match. If no 
>match is found return the input string and 0
>
>The reason I don't return the match is that I implemented so-called 
>"capturing parentheses" which record matching sub-expressions. These are 
>held in an array and it is convenient to hold the (caddr u) of the 
>matching string in the 0th element of that array.

So you have the match as implicit output parameter.  But then you have
to access it, and at least for the uses I am thinking of this would
not help.

The sub-expressions are useful, but I am wondering if an array is
enough.  I have had cases where I had such matching sub-expressions
inside a repetition (e.g., '((u(v+)w)*(x(y+)z)*)+'), and if you only
have an array, it's hard to keep track of which array component
matched (v+) and which (y+).  A tree might be more appropriate.

>One thing, that would have to be decided, and was not discussed at all 
>is how to specify a RE. There seem to be 2 choices:
>- use a Perl or similar format which is common across most programming 
>languages (I did this as does the FFL and iForth's regexp.frt) or
>- use a reverse polish type notation as used in GForth's regexp.fs
>
>Which is preferred? I suppose the first alternative could be built on 
>top of the second but it would still be worth standardising the first 
>for portability.

Certainly, for a feature like this, which is coming from other
programming languages, and which does not integrate intimately with
Forth features, we should go with the common regexp syntax, so that
the programmers can transfer knowledge (and regexp code) between other
languages and Forth.

>To use the results from a RE match I found it tiresome to use existing 
>string primitives, S+ etc and developed a higher level, complementary 
>package to build strings from a pattern string, much like a greatly 
>extended sprintf(). This concatenates characters with results from the 
>RE match as well as allowing other Forth words to be executed, RE 
>searches to be nested etc. IF it proves difficult or impossible to agree 
>on a set of strings word for concatenation and other string operations 
>perhaps a similar higher level specification is a possibility?

That's a little too abstract to comment on, except: does
>STRING-EXECUTE fit the bill, and if not, why not?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

EuroForth 2013 proceedings available anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-07 15:41 +0000
  Re: EuroForth 2013 proceedings available mentifex@myuw.net - 2013-10-07 10:18 -0700
  Re: EuroForth 2013 proceedings available Mark Wills <markrobertwills@yahoo.co.uk> - 2013-10-08 00:35 -0700
  Re: EuroForth 2013 proceedings available Paul Rubin <no.email@nospam.invalid> - 2013-10-08 01:36 -0700
    Re: EuroForth 2013 proceedings available anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-09 13:53 +0000
      Re: EuroForth 2013 proceedings available Paul Rubin <no.email@nospam.invalid> - 2013-10-19 10:59 -0700
        Re: EuroForth 2013 proceedings available anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-28 16:09 +0000
  Re: EuroForth 2013 proceedings available Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-13 20:24 +0100
    Re: EuroForth 2013 proceedings available anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-15 15:32 +0000
      Re: EuroForth 2013 proceedings available Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-17 11:22 +0100
        Re: EuroForth 2013 proceedings available Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-10-26 20:55 +0100

csiph-web