Thanks everyone for the replies. I guess the two questions I have pertain mainly to 1) lineage and 2) versioning:
Regarding lineage, I'm interested in knowing if Pugs/Parrot/Niecza/STD/Perlito/viv/JVM/Rakudo ever used the ICU Libraries--even if now that data has been extracted into a Raku-native data structure. I'm fairly certain one principal Rakudo developer is a C++ expert, so this idea isn't too far fetched. Regarding versioning, it would be great to tell people that Raku conforms to the latest-and-greatest ICU Library version, currently sitting at version# ICU_67. That way when people are weighing Raku vs Ruby or Python or Haskell or Go, we can tell them "Raku v6.d extracts ICU_67 thus it conforms to the most current (and most widely accepted) Unicode Library release (ICU 67 / CLDR 37 locale data / Unicode 13)." I've read over Daniel's blog post but I don't recall explicit mention of Unicode version 12, or 13, etc., although it does seem that following his links takes you to references for Unicode 13.0.0 (see https://www.unicode.org/reports/tr44/). Does Rakudo roll it's own UCD? Is there no reliance on ICU? Anyway, If Daniel or Samantha or Joseph or Liz can confirm/refute Raku's use of the (widely-adopted) ICU C-Library and/or Java-Library, I will have learned something. Thanks, Bill. http://site.icu-project.org/download/67 "ICU 67 updates to CLDR 37 locale data with many additions and corrections. This release also includes the updates to Unicode 13, subsuming the special CLDR 36.1 and ICU 66 releases. ICU 67 includes many bug fixes for date and number formatting, including enhanced support for user preferences in the locale identifier. The LocaleMatcher code and data are improved, and number skeletons have a new “concise” form that can be used in MessageFormat strings. This is the first regular release after ICU 65. ICU 66 was a low-impact release with just Unicode 13 and a few bug fixes." Library/Language support for ICU: Objective C CocoaICU A set of Objective-C classes that encapsulate parts of ICU. C# GenICUWrapper A tool that generates a rudimentary C# wrapper around the C API of ICU4C. This could be used to generate headers for other ICU wrappers. C# ICU Dotnet - .NET bindings for ICU D Mango.icu is a set of wrappers for the D programming language Erlang icu4e is a set of bindings for Erlang to ICU4C Cobol COBOL A page on how ICU could be used from a COBOL application. Go icu4go provides a Go binding for the icu4c library Haskell Data.Text.ICU Haskell bindings for ICU4C. Lua ICU-Lua ICU for the Lua language Pascal ICU4PAS An Object Pascal wrapper around ICU4C. Perl PICU Perl wrapper for ICU PHP PHP intl A PHP wrapper around core ICU4C APIs. Python PyICU A Python extension wrapper around ICU4C. R stringi An R language wrapper of for ICU4C. Ruby icu4r ICU4C binding for MRI ruby. Smalltalk VA Smalltalk Wrappers Parrot Virtual Machine This is a virtual machine for Perl 6 and other various programming languages. ICU4C is used to improve the Unicode support. PHP The upcoming PHP 6 language is expected to support Unicode through ICU4C. Companies and Organizations using ICU: ABAS Software, Adobe, Amazon (Kindle), Amdocs, Apache, Appian, Apple, Argonne National Laboratory, Avaya, BAE Systems Geospatial eXploitation Products, BEA, BluePhoenix Solutions, BMC Software, Boost, BroadJump, Business Objects, caris, CERN, CouchDB, Debian Linux, Dell, Eclipse, eBay, EMC Corporation, ESRI, Facebook (HHVM), Firebird RDBMS, FreeBSD, Gentoo Linux, Google, GroundWork Open Source, GTK+, Harman/Becker Automotive Systems GmbH, HP, Hyperion, IBM, Inktomi, Innodata Isogen, Informatica, Intel, Interlogics, IONA, IXOS, Jikes, Library of Congress, LibreOffice, Mathworks, Microsoft, Mozilla, Netezza, Node.js, Oracle (Solaris, Java), Lawson Software, Leica Geosystems GIS & Mapping LLC, Mandrake Linux, OCLC, Progress Software, Python, QNX, Rogue Wave, SAP, SIL, SPSS, Software AG, SuSE, Sybase, Symantec, Teradata (NCR), ToolAware, Trend Micro, Virage, webMethods, Wine, WMS Gaming, XyEnterprise, Yahoo!, Vuo, and many others. On Thu, Sep 24, 2020 at 11:14 AM Joseph Brenner <doom...@gmail.com> wrote: > > Elizabeth Mattijsen <l...@dijkmat.nl> wrote: > > https://www.codesections.com/blog/raku-unicode/ > > Thanks, yes I was just reading through that. It makes it clear that > the "Unicode Character Database" is built-in to the MoarVM, but I'm > not that clear what the ICU libraries do for you, and I thought there > might be some point in using them for something or other. > > > On 9/24/20, Elizabeth Mattijsen <l...@dijkmat.nl> wrote: > > https://www.codesections.com/blog/raku-unicode/ > > > >> On 24 Sep 2020, at 20:00, Joseph Brenner <doom...@gmail.com> wrote: > >> > >> I'm not sure myself, but my first guess would be probably not...I > >> *think* Raku is doing it's own Unicode thing, and isn't using any > >> system ICU libraries (but I'm willing to stand corrected on that). > >> > >> As far as perl (the-language-formerly-known-as-perl5) is concerned: > >> > >> That page http://site.icu-project.org/related is a little strange in > >> any case. If you follow the links for "perl" it goes to J. Briggs > >> personal web page, and if you comb through that there's a link to his > >> PICU just in tarball form. He has a CPAN account, but doesn't seem to > >> have put this code there. > >> > >> (On the other hand there's this cpan module that uses the system icu > >> libraries: https://metacpan.org/pod/Unicode::Transliterate) > >> > >> Anyway, I don't think perl has an ICU dependency either, it does it's > >> own unicode thing as well (i.e. the Unicode "database" ships with it). > >> > >> > >> On 9/24/20, William Michels <w...@caa.columbia.edu> wrote: > >>> Hi, > >>> > >>> I stumbled across the "ICU - International Components for Unicode" > >>> website: > >>> > >>> http://site.icu-project.org/ > >>> https://github.com/unicode-org/icu > >>> > >>> There's a list of programming languages using the ICU libraries here: > >>> > >>> http://site.icu-project.org/related > >>> > >>> Should Raku be added to the list above? > >>> I see Perl and Parrot listed, but not Raku. > >>> > >>> Best, Bill. > >>> > >
