Re: [racket-users] [ANN] Introducing "social" contracts

[Nathaniel W Griswold]

The changes look good, i like the idea of this.

> On Aug 25, 2021, at 10:59 AM, Siddhartha Kasivajhula  
> wrote:
> 
> Hello again folks,
> I recently migrated one of my repos to use social-contract, and thought I'd 
> share the before/after as an example to illustrate what the package does:
> 
> https://github.com/countvajhula/seq/commit/c959be577448640e00ab7015bdaddabb7f8b49ba?branch=c959be577448640e00ab7015bdaddabb7f8b49ba=split

-- 
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/ED34FB18-A06C-4CE6-B15B-4680D7B6F3E0%40nan.sh.

Re: [racket-users] [ANN] Introducing "social" contracts

[Siddhartha Kasivajhula]

Hello again folks,
I recently migrated one of my repos to use social-contract, and thought I'd
share the before/after as an example to illustrate what the package does:

https://github.com/countvajhula/seq/commit/c959be577448640e00ab7015bdaddabb7f8b49ba?branch=c959be577448640e00ab7015bdaddabb7f8b49ba=split

The diffset hopefully illustrates some of these benefits of using
social-contract over the usual contract language:
1. these contracts encode more information about the data, so they can be
more helpful to the reader
2. by exploiting phrase structure, they scale well with increasing
complexity of the contracts, and generally take up less space
3. they minimize or eliminate repetition in the contract specification

Another way of thinking about this package is that it is a high level
contract DSL, layering phrase structure onto the existing contract DSL.

Give it a try,
-Sid



On Mon, Aug 16, 2021 at 4:58 PM Siddhartha Kasivajhula 
wrote:

> Hi David,
> Yes, both ->* and ->i are supported. The forms in social-contract expand
> to flat or arrow contracts, which, since these work within ->* and ->i
> there shouldn't be any issues there.
>
> The only built-in form it doesn't support yet is case->, and that's
> because at the moment case-> specifically looks for the literal "->" (and
> not even ->*). It would be ideal if this restriction could be relaxed so
> that forms expanding to -> could be used here, but I'm not sure if
> there's a reason it is the way it is - does anyone know?
>
> If you are planning on using C3PO to migrate your existing contracts
> automatically, that does not parse ->i yet and simply leaves this form
> unchanged in the migrated output. It can certainly be added in the future,
> especially if there is interest or if anyone wants to take a crack at
> adding it. But until then, we can always provide its subforms to C3PO
> individually, so it can still help with the migration even if we can't
> quite "set it and forget it."
>
>
> On Mon, Aug 16, 2021 at 1:46 PM David Storrs 
> wrote:
>
>> Hi Siddhartha,
>>
>> Will this package handle ->* and ->i, either now or in the future?
>>
>> On Sat, Aug 14, 2021 at 1:40 PM Siddhartha Kasivajhula <
>> skasi...@gmail.com> wrote:
>>
>>> Fellow Scheming Racketeers,
>>> When you've written a function that takes an integer and returns another
>>> one, you may write a contract for it as (-> integer? integer?). I want
>>> to tell you about the social-contract
>>>  package which
>>> allows you to write it as (self-map/c integer?) instead.
>>>
>>> Why would the latter form be preferable? It isn't much less to type.
>>> But, as we'll see, it is composable and it exploits the phrase structure of
>>> a contract specification. Consider:
>>>
>>> (-> (-> integer? integer? integer?) (-> integer? integer? integer?)))
>>>
>>> With social-contract, this would be expressed as:
>>>
>>> (self-map/c (binary-composition/c integer?))
>>>
>>> With a little familiarity, this tells you a lot, and saves you the
>>> trouble of parsing the low level contract specification in order to
>>> understand what this function does.
>>>
>>> And how about this:
>>> (-> (-> any/c boolean?) sequence? sequence?)
>>>
>>> This becomes simply:
>>> filter/c
>>>
>>>
>>> *Who decides what "self map," "composition," and "filter" mean?*
>>> We all do! In principle. The contracts available right now correspond to
>>> well-known mathematical or programming ideas, but they could be anything at
>>> all that we find to be common and useful. The "social" idea here is that,
>>> through issues raised and discussed
>>>  on the source
>>> repo, we collectively agree on the forms and variations of useful high
>>> level contracts.
>>>
>>>
>>> *But wouldn't it be tedious to learn the social contract forms?*
>>> On the contrary, it just might be fun. The package ships with C3PO, a
>>> handy contract migration assistant that already knows both the Racket
>>> contract DSL as well as the social contract forms, so you can provide
>>> contracts you've already written and it will translate them into high-level
>>> social contract representations. This can be useful for learning the new
>>> forms in an interactive way, and can also greatly reduce the time it would
>>> take to migrate any existing contracts you may have.
>>>
>>> Incidentally, C3PO is a "reverse compiler" implemented using parser
>>> combinators (megaparsack
>>> ). It is "reverse"
>>> in that it translates low-level contract specifications into high-level
>>> ones, and may be a curiosity in its own right. You can learn more about it
>>> here
>>> 
>>> and see its source here
>>> 
>>> .
>>>
>>> Enjoy,
>>> -Sid
>>>
>>> --
>>> You received 

