Hello,
This code prints "hi" twice,
(define d (box #f))
(+ (begin (let/cc k (begin (set-box! d k) 3))) (begin (print "hi") 9))
((unbox d) 0)
whereas this prints "hi" once
(define d (box #f))
(begin (begin (let/cc k (begin (set-box! d k) 3))) (print "hi"))
((unbox d) 0)
Why?
Keiko
__
From: Matthew Flatt
> Each form at the top level is wrapped in a prompt, and the content of a
> top-level `begin' is spliced into the top level.
I see. Otherwise it should diverge.
Thanks,
Keiko
_
For list-related administrative tasks:
http://
Actually, I didn't see.
Why this code
(let ([d (box #f)] [a (box 0)])
(print (+ (begin (let/cc k (begin (set-box! d k) (set-box! a 2) 3))) (unbox
a)))
((unbox d) 9))
prints 5, rather than 5999?
Keiko
_
For list-related administ
Hi,
From: Matthew Flatt
> At Mon, 02 Aug 2010 21:54:54 +0900 (JST), Keiko Nakata wrote:
> > Why this code
> >
> > (let ([d (box #f)] [a (box 0)])
> > (print (+ (begin (let/cc k (begin (set-box! d k) (set-box! a 2) 3)))
> > (unbox
> > a)))
> &g
From: Laurent
> Maybe you could use `(let () *body ...*)' instead? It should be closer to
> your intentions.
Can you tweak my code
(let ([d (box #f)] [a (box 0)])
(print (+ (begin (let/cc k (begin (set-box! d k) (set-box! a 2) 3))) (unbox
a)))
((unbox d) 9))
or give me a hint, so that it
From: Sam Tobin-Hochstadt
> On Mon, Aug 2, 2010 at 9:48 AM, Keiko Nakata
> wrote:
> > Or, call/cc does not capture the state?
>
> `call/cc' does not capture the state of the heap (such as the contents
> of boxes).
Thanks! This makes it very clear.
This should als
I may think how call/cc should deal with delay's (call-by-need) is a moot point
(theory vs implementation).
Keiko
From: Matthias Felleisen
Subject: Re: [racket] begin vs +
Date: Mon, 2 Aug 2010 10:00:39 -0400
>
> call/cc captures the environment when it creates a procedural representation
> o
From: "Jos Koot"
> Calling a continuation does not undo side effects.
This seems to be at the base line.
Keiko
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
Hello,
Can I regard this behavior as intended semantics?
(let* ([x0 (delay (control k I))]
[x1 (delay (force x0))])
(reset (force x1)) (force x1) 0)
raises an error 'force: reentrant promise x1'.
I speculate that an operation of 'update x1' is captured therefore discarded.
But how this
>> I speculate that an operation of 'update x1' is captured therefore
>> discarded. But how this is implemented? Do you have a reference
>> implementation or something that I can consult?
>
> Do what Matthias suggested -- but the code in question is pretty
> tricky. You can also browse the srfi
Hi,
In the post-finalization discussion on iterative lazy algorithms (SRFI 45),
(http://srfi.schemers.org/srfi-45/post-mail-archive/msg00024.html)
Andre van Tonder points that Eli's proposal,
which I think is used in Racket roughly, is not memory safe.
But I do not get his point.
(force (letrec
ago, Keiko Nakata wrote:
> > Hi,
> >
> > In the post-finalization discussion on iterative lazy algorithms (SRFI 45),
> > (http://srfi.schemers.org/srfi-45/post-mail-archive/msg00024.html)
> > Andre van Tonder points that Eli's proposal,
> > which I think i
> > It looks clever.
>
> I'm not sure that it's a good term -- you've seen the comment above
> it?
Sure. I read the source, papers by R. Jones and Wadler.
I thought you have measurement.
It's simple and works, which is nice; isn't it?
Keiko
_
Fo
Hi,
> I don't have any concrete measurements. The implementation is as fast
> as I could make it, but it's still pretty slow -- for example, when
> you compare it with a naive implementation.
Naive implementation --- do you mean non-composable promises (i.e. delays)
or graph reductions (or ST
From: Eli Barzilay
> > > Most of the hit is due to doing the right thing wrt exceptions:
> > > when there's an exception when a promise is forced, the exception
> > > is stored as the "value" and will be re-raised when forced again.
> >
> > Yes. I believe this is right thing to do and I think (or
> > I do not think I'll be willing to give up this semantics
> > of memorizing exceptional behavior.
>
> I probably wouldn't mind giving it up, but the problems that it leads
> to tend to be much more significant in the lazy language.
What do you mean by "the problems that it leads
to tend to be
// Maybe I should go off-list if this is only of interest to two of us...
Here is what I've found in OCaml, Scala and F#.
(They are not latest release, though. I used REPL.)
I didn't get what I thought from Scala.
OCaml (3.11.2): Exception memorized, black hole is an exception
# let x = ref 0;;
> Well, think about `delay' as it's used in most Scheme implementations:
> you use it in specific contexts where usually you know in advance that
> you're not worried about exceptions -- if an exception always
> indicates a bug, then it doesn't matter that forcing some promise
> throws an exception
Hello,
How should I understand this behavior?
(with-handlers ([(lambda (_) #t) (lambda (_) (print "exit"))])
(print (+ (prompt (print "hi") (raise 3) (print "bye")) 10)))
prints "hi" then "exit", whereas
(+ (prompt (print "hi") (raise 3) (print "bye")) 10)
prints "hi", then I got an uncaught
ption inside prompt
Date: Wed, 22 Dec 2010 12:15:21 -0500
>
> Replace print with displayln. (You're buffering the output but it isn't
> displayed until the repl prints the next prompt.)
>
>
> On Dec 22, 2010, at 11:56 AM, Keiko Nakata wrote:
>
> > He
From: Robby Findler
Subject: Re: [racket] raise-ing an exception inside prompt
Date: Wed, 22 Dec 2010 11:46:49 -0600
> No, prompt doesn't do that.
>
> This boils down to what the default uncaught-exception-handler does, which is:
>
> (abort-current-continuation (default-continuation-prompt-ta
Hello,
Will someone give me an example which shows the continuation barrier
introduced by 'raise'? I.e., I want an program which raises an exception
because of the barrier.
I think I do not understand the documentation properly,
so have been failing to produce such an example myself...
Keik
Thanks for the code.
I'm a bit confused as replacing 'call-with-exception-handler' by
'with-handlers' seem to not produce the same bahavior:
(call-with-continuation-prompt
(lambda ()
(with-handlers
([(lambda (_) true) (lambda (_)
(call-with-current-continuation
(lambda (k) (abor
Hi again,
I'm not sure where to ask this question, but
why are 'raise' and 'abort' implemented separately
(rather than, say, 'raise' by means of 'abort')?
I haven't understood the implementations of these primitives,
but they appear very different (in error.c and fun.c).
Will someone explain to m
t does the interesting control.
>
> Robby
>
> On Wed, Jan 5, 2011 at 7:58 AM, Keiko Nakata
> wrote:
> > Hi again,
> >
> > I'm not sure where to ask this question, but
> > why are 'raise' and 'abort' implemented separately
> > (
> A `with-handlers' handler and a `call-with-exception-handler' handler
> are invoked with different continuations. A `with-handlers' handler is
> invoked with the continuation of the entire `with-handlers'
> expression; a `call-with-exception-handler' handler is invoked with
> the continuation of
> I don't think you could rebuild the
> missing portion of the continuation by reinstalling it before calling
> the exception handler due to dynamic-wind frames, which could notice
> the exit and re-entry, and continuation barriers, which could prevent
> reinstallation.
Something along this:
(wi
> I'm not completely clear, but I think the only point is that 'raise'
> does not, in general, actually abort. It calls a handler that makes
> the decision to abort or not. When aborting actually happens, however,
> abort is what does the aborting.
Hmm. If I understand, you are saying that 'raise'
From: Casey Klein
> Now I'm not sure I understand what you're trying to do.
I think I am getting confused by my own questions
and the wealth of the information I am getting from the list.
Anyway, I thank you for the feedbacks.
Keiko
_
For list
On Thu, Jan 6, 2011 at 3:20 PM, Casey Klein
wrote:
> > Still I am not certain that this behavior of 'raise' cannot be implemented
> > by other (delimited) control operators. And, probably I do not still
> > understand why 'raise' has to be a primitive.
>
> It can be implemented in terms of conti
On Thu, Jan 6, 2011 at 3:29 PM, Robby Findler
wrote:
> If you wanted to try, I'd suggest adapting the redex model and then
> using random testing to try to find the difference.
'By adapting the redex model' means to implement
those operators discussed above in the redex?
Then I first need
So, I fall back into the same question of why 'raise' has to be a primitive,
given
> >> It can be implemented in terms of continuation marks (if you know the
> >> key for exception handlers).
But,
On Thu, Jan 6, 2011 at 3:29 PM, Robby Findler
wrote:
> Probably you can get very close if not
ETAPS 2003: http://www.mimuw.edu.pl/etaps03/
-- IMPORTANT DATES --
Satellite event proposals deadline: 6 March 2011.
Notification of acceptance: 13 March 2011.
-- FURTHER INFORMATION AND ENQUIRIES --
Please contact Keiko Nakata or Tarmo Uustalu, etaps12-w...
Committee
-
Luca Aceto (Reykjavik, IS)
Simon Bliudze (CEA LIST, FR)
Filippo Bonchi (ENS Lyon & CNRS, FR)
Fabio Gadducci (Pisa, IT)
Matthew Hennessy (Dublin, IE)
Bartek Klin (Warsaw, PL)
Keiko Nakata (Talinn, EE)
Michel Reniers (Eindhoven, NL, co-chair)
Pawel Sobocinski (Southampton, UK, co-cha
NRS, FR)
Fabio Gadducci (Pisa, IT)
Matthew Hennessy (Dublin, IE)
Bartek Klin (Warsaw, PL)
Keiko Nakata (Talinn, EE)
Michel Reniers (Eindhoven, NL, co-chair)
Pawel Sobocinski (Southampton, UK, co-chair)
Sam Staton (Cambridge, UK)
Daniele Varacca (Paris 7, FR)
Important Dates
---
Submissi
Sciences, Russia)
Michael Leuschel (University of Dusseldorf, Germany)
Sam Lindley (University of Edinburgh, UK)
Michal Moskal (Microsoft Research, USA)
Keiko Nakata (Tallinn University of Technology, Estonia)
Jeremy Siek (Indiana University, USA)
Peter Thiemann (University o
36 matches
Mail list logo
