[m-rev.] for review: convert parse trees to strings

Zoltan Somogyi zoltan.somogyi at runbox.com
Tue Oct 31 17:32:16 AEDT 2023


The diff is long and boring. While I would appreciate a review of it,
I don't expect one. For anyone who does want to look at it, it contains
three ZZZs that I intend to address before commit. (Addressing those
now would have made the diff harder to review.)

The thing that needs discussing is that this diff will yield a slowdown
in its current form, because it replaces direct invocations of I/O operations
with indirect invocations through a typeclass instance. We have traditionally
accepted that cost on operations that small parts of parse trees, but not
on whole parse trees.  I am therefore proposing a new pragma that should
eliminate the speed impact of this diff, and it is this proposal that I need
reviews of. Any comments, either on the whole idea, or any of its details,
or the timing of its application, are welcome.

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.pto
Type: application/octet-stream
Size: 3121 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20231031/7aaeec6e/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.pto
Type: application/octet-stream
Size: 319181 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20231031/7aaeec6e/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TYPE_SPEC
Type: application/octet-stream
Size: 3591 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20231031/7aaeec6e/attachment-0005.obj>


More information about the reviews mailing list