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

Groups > comp.lang.forth > #26347 > unrolled thread

EuroForth 2013 proceedings available

Back to article view | Back to comp.lang.forth

Contents

  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

#26347 — EuroForth 2013 proceedings available

The EuroForth 2013 proceedings and the individual papers and/or
presentation slides are now available on

<http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/>

and BibTeX entries for these papers and slides are also available
<http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/euroforth2013.bib>.

The papers page is also linked from the EuroForth 2013 page
<http://www.complang.tuwien.ac.at/anton/euroforth/ef13/>, which is
linked from the EuroForth page <http://www.euroforth.org/> (or
<http://www.complang.tuwien.ac.at/anton/euroforth/>).

The authors and titles of the papers are:

Refereed Papers

    * Andrew Read: Optimizing memory access design for a 32 bit FORTH
      processor

Non-refereed papers

    * Nick J. Nelson:
      Forth Query Language (FQL) -- Implementation and Experience
    * M. Anton Ertl: PAF: A Portable Assembly Language
    * M. Anton Ertl: Standardize Strings Now!
    * Sergey Baranov: Forth in Russia
    * Willi Stricker:
      Forth Floating Point Word-Set without Floating Point Stack

Presentations

    * Ulrich Hoffmann: Forth Literate Programming with IPython notebook
    * Gerald Wodni: Forth to .NET Bridge
    * M. Anton Ertl: Region-Based Memory Allocation
    * Bernd Paysan: net2o: Application Layer -- Browser Components

- 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/

[toc] | [next] | [standalone]

#26348

On Monday, October 7, 2013 8:41:37 AM UTC-7, Anton Ertl wrote:
> [...] Sergey Baranov: Forth in Russia [...]

Interesting article on Forth in Russia.

McAfee warned me not to visit the site

http://wiki.forth.org.ru

but I clicked on "Visit anyway." 

Then I could not figure out how to gain entry
beyond the main page. 

Arthur
-- 
http://www.amazon.com/dp/B00FKJY1WY 

[toc] | [prev] | [next] | [standalone]

#26351

Wow. Some really interesting papers this year. The ones that jump out at me are:

* Optimizing memory access design for a 32 bit FORTH processor 
* Forth Query Language (FQL) -- Implementation and Experience 
* M. Anton Ertl: PAF: A Portable Assembly Language 
* M. Anton Ertl: Standardize Strings Now! 
* Sergey Baranov: Forth in Russia 

Can't wait to wade into these. Good job all. Very interested to see names that I am not familiar with; these people don't appear to post on CLF.

[toc] | [prev] | [next] | [standalone]

#26353

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> The EuroForth 2013 proceedings and the individual papers and/or
> presentation slides are now available on
> <http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/>

Thanks, looks like there is nice stuff there.  So far I've only looked
at your PAF paper and Bernd's net2o presentation, and both are great.

Regarding PAF, you might know about Reuben Thomas's "Mite" which
I've been wanting to try out: http://rrt.sc3d.org/Software/Mite/

The MINIMAL portable assembler used for retargeting SPITBOL is
documented here:
 https://github.com/hardbol/spitbol/blob/master/minimal-reference-manual.html

Also Dan Bernstein's qhasm might be of interest: http://cr.yp.to/qhasm.html
its purpose is rather different than PAF though.

FWIW, I'm impressed by this recent result of LuaJIT:
https://cowlark.com/luje/doc/stable/doc/index.wiki

I've wondered about using the backend of TinyCC as a JIT but it's quite
a lot of code, not that much smaller than LuaJIT.

[toc] | [prev] | [next] | [standalone]

#26367

Paul Rubin <no.email@nospam.invalid> writes:
>Regarding PAF, you might know about Reuben Thomas's "Mite" which
>I've been wanting to try out: http://rrt.sc3d.org/Software/Mite/

Certainly, Mite has been presented at EuroForth.  There is a
difference in focus between portable assembly languages like PAF and
virtual machines like JVM and Mite:

