On Tue, 04 May 2010 11:56:31 -0700, Andrei Alexandrescu wrote: > Graham Fawcett wrote: >> On Tue, 04 May 2010 09:09:29 -0700, Andrei Alexandrescu wrote: >> >>> Graham Fawcett wrote: >>>> On Mon, 03 May 2010 16:01:30 -0700, Andrei Alexandrescu wrote: >>>> >>>>> Graham Fawcett wrote: >>>>>> The fact that libxml2/libxslt support not only XML parsing and DOM >>>>>> building, but also XSLT, XPath, XPointer, XInclude, RelaxNG, etc., >>>>>> means that any homegrown library will be hard-pressed to cover the >>>>>> same range of tools and features. >>>>>> >>>>>> There are too many half-baked XML libraries in the world. No >>>>>> disrespect intended to opticron or anyone else; it just doesn't >>>>>> make a lot of sense to reinvent such a complex wheel (and believing >>>>>> that XML processing isn't complex is a sure sign that your >>>>>> homegrown library's design is incomplete!). >>>>>> >>>>>> Graham >>>>> I think what we need for the standard library is to take a solid XML >>>>> library licensed generously and adapt it to work with arbitrary >>>>> ranges. >>>> By "adapt" do you mean writing a wrapper for an existing library, or >>>> translating the source code of the library into D? >>>> >>>> What constitutes a "generous license" in this context? (For what it's >>>> worth, libxml2 is under the MIT License.) >>>> >>>> Graham >>> We'd need to modify the code. I haven't looked into available xml >>> libraries so I don't know which would be eligible. >> >> I think I understand your motivations: this is standard library, and so >> you want to minimize dependencies. But from a maintenance perspective, >> it seems a bad idea to translate a complex library into D code that few >> people will actively maintain -- whereas writing a wrapper (and >> introducing a library dependency) would keep the codebase small, let >> you share maintenance costs with the third-party library's developers, >> and (arguably) increase the stability and quality of the stdlib? >> >> I am not pushing for libxml2 as The Answer. I'm just questioning the >> motivation to translate other people's code to D, when the D platform >> excels at library integration. (Although I agree with your suggestion >> to borrow inspiration/code from Boost for datetime and other features; >> that's different, since Boost cannot feasibly be wrapped.) >> >> Best, >> Graham > > My concern is purely technical - a library we just link to would force a > number of choices, such as input representation (e.g. arrays of char). > Ideally we should be able to change the library to accept any compatible > range of any compatible characters. > > As a simple example, consider std.algorithm.levenshteinDistance. There > are plenty of good implementations and initially I just wrote one almost > identical to the Web lore. However, later I needed to compute > Levenshtein distances between strings stored in lists (tries, actually). > Well that doesn't work because the implementation at that time used > random access s[i] and t[i] all over the place. But it wasn't difficult > to change the algorithm to work with forward ranges. So now we have one > of the few Levenshtein distance implementations that work with other > inputs than arrays. In particular, we work correctly with UTF inputs > without needing to copy the input, something that I haven't seen > anywhere else. If you google for ``levenshtein utf'' Google will even > think the query has a typo. Search results include an OCaml > implementation that copies the input > (http://en.wikibooks.org/wiki/Algorithm_Implementation/Strings/ Levenshtein_distance#OCaml) > and a Ruby implementation that also copies the input > (http://rubyforge.org/frs/?group_id=2080&release_id=7389). By using the > range abstraction, we get to support UTF Levenshtein without significant > additional implementation effort - the code is very similar to the one > using indices throughout.
That's a strong argument -- thank you for taking the time to respond. Regards, Graham
