'John Clements' via Racket Users wrote on 1/30/19 1:46 PM:
Fundamentally, I think that what you’re proposing is sensible … and probably a lot of work that’s not currently at the top of anyone’s list. :)
Yes, the xexprs and SXML stuff is mostly very old (perhaps most of it from so far back that Racket even had its own little Web browser), though most of the code has held up pretty well despite its age, but I'm not aware of much recent development. (Held up well, thanks to John heroically preserving Oleg's code in the current Racket package system -- the biggest bit of bitrot was perhaps due to it not being written for a package system and doc system.)
The sparse recent development might be partly due to practitioners largely shifting away from HTML and XML, to JS-based frameworks and JSON.
There's also perhaps some "solved problem", such as when Oleg took a close look at XML, made his excellent parser, published about what he learned, and then moved on to other SXML/XML aspects, and to other areas.
That said, I speculate that there might be new boost of interest in HTML&XML in Racket, if Racket gets a WASM backend, perhaps through the Chez work, and someone invests in pushing what that can do.
For now, I occasionally resist the urge to make a new representation (probably involving a mix of SXML and Racket syntax objects, and possibly also structs), and write new tools for it. I've also wanted to do a few neat things with URI/URL, taking advantage of current Racket features, and based on what I learned with two earlier URI libraries in Scheme. And to build upon my template work, and to do frameworky stuff. Realistically, all that would have to be motivated and funded by paying work/research, like how some solid engineering work on Racket has and continues to be funded by goals of CS/PL systems research and CS education.
On Jan 30, 2019, at 10:27 AM, Christopher Lemmer Webber <cweb...@dustycloud.org> wrote: I wish the Racket community could collectively make a decision and "deprecate" one of them.
In case it comes up in discussion: one alternative to deprecating one of them in favor of the other won't work. I previously tried to make a compromise unified representation, but it just didn't want to work without sacrificing the arbitrary nesting of SXML, which is one of SXML's performance strengths (for efficient splicing of potentially large chunks of SXML during transformation, especially now that Racket pairs are immutable). I also tried to add splicing operators to the unified representation, then decided that Oleg had the more elegant idea from the start.
As a different approach to bridging xexpr and SXML worlds, I also started to try to make my SXML-ish template stuff also work with the Racket Web Server, but that work (along with my book and such) got interrupted in the middle of performance optimizing: https://www.neilvandyke.org/racket/rws-html-template/#%28part._.Known_.Issues%29
What I suspect will happen is that we'll continue to have our efforts divided between the xexpr and SXML worlds until the Chosen One foretold by the prophets is born, to do all the PL&engineering work and human leadership needed to unite the two peoples.
BTW, to someone not very familiar with the XML and HTML stuff in Racket, I don't want to overstate the impression of a problem. There's a good chance that you'd just develop in one world, and find that the available libraries for that world do what you need. I think it's only painful when you don't realize there's multiple worlds, and you take a while to realize that the library you're looking at is for a different world; or when your world happens to be missing functionality you need that the other world has.
-- 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.
