There are some bugs in the semantics. I try to fix them here
Consider
* k, the r5rs continuation
* dynamic-wind, r5rs dynamic wind with the addition that continuation
k is an argument
to the rewinder.
Introduce (with-special ((a:id kind:object) ...) code ...) and
(set~ a:id v:obj)
Introduc
Ok, I have felt your punches against the idea and have thought about it
somewhat more.
1. I can only conclude that today it's already difficult to reason about code
with respect to multiple restarts of continuation and the main reason is that
at least I have been sloppy to add a ! to the macros th
Hi guiler, Hi Daniel.
I lost this thread in my mail application, sorry, so I try to continue
this way instead.
* This feature for scheme is mainly for macro writers which knows what
they are doing and which only guard state varibles not seen to the
application programmer. This is how I use
On 23 March 2013 06:33, Stefan Israelsson Tampe wrote:
> (define (f x)
> (let ((s 0))
> (with-special-soft ((s 0))
>(let lp ((i 0))
> (cond
> ((>= i 100) s)
> ((= i 50) (abort-to-prompt 'tag) (lp (+ i 1)))
> (else (set! s (+ s i)) (lp
Hi list, Mark and Noah,
Yesterday I noticed that the sematics for special variables are quite
close to fluids and decied to see if I could model special variables
ontop of that with-fluids semantics. That was pretty easy. The basic
difference between fluid and special variables is that with fluids
Hi,
Stefan and Mark, I think you are talking past each other. Stefan is
offering a very concrete definition of what he wants, and Mark is looking
for a more abstract version. Here is what I think Stefan wants, in the
language of R5RS' storage model:
A variable is simply a name for a particular lo
On Thursday, March 21, 2013 03:03:06 PM Mark H Weaver wrote:
> Stefan, you're still describing your proposal in terms of low-level
> implementation details such as stacks. In the general case, we cannot
> store environment structures on the stack. Furthermore, in the
> general case *all* variable
Stefan, you're still describing your proposal in terms of low-level
implementation details such as stacks. In the general case, we cannot
store environment structures on the stack. Furthermore, in the general
case *all* variables in scheme are bound to locations, not values. Only
in special case
On Thursday, March 21, 2013 11:35:19 AM Noah Lavine wrote:
> (lambda ()
> (let ((x 5))
> (set! x (compute-1 x))
> (set! x (compute-2 x))
> x))
>
> becomes
>
> (lambda ()
> (let ((k1 (lambda (x) (k2 (compute-2 x
> (k2 (lambda (x) x)))
> (k1 (compute-1 x
>
> How
Hello,
I think I understand what Stefan wants here, and I think it should probably
be possible.
If I understand correctly, the issue is that when a continuation is
captured, it stores the *locations* of all of the variables in-scope at
that point. If that continuation is invoked many times, each
Ok, This was a first step to get what I would like to have implemented
in the tree il backend (Not for scheme but perhaps something useful
for e.g. emacs-lisp, python etc).
My main issue with the current setup is that adding undoing and
redoing feature with the help of prompts will fail in 95% of
Hi Stefan,
Stefan Israelsson Tampe writes:
> I wouldl like to start a discussion of introducing a way to mark
> variables as special, and by that mean that set! variables does not
> nessesary get boxed.
I don't think you fully understand the ramifications of what you're
proposing here. In the g
12 matches
Mail list logo
