On Dec 29, 2014, at 7:43 PM, Eli Barzilay <e...@barzilay.org> wrote:
> On Tue, Dec 30, 2014 at 1:01 AM, Alexander D. Knauth
> <alexan...@knauth.org> wrote:
>>
>> On Dec 29, 2014, at 4:53 PM, Eli Barzilay <e...@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?
____________________
Racket Users list:
http://lists.racket-lang.org/users