They are both intermediate languages, but VMs like these also have
their own code distribution format and present the program with a
closed environment that allows things like garbage collection on the
VM level, but may be a bad match for many languages (e.g., the JVM is
a bad match for Forth).  In contrast, a portable assembly just
abstracts some differences between concrete machines away for
portability, but otherwise tries to give access to the raw
(user-level) machine.

>The MINIMAL portable assembler used for retargeting SPITBOL is
>documented here:
> https://github.com/hardbol/spitbol/blob/master/minimal-reference-manual.html

That seems to be similar in spirit to PAF.  I would have to look
closer at it to make a well-founded comparison.

>Also Dan Bernstein's qhasm might be of interest: http://cr.yp.to/qhasm.html
>its purpose is rather different than PAF though.

Yes, I looked at that when writing the paper (it comes up when you
google for "portable assembly language").  It's also a portable
assembly language in spirit, but the focus is on multi-precision
arithmetic (where existing portable assembly languages such as C suck,
and PAF is not much better) rather than on features a language
compiler would use.  Some comments in my paper on missing features of
PAF were inspired by this work.

>I've wondered about using the backend of TinyCC as a JIT

AFAIK The back end of tcc is integrated with the front end, so that
would be quite a bit of work.

- 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/

[toc] | [prev] | [next] | [standalone]

#26649

>>Regarding PAF, you might know about Reuben Thomas's "Mite"
> They are both intermediate languages, but VMs like these also have
> their own code distribution format and present the program with a
> closed environment that allows things like garbage collection 

Aha, I didn't realize Mite was that fancy, and apparently it has (or is
made for) a JVM-like JIT rather than having a static translator.  So it
doesn't sound so good for very small targets.

>>The MINIMAL portable assembler used for retargeting SPITBOL
> That seems to be similar in spirit to PAF.  I would have to look
> closer at it to make a well-founded comparison.

MINIMAL seems much more primitive than PAF.  It's basically a macro
preprocessor written in Spitbol, that translates a
lowest-common-denominator, abstracted assembly language to various
targets.  So for example, it exposes six or so fixed registers to the
user program.  On the other hand, a quite substantial program (Spitbol)
was written in it.

PAF on the other hand seems more like a compiler IR than an assembly
language, in that it has register allocation and instruction selection.
Can you say how are you doing instruction selection?  Also, are you
planning to release the code?

> AFAIK The back end of tcc is integrated with the front end, so that
> would be quite a bit of work.

Yeah, tcc looked pretty tightly coupled.  My current thoughts are
towards HBurg:

  http://www.bytelabs.org/hburg.html

It generates BURG-style instruction recognizers, that are currently
emitted in Java, though that is probably hackable.  (HBurg itself is
written in Haskell).  It cites this, which might be more in the PAF
and Forth spirit:

http://www.well.com/~cwf/pro/Fraser%20and%20Proebsting.%20Finite-state%20code%20generation.pdf

From the abstract: "A stack-based virtual machine-known as the Lean
Virtual Machine (LVM)-tuned for fast code generation is also described.
GBURG translates the two-page LVM-to-x86 specification into a code
generator that fits entirely in an 8 KB I-cache and that emits x86 code
at 3.6 MB/set on a 266-MHz P6.  Our just-in-time code generator
translates and executes small benchmarks at speeds within a factor of
two of executables derived from the conventional compile-time code
generator on which it is based."

