Re: [racket-users] Smart contracts in Racket

[James Platt]

On Mar 15, 2021, at 7:01 PM, Beatriz Moreira wrote:

> Hello! I recently used Racket as a tool to see the small step execution of 
> some smart contract languages and I was wondering if there is anywhere i can 
> submit my work or share it with the Racket community.

One place might be the Racket Artifacts site.  I think it's mainly intended for 
short demonstrations of code but, if yours is not too long, that might be the 
place. 

https://github.com/racket/racket/wiki/Artifacts

I am interested in smart contracts, as well, for a possible future addition to 
a project I am working on but it will be a while before I get to that point.  

-- 
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/E3DCE2FA-3159-4F4C-A7FE-D529A95E8755%40biomantica.com.

Re: [racket-users] Smart contracts in Racket

[Christopher Lemmer Webber]

James Platt writes:

> On Mar 15, 2021, at 7:01 PM, Beatriz Moreira wrote:
>
>> Hello! I recently used Racket as a tool to see the small step
>> execution of some smart contract languages and I was wondering if
>> there is anywhere i can submit my work or share it with the Racket
>> community.
>
> One place might be the Racket Artifacts site.  I think it's mainly
> intended for short demonstrations of code but, if yours is not too
> long, that might be the place.
>
> https://github.com/racket/racket/wiki/Artifacts
>
> I am interested in smart contracts, as well, for a possible future
> addition to a project I am working on but it will be a while before I
> get to that point.

Spritely Goblins is probably what you want to look at, or will after the
next release (v0.8) comes out:

   https://docs.racket-lang.org/goblins/index.html

In the not too distant future, Spritely and Agoric's CapTP should
converge.  Agoric's current work is all based around smart contracts:

  https://agoric.com/
  https://github.com/Agoric/agoric-sdk/issues/1827

There's a lot of confusion out there about what "smart contracts" mean;
most of the examples tend to assume it has to do with blockchains.  In
fact, work on smart contracts precedes blockchains by several decades.
If you look at http://www.erights.org/ on which many of the ideas in
Spritely Goblins is based, you'll notice that it has the word "smart
contracts" prominently, yet this was well over a decade before
blockchains even existed.  What the heck?

Smart contracts as something implemented with distributed objects can be
best understood probably by reading Capability Based Financial Instruments:

  http://erights.org/elib/capability/ode/index.html

The mint example from that paper is implemented in Goblins:

  
https://gitlab.com/spritely/goblins/-/blob/dev/goblins/actor-lib/simple-mint.rkt

That's right, in about 25 lines of Goblins code you can have a
functioning bank of sorts, which preserves financial integrity and even
permits networked accounts.  No blockchain required.

Yet, you could add a blockchain, or even turn Goblins into a blockchain
if you wanted.  (Since Goblins' actor state is transactional and
snapshottable, you can have a merkle tree of all inputs, and global
consensus on the set of messages accepted by the network, and all
participants can replay and simulate the same abstract machine.  This is
fairly trivial to do in Goblins.)

But more interestingly, Agoric has already done the work of abstracting
even remote blockchains as abstract machines on the network.  Since
we'll be implementing the same CapTP, when the time comes you'll be able
to access all that for free, even though Agoric programs are written in
Javascript and Goblins programs in Racket.

Anyway, the next release of Goblins, coming soon, should allow for
beginning to play with this kind of stuff on the network more easily
than in the present (v0.7) stuff, which currently takes a lot of work.
So maybe if you can wait a few weeks, it'll be easier to talk about.

But "smart contracts" is a use case, a broad problem domain.  What kind
of smart contracts are you wanting to write?

 - Chris

-- 
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/87h7lac36a.fsf%40dustycloud.org.

[racket-users] Version metadata on Racket packages

[Jeff Henrikson]

Hello racket-users,

As far as I can tell from reading the Racket documentation, the racket 
package manager has only one field to indicate version.  I am trying to 
understand the intended use of the version field.


