On 2010-12-23, at 14:49, Alex Shinn wrote:
> We can certainly leave time altogether out of the WG1 standard,
> but I don't want to incorporate designs that are broken and may
> even eventually be fixed - even if it takes 50 years.
WG1 can have a procedure that returns a non-decreasing approximation to the
number of seconds since an epoch. This is just fine for the vast majority of
tasks such as timing program execution and the like. It can have procedures
that convert between such values and Gregorian calendar values. This too is
just fine for such things as computing the overdue fines for a library book.
Agreed that these procedures are totally inadequate for programming a
telescope, but I stand by my point that WG1 should be something that's
understandable to undergraduate students in computer science. I am quite
comfortable with the WG1 description of date and time facilities having a note
that says they provide only approximations to the actual values.
There are many supplementary libraries that can be used to extend this. One
indeed can provide TAI times, and generally allow extremely precise longterm
timing. Other libraries might support the full ISO 8601 calendar model,
including week numbering. Others might support the Hebrew or Islamic calendar,
or even the Mayan calendars, for those who count in baktuns. But none of these
is needed for the common things that people need to do.
>> Unicode is another example. Full Unicode support requires an internal
>> copy of most or all of the Unicode Character Database, which, for many
>> applications that just need to throw around a few accented characters or
>> math symbols, is overkill. R6RS requires a relatively small subset of
>> Unicode [...]
>
> Actually, you have it backwards. R6RS requires full Unicode support,
> which was one of the (many) complaints against it, and is why the WG1
> standard doesn't require anything beyond ASCII.
Er, no. R6RS itself requires support for the Unicode character set and Unicode
classifications. (r6rs unicode) adds procedures for character classification,
case conversion, and normalization; elsewhere the library requires support for
Unicode encodings. Neither requires or provides support for Unicode character
names, bidirectional layout, Arabic contextual shaping, line-breaking
characteristics, CJK characters, language-dependent comparison ("Müllerstraße"
versus "muellerstrasse"), etc. It would be crazy to require all of these in any
programming language, which is my point. I'm quite happy with ASCII for WG1 and
simplified Unicode (more-or-less what R6RS has, though I'm not too keen on the
API R6RS offers) for WG2. My point was that the core libraries should try to
address the tasks that most programmers encounter, rather than attempting to
solve problems completely.
-- vincent
_______________________________________________
Scheme-reports mailing list
[email protected]
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
