FAQ
Please forgive me if this an FAQ. I am new to the world of RecDescent
and grammars in general. I'm assisting on a project for which the
original grammar was developed by someone else; making my own
additions, learning (sometimes) as I go. Not a pro, just dabbling.

I've tried to distill the grammar down for this post, but again, I
apologize if it is too long to digest. If you don't like it, you can
say, in our full grammar: ex R3 up.

I can't for the life of me figure out how to ensure that the tokens
are separated by whitespace, so that, eg
5 pu 2n mu 3
would not be confused with
5 pu 2nm

I tried setting $Parse::RecDescent::skip = '[ \t]+' and every line was
bad. Is this separation something that needs to be dealt with in the
rules, and if so how?

TIA,
Scott Swanson

<code>
package SFNParse;

use Parse::RecDescent;

# Note: the grammar is stripped down, so a lot of these don't appear in it.
our %abbrevs = (
# Hands (X-axis)
'L'=>'left','R'=>'right','M'=>'middle',
# z-axis
'n'=>'near','f'=>'far', 'a'=>'axial',
# x-axis
'o'=>'outer', 'i'=>'inner', 'm'=>'middle',
# y-axis
't'=>'top', 'c'=>'center','b'=>'bottom',
# Directions
'dx'=>'distally','px'=>'proximally','lr'=>'from left to right','rl'=>'from right to left','nf'=>'near to far', 'fn'=>'far to near',
'up'=>'upwards', 'dn'=>'downwards',
'da'=>'down and away from you','ua'=>'up and away from you','dt'=>'down and towards you','ut'=>'up and towards you',
'tw'=>'towards you','aw'=>'away from you','io'=>'from centre out','oi'=>'from outside to centre',
'lor'=>'left over right', 'rol'=>'right over left',
# Twists
'>'=>"a half turn away from you",'>>'=>"a full turn away from you",'<'=>"a half turn towards you",'<<'=>"a full turn towards you",
# 'Descriptor' strings (added VS, changed text of CS, anticipating 'mid')
'DS'=>'diagonal','SS'=>'straight','XS'=>'crossed','CS'=>'centre','TV'=>'transverse',
'VS'=>'vertical','DM'=>'diamond',
# Bodyparts (. means 'in the figure')
'1'=>'thumb', '2'=>'forefinger', '3'=>'middle finger','4'=>'ring finger','5'=>'little finger',
'P'=>'palm','H'=>'hand','W'=>'wrist','O'=>'mouth','.'=>' ','B'=>'back of hand',
'T'=>'toe or etc', 'F'=>'fingers',
# Commands (added hu,hd)
'pu'=>'pick up','gr'=>'grasp','hu'=>'hook up','hd'=>'hook down',
'kl'=>'keep loose','ls'=>'let slip','ht'=>'hold tight','ex'=>'extend',','=>'then..',
'na'=>'navaho','tr'=>'transfer','fl'=>'flip','<=>'=>'exchange',
'mo'=>'over','mu'=>'under','mt'=>'through',
'mb'=>'between',
'rep'=>'repeat', 'rot'=>'rotate','rel'=>'release','ret'=>'return','pnt'=>'point',
);

