Re: [racket-users] Syntax Parse Bee 2021

[Stephen De Gabrielle]

There is only a couple more days! it's not too late!

On Tuesday, August 3, 2021 at 8:55:14 PM UTC+1 Stephen De Gabrielle wrote:

> The bee is still on!
> Have you made a contribution yet?
>
> Write a macro with Racket this summer! Win stickers!
>
> The purpose of this event is to grow the syntax-parse-example 
> documentation and repository to grow as a resource for the Racket 
> community. (You can also contribute directly to the syntax parse examples 
> repository)
>
> It's like a Quilting Bee, but for syntax parse macros!
>
> Submit by opening an issue here: 
>
> https://github.com/syntax-objects/Summer2021/issues/new?assignees==entry=enter-the-syntax-parse-bee.md=%5Bentry+-+name%2Fdescription+of+macro%5D
>
>
>
> On Tue, 13 Jul 2021 at 09:06, Stephen De Gabrielle  
> wrote:
>
>> It’s very exciting seeing the entries pouring in.
>>
>> Reminder: Racket includes a macro debugger 
>>  to make it 
>> easier for the experienced to debug their macros and for beginners to study 
>> their behaviour: https://docs.racket-lang.org/macro-debugger/index.html
>>
>> Click ‘Macro Stepper’ in DrRacket or M-x  racket-stepper-mode in Racket 
>> Mode if you prefer Emacs: https://www.racket-mode.com/#Macro-expand
>>
>> Bw
>> Stephen
>>
>> On Thu, 1 Jul 2021 at 01:23, Ben Greenman  wrote:
>>
>>> Hi folks,
>>>
>>> *Write a macro with Racket this summer! Win stickers!*
>>>
>>> The purpose of this event is to grow the syntax-parse-example 
>>> documentation and repository to grow as a resource for the Racket 
>>> community. But you do not need to submit a full example to win stickers --- 
>>> any syntax-parse macro counts.
>>>
>>> *It's like a Quilting Bee, but for syntax parse macros!*
>>>
>>> Ground Rules:
>>>
>>>- you can write any macro as long as it uses syntax-parse somehow
>>>- enter as many times as you like
>>>- the first 20 individuals who enter will win exclusive stickers
>>>- open July 1 to September 1
>>>
>>> Submit by opening an issue here:
>>>
>>>
>>> https://github.com/syntax-objects/Summer2021/issues/new?assignees==entry=enter-the-syntax-parse-bee.md=%5Bentry+-+name%2Fdescription+of+macro%5D
>>>
>>> To help you get started, we suggest two categories of before-and-after 
>>> macro:
>>>
>>>1. *Code Cleaning* : Introduce a macro where there was none before. 
>>>Look for ways to make your source code more beautiful and/or less 
>>>repetitive.
>>>2. *Macro Engineering* : Use the tools in syntax-parse to improve an 
>>>existing  macro (which may or may not currently use syntax-parse). Try 
>>> to 
>>>make the old macro more maintainable, more robust against errors, and/or 
>>>more flexible.
>>>
>>> Updates will be via Racket News, Racket-Users, Slack, Discord & Reddit.
>>>
>>> Whatever you decide, we hope that you learn and have fun!
>>>
>>> - Ben + Stephen
>>>
>>>
>>> PS a 'Bee' is a community effort toward a common goal. A quilting bee is 
>>> for
>>> making a quilt. In this case the quilt is a patchwork of syntax-parse 
>>> macros.
>>>
>>> - - -
>>>
>>> Syntax parse docs:
>>>  https://docs.racket-lang.org/syntax/stxparse.html
>>>
>>> Syntax parse examples:
>>>  https://docs.racket-lang.org/syntax-parse-example/
>>>
>>> Extra syntax classes:
>>>  https://docs.racket-lang.org/syntax-classes/
>>>
>>> Mythical Macros tutorial:
>>>  https://soegaard.github.io/mythical-macros/
>>>
>>> Macros and Languages in Racket book draft:
>>>  http://rmculpepper.github.io/malr/
>>>
>>> Fine print:
>>>
>>>- this is an UNOFFICIAL event run by Racket users (@spdegabrielle 
>>>and @bennn)
>>>- entries must be submitted under the MIT license [1] for code and 
>>>under CC [2] for accompanying prose
>>>- stickers will be mailed via USPS; international entries are allowed
>>>- please abide by the Racket Friendly Environment Policy [3]
>>>
>>>
>>> [1] 
>>> https://github.com/racket/racket/blob/master/racket/src/LICENSE-MIT.txt
>>> [2] http://creativecommons.org/licenses/by/4.0/
>>> [3] https://racket-lang.org/friendly.html
>>>
>>>
>>> -- 
>>> 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/CAFUu9R6kCG%2BXFnYwOnD_9XyfNq%2BNbJnPVA_rpD4vGKPkzSXBDA%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 

