Philip McGrath wrote on 2/1/19 5:14 PM:
I will say an advantage of the xexpr code is that it's written in (reasonably) modern Racket rather than portable Scheme, which I've found somewhat easier to understand when I've wanted to read the sources, though the sxml code is extensively commented.
Yes, IIRC, Oleg's code of that era was mostly RnRS portable, and a few bits of implementation-specific (Chez?), and his "standard prologue" (which made sense at the time, but, thankfully, package systems help make more-reusable packages without that). (IIRC, I did the first packaging of Oleg's SSAX for Racket (nee PLT Scheme) v103 or v200, and then Kirill Lisovsky et al. packaged various Oleg code for many Scheme variants, and then John Clements did a heavier wrangling of Oleg's code for modern Racket.)
My relatively small contributions are mostly old portable Scheme code that I wish I could rethink and reimplement. (IIRC, the permissive HTML parser you mention was the very first Scheme code I ever wrote, to start to build out Scheme as a platform for research like Web-inhabiting autonomous agents and Semantic Web, and I did some naive things while blindly guessing at performance costs (e.g., parsing lookahead). Today, I'm more comfortable on performance, and I'm also not coding to a portable subset of RnRS and minimal SRFIs. Though I'd probably write the next one in RnRS and judicious use of Racket extensions, so one might still see the occasional precise named-`let` in some places where a `for`-something might've been shoehorned in. :)
For example, if you care about the source syntax, you want to distinguish <![CDATA[ ]]> blocks and numeric entity references from naked textual data, but for higher-level purposes I want to treat all of those things as Racket strings
The SXML faction is not totally unresponsive to the desire for conveniences. :) https://docs.racket-lang.org/html-writing/#%28part._script_.Element%29
There were also a few SXML extensions that, last I looked at it, I was backing out, more towards canonical SXML (for example, the character entity notation made more sense before widespread Unicode, and when some Schemes were even had character case-insensitive symbols): https://docs.racket-lang.org/sxml-intro/#%28part._sxml-xexp%29
The new representation I'd hypothetically do would be different than either xexpr or SXML.
Anyway, it sounds like those people who have being doing XML and HTML in Racket (or at least, are still on the list?) have been able to get their work done, despite the unfortunate historical accident that led to the two main representations?
I couldn't say whether or how much opportunity we've missed over the years, with the divided effort, and potentially lost network effects (e.g., a couple people are impressed by what's available, uses it, contributes back a layered library or framework that someone else uses, repeat exponentially). And exactly what library support we could use today is different from back then, so we don't want to just do now what we wish we'd done back then.
-- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
