Re: [racket-users] Being a good macro citizen: patterns to follow for good error reporting

2019-04-21 Thread Matthias Felleisen


> On Apr 21, 2019, at 6:48 AM, zeRusski  wrote:
> 
> I just had an epiphany, or rather a very painful revelation, that if your 
> macro does not report errors in terms of user code, say, when inputs are 
> wrong, you ought to be ostracized by the community if not banished from any 
> social interactions altogether. You don't deserve the good life. Solitary 
> confinement, damn it, until you've repented your sins, for you have sinned!


This was the problem I formulated in slightly more polite words to launch Ryan 
C’s dissertation on his dissertation research in ’03. 


> 
> Every macro has a good path - one that lets us figure what it should expand 
> into. I doubt I'm alone in merrily banging out said expansions without so 
> much as a single thought about all the bad paths the macro can take. It's 
> gotten painfully obvious lately, that if I don't take care to capture such 
> erroneous states and expansions, my macro may as well be broken, as in 
> completely wrong, even if it does the right thing for correct inputs.
> 
> Sadly, I don't think I have any systematic approach to being a good citizen 
> here, nor is my mental model for syntax objects I produce has an entry for 
> good locations and context. First, I noticed that I started to use syntax/loc 
> in place of #' everywhere I produce syntax objects. Then more pain led me to 
> discover a combination of ~describe pattern with #:context syntax-parse 
> option. And, I tell ya they are MAGICAL! Both were learnt through hardship 
> and pain, s


Yeap, this is part of the result of this research. See my second lecture from 
Racket School ’18.


BTW, for all those reading this far, we’re running another Racket School. 
Priomised I’ll lecture less and Jay will do better :) 




> o I wonder if there is a compendium of patterns that I should be cognizant of 
> to avoid at least some of that pain as I push Racket harder?
> 
> Could people maybe share relevant examples, or point out Racket machinery 
> that may not be immediately relevant but one should have at least passing 
> knowledge of to recognize when it may come in handy?
> 
> Is this too broad of a request?


No, even with syntax-parse and define-syntax-class around, we still need guides 
for people who enter Macroland so that they find their way to the good 
waterholes. Kind of like a cross between AppleMap and Yelp. 

— Matthias

-- 
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.
For more options, visit https://groups.google.com/d/optout.


[racket-users] Being a good macro citizen: patterns to follow for good error reporting

2019-04-21 Thread zeRusski
I just had an epiphany, or rather a very painful revelation, that if your 
macro does not report errors in terms of user code, say, when inputs are 
wrong, you ought to be ostracized by the community if not banished from any 
social interactions altogether. You don't deserve the good life. Solitary 
confinement, damn it, until you've repented your sins, for you have sinned!

Every macro has a good path - one that lets us figure what it should expand 
into. I doubt I'm alone in merrily banging out said expansions without so 
much as a single thought about all the bad paths the macro can take. It's 
gotten painfully obvious lately, that if I don't take care to capture such 
erroneous states and expansions, my macro may as well be broken, as in 
completely wrong, even if it does the right thing for correct inputs.

Sadly, I don't think I have any systematic approach to being a good citizen 
here, nor is my mental model for syntax objects I produce has an entry for 
good locations and context. First, I noticed that I started to use 
syntax/loc in place of #' everywhere I produce syntax objects. Then more 
pain led me to discover a combination of ~describe pattern with #:context 
syntax-parse option. And, I tell ya they are MAGICAL! Both were learnt 
through hardship and pain, so I wonder if there is a compendium of patterns 
that I should be cognizant of to avoid at least some of that pain as I push 
Racket harder?

Could people maybe share relevant examples, or point out Racket machinery 
that may not be immediately relevant but one should have at least passing 
knowledge of to recognize when it may come in handy?

Is this too broad of a request?

-- 
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.
For more options, visit https://groups.google.com/d/optout.