[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: prolog, pure guile scheme

From: Andy Wingo
Subject: Re: prolog, pure guile scheme
Date: Thu, 08 Jul 2010 19:21:30 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Hi Stefan,

On Tue 06 Jul 2010 22:52, stefan <address@hidden> 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.

If that is the case, you will need N prompts, with N unique prompt
tags. 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

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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]