Dburg and swi-prolog

[Alex McDonald]

Anton: I stumbled on dburg while researching how to modify lcc's md
files to generate rules, and discovering that running against a DAG
rather than a tree isn't quite as straightforward as I'd thought. With
dburg downloaded, I tried running the Prolog provided on swi-prolog
since the recommended Sicstus Prolog costs serious money. swi-prolog
generates an error for nth/3 in dburg.pl, which is correctable by
adding

nth(N, List, Element):-
N1 is N - 1,
length(Head, N1),
append(Head, [Element|_Rest], List).

prior to its use in op_arg_nt (or by using nth1 which I believe to be
equivalent). Presuming that this is correct -- and I'm not sure -- I
now get error messages on the rules. For instance, running against
proebstring.dburg generates

1 ?-
% library(assoc) compiled into assoc 0.00 sec, 19,640 bytes
% library(oset) compiled into oset 0.02 sec, 9,896 bytes
% library(ordsets) compiled into ordsets 0.02 sec, 21,588 bytes
*************


Error: no optimal rule for addr. Rulesets: [[addr->reg:0],[addr-
>tadd[reg,reg]:1]]
State:
state(ERROR: c:/w32f/dburg/dburg.pl:548:
</2: Arithmetic: `addr/0' is not a function
Warning: c:/w32f/dburg/dburg.pl:548:
Goal (directive) failed: user: (main,halt)
% dburg.pl compiled 0.03 sec, 74,600 bytes
% c:/w32f/dburg/proebsting.dburg compiled 0.03 sec, 76,344 bytes

The same error as reported for addr/0 is reported against mem/0 and so
on in the other dburg files as part of the rules() set. I have a
feeling it's a parse problem. Any clues?

http://www.complang.tuwien.ac.at/papers/ertl99.ps.gz
http://www.complang.tuwien.ac.at/anton/dburg/
http://www.swi-prolog.org/

[Anton Ertl]

Alex McDonald <bl...@rivadpm.com> writes:
>Anton: I stumbled on dburg while researching how to modify lcc's md
>files to generate rules, and discovering that running against a DAG
>rather than a tree isn't quite as straightforward as I'd thought. With
>dburg downloaded, I tried running the Prolog provided on swi-prolog
>since the recommended Sicstus Prolog costs serious money.

Even if you had Sicstus, I would not recommend using dburg. It's only
a grammar checker, so it does not generate a DAG parser, and it's only
proof-of-concept quality.

If you use some burg/iburg input, extending that to DAGs is relatively
easy:

1) Let the labeler visit every node once, in any topologically sorted
order (e.g., use the ordinary depth-first labeler, but with a
"visited" flag).

2) The reducer visits some node/nt combination, and marks that it was
there; if it visits such a combination and it is already marked, it
does not mark it again. The actions have to be designed appropriately
for this strategy.

For lcc's lburg and its md files, things are more complicated, because
it is a more complicated tool with extra functionality and that is
used in various funny ways in the .md files.

>Error: no optimal rule for addr. Rulesets: [[addr->reg:0],[addr-
>>tadd[reg,reg]:1]]
>State:
>state(ERROR: c:/w32f/dburg/dburg.pl:548:
> </2: Arithmetic: `addr/0' is not a function

Looks to me like some extra functionality of SWI is trying to evaluate
"addr->reg:0" as arithmetic expression instead of as uninterpreted
term.

>The same error as reported for addr/0 is reported against mem/0 and so
>on in the other dburg files as part of the rules() set. I have a
>feeling it's a parse problem. Any clues?

Yes, might also be something like that. No clues, I never worked with
SWI, and my last serious use of Sicstus was in the last millenium:-).

- 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 2011: http://www.euroforth.org/ef11/

[Alex McDonald]

On Jan 31, 3:09 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

> Alex McDonald <b...@rivadpm.com> writes:
> >Anton: I stumbled on dburg while researching how to modify lcc's md
> >files to generate rules, and discovering that running against a DAG
> >rather than a tree isn't quite as straightforward as I'd thought. With
> >dburg downloaded, I tried running the Prolog provided on swi-prolog
> >since the recommended Sicstus Prolog costs serious money.
>
> Even if you had Sicstus, I would not recommend using dburg.  It's only
> a grammar checker, so it does not generate a DAG parser, and it's only
> proof-of-concept quality.

Grammar checking seemed like a good goal, since I'm having to write
(or at least heavily modify) an existing grammar.

>
> If you use some burg/iburg input, extending that to DAGs is relatively
> easy:
>
> 1) Let the labeler visit every node once, in any topologically sorted
> order (e.g., use the ordinary depth-first labeler, but with a
> "visited" flag).
>
> 2) The reducer visits some node/nt combination, and marks that it was
> there; if it visits such a combination and it is already marked, it
> does not mark it again.  The actions have to be designed appropriately
> for this strategy.

Thanks. The paper you wrote covers that nicely.

>
> For lcc's lburg and its md files, things are more complicated, because
> it is a more complicated tool with extra functionality and that is
> used in various funny ways in the .md files.

Yes. Quite a chunk of the preparation for generation seems to take
place "out of sight" of the burg in lcc's pre-processing stages.

>
> >Error: no optimal rule for addr. Rulesets: [[addr->reg:0],[addr-
> >>tadd[reg,reg]:1]]
> >State:
> >state(ERROR: c:/w32f/dburg/dburg.pl:548:
> >        </2: Arithmetic: `addr/0' is not a function
>
> Looks to me like some extra functionality of SWI is trying to evaluate
> "addr->reg:0" as arithmetic expression instead of as uninterpreted
> term.
>
> >The same error as reported for addr/0 is reported against mem/0 and so
> >on in the other dburg files as part of the rules() set. I have a
> >feeling it's a parse problem. Any clues?
>
> Yes, might also be something like that.  No clues, I never worked with
> SWI, and my last serious use of Sicstus was in the last millenium:-).

You'll be claiming you're as old as me next... I'll see if I can get
it running in a reasonably short debug session. If not, I'll leave it
alone.

[Anton Ertl]

Alex McDonald <bl...@rivadpm.com> writes:
>On Jan 31, 3:09=A0pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)

>wrote:
>> Alex McDonald <b...@rivadpm.com> writes:
>> >Anton: I stumbled on dburg while researching how to modify lcc's md
>> >files to generate rules, and discovering that running against a DAG
>> >rather than a tree isn't quite as straightforward as I'd thought. With
>> >dburg downloaded, I tried running the Prolog provided on swi-prolog
>> >since the recommended Sicstus Prolog costs serious money.
>>

>> Even if you had Sicstus, I would not recommend using dburg. =A0It's only

>> a grammar checker, so it does not generate a DAG parser, and it's only
>> proof-of-concept quality.
>
>Grammar checking seemed like a good goal, since I'm having to write
>(or at least heavily modify) an existing grammar.

I actually don't see it as very valuable in practice. If parsing DAGs
leads to suboptimal code in a few cases, the checker would say that
the grammar is not usable for optimal DAG parsing. But the grammar
may still be better than the usual alternatives, like splitting the
DAGs into trees.

You can just use an unchecked grammar, and if you find out that there
is too much duplicated effort in the resulting code, tweak the
grammar to reduce that.