[racket-users] test suite for hygienic expander?

Is there a test suite for the macro expander? I assume that you must have one, but it would save me some effort if somebody can tell me where it is. I'm interested in finding out if you have good corner cases for testing a proposal for a hygienic expander. --Mitch -- You received this

[racket-users] Re: test suite for hygienic expander?

As far as I'm aware, the new expander was tested initially on the simple cases in: https://github.com/racket/racket/blob/master/racket/src/expander/demo.rkt The `racket-tests-core` tests here: https://github.com/racket/racket/tree/master/pkgs/racket-test-core/tests/racket particularly

[racket-users] Re: test suite for hygienic expander?

You might also find the redex model and examples from the scope sets paper useful: http://www.cs.utah.edu/plt/popl16/ On Monday, August 6, 2018 at 5:18:47 PM UTC-4, michael.ballantyne wrote: > > As far as I'm aware, the new expander was tested initially on the simple > cases in: > >

Re: Parameters considered often harmful (was: Re: [racket-users] Re: A (long) question regarding parameters and scope)

> On Aug 3, 2018, at 15:36, Alexis King wrote: > > Maybe this isn’t really a direct response to the direction this thread > has taken, but given the question proposed in the original message, I > think it’s relevant to share a particular design pattern for parameters > that seems to work

Re: [racket-users] difficult to package library

I believe that Ben is assuming that you’re not using (define collection ‘multi) in your top-level info.rkt file. If you *are* using multi-collection style, I believe you have some changes to make. If you’re not using the ‘multi style, you should totally ignore this email. John > On Aug 1,

Re: [racket-users] Re: Parameters considered often harmful

You illustrate my point precisely: for the implementor, parameters provide a low-effort way of adding knobs and buttons without having to thread arguments through every call. Unfortunately, with parameters you also get surprising behavior related to threads and re-entry, because this kind of

[racket-users] parameterized logging

Hi all, Is there a way to automatically send say a prefix string with many already coded logger invocations? For example, to go from: (thread ... (log-debug "information specific to particular thread, without mention of which thread"))

Re: [racket-users] parameterized logging

I was just now coding something similar (to add info like `port-next-location` to errors and warning logging).  Ideas: 1. If changing the module with the logging forms is practical, and you just don't want the changes to be too messy, you could make syntax that expands to the logging syntax: