[ANN] Introducing "social" contracts
84 views
Skip to first unread message
Siddhartha Kasivajhula
Aug 14, 2021, 1:40:21 PM8/14/21
to racket...@googlegroups.com
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.
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
Enjoy,
-Sid
David Storrs
Aug 16, 2021, 4:46:16 PM8/16/21
to Siddhartha Kasivajhula, Racket Users
Hi Siddhartha,
Will this package handle ->* and ->i, either now or in the future?
--
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/CACQBWFnUiaRZrO6jaGtOdyr1HxF%2BXn8aSovjC_VAaMHQtuHFxQ%40mail.gmail.com.
Siddhartha Kasivajhula
Aug 16, 2021, 7:58:27 PM8/16/21
to David Storrs, Racket Users
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."
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."
Siddhartha Kasivajhula
Aug 25, 2021, 11:59:41 AM8/25/21
to David Storrs, Racket Users
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&diff=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
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&diff=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
Nathaniel W Griswold
Sep 23, 2021, 4:06:11 PM9/23/21
to Siddhartha Kasivajhula, Racket Users
The changes look good, i like the idea of this.
Reply all
Reply to author
Forward
0 new messages