I'm not sure about that - I suspect it would still be useful even just for surface forms, although it's probably not ideal to have two different modes for when you have the data or not. I had assumed that, assuming that most macro forms are spec'ed, most syntax problems would be encountered by the top-level macro spec. However thinking about it, in the case you mentioned the condition is probably passed through the two macros untouched and a problem there would be encountered by 'if'. However in that case the original text would still be useful since it would not have been touched during the expansions, the problem would be detecting that the form hasn't been modified. Similarly, the 'then' expression of the 'if' would be the original forms from the when-let body wrapped in a do.
I'm not sure how useful this idea would be in practice, it would need some experimentation to see how well it works. On 26 August 2016 at 20:24, Alex Miller <a...@puredanger.com> wrote: > On Thursday, August 25, 2016 at 9:11:39 PM UTC-5, Colin Fleming wrote: >> >> >> One thing that I think would help a lot would be if it were possible to >> show the actual text from the failing expression rather than pretty >> printing a seq representation of it. This would mean modifying the reader >> such that it either caches the program text from each top-level form as it >> reads it, or perhaps re-reading the file on an error. This means the >> relevant code is likely to look more familiar to the user, and also avoids >> any need to pretty print. Pretty printing is likely to be complicated since >> it normally works top-down, and uses the type of each form to decide how to >> lay its sub-parts out. If you're only pretty-printing a fragment from >> within, say, a large ns form, pprint is unlikely to format it as the user >> would expect. >> > > Does the caching or file re-reading have any hope of working when you have > nested macro expansions (like when-let -> when -> if)? The input to when in > that case is a form constructed by when-let, not text sitting in a file. > But maybe that doesn't matter if it's still useful for some good percentage > of macro calls that have access to text. One benefit of using pprint is > that you (the user) can control stuff like *print-length*, > *print-suppress-namespace*, *print-right-margin*, etc. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