Re: [racket-users] [ANN] Introducing "social" contracts

[Siddhartha Kasivajhula]

Hi David,
Yes, both ->* and ->i are supported. The forms in social-contract expand to
flat or arrow contracts, which, since these work within ->* and ->i there
shouldn't be any issues there.

The only built-in form it doesn't support yet is case->, and that's because
at the moment case-> specifically looks for the literal "->" (and not even
->*). It would be ideal if this restriction could be relaxed so that forms
expanding to -> could be used here, but I'm not sure if there's a reason it
is the way it is - does anyone know?

If you are planning on using C3PO to migrate your existing contracts
automatically, that does not parse ->i yet and simply leaves this form
unchanged in the migrated output. It can certainly be added in the future,
especially if there is interest or if anyone wants to take a crack at
adding it. But until then, we can always provide its subforms to C3PO
individually, so it can still help with the migration even if we can't
quite "set it and forget it."


On Mon, Aug 16, 2021 at 1:46 PM David Storrs  wrote:

> Hi Siddhartha,
>
> Will this package handle ->* and ->i, either now or in the future?
>
> On Sat, Aug 14, 2021 at 1:40 PM Siddhartha Kasivajhula 
> wrote:
>
>> Fellow Scheming Racketeers,
>> When you've written a function that takes an integer and returns another
>> one, you may write a contract for it as (-> integer? integer?). I want
>> to tell you about the social-contract
>>  package which
>> allows you to write it as (self-map/c integer?) instead.
>>
>> Why would the latter form be preferable? It isn't much less to type. But,
>> as we'll see, it is composable and it exploits the phrase structure of a
>> contract specification. Consider:
>>
>> (-> (-> integer? integer? integer?) (-> integer? integer? integer?)))
>>
>> With social-contract, this would be expressed as:
>>
>> (self-map/c (binary-composition/c integer?))
>>
>> With a little familiarity, this tells you a lot, and saves you the
>> trouble of parsing the low level contract specification in order to
>> understand what this function does.
>>
>> And how about this:
>> (-> (-> any/c boolean?) sequence? sequence?)
>>
>> This becomes simply:
>> filter/c
>>
>>
>> *Who decides what "self map," "composition," and "filter" mean?*
>> We all do! In principle. The contracts available right now correspond to
>> well-known mathematical or programming ideas, but they could be anything at
>> all that we find to be common and useful. The "social" idea here is that,
>> through issues raised and discussed
>>  on the source
>> repo, we collectively agree on the forms and variations of useful high
>> level contracts.
>>
>>
>> *But wouldn't it be tedious to learn the social contract forms?*
>> On the contrary, it just might be fun. The package ships with C3PO, a
>> handy contract migration assistant that already knows both the Racket
>> contract DSL as well as the social contract forms, so you can provide
>> contracts you've already written and it will translate them into high-level
>> social contract representations. This can be useful for learning the new
>> forms in an interactive way, and can also greatly reduce the time it would
>> take to migrate any existing contracts you may have.
>>
>> Incidentally, C3PO is a "reverse compiler" implemented using parser
>> combinators (megaparsack
>> ). It is "reverse"
>> in that it translates low-level contract specifications into high-level
>> ones, and may be a curiosity in its own right. You can learn more about it
>> here
>> 
>> and see its source here
>> 
>> .
>>
>> Enjoy,
>> -Sid
>>
>> --
>> 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/CACQBWFnUiaRZrO6jaGtOdyr1HxF%2BXn8aSovjC_VAaMHQtuHFxQ%40mail.gmail.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/CACQBWFkh_GkfF_XACuJ5-F03qs8HC4pqyY0yJdQmA1W%2BeuoUaQ%40mail.gmail.com.

Re: [racket-users] [ANN] Introducing "social" contracts

[David Storrs]

Hi Siddhartha,

