Hi Eric,<br><br><div class="gmail_quote">On 17 January 2012 14:19, Erik Silkensen <span dir="ltr">&lt;<a href="mailto:eriksilkensen@gmail.com">eriksilkensen@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word">Hi Simon,<div><br></div><div>I think one problem might be that &#39;any-string&#39; is including whitespace.  Could you define alias and fact in some way that&#39;s more specific?  For example, if you had an &#39;id&#39; token of just letters ((:+ alphabetic) (token-id lexeme)) then maybe your grammar is just...</div>

<div></div></div></blockquote></div><br><div>Unfortunately I&#39;d like an alias or a fact to include whitespace. I guess for this, parser-tools would need genuine look-ahead which it doesn&#39;t seem to offer. Ideally, I&#39;d just like to lex either &#39;word&#39; or &#39;address&#39; tokens and have the grammar compile these in to place, so I could express the language as:</div>

<div>&#39;Remember &lt;word&gt;+ is &lt;address&gt;&#39; -&gt; &#39;(remember ,$2 ,$4)</div><div>&#39;Remember &lt;word&gt;+&#39; -&gt; &#39;(fact ,$2)</div><div><br></div><div>I could probably fudge something like this in the lexer, but I&#39;d then have to regex the lexeme to extract the relevant parts. Another problem is the parser-tools parser (and bison, for that matter) can&#39;t compile arbitrary tokens--they need to be declared beforehand, so I can&#39;t have a transformation rule &#39;word-token whose value is &quot;is&quot;&#39;, for example.</div>

<div><br></div><div>It looks like my best approach is a phalanx of regexes, so I&#39;ll give this a try. Many thanks for your reply and suggestions.</div><div>Simon.</div><div><br></div><div><br></div>