[racket-users] Ubuntu PPA also updated to v8.2

[Asumu Takikawa]

On 2021-07-18 18:55:35 +, 'John Clements' via Racket Users wrote:
> Racket version 8.2 is now available from

The Ubuntu PPA is also now updated to v8.2 on all supported releases (groovy no
longer supported):

  https://launchpad.net/~plt/+archive/ubuntu/racket

As usual please report bugs here:

  https://github.com/takikawa/racket-ppa

Cheers,
Asumu

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20210730055304.ejfhyn2zi3bozu26%40pazu.

[racket-users] Re: Re-entrant parameterize modification isolation when using shift/reset

[Greg Rosenblatt]

Thanks for the response, Jack.

I'm looking at: https://docs.racket-lang.org/reference/contmarks.html

I don't see a way to update the value of an existing key without installing 
a new mark.  Is it possible to do that?  Parameters allow you to update the 
value associated with the innermost use of `parameterize` without 
re-parameterizing.  These updates are what I'd like to isolate between 
resumes.

The idea in the example is that `(shift k k)` "throws" the continuation at 
that point up to the enclosing `reset`.  So `K` ends up bound to a 
procedure of one (unused) argument that continues where the `(shift k k)` 
left off, inside the body of the `parameterize`.  You can use continuations 
like these to implement a form of cooperative thread or coroutine, which 
can even be resumed from the same point multiple times.  However in cases 
where you're also using `parameterize`, unlike spawning a real Racket 
thread, it looks like we don't get the benefit of local parameter updates 
being isolated across multiple resumes, so each one sees any further 
updates made by other resumes, like they are sharing mutable state.  I was 
hoping to see each resume begin in the same dynamically-scoped state, 
oblivious to dynamically-scoped updates made by other resumes.

Aside from the thread-wrapping hack, I'm not sure I see a good way to 
recover isolation behavior from non-isolation-by-default (though the 
reverse doesn't seem to be a problem: if we started with 
isolation-by-default, we could recover non-isolation by installing a 
mutable box as the parameter).  An alternative is to abandon parameters 
completely and replace them with algebraic state effects (also using 
delimited continuations), but it seems like a shame to have to do that when 
parameters are already so close to the right thing.
On Thursday, July 29, 2021 at 10:25:54 PM UTC-4 jackh...@gmail.com wrote:

> I don't fully follow the example you gave because I'm not super familiar 
> with shift/reset, but would using continuation marks directly instead of 
> parameters work for your use case? Continuation marks work like what you 
> described, where data is stored directly on the stack rather than in a 
> thread cell pointed to by the stack.
>
> On Sunday, July 25, 2021 at 10:35:00 AM UTC-7 greg@gmail.com wrote:
>
>> I'm using dynamic binding while also using delimited control operators 
>> such as shift and reset.  When shift captures the context of a 
>> `parameterize`, I'd like to be able to resume that continuation in the same 
>> context multiple times without observing modifications caused by other 
>> resumptions.
>>
>> I was surprised that subsequent re-entries can observe modifications from 
>> the earlier ones, since my mental model of dynamic parameters was that 
>> their values were retrieved from a fresh dynamic calling context, whose 
>> frames are copied each time the delimited continuation is invoked.  But it 
>> looks like dynamic parameters actually rely on a shared mutable cell, in 
>> this case a thread cell.
>>
>> Knowing this, I have a strange workaround using a wrapping thread to 
>> force a distinct thread cell to be created for each resumption, providing 
>> isolation.  Is there a better way to do this?
>>
>> I'm also interested in the reasons behind the current design.  Is there a 
>> downside to storing parameter bindings directly on the stack, rather than 
>> in a thread cell pointed to by the stack?
>>
>>
>> Here is an example, including a demonstration of the workaround:
>>
>> ```
>> #lang racket/base
>> (require racket/control)
>>
>> (define P (make-parameter #f))
>> (define (show) (displayln (P)))
>> (define (inc) (P (+ 1 (P
>>
>> (define (re-enter k)
>>   (define result (void))
>>   (define t (thread
>>   (lambda ()
>> (set! result (k (void))
>>   (thread-wait t)
>>   result)
>>
>>
>> (define K (reset (parameterize ((P 0))
>>(show)
>>(inc)
>>(shift k k)
>>(show)
>>(inc)
>>(P
>>
>> ;; The behavior that surprised me:
>> (displayln "without threads:")
>> (K) ; 2
>> (K) ; 3
>> (K) ; 4
>>
>> ;; The behavior I would like:
>> (displayln "with threads:")
>> (re-enter K) ; 5
>> (re-enter K) ; 5
>> (re-enter K) ; 5
>> ```
>>
>>
>> Program output:
>>
>> 0
>> without threads:
>> 1
>> 2
>> 2
>> 3
>> 3
>> 4
>> with threads:
>> 4
>> 5
>> 4
>> 5
>> 4
>> 5
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/0439bf01-baac-462c-ac61-4a218a9efebcn%40googlegroups.com.