Here the documentation seems to recommend that packages use the version 
field to denote a semantic versioning scheme of for the specific 
package's release cycle:


   https://docs.racket-lang.org/pkg/Package_Concepts.html
    a version — a string of the form ‹maj›.‹min›,
   ‹maj›.‹min›.‹sub›, or ‹maj›.‹min›.‹sub›.‹rel›, where ‹maj›, ‹min›,
   ‹sub›, and ‹rel› are all canonical decimal representations of
   natural numbers, ‹rel› is not 0, ‹sub› is not 0 unless ‹rel› is
   supplied, ‹min› has no more than two digits, and ‹sub› and ‹rel›
   have no more than three digits. A version is intended to reflect
   available features of a package, and should not be confused with
   different releases of a package as indicated by the checksum.

Here the documentation refers to a "Racket version number," which might 
be taken to mean a version number of the Racket language:


   https://docs.racket-lang.org/pkg/catalog-protocol.html
    8.1 Remote and Directory Catalogs
    In the case of a remote URL or a local directory naming
   a package catalog, the URL/path is extended as follows to obtain
   information about packages:

    pkg and ‹package› path elements, where ‹package› is a
   package name, plus a version=‹version› query (where ‹version› is a
   Racket version number) in the case of a remote URL.

It seems natural for packages that tightly depend on quickly evolving 
features of the Racket language to have a versioning scheme coupled to 
Racket's own versions.  On the other hand, for packages that work with a 
variety of possible Racket versions, it seems to make sense that said 
packages would have their own release cycles, compatibility aspirations, 
and semantic versioning contract.


Note that some package managers for evolving languages have two 
versioning coordinates, one for the language version and one for the 
package version.


Appended below this message is a small racket program that inspects data 
from the https://pkgs.racket-lang.org/pkgs-all HTTP endpoint.  According 
to this analysis, 21% of published Racket packages version using version 
numbers of the Racket language. Fewer than 1% of published Racket 
packages seem to version using their own version scheme.  And 78% of 
published Racket packages have only ever filled the version field with 
"default".


As the documentation notes, using checksum instead of a version field is 
sort of like saying any feature can change at any time to any degree: "A 
version is intended to reflect available features of a package, and 
should not be confused with different releases of a package as indicated 
by the checksum."


My question is this: What is the intended use of the version field in 
the Racket package manager?


Thanks in advance,