my $grammar = q {
move: (rel_move | take ) stringdesc {"$item[1] $item[2]";}
take: ("pu" | "gr" | "hu" | "hd") direction(?) {$SFNParse::abbrevs{$item[1]}." ".$item[2][0];}
rel_move: ("mo" | "mu" | "mt") direction(?) {"move" . "$item[2][0] ".$SFNParse::abbrevs{$item[1]};}
stringdesc: strings {$item[1];}
strings: string(s) {join(" / ", @{$item[1]});}
string: ( mnoose | mstring )
mnoose: manipulator "N" height(?){"$item[3][0] $item[1] noose";}
mstring: manipulator height(?) side(?) lat(?) descriptor(?){join(" ", @{$item[2]},@{$item[3]},@{$item[4]},$item[1],@{$item[5]}," string");}
side: ("n" | "f" | "a") {$SFNParse::abbrevs{$item[1]};}
lat: ("i" | "o" | "m") {$SFNParse::abbrevs{$item[1]};}
height: ("t" | "c" | "b") {$SFNParse::abbrevs{$item[1]};}
descriptor: ("DS" | "XS" | "CS" | "SS" | "TV" | "VS" | "DM") {$SFNParse::abbrevs{$item[1]};}
direction:("px" | "dx" | "lr" | "rl" | "nf" | "fn") {$SFNParse::abbrevs{$item[1]};}
manipulator: hand(?) bodypart(s) {"$item[1][0] ".join("/", @{$item[2]});}
hand: ("L" | "R" | "M") {$SFNParse::abbrevs{$item[1]};}
bodypart:("1" | "2" | "3" | "4" | "5" | "P" | "H") {$SFNParse::abbrevs{$item[1]};}
action: manipulator move(s) {$item[1] . " " . join (", ", @{$item[2]});}
fullmove: action modifier(?) {$item[1].(($item[2][0]) ? " and ". $item[2][0] : "");}
modifier: ("ex" | "ret" | "si" | "kl" | ",") {$SFNParse::abbrevs{$item[1]};}
validstep: code_ref | repeat | fullmove | voice
stepline: /\\\{?/ validstep /\\\}?/ comment(?) {"$item[1] $item[2] $item[3] $item[4][0]";}
comment: "#" /.+/ {"($item[2])";}
code_ref: "[" /\w+/ "]" { "perform $item[2]";}
voice: "v" /.+/ {'"'.$item[2].'"';}
repeat: "rep" stepnumber "-" stepnumber {"repeat steps $item[2] to $item[4] "}
stepnumber: /\d+/

};

my $parser = new Parse::RecDescent ($grammar) or die "Bad grammar!\n";

while (<DATA>) {
my $text = $parser->stepline($_) || "Error: $_";
print "$text\n";
}
__DATA__
1 pu 5f
1 pu 5tfo
1 mu 2n pu 5cni
1 pu 2n mu 5cni # this is wrong
1mu2npu5cni # Yucch! But it parses....

</code>