[racket-users] Re: Re-entrant parameterize modification isolation when using shift/reset

[jackh...@gmail.com]

I don't fully follow the example you gave because I'm not super familiar 
with shift/reset, but would using continuation marks directly instead of 
parameters work for your use case? Continuation marks work like what you 
described, where data is stored directly on the stack rather than in a 
thread cell pointed to by the stack.

On Sunday, July 25, 2021 at 10:35:00 AM UTC-7 greg@gmail.com wrote:

> I'm using dynamic binding while also using delimited control operators 
> such as shift and reset.  When shift captures the context of a 
> `parameterize`, I'd like to be able to resume that continuation in the same 
> context multiple times without observing modifications caused by other 
> resumptions.
>
> I was surprised that subsequent re-entries can observe modifications from 
> the earlier ones, since my mental model of dynamic parameters was that 
> their values were retrieved from a fresh dynamic calling context, whose 
> frames are copied each time the delimited continuation is invoked.  But it 
> looks like dynamic parameters actually rely on a shared mutable cell, in 
> this case a thread cell.
>
> Knowing this, I have a strange workaround using a wrapping thread to force 
> a distinct thread cell to be created for each resumption, providing 
> isolation.  Is there a better way to do this?
>
> I'm also interested in the reasons behind the current design.  Is there a 
> downside to storing parameter bindings directly on the stack, rather than 
> in a thread cell pointed to by the stack?
>
>
> Here is an example, including a demonstration of the workaround:
>
> ```
> #lang racket/base
> (require racket/control)
>
> (define P (make-parameter #f))
> (define (show) (displayln (P)))
> (define (inc) (P (+ 1 (P
>
> (define (re-enter k)
>   (define result (void))
>   (define t (thread
>   (lambda ()
> (set! result (k (void))
>   (thread-wait t)
>   result)
>
>
> (define K (reset (parameterize ((P 0))
>(show)
>(inc)
>(shift k k)
>(show)
>(inc)
>(P
>
> ;; The behavior that surprised me:
> (displayln "without threads:")
> (K) ; 2
> (K) ; 3
> (K) ; 4
>
> ;; The behavior I would like:
> (displayln "with threads:")
> (re-enter K) ; 5
> (re-enter K) ; 5
> (re-enter K) ; 5
> ```
>
>
> Program output:
>
> 0
> without threads:
> 1
> 2
> 2
> 3
> 3
> 4
> with threads:
> 4
> 5
> 4
> 5
> 4
> 5
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/b0d6f680-7c69-4b41-b21e-8744ee997e78n%40googlegroups.com.

Re: [racket-users] Re: The history of hygiene for definition contexts

[Alexis King]

On Thu, Jul 29, 2021 at 12:53 PM Michael Ballantyne <
michael.ballant...@gmail.com> wrote:

> The second example you give becomes more natural if you've considered
> simpler cases of macros in definition contexts first
>

I agree that breaking the macro into two parts—one of which inserts a
binder and one of which inserts a reference—is the most compelling way to
intuitively explain the behavior of the second expression. (And Shu-Hung
previously posted the same observation
 on Twitter.)
Still, it is interesting how many people find the result deeply
unintuitive.