[racket-users] Changing log destination from the environment

[David Storrs]

I've always used loggers in their default form, where they send to the
terminal, and then I use tee if I want it to go to a file as well.  That's
easy and effective but there's got to be a better way.  Two questions:

1) Is there a way to change logger destinations from the environment such
that modifying the code isn't necessary?   (e.g. send it to a file instead
of the terminal)

2) Is there a way to make a log message go to multiple destinations at the
same time? (e.g. to the terminal and to a file)

My sense is that Racket is explicitly designed to not allow redirecting the
logs at runtime, since the documentation makes a point of saying that it
sends to the process's *original* error port.  Is that right?

It looks like I could get around this by manually creating log receivers,
syncing them in a separate thread, and manually processing the messages
that get pumped to them.  I could even have it poll the environment to
check for destination CLI arguments. That seems pretty kludgy and I thought
I'd ask for a better solution.


I've been through the command line section and the logging section of the
docs and am stumped.  If there's a relevant section of the FM that I missed
please point me.

https://docs.racket-lang.org/reference/running-sa.html#%28part._mz-cmdline%29
https://docs.racket-lang.org/reference/logging.html

-- 
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/CAE8gKodh2A2gE%3DbJ_DDJdRMN2B8LLnn%2BEHKPxU7oyM1XbS7TwA%40mail.gmail.com.

[racket-users] IFL'21 call for participation

[Pieter Koopman]

IFL 2021



33rd Symposium on Implementation and Application of Functional Languages





 venue: online

  1 - 3 September 2021



 https://ifl21.cs.ru.nl






*Registration*


Registration is free of charge, but required for participation! Use the
below link to register for IFL 2021:



https://docs.google.com/forms/d/e/1FAIpQLSdMFjo-GumKjk4i7szs7n4DhWqKt96t8ofIqshfQFrf4jnvsA/viewform?usp=sf_link




*Scope*


The goal of the IFL symposia is to bring together researchers actively
engaged in the implementation and application of functional and
function-based programming languages. IFL 2021 will be a venue for
researchers to present and discuss new ideas and concepts, work in
progress, and publication-ripe results related to the implementation and
application of functional languages and function-based programming.



*Program*

The program is now available at https://ifl21.cs.ru.nl/Program

.



*Organisation*

IFL 2021 Chairs: Pieter Koopman and Peter Achten, Radboud University, The
Netherlands

IFL Publicity chair: Pieter Koopman, Radboud University, The Netherlands



*PC*

Peter Achten (co-chair)   - Radboud University, Netherlands

Thomas van Binsbergen - University of Amsterdam, Netherlands

Edwin Brady   - University of St. Andrews, Scotland

Laura Castro  - University of A Coruña, Spain

Youyou Cong   - Tokyo Institute of Technology, Japan

Olaf Chitil   - University of Kent, England

Andy Gill - University of Kansas, USA

Clemens Grelck- University of Amsterdam, Netherlands

John Hughes   - Chalmers University, Sweden

Pieter Koopman (co-chair) - Radboud University, Netherlands

Cynthia Kop   - Radboud University, Netherlands

Jay McCarthey - University of Massachussetts Lowell, USA

Neil Mitchell - Facebook, England

Jan De Muijnck-Hughes - Glasgow University, Scotland

Keiko Nakata  - SAP Innovation Center Potsdam, Germany

Jurriën Stutterheim   - Standard Chartered, Singapore

Simon Thompson- University of Kent, England

Melinda Tóth  - Eötvos Loránd University, Hungary

Phil Trinder  - Glasgow University, Scotland

Meng Wang - University of Bristol, England

Viktória Zsók - Eötvos Loránd University, Hungary
[image: beacon]

-- 
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/CAGtcRvD%2BokXz%3DC-jZdiZo1vAXT9UpAgfujffFBB_R7ysk5QAxw%40mail.gmail.com.

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