Gregory Vanuxem <g.vanu...@orange.fr> writes:

| Hello Gaby,
| 
| Le mercredi 17 décembre 2008 à 03:41 -0600, Gabriel Dos Reis a écrit :
| > On Sun, Aug 3, 2
| >   I had a closer look into this and it turns out that, it is not even
| > a parsing bug: It is a preparsing bug!  Well, that may sound a
| > bit pedantic, but it has a practical implication.
| > 
| >   Preparsing is the phase before tokenization and parsing.  The purpose
| > of that phase in the old parser is to munge input text, putting parenthesis
| > around things that are in pile, and separating the items with semi-colons,
| > (You may have noticed the compiler sometimes displays severly
| > molested input text in case it thinks you made a syntax error).
| 
| Yes :-). I find very strange that the original developers of Axiom did
| not know this bug (or did not mention it somewhere), after all the
| construct that triggers this bug is usual. 

My suspicion is that they knew about it, but did not document the bug
because it takes some combination of events to exhibit it and they
carefully write their codes in such way that they don't run into it.
For example, you need to have `else' or `then' by themselves on a
line, and you need `single' expressions in at least one branch.  
If you look at the algebra codes, you'll see you don't get those
combinations :-)  Also, the logic was fixed in the interpreter parser.

For your amusement, you can have a look at the documentation of
ADD-PARENS-AND-SEMIS-TO-LINE (the offender) in preparse.lisp to see
why the logic is bogus (item C.).  You can use the following testcase

    % cat > if.spad
    f x == 
      if a then
         if x then
            y
      else
        if c then d
      e

and issue the following instructions in OpenAxiom

    )boot TRACE ADD_-PARENS_-AND_-SEMIS_-TO_-LINE
    )boot PREPARSE
    parse "if.spad"

to see the bug in the preparsing phase.

| > That phase is improperly putting parenthesis and around things (more
| > precisely, it misses places where it should put parenthesis).
| > I suspect a proper fix for that is to do actual tokenization, but the whole
| > purpose of the preparsing phase is that it is done before tokenization.
| > A proper fix to that problem is probably: Just Throw Away The Old Parser.
| 
| Hmm... Do you plan to do that ? 

I did plan to do that a while ago, but daytime job consistently gets
me focused on other things.  You may realize that the interpreter
parser now parses much more library stuff than before (there remains
one last bug that needs to be fixed).  Some people here are working on
Spad extensions and it is much easier and simpler not to have the
input source mutilated as the old parser does.  So, there is enough
incentive.  It is just a matter of finding time.

| That will probably take a while, won't it?

Yes, it certainly takes some amount of work and I'll use all the help
I can get :-)

-- Gaby

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel

Reply via email to