Experience with SmaCC C parser?

Hello all,

Is the C parser packaged with SmaCC "real"?  I have a big pile of
documentation and/or header files to be converted into working software,
and have a reuse/roll-own decision to make.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:
> Hello all,
>
> Is the C parser packaged with SmaCC "real"?  I have a big pile of
> documentation and/or header files to be converted into working software,
> and have a reuse/roll-own decision to make.

The one with SmaCC doesn't have a preprocessor so it doesn't do "real"
programs. However, Alejandra Garrido has been working on CRefactory
(https://netfiles.uiuc.edu/garrido/www/CRefactory.html). It does
refactorings with preprocessor directives. I used it last year for a
project. It is written for VW, but it only took a few hours to convert
to Dolphin.


John Brant

John,

> The one with SmaCC doesn't have a preprocessor so it doesn't do "real"
> programs.

I suspected as much.  Preprocessing might be negotiable for much of what
I have in mind.  Another option might be to get a compiler to do the
preprocessing and leave behind the result?? I vaguely recall reading
about that trick in my Borland days.  Google seems to reinforce it: gcc
-E might do it.  It sounds like it would produce a .c file with all of
the header files "in-line" and directives/macros expanded.

Given that, would SmaCC be up to it, or would it be likely to fall
short?  We're not bashing SmaCC or its authors.  I simply have a weird
problem and want to consider the off the shelf stuff before I start
(well, continue<g>) hacking.  In truth, I didn't think of SmaCC when I
started on my oversimplified parser.


 > However, Alejandra Garrido has been working on CRefactory
> (https://netfiles.uiuc.edu/garrido/www/CRefactory.html). It does
> refactorings with preprocessor directives. I used it last year for a
> project. It is written for VW, but it only took a few hours to convert
> to Dolphin.

Thanks for the link!  I completely understand what Ralph is trying to do
(build useful stuff, find good projects for students, etc.), but can't
resist mentioning that it is a little ironic to spend all that
Smalltalking time on making a tool to speed up C programming.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:

I don't know your problem, but I think it should work. Of course, I'm
bias since I'm one of the authors. Ale's CRefactory work uses SmaCC for
her parser. Also, I've used it to make some custom Delphi refactorings.
For the Delphi work, I was using a not yet released version that
automatically generated parse trees, visitors, and added methods for
transforming code.


John Brant

"John Brant" <[hidden email]> wrote in message
news:[hidden email]...

> For the Delphi work, I was using a not yet released version that

you understand that we will now start bombing you with those pesky questions
like when, what's new, and similar?  ;)

Any chance that flex like feature where scanner can be in number of modes,
and depending on the mode scanner applies different set of rulese, will be
included?

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/

John,

I got the parser installed and running, and was working toward
understanding what it is doing.  Along the way, I found that the debug
it command is getting into trouble, with an almost recursive walkback
situation resulting from it.  Could the Smalltalk parser have been
adversely affected?  For now, I'm going to assume so and retreat to a
backup.

Have a good one,

Bill



2:55:09 PM, Thursday, June 16, 2005: 'Error: no period at end of statement'
SmalltalkParser>>parserError:range:
SmalltalkParser>>parseStatementList:into:
SmalltalkParser>>parseStatements:
SmalltalkParser>>parseExpression:
SmalltalkParser class>>parseExpression:in:onError:
SmalltalkParser class>>parseExpression:in:
Debugger>>buildParseTree
Debugger>>parseTree
Debugger>>selectedNode
Debugger>>queryCodeRefactoring:selector:
Debugger>>queryRefactoringCommand:
Debugger(SmalltalkToolShell)>>queryCommand:
Debugger>>queryCommand:
DelegatingCommandPolicy(CommandPolicy)>>queryCommand:ofTarget:
[] in DelegatingCommandPolicy(CommandPolicy)>>queryCommand:
OrderedCollection>>do:
DelegatingCommandPolicy(CommandPolicy)>>queryCommand:
DelegatingCommandPolicy(CommandPolicy)>>query:
Menu>>queryAlong:
[] in MenuBar(Menu)>>queryAllAlong:
Array(SequenceableCollection)>>uncheckedFrom:to:keysAndValuesDo:
Array(SequenceableCollection)>>from:to:keysAndValuesDo:
Array(SequenceableCollection)>>from:keysAndValuesDo:
Array(SequenceableCollection)>>keysAndValuesDo:
MenuBar(Menu)>>queryAllAlong:
MenuBar(Menu)>>queryAllFromView:
ShellView>>wmInitMenu:wParam:lParam:
ShellView(View)>>dispatchMessage:wParam:lParam:
[] in InputState>>wndProc:message:wParam:lParam:cookie:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>callback:evaluate:
InputState>>wndProc:message:wParam:lParam:cookie:
ShellView(View)>>defaultWindowProcessing:wParam:lParam:
ShellView(View)>>dispatchMessage:wParam:lParam:
[] in InputState>>wndProc:message:wParam:lParam:cookie:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>callback:evaluate:
InputState>>wndProc:message:wParam:lParam:cookie:
ShellView(View)>>defaultWindowProcessing:wParam:lParam:
ShellView(View)>>dispatchMessage:wParam:lParam:
[] in InputState>>wndProc:message:wParam:lParam:cookie:
BlockClosure>>ifCurtailed:



--
Wilhelm K. Schwab, Ph.D.
[hidden email]

John,

> I don't know your problem, but I think it should work. Of course, I'm
> bias since I'm one of the authors. Ale's CRefactory work uses SmaCC for
> her parser. Also, I've used it to make some custom Delphi refactorings.
> For the Delphi work, I was using a not yet released version that
> automatically generated parse trees, visitors, and added methods for
> transforming code.

One of the tasks will involve parsing quite a few structures with fields
defined in terms of fixed-size types.  Toward that end, is it reasonable
to expect this to parse:

    CParser parse:'typedef unsigned char byte; byte x=1;'.

AFAICT, typedefs are not handled by the preprocessor, though some
sources suggest that is the case.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

rush wrote:

> Any chance that flex like feature where scanner can be in number of modes,
> and depending on the mode scanner applies different set of rulese, will be
> included?

The current version has some support. It's not documented, but you can
see a couple test cases for it (search for methods matching test*State*).


John Brant

Bill Schwab wrote:

> I got the parser installed and running, and was working toward
> understanding what it is doing.  Along the way, I found that the debug
> it command is getting into trouble, with an almost recursive walkback
> situation resulting from it.  Could the Smalltalk parser have been
> adversely affected?  For now, I'm going to assume so and retreat to a
> backup.

It doesn't change any base classes so I don't know why you would have
problems with the Smalltalk parser. What method was it trying to parse?


John Brant

Bill Schwab wrote:

> One of the tasks will involve parsing quite a few structures with fields
> defined in terms of fixed-size types.  Toward that end, is it reasonable
> to expect this to parse:
>
>    CParser parse:'typedef unsigned char byte; byte x=1;'.
>
> AFAICT, typedefs are not handled by the preprocessor, though some
> sources suggest that is the case.

I believe the problem is that the parser isn't telling the scanner that
"byte" is a type name after it parses the typedef. Since type names and
identifiers overlap, the parser needs to tell the scanner what are valid
type names. Try pulling out the second line of the declaration
production, and then writing a reduce rule for it:
------------------
declaration
        : declaration_specifiers ";"
        | init_declaration ";"
        ;
init_declaration
        : declaration_specifiers init_declarator_list
                {'1' first value = 'typedef'
                        ifTrue:
                                [1 to: '2' size by: 2 do: [:i | self addTypeName: ('2' at: i) value]].
                self reduceFor: nodes}
        ;
------------------


John Brant

John,

> It doesn't change any base classes so I don't know why you would have
> problems with the Smalltalk parser. What method was it trying to parse?

I think it's a false alarm.  It looks like a case of Dolphin's compiler
being more forgiving than the parser.  This is pretty close (only the
names have been changed to protect the intelligent<g>):

        SmalltalkParser parseExpression:'Association new
                targetClass:AdvApiLibrary;
                text:self createProcessAsUser;
                generate codeGenerator showResults.'.

To blow up the debugger (I suggest not doing this in an image you care
about), select

        Association new
                targetClass:AdvApiLibrary;
                text:self createProcessAsUser;
                generate codeGenerator showResults.

and choose debug-it.

The fact that the first expression above results in a walkback makes me
far less nervous than I was when I first realized that the debug-it
problem occured after restoring a recent backup.

It looks as though my finding this when I did was purely coincidental,
and that SmaCC is innocent.  Anyone disagree?

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

John,

I _think_ I accomplished that, and got it to compile the revised parser.
  Here are the resulting messages:

-------------------------
Shift/Reduce Conflict

[selection_statement : "if" "(" expression ")" statement .  "else"
statement;<CONSTANT> "else" "return" "goto" "++" "switch" "("
<STRING_LITERAL> ";" <LEFT_BRACE> "case" "!" "*" "if" "+" "while" "-"
"break" "&" "for" "continue" "do" "default" <IDENTIFIER> <RIGHT_BRACE>
"~" "sizeof" "--"] *****
[selection_statement : "if" "(" expression ")" statement . ;<CONSTANT>
"else" "return" "goto" "++" "switch" "(" <STRING_LITERAL> ";"
<LEFT_BRACE> "case" "!" "*" "if" "+" "while" "-" "break" "&" "for"
"continue" "do" "default" <IDENTIFIER> <RIGHT_BRACE> "~" "sizeof" "--"]

Unless you reply before I get time, I will repeat the compilation in an
image w/o the patch to see if this is new.

The next step is to handle structs.  This works:

CParser parse:'typedef struct {int x; int y;} point; struct pointPlus {
point p; int z; };'.


This does not:
CParser parse:'struct point {int x; int y;}; struct pointPlus { struct
point p; int z; };'.

I _think_ the syntax is valid in both cases, but need to verify it.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:

This is OK. It is complaining that the grammar is ambiguous when you are
parsing nested if/else statements. In this case it is picking the first
production (the shift action) which keeps the else clause with the
innermost if.


John Brant