This might also be of interest (I haven't looked at it much yet, but
it's also cited in the HBurg paper):

Todd A. Proebsting , Benjamin R. Whaley: 
One-Pass, Optimal Tree Parsing - With Or Without Trees (1995) /
Compiler Construction (CC'96), pages 294--308, Linkoping

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.8367

"This paper describes the theory behind and implementation of wburg, a
code-generator generator that accepts tree grammars as input and
produces a code generator that emits an optimal parse of an IR tree in
just a single bottom-up pass. Furthermore, wburg eliminates the need for
an explicit IR tree altogether."

[toc] | [prev] | [next] | [standalone]

#26723

Paul Rubin <no.email@nospam.invalid> writes:
>PAF on the other hand seems more like a compiler IR than an assembly
>language, in that it has register allocation and instruction selection.

Yes.  It's a "portable assembly language" in the same sense that C--
is and that C used to be.

>Can you say how are you doing instruction selection?

Tree parsing (i.e., (i)BURG-like).  Maybe also have GNU Lightning as
target.

>Also, are you
>planning to release the code?

I have to write it first, but if and when I do, yes, of course.

>It cites this, which might be more in the PAF
>and Forth spirit:
>
>http://www.well.com/~cwf/pro/Fraser%20and%20Proebsting.%20Finite-state%20code%20generation.pdf

That would be a possible code generation technology for PAF, but the
focus of PAF is as language.  You can use a variety of code generation
techniques when compiling it to native code.

- 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/

[toc] | [prev] | [next] | [standalone]

#26481

On 07/10/2013 16:41, Anton Ertl wrote:
> The EuroForth 2013 proceedings and the individual papers and/or
> presentation slides are now available on
>
> <http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/>
>

>

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 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

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

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.

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.

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?


-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#26557

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/

[toc] | [prev] | [next] | [standalone]

#26608

On 15/10/2013 16:32, Anton Ertl wrote:
> 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).
>
[...]

>> 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.
>

I followed the Perl model, at least what it was 2 or 3 years ago, where 
the sub-expression captured is that last encountered during the matching 
process, as illustrated in these examples: (STRINGER$ is the word that 
builds the string from the output of the RE match - more later)

\ ------- Using GForth
s" regex.fth" included

s" ((u(v+)w)*(x(y+)z)*)+" regex$ constant rgx1

: .results  ( caddr u f -- )
    if
       cr ." Unused: " type
       s" \nMatch: \M\nSub-expressions: \1, \2, \3, \4, \5\n"
       stringer$ type
    else
       cr ." No match" 2drop
    then
;

s" uvvwxyyyzabc" rgx1 match .results
Unused: abc
Match: uvvwxyyyz
Sub-expressions: uvvwxyyyz, uvvw, vv, xyyyz, yyy

s" uvvwxyyyzuvvvwxyz" rgx1 match .results
Unused:
Match: uvvwxyyyzuvvvwxyz
Sub-expressions: uvvvwxyz, uvvvw, vvv, xyz, y

s" uvvwxyyyzuvvvw" rgx1 match .results
Unused:
Match: uvvwxyyyzuvvvw
Sub-expressions: uvvvw, uvvvw, vvv, xyyyz, yyy
  ok
\ ----------------------
Perl gives the same results.

The final + in the RE effectively causes multiple loops that, as you 
say, needs a tree to store all captured sub-expressions. I suppose that 
a decision has to be made whether the RE processor has to handle that 
level of complexity for capturing sub-expressions or whether the user 
has to program multiple loops and either use the results as they appear 
or build the tree himself e.g.

s" ((u(v+)w)*(x(y+)z)*)" regex$ constant rgx2
...
( caddr u ) begin rgx2 match while ( use the results) repeat
...

I chose that approach. What does awk do? I've never used it.

>> 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.

Good I totally agree.

>
>> 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?

I haven't seen a specification for >STRING-EXECUTE but from the paper 
we're discussing I assume it's a wrapper that allocates a buffer or 
region, and vectors output words like TYPE to save strings into the 
buffer before EXECUTEing the xt. If so then >STRING-EXECUTE doesn't fit 
the bill as it has a completely different function.

It's probably best to illustrate my approach with examples. In the above 
example I used:

s" \nMatch: \M\nSub-expressions: \1, \2, \3, \4, \5\n" stringer$

where STRINGER$ ( caddr u -- addr2 u2 ) builds an output string (caddr2 
u2) by interpreting the pattern (caddr u). In the pattern '\' is an 
escape character and:
\n is a new line, \M is the RE match, \1 is sub-expression 1, \2 
sub-expression 2 etc. Other characters are passed through unchanged.
STRINGER$ concatenates items from the pattern into a pre-allocated 
buffer which is optionally cleared at the start. The output of the 
second use of STRINGER$ was:

Match: uvvwxyyyzuvvvwxyz
Sub-expressions: uvvvwxyz, uvvvw, vvv, xyz, y

Another example taken from your paper:

\ --- Your example
: repl-num1 ( -- )
    begin
       s" [0-9]+" parse-regexp while
       2swap type 2drop ." <num>"
    repeat
    0 parse type ;
: repl-num2 ( c-a u -- )
    [’] repl-num1 execute-parsing ;
: repl-num ( c-a1 u1 -- c-a2 u2 )
    [’] repl-num2 >string-execute ;

\ --- My equivalent, using GForth, regex already included

: repl-num  ( c-a u -- c-a2 u2 )
    clear-concat s" [0-9]+" regex$ >r
    begin
       r@ match
    while
       s" (?-c)\H<num>(?-g)" stringer$
    repeat r> drop
    2drop s" (?-c)\H" stringer$    \ Or concat get-concat
;

s" a = 123, b = -456, c = 2 done" repl-num cr type   \ gives
a = <num>, b = -<num>, c = <num> done ok
\ -----------

In the pattern (?-c) means don't clear the buffer, cleared by default
(?-g) means don't return the contents of the buffer, default is return
\H is the input string before the match,
\T is the string after the match

Probably >STRING-EXECUTE could be used to call STRINGER$ to allocate the 
buffer.

There's a lot more to the RE package and the string builder. If you're 
interested I can send you a description or even the whole package so you 
can try it out.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#26701

On 17/10/2013 11:22, Gerry Jackson wrote:

[...]

> Another example taken from your paper:
>
> \ --- Your example
> : repl-num1 ( -- )
>     begin
>        s" [0-9]+" parse-regexp while
>        2swap type 2drop ." <num>"
>     repeat
>     0 parse type ;
> : repl-num2 ( c-a u -- )
>     [’] repl-num1 execute-parsing ;
> : repl-num ( c-a1 u1 -- c-a2 u2 )
>     [’] repl-num2 >string-execute ;
>
> \ --- My equivalent, using GForth, regex already included
>
> : repl-num  ( c-a u -- c-a2 u2 )
>     clear-concat s" [0-9]+" regex$ >r
>     begin
>        r@ match
>     while
>        s" (?-c)\H<num>(?-g)" stringer$
>     repeat r> drop
>     2drop s" (?-c)\H" stringer$    \ Or concat get-concat
> ;
>
> s" a = 123, b = -456, c = 2 done" repl-num cr type   \ gives
> a = <num>, b = -<num>, c = <num> done ok
> \ -----------

It has since occurred to me that, since both regex$ and stringer$ can 
include executable forth code and conditionals in their strings and are 
nestable, we can implement the above Forth loop in a RE. One possibility is:

: repl-one  ( -- )  s" (?-c)\H(?(1)<num>)(?-g)" stringer$ ;

s" ([0-9]+)" regex$ constant num-regex

: repl-all  ( caddr u -- caddr2 u2 )
    2dup
    s" (?(?{num-regex match repl-one})|(?{2drop})(?!))*" regex$ match
    drop 2drop
;

: repl-num  ( caddr u -- caddr2 u2 )  s" (?{repl-all})" stringer$ ;

s" a = 123, b = -456, c = 2 done" repl-num cr type
a = <num>, b = -<num>, c = <num> done ok

\ as before

If MATCH returned the same strings as your SEARCH-REGEXP the above would 
have been more cumbersome.

-- 
Gerry

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web