Hi Alex,

I keep going back and forth on that, trying to think of a terse syntax that 
will accommodate all the cases :-/

It may be that just handling the dcg cases which have no arguments well, would 
be a good compromise.

I found out that you can read prolog dcg clauses into swi-prolog and then a 
listing will show the non-dcg prolog, which can be a help for gnarly dcg with 
args.  (Fortunately swi doesn't turn it back to dcg notation for listing!)

Here's my current pilog/dcg project:

using http://victoriafamilyrobotics.net/vfr1/media/dcg.l and 

which is this: 


translated into pilog.  

 ./pil sec7_3.l -t_2

?? Please put a on b.
@X=(please put a on b ".")
@F=((on a b))




--- On Thu, 7/21/11, Alexander Burger <a...@software-lab.de> wrote:

> From: Alexander Burger <a...@software-lab.de>
> Subject: Re: pilog dcg with args
> To: picolisp@software-lab.de
> Date: Thursday, July 21, 2011, 11:33 PM
> On Fri, Jul 22, 2011 at 08:19:47AM
> +0200, Alexander Burger wrote:
> > 2. We rewrite 'dcg' to inspect each term. As long as
> each element is
> >    atomic (as in [A]), it behaves as it does
> now. If there are lists (as
> >    in [B]), then it appends its
> self-generated arguments.
> Hmm, now that I looked at 'dcg', I see that then we have a
> problem with
> other parts of the syntax. For example, in
>    (dcg noun [cat])
> the current 'dcg' interprets 'cat' as a terminal fact,
> because it is in
> a list (the brackets are just syntactic sugar, being
> super-parentheses
> in PicoLisp). We'd need another syntax convention for facts
> then.
> Cheers,
> - Alex
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to