[racket] at-exp: is there any way to make it turn @list{A @"string" escape} into (list "A " "string" " escape") ?

On Dec 29, 2014, at 7:43 PM, Eli Barzilay <eli at barzilay.org> wrote:

> On Tue, Dec 30, 2014 at 1:01 AM, Alexander D. Knauth
> <alexander at knauth.org> wrote:
>> 
>> On Dec 29, 2014, at 4:53 PM, Eli Barzilay <eli at barzilay.org> wrote:
>> 
>>> And you can probably also run into surprises when some argument
>>> evaluates to a string that has ~s in it.
>> 
>> No, because it never tries to parse an argument as a format string,
>> because it knows the number of arguments there should be from the
>> previous format string.
> 
> I mean that you can get a mess if you make parsing mistakes, or when
> format strings change (like the change that added the dotted "~.e" etc
> forms).  There's not too much complications in Racket's format strings,
> but I wouldn't be surprised if they eventually grow more features.
> Another way of looking at it is that there are some extensions, like the
> dot thing, that are mostly backward compatible because they only specify
> useful stuff for things that used to be invalid -- and the existense of
> another piece of code that does format-string-parsing mean that now
> *any* change to format strings is a real bug for you.  (So "morally"
> speaking, if I'd write such code I'd want a whole pile of tests that
> check all valid and invalid format strings, so I know when they change;
> or an even better solution would be to expose the Racket format string
> parser but that makes it a much heavier tool.)

My code don’t actually do any format-string parsing, it does (format str)
inside a with-handlers and if it succeeds it knows it takes 0 arguments,
and if it fails it looks at the error message.

>>> or even ignore voids
>>> 
>>>   (define (my-print . stuff)
>>>     (for ([thing (in-list stuff)] #:unless (void? thing))
>>>       ((if (string? thing) display print) thing)))
>>> 
>>> so you can do something like:
>>> 
>>>   @my-print{blah @some-value blah @write[another-value] blah}
>> 
>> This is interesting, and solves most of the same "problems," but it
>> doesn't extend to things like error.
> 
> I don't see why not...  I'm assuming that you have some extension to
> exceptions that hold the values to show in some way, so you can just as
> well change it to hold thunks that output stuff instead.  Or, if you
> want to actually hold the values, the add some struct for "printed
> values" that hold the value and how it should be printed.

Oh ok, up until now I hadn’t realized that error converted them to strings
anyway.  (for the “tests” I used my-printf so that it would go on the the next “test”)
But I could probably add an extension to exceptions that did that.

But you still couldn’t do something like: (with your my-error)
@my-error[name]{blah @some-value blah @write[another-value] blah}
without my-error being a macro that wrapped everything in thunks, but
my version of my-error could still be a function.  

Random thought:
Would it make sense for there to be an extra field in exceptions that could
hold a function that the error-display-handler would use to display it?