Will this package handle ->* and ->i, either now or in the future?

On Sat, Aug 14, 2021 at 1:40 PM Siddhartha Kasivajhula 
wrote:

> Fellow Scheming Racketeers,
> When you've written a function that takes an integer and returns another
> one, you may write a contract for it as (-> integer? integer?). I want to
> tell you about the social-contract
>  package which
> allows you to write it as (self-map/c integer?) instead.
>
> Why would the latter form be preferable? It isn't much less to type. But,
> as we'll see, it is composable and it exploits the phrase structure of a
> contract specification. Consider:
>
> (-> (-> integer? integer? integer?) (-> integer? integer? integer?)))
>
> With social-contract, this would be expressed as:
>
> (self-map/c (binary-composition/c integer?))
>
> With a little familiarity, this tells you a lot, and saves you the trouble
> of parsing the low level contract specification in order to understand what
> this function does.
>
> And how about this:
> (-> (-> any/c boolean?) sequence? sequence?)
>
> This becomes simply:
> filter/c
>
>
> *Who decides what "self map," "composition," and "filter" mean?*
> We all do! In principle. The contracts available right now correspond to
> well-known mathematical or programming ideas, but they could be anything at
> all that we find to be common and useful. The "social" idea here is that,
> through issues raised and discussed
>  on the source
> repo, we collectively agree on the forms and variations of useful high
> level contracts.
>
>
> *But wouldn't it be tedious to learn the social contract forms?*
> On the contrary, it just might be fun. The package ships with C3PO, a
> handy contract migration assistant that already knows both the Racket
> contract DSL as well as the social contract forms, so you can provide
> contracts you've already written and it will translate them into high-level
> social contract representations. This can be useful for learning the new
> forms in an interactive way, and can also greatly reduce the time it would
> take to migrate any existing contracts you may have.
>
> Incidentally, C3PO is a "reverse compiler" implemented using parser
> combinators (megaparsack
> ). It is "reverse"
> in that it translates low-level contract specifications into high-level
> ones, and may be a curiosity in its own right. You can learn more about it
> here
> 
> and see its source here
> 
> .
>
> Enjoy,
> -Sid
>
> --
> 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/CACQBWFnUiaRZrO6jaGtOdyr1HxF%2BXn8aSovjC_VAaMHQtuHFxQ%40mail.gmail.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/CAE8gKofRhtH6LRMQLMMSpdWtAdysrw7mjqB%2BnMG%2BHoEy48MtLg%40mail.gmail.com.

[racket-users] [ANN] Introducing "social" contracts

[Siddhartha Kasivajhula]

Fellow Scheming Racketeers,
When you've written a function that takes an integer and returns another
one, you may write a contract for it as (-> integer? integer?). I want to
tell you about the social-contract
 package which
allows you to write it as (self-map/c integer?) instead.

Why would the latter form be preferable? It isn't much less to type. But,
as we'll see, it is composable and it exploits the phrase structure of a
contract specification. Consider:

(-> (-> integer? integer? integer?) (-> integer? integer? integer?)))

With social-contract, this would be expressed as:

(self-map/c (binary-composition/c integer?))

With a little familiarity, this tells you a lot, and saves you the trouble
of parsing the low level contract specification in order to understand what
this function does.

And how about this:
(-> (-> any/c boolean?) sequence? sequence?)

This becomes simply:
filter/c


*Who decides what "self map," "composition," and "filter" mean?*
We all do! In principle. The contracts available right now correspond to
well-known mathematical or programming ideas, but they could be anything at
all that we find to be common and useful. The "social" idea here is that,
through issues raised and discussed
 on the source
repo, we collectively agree on the forms and variations of useful high
level contracts.


*But wouldn't it be tedious to learn the social contract forms?*
On the contrary, it just might be fun. The package ships with C3PO, a handy
contract migration assistant that already knows both the Racket contract
DSL as well as the social contract forms, so you can provide contracts
you've already written and it will translate them into high-level social
contract representations. This can be useful for learning the new forms in
an interactive way, and can also greatly reduce the time it would take to
migrate any existing contracts you may have.

Incidentally, C3PO is a "reverse compiler" implemented using parser
combinators (megaparsack
). It is "reverse" in
that it translates low-level contract specifications into high-level ones,
and may be a curiosity in its own right. You can learn more about it here

and see its source here

.

Enjoy,
-Sid

-- 
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/CACQBWFnUiaRZrO6jaGtOdyr1HxF%2BXn8aSovjC_VAaMHQtuHFxQ%40mail.gmail.com.