Jeff Henrikson


   #lang racket

   ;; obtain data with:
   ;; curl https://pkgs.racket-lang.org/pkgs-all > contrib_pkgs-all.sexp


   ;; relfin is "contrib_pkgs-all.sexp" or similar.
   ;;
   ;; In practice it's one value that comes over the wire, so
   ;; we'll just take the car now.
   (define (read-pkgs5 relfin)
  (letrec (
   (fin (open-input-file relfin))
   (iter (lambda (xs)
   (let ((x (read fin)))
 (if (not (equal? x eof))
 (iter (cons x xs))
 (begin
   (close-input-port fin)
   xs))
    (car (reverse (iter '())


   ;;; Get the versions of a package hash
   (define (versions-of-pkg pkg)
  (hash-keys (hash-ref pkg 'versions)))

   ;;; Is there at least one version that appears to be distinct
   ;;; from a racket version?
   ;; Racket version numbers contemporaneous with the remote catalog
   ;; seem to start around version 6.
   (define (package-uses-version-for-package? pkg)
  (not (empty? (filter (lambda (v)
 (and
  (string? v)
  (stringlist pkgs)))
 (num-by-use (hash->list h)))
    num-by-use))



   (module+ main
  (define pkgs (read-pkgs5 "contrib_pkgs-all.sexp"))

  (classify-version-use pkgs)
  ;; '((no-versioning-used . 1472) (racket-versioned . 379)
   (package-versioned . 13))
   )


--
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/cde363b4-f0c4-eb6f-c68f-7033bfa14c3c%40gmail.com.

Re: [racket-users] Version metadata on Racket packages

[Sage Gerard]

The last sentence of the first paragraph you quoted starts with "A version is 
intended," but I don't know for sure if it is a complete answer. You'll also 
notice on the catalog that there are version exceptions, but you may have 
already read that by now.

https://docs.racket-lang.org/pkg/getting-started.html?q=version%20exceptions#%28part._.Version_.Exceptions%29

Beyond what the manual says, the version field really doesn't mean much in the 
sense I think you're hinting at. There is no query language where you can ask 
for, say, the latest version within those available within 4.2.x, for example. 
Even if there was, it wouldn't be that useful since the default catalog does 
not maintain artifacts (Bogdan's racksnaps improves on this situation).

Also remember that it is the collection, not the package, is the real "unit of 
exchange" in the Racket ecosystem. If you release a version 2.0 that includes a 
breaking change in a `foo` collection, it will conflict with any version of any 
package published by anyone that happens to define modules of the same name in 
the same collection. There are reasons for this, but that's out of the scope 
for your question.

On 3/16/21 6:51 PM, Jeff Henrikson wrote:

> Hello racket-users,
>
> As far as I can tell from reading the Racket documentation, the racket 
> package manager has only one field to indicate version. I am trying to 
> understand the intended use of the version field.
>
> Here the documentation seems to recommend that packages use the version field 
> to denote a semantic versioning scheme of for the specific package's release 
> cycle:
>
>> https://docs.racket-lang.org/pkg/Package_Concepts.html
>> a version — a string of the form ‹maj›.‹min›, ‹maj›.‹min›.‹sub›, or 
>> ‹maj›.‹min›.‹sub›.‹rel›, where ‹maj›, ‹min›, ‹sub›, and ‹rel› are all 
>> canonical decimal representations of natural numbers, ‹rel› is not 0, ‹sub› 
>> is not 0 unless ‹rel› is supplied, ‹min› has no more than two digits, and 
>> ‹sub› and ‹rel› have no more than three digits. A version is intended to 
>> reflect available features of a package, and should not be confused with 
>> different releases of a package as indicated by the checksum.
>
> Here the documentation refers to a "Racket version number," which might be 
> taken to mean a version number of the Racket language:
>
>> https://docs.racket-lang.org/pkg/catalog-protocol.html
>> 8.1 Remote and Directory Catalogs
>> In the case of a remote URL or a local directory naming a package catalog, 
>> the URL/path is extended as follows to obtain information about packages:
>>
>> pkg and ‹package› path elements, where ‹package› is a package name, plus a 
>> version=‹version› query (where ‹version› is a Racket version number) in the 
>> case of a remote URL.
>
> It seems natural for packages that tightly depend on quickly evolving 
> features of the Racket language to have a versioning scheme coupled to 
> Racket's own versions. On the other hand, for packages that work with a 
> variety of possible Racket versions, it seems to make sense that said 
> packages would have their own release cycles, compatibility aspirations, and 
> semantic versioning contract.
>
> Note that some package managers for evolving languages have two versioning 
> coordinates, one for the language version and one for the package version.
>
> Appended below this message is a small racket program that inspects data from 
> the https://pkgs.racket-lang.org/pkgs-all HTTP endpoint. According to this 
> analysis, 21% of published Racket packages version using version numbers of 
> the Racket language. Fewer than 1% of published Racket packages seem to 
> version using their own version scheme. And 78% of published Racket packages 
> have only ever filled the version field with "default".
>
> As the documentation notes, using checksum instead of a version field is sort 
> of like saying any feature can change at any time to any degree: "A version 
> is intended to reflect available features of a package, and should not be 
> confused with different releases of a package as indicated by the checksum."
>
> My question is this: What is the intended use of the version field in the 
> Racket package manager?
>
> Thanks in advance,
>
> Jeff Henrikson
>
>> #lang racket
>>
>> ;; obtain data with:
>> ;; curl https://pkgs.racket-lang.org/pkgs-all > contrib_pkgs-all.sexp
>>
>> ;; relfin is "contrib_pkgs-all.sexp" or similar.
>> ;;
>> ;; In practice it's one value that comes over the wire, so
>> ;; we'll just take the car now.
>> (define (read-pkgs5 relfin)
>> (letrec (
>> (fin (open-input-file relfin))
>> (iter (lambda (xs)
>> (let ((x (read fin)))
>> (if (not (equal? x eof))
>> (iter (cons x xs))
>> (begin
>> (close-input-port fin)
>> xs))
>> (car (reverse (iter '())
>>
>> ;;; Get the versions of a package hash
>> (define (versions-of-pkg pkg)
>> (hash-keys (hash-ref pkg 'versions)))
>>
>> ;;; Is there at least one version that appears to be distinct
>> ;;; from a rack

Re: [racket-users] Version metadata on Racket packages

[Philip McGrath]

Hi Jeff,

In fact there are two concepts here, and part of what I think confused you
is something I just discovered this week and plan to report as a bug:
https://pkgs.racket-lang.org/pkgs-all does not include the package's
version: that's what's discussed on the Package Concepts
 page you linked
to. The ?version= query parameter corresponds to the `'versions` (plural—in
hindsight this should have had a different name!) entry in the hash table,
which is documented slightly below the passage you quoted from the section
on Remote and Directory Catalogs

:

> -
>
> 'versions (optional) — a hash table mapping version strings and 'default
> to hash tables, where each version-specific hash table provides mappings to
> override the ones in the main hash table, and 'default applies to any
> version not otherwise mapped.
>
> Clients of a remote catalog may request information for a specific
> version, but they should also check for a 'versions entry in a catalog
> response, in case a catalog with version-specific mappings is implemented
> as a directory or by a file-serving HTTP server. A 'default mapping,
> meanwhile, allows the main hash table to provide information that is
> suitable for clients at version 5.3.6 and earlier (which do not check for
> 'versions).
>
This field is not a property of the package: it is part of the package
catalog. For example, when registering a package at
https://pkgs.racket-lang.org, you can optionally enter this data in a field
on the web form. The purpose is to implement "version exceptions", which
are documented further down the page—but clearly this section should be
much more pervasively linked to, because this is quite confusing:

> To make supporting multiple versions of Racket easier, the package catalog
> 
> software supports version exceptions. Version exceptions allow package
> authors to specify alternative package source
> s
> to be used when installing a given package using a specific version of
> Racket.
>
> For example, a package that uses on Racket 6.0-specific features could
> provide a version exception
> 
> for Racket 5.3.6 using a different branch or tag in the package’s GitHub
> repository, or a different zip archive, as package source. Users installing
> the package from Racket 6.0 will use the default source for the package,
> while those using Racket 5.3.5 will install from the alternative branch,
> tag, or archive.
>
This is very rarely useful, in my experience: I thought I might have used
it once, but it now seems I didn't.

With that confusing detour out of the way, on to your actual question:
"What is the intended use of the version field in the Racket package
manager?"

The summary you quoted is right, but there are some important details:

> A version is intended to reflect available features of a package, and
> should not be confused with different releases of a package as indicated by
> the checksum.
>

Let's imagine package A depends on package B. Both are at version 0.0. Now
B exports a new function, which A would like to use. If B is well-behaved,
it has changed its package info.rkt file to include:

> (define version "0.1")
>
Now A can write:

> (define deps
>   '("base"
> ["B" #:version "0.1"]))
>
and `raco pkg` will prompt anyone who installs or updates A but has an old
version of B to update B, too.

Note that there are some important differences from the semver systems used
by some other package managers: in particular, by design, the only possible
version constraint is "at least". When you write:

> It seems natural for packages that tightly depend on quickly evolving
> features of the Racket language to have a versioning scheme coupled to
> Racket's own versions.  On the other hand, for packages that work with a
> variety of possible Racket versions, it seems to make sense that said
> packages would have their own release cycles, compatibility aspirations,
> and semantic versioning contract.
>

Racket has some strong views about compatibility, both as a
language/distribution and in the design of its package manager. Racket has,
from my perspective, a fairly remarkable level of commitment to not
breaking existing code. The package system is modeled on an os-level
package manager, a deliberate choice to move away from the intricate
versioning mechanism of the older PLaneT package system. It is focused on
getting your files installed in the right place. The expectation is that
releases of a package will only add functionality, not remove or break it.
A package therefore need only increment the version number if it has added
something t

Re: [racket-users] Synchronizable conjunction of events?

[Greg Rosenblatt]

Thanks for the help, everyone.

Sam, it looks like you've worked with Aaron a bit on reagents in 
https://github.com/aturon/Caper.  Is there anything CML can express that 
reagents have trouble with?  How does the implementation complexity compare?

On Monday, March 15, 2021 at 8:12:03 PM UTC-4 Sam Tobin-Hochstadt wrote:

> I think Aaron Turon's reagents (and more generally k-cas) are an example 
> of N-way rendezvous. 
>
> Sam
>
> On Mon, Mar 15, 2021, 5:50 PM Matthew Flatt  wrote:
>
>> At Mon, 15 Mar 2021 13:38:46 -0700 (PDT), Greg Rosenblatt wrote:
>> > Is there a corresponding event for a logical conjunction (I was looking 
>> for 
>> > something like `all-evt` or `every-evt`), which requires that all of 
>> its 
>> > members be ready for synchronization at the same time? 
>>
>> No. (Although `replavce-evt` is a weak kind of "and", it's not what
>> you're looking for.)
>>
>> > If not, is there a fundamental barrier to its implementation with the
>> > ConcurrentML approach?
>>
>> Yes, at least in the sense that it's not possible to implement N-way
>> rendezvous given only CML's rendezvous.
>>
>> So, N-way rendezvous would have to be implemented in the core. I'm
>> certain that some languages have implemented that, but I have forgotten
>> the examples.
>>
>> > Related to this, I've been reading "Kill-Safe Synchronization 
>> Abstractions" 
>> > (https://www.cs.utah.edu/plt/publications/pldi04-ff.pdf), and found it 
>> > notable that the swap channel couldn't be implemented in a way that was 
>> > both kill-safe and break-safe (not ruining `sync/enable-break`'s 
>> > exclusive-or guarantee).  I'm wondering if both forms of safety could 
>> be 
>> > achieved by using a hypothetical `all-evt` that behaves as I've 
>> described.
>>
>> Probably so. The citation of [17] in that part of the paper is meant to
>> allude to the CML-style rendezvous versus N-way rendezvous constraint.
>>
>>
>> Matthew
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/racket-users/20210315155008.cc%40sirmail.smtps.cs.utah.edu
>> .
>>
>

-- 
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/646ab600-4655-4f5e-ad53-18eba5966fben%40googlegroups.com.

Re: [racket-users] Synchronizable conjunction of events?

[Sam Tobin-Hochstadt]

Reagents are a generalization of core CML, but Racket extends the basics of
CML considerably. I think there's definitely implementation complexity in
reagents that would need to be added to support conjunction, but I don't
know how much.

Looking back at Aaron's thesis, I see several other systems with forms of
conjunction that are relevant here. First, join patterns, which reagents
are based on, also include conjunction. Second, transactional events
(Donnelly and Fluent) are in some sense exactly what's requested here, the
andThen combinator mentioned here is what I think you originally requested:
http://www.cs.cornell.edu/people/fluet/research/tx-events/

Sam

On Tue, Mar 16, 2021, 9:48 PM Greg Rosenblatt  wrote:

> Thanks for the help, everyone.
>
> Sam, it looks like you've worked with Aaron a bit on reagents in
> https://github.com/aturon/Caper.  Is there anything CML can express that
> reagents have trouble with?  How does the implementation complexity compare?
>
> On Monday, March 15, 2021 at 8:12:03 PM UTC-4 Sam Tobin-Hochstadt wrote:
>
>> I think Aaron Turon's reagents (and more generally k-cas) are an example
>> of N-way rendezvous.
>>
>> Sam
>>
>> On Mon, Mar 15, 2021, 5:50 PM Matthew Flatt  wrote:
>>
>>> At Mon, 15 Mar 2021 13:38:46 -0700 (PDT), Greg Rosenblatt wrote:
>>> > Is there a corresponding event for a logical conjunction (I was
>>> looking for
>>> > something like `all-evt` or `every-evt`), which requires that all of
>>> its
>>> > members be ready for synchronization at the same time?
>>>
>>> No. (Although `replavce-evt` is a weak kind of "and", it's not what
>>> you're looking for.)
>>>
>>> > If not, is there a fundamental barrier to its implementation with the
>>> > ConcurrentML approach?
>>>
>>> Yes, at least in the sense that it's not possible to implement N-way
>>> rendezvous given only CML's rendezvous.
>>>
>>> So, N-way rendezvous would have to be implemented in the core. I'm
>>> certain that some languages have implemented that, but I have forgotten
>>> the examples.
>>>
>>> > Related to this, I've been reading "Kill-Safe Synchronization
>>> Abstractions"
>>> > (https://www.cs.utah.edu/plt/publications/pldi04-ff.pdf), and found
>>> it
>>> > notable that the swap channel couldn't be implemented in a way that
>>> was
>>> > both kill-safe and break-safe (not ruining `sync/enable-break`'s
>>> > exclusive-or guarantee).  I'm wondering if both forms of safety could
>>> be
>>> > achieved by using a hypothetical `all-evt` that behaves as I've
>>> described.
>>>
>>> Probably so. The citation of [17] in that part of the paper is meant to
>>> allude to the CML-style rendezvous versus N-way rendezvous constraint.
>>>
>>>
>>> Matthew
>>>
>>> --
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/racket-users/20210315155008.cc%40sirmail.smtps.cs.utah.edu
>>> .
>>>
>> --
> 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/646ab600-4655-4f5e-ad53-18eba5966fben%40googlegroups.com
> 
> .
>

-- 
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/CAK%3DHD%2BaXvUNarLG%2BtWFB_0Wive-h4dJrOMmPLVoYaWc0qWt0tA%40mail.gmail.com.

Re: [racket-users] Synchronizable conjunction of events?

[Greg Rosenblatt]

Thanks for the info, lots of reading to do now.

I ran across transactional events, and also "Isolates: Serializability 
Enforcement for Concurrent ML" 
(https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=2730&context=cstech) 
which looks like it may extend transactional events.

On Tuesday, March 16, 2021 at 10:03:48 PM UTC-4 Sam Tobin-Hochstadt wrote:

> Reagents are a generalization of core CML, but Racket extends the basics 
> of CML considerably. I think there's definitely implementation complexity 
> in reagents that would need to be added to support conjunction, but I don't 
> know how much. 
>
> Looking back at Aaron's thesis, I see several other systems with forms of 
> conjunction that are relevant here. First, join patterns, which reagents 
> are based on, also include conjunction. Second, transactional events 
> (Donnelly and Fluent) are in some sense exactly what's requested here, the 
> andThen combinator mentioned here is what I think you originally requested: 
> http://www.cs.cornell.edu/people/fluet/research/tx-events/
>
> Sam
>
> On Tue, Mar 16, 2021, 9:48 PM Greg Rosenblatt  wrote:
>
>> Thanks for the help, everyone.
>>
>> Sam, it looks like you've worked with Aaron a bit on reagents in 
>> https://github.com/aturon/Caper.  Is there anything CML can express that 
>> reagents have trouble with?  How does the implementation complexity compare?
>>
>> On Monday, March 15, 2021 at 8:12:03 PM UTC-4 Sam Tobin-Hochstadt wrote:
>>
>>> I think Aaron Turon's reagents (and more generally k-cas) are an example 
>>> of N-way rendezvous. 
>>>
>>> Sam
>>>
>>> On Mon, Mar 15, 2021, 5:50 PM Matthew Flatt  wrote:
>>>
 At Mon, 15 Mar 2021 13:38:46 -0700 (PDT), Greg Rosenblatt wrote:
 > Is there a corresponding event for a logical conjunction (I was 
 looking for 
 > something like `all-evt` or `every-evt`), which requires that all of 
 its 
 > members be ready for synchronization at the same time? 

 No. (Although `replavce-evt` is a weak kind of "and", it's not what
 you're looking for.)

 > If not, is there a fundamental barrier to its implementation with the
 > ConcurrentML approach?

 Yes, at least in the sense that it's not possible to implement N-way
 rendezvous given only CML's rendezvous.

 So, N-way rendezvous would have to be implemented in the core. I'm
 certain that some languages have implemented that, but I have forgotten
 the examples.

 > Related to this, I've been reading "Kill-Safe Synchronization 
 Abstractions" 
 > (https://www.cs.utah.edu/plt/publications/pldi04-ff.pdf), and found 
 it 
 > notable that the swap channel couldn't be implemented in a way that 
 was 
 > both kill-safe and break-safe (not ruining `sync/enable-break`'s 
 > exclusive-or guarantee).  I'm wondering if both forms of safety could 
 be 
 > achieved by using a hypothetical `all-evt` that behaves as I've 
 described.

 Probably so. The citation of [17] in that part of the paper is meant to
 allude to the CML-style rendezvous versus N-way rendezvous constraint.


 Matthew

 -- 
 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...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/racket-users/20210315155008.cc%40sirmail.smtps.cs.utah.edu
 .

>>> -- 
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/racket-users/646ab600-4655-4f5e-ad53-18eba5966fben%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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/01365d33-66e7-4630-aed7-aedc66ad87f5n%40googlegroups.com.