To understand why, it seems helpful to start from Clinger and Rees’ *strong
hygiene condition*, which provides a high-level definition of what hygiene
is supposed to mean:


>1.
>
>It is impossible to write a high-level macro that inserts a binding
>that can capture references other than those inserted by the macro.
>2.
>
>It is impossible to write a high-level macro that inserts a reference
>that can be captured by bindings other than those inserted by the macro.
>
> The precise meaning of these criteria is not completely obvious, because
the intended interpretation of the phrase “inserted by the macro” is not
perfectly clear. However, the intended interpretation seems to be that a
“macro-inserted” reference or binding is one for which the reference or
binding identifier itself does not come from the macro’s inputs.

This naturally justifies the interpretation of the first expression, since
by the above definition, the reference to x is macro-inserted, but the
binder for x is not. This lines up with the results of the survey:
programmers generally agree that the result of the first example ought to
be 'outer.

The second example is trickier, as at first blush it clearly violates the
second criterion of the hygiene condition: the macro-inserted reference to x
is captured by the non-macro-inserted binder. However, I don’t think the
applying the condition is quite so straightforward when recursive
definition contexts are involved.

My reasoning starts with contemplating the meaning of a macro like

(define-syntax-rule (define-false x)
  (define x #f))

in isolation. What makes macros like this unusual is that they introduce
what one might call *free binders* by analogy to the notion of a free
reference. The first criterion of the strong hygiene condition clearly
always applies to macro-inserted *bound binders*, but it doesn’t always
seem apply to free ones. Why?

Intuitively, this is because the scope of a bound binder fundamentally
never contains the macro definition, which is the lexical location of any
macro-inserted reference. This invariant is broken by definition contexts,
where a free binder can eventually become bound in a scope that *does*
contain the macro definition. It is precisely this ability for a macro’s
use site to “retroactively” affect its definition’s scope that allows the
macro-inserted reference to be captured.

In other words, I don’t think this is actually a violation of the hygiene
condition because the macro-inserted reference is not actually “captured.”
Rather, the nature of recursive definition contexts necessarily allows
future definitions to affect earlier ones, and in this case, the future
definition of x is in scope at the macro’s *definition site*, which means
it must be in scope in the context of the macro-inserted x.

I think what’s so intuitively surprising about this essentially stems from
two things:

   1.

   After expansion, the macro-inserted reference to x appears *after* the
   internal definition, which means the binding structure of the expanded
   expression does not need to be recursive. A completely sequential structure
   would suffice, a la let*.
   2.

   If definition contexts were in fact sequential, not recursive, the
   result of the second expression would in fact be 'outer. This is because
   the internal definition of x would not be in scope at the macro’s
   definition, so the macro-inserted x should not be able to see it.

It is this bait-and-switch that seems to trip people up. The fact that the
macro-inserted reference appears after the internal definition in the
expansion makes it seem as though the macro-inserted reference is being
captured, but in fact it is not the structure of the expansion that
matters, but rather the structure of the original program. Indeed, there is
nothing special, magical, or broken about define itself, which introducing
a scope between macro definition and macro use site cleanly illustrates:

> (let ([x 'outer])
(define-syntax-rule (m a)
  (begin
(define a 'inner)
x))
(let ()
  (m x)))
'outer

Anyway, this email has ended up rather long, so perhaps it would be better
moved to a small blog post. But an explicit statement of the above
reasoning is precisely the sort of thing I have been looking for but have

[racket-users] Re: The history of hygiene for definition contexts

[Michael Ballantyne]

Section 4.5 of Abdulaziz Ghuloum's PhD thesis is the earliest description 
I've seen of an algorithm: 
https://www.proquest.com/openview/f6a12fd14db7fd3ea85cfebbf72e0bc5

It also does not provide much justification.

The second example you give becomes more natural if you've considered 
simpler cases of macros in definition contexts first:

1. Macro-generated references may refer to locally defined names

(let ([x 'outer])
  (define x 'inner)
  (define-syntax-rule (m)
x)
  (m))

2. Macros may abstract over define

(let ([x 'outer])
  (define-syntax-rule (m a)
(define a 'inner))
  (m x)
  x)

3. Definitions splice out of begin, in order to allow macros to generate 
multiple definitions

(let ([x 'outer] [y 'outer])
  (define-syntax-rule (define2 a b)
(begin
  (define a 'inner)
  (define b 'inner))
  (m x y)
  (list x y))

>From there, your second example is a macro simultaneously abstracting over 
a definition and referring to a locally defined name.
On Wednesday, July 28, 2021 at 1:31:25 AM UTC-6 lexi@gmail.com wrote:

> Hi all,
>
> I recently posted two tricky hygiene puzzles on Twitter 
> , reproduced 
> below for completeness:
>
> (let ([x 'outer])
>   (define-syntax-rule (m a)
> (let ([a 'inner]) x))
>   (m x))
>
> (let ([x 'outer])
>   (define-syntax-rule (m a)
> (begin
>   (define a 'inner)
>   x))
>   (m x))
>
> The puzzle is to guess what these expressions evaluate to. I have 
> discovered that people find the “correct” answer *remarkably* 
> unintuitive—at the time of this writing, it is the single least popular 
> choice in the poll!
>
> Despite this confusion, the Scheme implementations I’ve tried are 
> unwaveringly consistent in their interpretation of these expressions: 
> Racket, Chez, and Guile all agree on what the answers should be. This has 
> led me to wonder where the original justification for these answers comes 
> from, but I have been struggling to hunt down a source.
>
> Matthew’s 2016 paper, “Bindings as Sets of Scopes”, discusses examples 
> like these ones in gory detail, but it gives no justification for *why* 
> these results are the right ones, it simply takes their meaning for 
> granted. Earlier papers on macro technology I have found do not discuss 
> internal definitions, and no Scheme standard specifies the macro system, 
> not even R6RS. Obviously, something at some point must have set the 
> precedent for the handling of such macros, but I cannot figure out what it 
> is.
>
> So, my question: when was hygiene for internal definitions first worked 
> out, and did it make it into any papers, specifications, or documentation? 
> Hopefully someone (probably Matthew) can provide some insight.
>
> Thanks,
> Alexis
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/ef3475e3-1b06-44f0-86e4-087dc57034fen%40googlegroups.com.

[racket-users] Re: The history of hygiene for definition contexts

[Eric Eide]

Alexis King  writes:

> So, my question: when was hygiene for internal definitions first worked out,
> and did it make it into any papers, specifications, or documentation?
> Hopefully someone (probably Matthew) can provide some insight.

I saw an interesting talk about the history of hygenic macro technology at
HOPL-IV.  I haven't read the paper, but maybe you might ;-).

  William D. Clinger and Mitchell Wand.  2020.  Hygienic macro technology.
  Proc. ACM Program. Lang. 4, HOPL, Article 80 (June 2020), 110 pages.
  DOI:https://doi.org/10.1145/3386330

Eric.

-- 
---
Eric Eide.University of Utah School of Computing
https://www.cs.utah.edu/~eeide/ . +1 801-585-5512 .   Salt Lake City, Utah, USA

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/m1fsvyuzk0.fsf%40cs.utah.edu.

[racket-users] Re: Question from a beginner. Why Racket Over Scheme?

[Juan Carlos Olivo]

Realm of Racket is a good beginner book. I love it, and is where I got my 
start from:
Realm of Racket | No Starch Press 


On Tuesday, July 13, 2021 at 9:13:38 AM UTC-5 italian...@gmail.com wrote:

> Hello,
>
> Im am looking at learning a programming language, and have been 
> bouncing around with scheme/racket/dyalog APL/squeak. upon investigation of 
> scheme and racket, i found that in regards to racket, there really isn't a 
> "Beginners book" that teaches the language. The only beginner book i could 
> really see being close to teaching the language is HtDP, but that doesn't 
> *technically* teach racket, but BSL. For scheme, im able to find beginner 
> books, unless im not looking deep enough. Maybe if you fine folk don't mind 
> pointing me in the right direction? Please excuse my ignorance.
>
> -- Joseph T
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/1a97ea09-1167-4bf6-9756-71cc93570233n%40googlegroups.com.