On 07/22/2016 01:17 PM, Vincent St-Amour wrote:
Ok, just a few left.
ryanc:
- upcoming syntax/parse backwards incompatibility
I've re-read the discussion, and now I'm confused. Was the resolution a
new set of changes that accomplishes what the older, backwards-
incompatible changes would have achieved, but which preserves backwards
compatibility? I.e., are we still planning to introduce an incompatibility
in 6.7?
A change is still happening, but it doesn't affect those packages we
discussed earlier; they were taken care of by refining when
"nullability" matters. Here's my text:
* `syntax-parse` raises an error when an ellipsis pattern has an empty
match rather than diverging, and it logs a warning when it statically
detects a nullable pattern, such as `((~seq) ...)`. In the next version
of Racket, it will reject the pattern instead, and it will remove
special handling that currently makes some uses of such patterns terminate.
- syntax/parse progress tracking 80364d85ddc4977b4e10086b4993e7b3e152a04c
4e6438eaf2b252d64d7f101141d3cdad74618cec
`syntax/parse` has improved progress tracking, leading to error
message improvements for macros implemented with it.
I think we can leave this out, but if you want to include it I like this
text.
- macro-debugger: macro code size profiler
7abcdbd3bd4e1c2d31b0880ad31efe7e47922bda
The new macro profiler shows which macros contribute most to expanded
code size.
* The new Macro Profiler command-line tool (`raco macro-profiler`) shows
how macros contribute to the final expanded code size of a program.
Ryan
--
You received this message because you are subscribed to the Google Groups "Racket
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-dev+unsubscr...@googlegroups.com.
To post to this group, send email to racket-dev@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-dev/57925ACE.7030806%40ccs.neu.edu.
For more options, visit https://groups.google.com/d/optout.