Search Discussions

  • Ron Smith at Jun 27, 2005 at 5:19 pm

    Scott wrote:

    Subject:
    space-separated tokens (FAQ?)
    From:
    Scott <harview@montana.com>
    Date:
    Sun, 26 Jun 2005 12:28:05 -0600
    To:
    recdescent@perl.org

    To:
    recdescent@perl.org


    Please forgive me if this an FAQ. I am new to the world of RecDescent
    and grammars in general. I'm assisting on a project for which the
    original grammar was developed by someone else; making my own
    additions, learning (sometimes) as I go. Not a pro, just dabbling.

    I've tried to distill the grammar down for this post, but again, I
    apologize if it is too long to digest. If you don't like it, you can
    say, in our full grammar: ex R3 up.

    I can't for the life of me figure out how to ensure that the tokens
    are separated by whitespace, so that, eg
    5 pu 2n mu 3
    would not be confused with
    5 pu 2nm

    I tried setting $Parse::RecDescent::skip = '[ \t]+' and every line was
    bad. Is this separation something that needs to be dealt with in the
    rules, and if so how?

    TIA,
    Scott Swanson

    <code>
    package SFNParse;

    use Parse::RecDescent;

    # Note: the grammar is stripped down, so a lot of these don't appear in it.
    our %abbrevs = (
    # Hands (X-axis)
    'L'=>'left','R'=>'right','M'=>'middle',
    # z-axis
    'n'=>'near','f'=>'far', 'a'=>'axial',
    # x-axis
    'o'=>'outer', 'i'=>'inner', 'm'=>'middle',
    # y-axis
    't'=>'top', 'c'=>'center','b'=>'bottom',
    # Directions
    'dx'=>'distally','px'=>'proximally','lr'=>'from left to right','rl'=>'from right to left','nf'=>'near to far', 'fn'=>'far to near',
    'up'=>'upwards', 'dn'=>'downwards',
    'da'=>'down and away from you','ua'=>'up and away from you','dt'=>'down and towards you','ut'=>'up and towards you',
    'tw'=>'towards you','aw'=>'away from you','io'=>'from centre out','oi'=>'from outside to centre',
    'lor'=>'left over right', 'rol'=>'right over left',
    # Twists
    '>'=>"a half turn away from you",'>>'=>"a full turn away from you",'<'=>"a half turn towards you",'<<'=>"a full turn towards you",
    # 'Descriptor' strings (added VS, changed text of CS, anticipating 'mid')
    'DS'=>'diagonal','SS'=>'straight','XS'=>'crossed','CS'=>'centre','TV'=>'transverse',
    'VS'=>'vertical','DM'=>'diamond',
    # Bodyparts (. means 'in the figure')
    '1'=>'thumb', '2'=>'forefinger', '3'=>'middle finger','4'=>'ring finger','5'=>'little finger',
    'P'=>'palm','H'=>'hand','W'=>'wrist','O'=>'mouth','.'=>' ','B'=>'back of hand',
    'T'=>'toe or etc', 'F'=>'fingers',
    # Commands (added hu,hd)
    'pu'=>'pick up','gr'=>'grasp','hu'=>'hook up','hd'=>'hook down',
    'kl'=>'keep loose','ls'=>'let slip','ht'=>'hold tight','ex'=>'extend',','=>'then..',
    'na'=>'navaho','tr'=>'transfer','fl'=>'flip','<=>'=>'exchange',
    'mo'=>'over','mu'=>'under','mt'=>'through',
    'mb'=>'between',
    'rep'=>'repeat', 'rot'=>'rotate','rel'=>'release','ret'=>'return','pnt'=>'point',
    );

    my $grammar = q {
    move: (rel_move | take ) stringdesc {"$item[1] $item[2]";}
    take: ("pu" | "gr" | "hu" | "hd") direction(?) {$SFNParse::abbrevs{$item[1]}." ".$item[2][0];}
    rel_move: ("mo" | "mu" | "mt") direction(?) {"move" . "$item[2][0] ".$SFNParse::abbrevs{$item[1]};}
    stringdesc: strings {$item[1];}
    strings: string(s) {join(" / ", @{$item[1]});}
    string: ( mnoose | mstring )
    mnoose: manipulator "N" height(?){"$item[3][0] $item[1] noose";}
    mstring: manipulator height(?) side(?) lat(?) descriptor(?){join(" ", @{$item[2]},@{$item[3]},@{$item[4]},$item[1],@{$item[5]}," string");}
    side: ("n" | "f" | "a") {$SFNParse::abbrevs{$item[1]};}
    lat: ("i" | "o" | "m") {$SFNParse::abbrevs{$item[1]};}
    height: ("t" | "c" | "b") {$SFNParse::abbrevs{$item[1]};}
    descriptor: ("DS" | "XS" | "CS" | "SS" | "TV" | "VS" | "DM") {$SFNParse::abbrevs{$item[1]};}
    direction:("px" | "dx" | "lr" | "rl" | "nf" | "fn") {$SFNParse::abbrevs{$item[1]};}
    manipulator: hand(?) bodypart(s) {"$item[1][0] ".join("/", @{$item[2]});}
    hand: ("L" | "R" | "M") {$SFNParse::abbrevs{$item[1]};}
    bodypart:("1" | "2" | "3" | "4" | "5" | "P" | "H") {$SFNParse::abbrevs{$item[1]};}
    action: manipulator move(s) {$item[1] . " " . join (", ", @{$item[2]});}
    fullmove: action modifier(?) {$item[1].(($item[2][0]) ? " and ". $item[2][0] : "");}
    modifier: ("ex" | "ret" | "si" | "kl" | ",") {$SFNParse::abbrevs{$item[1]};}
    validstep: code_ref | repeat | fullmove | voice
    stepline: /\\\{?/ validstep /\\\}?/ comment(?) {"$item[1] $item[2] $item[3] $item[4][0]";}
    comment: "#" /.+/ {"($item[2])";}
    code_ref: "[" /\w+/ "]" { "perform $item[2]";}
    voice: "v" /.+/ {'"'.$item[2].'"';}
    repeat: "rep" stepnumber "-" stepnumber {"repeat steps $item[2] to $item[4] "}
    stepnumber: /\d+/

    };

    my $parser = new Parse::RecDescent ($grammar) or die "Bad grammar!\n";

    while (<DATA>) {
    my $text = $parser->stepline($_) || "Error: $_";
    print "$text\n";
    }
    __DATA__
    1 pu 5f
    1 pu 5tfo
    1 mu 2n pu 5cni
    1 pu 2n mu 5cni # this is wrong
    1mu2npu5cni # Yucch! But it parses....
    Scott, it is "bad form" to post code that you have not tested. I copied
    the above verbatim into an editor and every line in your test data
    causes an "error" message. Moreover, there is nothing in your grammar
    that handles "comments".

    Second if you really want help, telling the potential helper to go "ex
    R3 Up" themselves is also not particularly helpful. Ex R3 up to you
    too... "Ex R3 io" for the horse you rode in on.

    But assuming that you meant this somewhat in jest and that your mother
    didn't raise you to have enough sense to be gracious, I'll provide a few
    bread crumbs.

    First, turn on "$RD_TRACE = 1;", it will show you what the parser is
    doing while it is doing it. I find this helpful to work through problems.

    Second, it seems that what you want to parse is inherently ambiguous
    because there is no obvious difference between "n mu" and "nm" when you
    discount white space.

    Fundamentally you need to decide if white-space is part of your grammar.
    If so, then what will help to disambiguate this case is a look-ahead
    that comprehends the white-space. If white space is not truly required,
    than what you need is still a look-ahead, but something that parses
    ahead to see if the "other" case is what *will* happen.

    However, in general, designing ambiguous grammars is something to avoid.
  • Scott at Jun 28, 2005 at 4:27 am

    On Mon, Jun 27, 2005 at 10:19:22AM -0700, Ron Smith wrote:

    Scott, it is "bad form" to post code that you have not tested. I copied
    the above verbatim into an editor and every line in your test data
    causes an "error" message. Moreover, there is nothing in your grammar
    that handles "comments".
    Hmmm. I had tested the code before sending, and it worked fine. I know
    better than to post untested code.
    Second if you really want help, telling the potential helper to go "ex
    R3 Up" themselves is also not particularly helpful. Ex R3 up to you
    too... "Ex R3 io" for the horse you rode in on. cute....
    But assuming that you meant this somewhat in jest and that your mother
    didn't raise you to have enough sense to be gracious, I'll provide a few
    bread crumbs.
    Whoa. What I said was that, if my post was in bad form,
    you were free to tell _me_ 'ex R3 up'. I was trying to be gracious in
    apologising in advance for intruding into the world of experts. Viz:
    I've tried to distill the grammar down for this post, but again, I
    apologize if it is too long to digest. If you don't like it, you can
    ^^^
    say, in our full grammar: ex R3 up.
    Please read before ranting. And you can leave my mother out of this,
    thanks.
    Second, it seems that what you want to parse is inherently ambiguous
    because there is no obvious difference between "n mu" and "nm" when you
    discount white space. Right....
    Fundamentally you need to decide if white-space is part of your
    grammar.
    As is evident from my question, it is.
    If so, then what will help to disambiguate this case is a look-ahead
    that comprehends the white-space. If white space is not truly required,
    than what you need is still a look-ahead, but something that parses
    ahead to see if the "other" case is what *will* happen.
    I guess I was asking for the 'look-ahead that comprehends
    white-space'. I always thought a grammar was handed 'tokens',
    notjustawholebunchofstuffglommedtogetherinonestream;guessIwaswrong.
    However, in general, designing ambiguous grammars is something to
    avoid.
    Fruit flies like a banana.

    Thanks for the crumbs,
    Scott.
  • Ron Smith at Jun 28, 2005 at 4:59 pm

    Scott wrote:
    On Mon, Jun 27, 2005 at 10:19:22AM -0700, Ron Smith wrote:

    Scott, it is "bad form" to post code that you have not tested. I copied
    the above verbatim into an editor and every line in your test data
    causes an "error" message. Moreover, there is nothing in your grammar
    that handles "comments".

    Hmmm. I had tested the code before sending, and it worked fine. I know
    better than to post untested code.
    Well, what I did was simple. I cut and pasted your code into an editor,
    no more, no less.

    I got this result:

    Error: 1 pu 5f
    Error: 1 pu 5tfo
    Error: 1 mu 2n pu 5cni
    Error: 1 pu 2n mu 5cni
    Error: 1mu2npu5cni

    Second, it seems that what you want to parse is inherently ambiguous
    because there is no obvious difference between "n mu" and "nm" when you
    discount white space.

    Right....

    Fundamentally you need to decide if white-space is part of your
    grammar.

    As is evident from my question, it is.
    No, see that is the point, it is not "evident" as there is more than one
    way to do it, and one of those ways may not really require white space.
    notjustawholebunchofstuffglommedtogetherinonestream;guessIwaswrong.
    It is interesting that the above is not ambiguous! While it may be
    difficult to read, it is clearly not ambiguous.

    Starting from left to right, you have:
    "n"
    but this is not a word.
    Next it could be:
    "no"
    which is a word, so we have a "possibility" here. But when you accept
    "no" as a word, the remainder of the sentence starting with "tjust..."
    cannot be completely and totally broken into words. So in the end, a
    production is forced to accept "not" as the first word, simply because
    it is the only way to allow a production to find a second word. And so
    on. Parsing the above sentence does *not* require white space even
    though there are specific instances of ambiguity such as "no" vs. "not".
    Thanks for the crumbs,
    Scott.
    If you want more than crumbs, post code that you can prove to yourself
    can be cut and pasted into an editor such as emacs and run without any
    modification. It is hard enough to reverse engineer someone's intent in
    a piece of code when it works, let alone try to figure it out when it
    doesn't.
  • Scott at Jun 29, 2005 at 5:49 am

    On Tue, Jun 28, 2005 at 09:58:56AM -0700, Ron Smith wrote:
    Well, what I did was simple. I cut and pasted your code into an editor,
    no more, no less.

    I got this result:

    Error: 1 pu 5f
    Error: 1 pu 5tfo
    Error: 1 mu 2n pu 5cni
    Error: 1 pu 2n mu 5cni
    Error: 1mu2npu5cni
    Well, here are my results (where test.pl was the file I cut and pasted
    into the original email):

    [0 ~/string/spl]$ perl ./test.pl
    thumb pick up far little finger string
    thumb pick up top far outer little finger string
    thumb move under near forefinger string, pick up center near inner little finger string
    thumb pick up near middle forefinger string
    thumb move under near forefinger string, pick up center near inner little finger string (Yucch!)
    [0 ~/string/spl]$ perl -v

    This is perl, v5.8.0 built for i386-linux-thread-multi
    [...]

    [0 ~/string/spl]$ perldoc Parse::RecDescent
    [...]
    VERSION
    This document describes version 1.80 of Parse::RecDescent, released
    January 20, 2001.
    [...]

    Are we running wildly disparate versions of these, perhaps?
    Second, it seems that what you want to parse is inherently ambiguous
    because there is no obvious difference between "n mu" and "nm" when you
    discount white space.

    Right....

    Fundamentally you need to decide if white-space is part of your
    grammar.

    As is evident from my question, it is.
    No, see that is the point, it is not "evident" as there is more than one
    way to do it, and one of those ways may not really require white
    space.
    We WANT white space. This is the way we want to do it. How do we do
    it? That was the question.
    notjustawholebunchofstuffglommedtogetherinonestream;guessIwaswrong.
    It is interesting that the above is not ambiguous! While it may be
    difficult to read, it is clearly not ambiguous.
    Hmmm. Is it 'together' or 'to get her'? Who is she? Who's on first?
    Starting from left to right, you have:
    "n"
    but this is not a word.
    Next it could be:
    "no"
    which is a word, so we have a "possibility" here. But when you accept
    "no" as a word, the remainder of the sentence starting with "tjust..."
    cannot be completely and totally broken into words. So in the end, a
    production is forced to accept "not" as the first word, simply because
    it is the only way to allow a production to find a second word. And so
    on. Parsing the above sentence does *not* require white space even
    though there are specific instances of ambiguity such as "no" vs. "not".
    Isthatreallyhowyoureadtext?IfsothenIcanreallysaveawholelotofwearandtearonmythumbsbynotbotheringtoeverpressthespacebaronthiskeyboard!Thankyouverymuchforthishelp,Iwilltreasureitalways.Wasthata'spacebar'ora'spacebaron'?Whocares,asthereisnospace.Wewantspacescanyoutellushoworisitjustnotapossibility?
    Thanks for the crumbs,
    Scott.
    If you want more than crumbs, post code that you can prove to yourself
    can be cut and pasted into an editor such as emacs and run without any
    modification. It is hard enough to reverse engineer someone's intent in
    a piece of code when it works, let alone try to figure it out when it
    doesn't.
    I've proven it to myself. Above run _was_ done in emacs. (Is there any
    other editor?) Sorry it doesn't seem to work out on your setup....

    If anyone on this list can address the question of how best to attack
    input as a series of space-separated tokens
    insteadofasteadystreamofcharacters, please let me know.... Seems to be
    something that should be an easy thing to do, but what do I know? Can
    someone either tell me how to do it or tell me why it can't be done?

    Thanks,
    Scott.
  • Ron Smith at Jun 29, 2005 at 4:01 pm

    Scott wrote:
    On Tue, Jun 28, 2005 at 09:58:56AM -0700, Ron Smith wrote:

    Well, here are my results (where test.pl was the file I cut and pasted
    into the original email):

    [0 ~/string/spl]$ perl ./test.pl
    thumb pick up far little finger string
    thumb pick up top far outer little finger string
    thumb move under near forefinger string, pick up center near inner little finger string
    thumb pick up near middle forefinger string
    thumb move under near forefinger string, pick up center near inner little finger string (Yucch!)
    Oops, my bad. I didn't copy "package SFNParse;". Makes all the
    difference...

    Fundamentally you need to decide if white-space is part of your
    grammar.

    As is evident from my question, it is.
    No, see that is the point, it is not "evident" as there is more than one
    way to do it, and one of those ways may not really require white
    space.

    We WANT white space. This is the way we want to do it. How do we do
    it? That was the question.
    NO, we *don't* want the white space, if we can avoid it.

    Hmmm. Is it 'together' or 'to get her'? Who is she? Who's on first?
    Touché.

    Isthatreallyhowyoureadtext?IfsothenIcanreallysaveawholelotofwearandtearonmythumbsbynotbotheringtoeverpressthespacebaronthiskeyboard!Thankyouverymuchforthishelp,Iwilltreasureitalways.Wasthata'spacebar'ora'spacebaron'?Whocares,asthereisnospace.Wewantspacescanyoutellushoworisitjustnotapossibility?
    Originally, I debated whether or not to respond to this in the above,
    without any white space.
    I've proven it to myself. Above run _was_ done in emacs. (Is there any
    other editor?) Sorry it doesn't seem to work out on your setup....
    No, there is no other editor. At least you belong to the True Religion.
    If anyone on this list can address the question of how best to attack
    input as a series of space-separated tokens
    insteadofasteadystreamofcharacters, please let me know....
    How ironic that I am the only one responding...
    Thanks,
    Scott.
    OK, there is more than one way to do it.

    Way number one:

    lat: ("i" | "o" | /m\b/) {$SFNParse::abbrevs{$item[1]};}
    .....................^.^^^

    forces a "break", usually with white space given your grammar. Doing
    this gives:

    thumb pick up far little finger string
    thumb pick up top far outer little finger string
    thumb move under near forefinger string, pick up center near inner
    little finger string
    thumb pick up near forefinger string, move under center near inner
    little finger string (this is now right - maybe?)
    thumb move under near forefinger string, pick up center near inner
    little finger string (Yucch! But it parses....)


    Which I think is what you want. (You never *did* say what you were
    looking *for*. So I'm guessing here.

    Way number two is:

    lat: ("i" | "o" | "m" ...!rel_move ) {$SFNParse::abbrevs{$item[1]};}

    which is the "lookahead" I mentioned previously.

    Now note that it *still* works,
    andevenworksinyournowhitespacecasethatyousodetest:

    1 pu 5f
    thumb pick up far little finger string

    1 pu 5tfo
    thumb pick up top far outer little finger string

    1 mu 2n pu 5cni
    thumb move under near forefinger string, pick up center near inner
    little finger string

    1 pu 2n mu 5cni # this is now right
    thumb pick up near forefinger string, move under center near inner
    little finger string (this is wrong)

    1pu2nmu5cni # this is the no white space case
    thumb pick up near forefinger string, move under center near inner
    little finger string (this is wrong)

    1mu2npu5cni # Yucch! But it parses....
    thumb move under near forefinger string, pick up center near inner
    little finger string (Yucch! But it parses....)


    Noticethatwhitespacehasnothingtodowithitsavingwearandtearonboththespacebaraswellasyourthumb.
  • Scott at Jun 30, 2005 at 2:33 pm

    On Wed, Jun 29, 2005 at 09:01:19AM -0700, Ron Smith wrote:

    NO, we *don't* want the white space, if we can avoid it.
    Okay, but why? Or would that be an entire treatise?
    Hmmm. Is it 'together' or 'to get her'? Who is she? Who's on first?
    Touché.
    So would a spaceless grammar have to make special provisions for any
    and all foreseeable ambiguities such as this?
    Isthatreallyhowyoureadtext?IfsothenIcanreallysaveawholelotofwearandtearonmythumbsbynotbotheringtoeverpressthespacebaronthiskeyboard!Thankyouverymuchforthishelp,Iwilltreasureitalways.Wasthata'spacebar'ora'spacebaron'?Whocares,asthereisnospace.Wewantspacescanyoutellushoworisitjustnotapossibility?
    Originally, I debated whether or not to respond to this in the above,
    without any white space.
    Glad you changed your mind....

    OK, there is more than one way to do it.

    Way number one:

    lat: ("i" | "o" | /m\b/) {$SFNParse::abbrevs{$item[1]};}
    .....................^.^^^

    forces a "break", usually with white space given your grammar. Doing
    this gives:
    Okay! So any character in our grammar which conceivably could cause
    'overlapping' interpretations can be 'escaped' by enforcing a break.
    thumb pick up far little finger string
    thumb pick up top far outer little finger string
    thumb move under near forefinger string, pick up center near inner
    little finger string
    thumb pick up near forefinger string, move under center near inner
    little finger string (this is now right - maybe?)
    thumb move under near forefinger string, pick up center near inner
    little finger string (Yucch! But it parses....)


    Which I think is what you want. (You never *did* say what you were
    looking *for*. So I'm guessing here.
    That is correct. Here is perhaps a better illustration, using the
    break method:

    1 pu 2nm mu 5cni

    thumb pick up near middle forefinger string, move under center near
    inner little finger string

    Correct.

    1pu2nmmu5cni

    thumb pick up near forefinger string

    And doesn't work because no break.

    Way number two is:

    lat: ("i" | "o" | "m" ...!rel_move ) {$SFNParse::abbrevs{$item[1]};}

    which is the "lookahead" I mentioned previously.
    Whoops! Now for the two previous lines I get:

    thumb pick up near forefinger string

    for both, which is incorrect. Looks like I'll have to adopt method 1.

    Hey, thank you for the help. Sorry we hit it off on the wrong foot
    initially (or wrong finger, I guess... Actually, the grammar used to
    have a 'foot' in it as a bodypart - so you could say 'tr F O'. Except
    it would probably come out 'transfer foots to mouth' due to some
    semi-kludgy plural-handling code I expunged from the sample...).

    Scott

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprecdescent @
categoriesperl
postedJun 26, '05 at 6:31p
activeJun 30, '05 at 2:33p
posts7
users2
websitemetacpan.org...

2 users in discussion

Scott: 4 posts Ron Smith: 3 posts

People

Translate

site design / logo © 2019 Grokbase