Fwd: Re: prolog, pure guile scheme

Fwd: Re: prolog, pure guile scheme

[stefan]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: stefan <stefan.tampe@spray.se>: Re: prolog, pure guile scheme --]
[-- Type: message/rfc822, Size: 4653 bytes --]

From: stefan <stefan.tampe@spray.se>
To: Andy Wingo <wingo@pobox.com>
Subject: Re: prolog, pure guile scheme
Date: Sun, 11 Jul 2010 23:37:48 +0200
Message-ID: <201007112337.49007.stefan.tampe@spray.se>

On Thursday 08 July 2010 08:21:30 pm you wrote:
> Hi Stefan,
> 
> On Tue 06 Jul 2010 22:52, stefan <stefan.tampe@spray.se> writes:
> > So here is what I would like to use
> >
> > (match #:tag pr
> >        Z
> >        ((a X)  (begin (do-something X pr)
> >                        (abort-to-prompt pr)))
> >        ((b X)  (b-it X)))
> >
> > And this translate to something like
> >
> > (call-with-prompt
> >    *prompt*
> >    (lambda ()
> >      (let ((pr *prompt*))
> >        (ma-it Z (a X)
> > 	      (begin (do-something X pr) ...)
> > 	      (abort-to-prompt pr))))
> >    (lambda (s) ...))
> >
> > Now this works if we stay in the function, but if do-something contains
> > again a match constructed from the *prompt* prompt, then it get confused
> > so I was thinking like *prompt* beeing like a fluid let but it's not as
> > it seams. At the repo unify-iso I instead construct a fresh new prompt at
> > each match invocation which of cause is very costly but correct. I
> > suspect that there is a quick hack to fix this and therefore I ask if
> > anyone can help?
>
> Let me see if I understand you: you want to be able to do a match, and
> if it fails, abort the match.

yes this is it, but the main thing here is to implement a prolog Cut. 
It's kind a neat to send a rewind object containing register state and 
continuation adress.


 
> If that is the case, you will need N prompts, with N unique prompt
> tags. 

I tried the unique prompt tag lane, it become extremly slow.

> Otherwise you could just use one tag, and pass some auxiliary
> identifier to the abort handlers; but that is silly, unless you need to
> unwind somehow, and in that case you could handle it with dynamic-wind
> anyway.

I need to unwind and everything that a prompt has is needed except the 
"parameter" int the abort code path. Also using prompts gets more expensive on 
the stack then actually needed (there are some of tricks to play here to 
minimize stack consumption) 

I don't see how to use dynamic-wind in this context, maybe I'm just 
ignorant of this tool.

> So why not have the second argument to `do-something' not be a tag, but
> instead a procedure, e.g. (lambda () (abort-to-prompt pr)). You generate
> the prompt tag local to the invocation of `match', and pass the thunk
> encapsulating that tag to nested match helper procedures. If the helper
> fails, it invokes the thunk. Otherwise you could bind the thunk to a
> fluid using with-fluids, as is done by `catch' et al -- but that would
> make it be *the* abort handler for the dynamic extent of that invocation
> to match.

Hmm I though that this could work, but it doesn't. I've tried it :-(. the pr 
object that is made seems to be an object whose purpose is to bring out the 
tag 
identity. Now when reusing the same tag identity in prompt creations further 
down int the call stack wich is what this prolog system is all about. So 
calling an abort for a tag it just unwinds the dynamic dynwinds to the most 
resent prompt with this tag which is not what you would like to have when 
issuing a Cut. You could introduce a Cut tag and a Next tag but this
makes the code very clumsy with nested aborts and results in a mess that I 
don't
want to have.

I did solve the issue by unwinding to an actual prompt identity which just is
the address of the memory location containing the stored state e.g. the prompt 
vector. Now this code look like beeing general, but i'm not sure.

One could of cause just return a fail object and testing that return value and 
from that build the Cut logic. But using prompt looked on the paper to bring 
out some really smart tail call behavior which is already included in the 
faster, ruder and fragile and in some scheme contexts plainly wrong master 
branch in my playgarden repo.

But using prompts I can have two backends. One that plays nice and one that 
drives the guile formula one engine like a madman. A kind of cool approach to 
the 
work flow, so I do want to use prompts in some way.

> That's one way to do it, anyway. Let me know if I'm misunderstanding the
> issue.
> 
> Cheers,
> 
> Andy

Indeed, Cheers.
Stefan