Re: [Scheme-reports] *TELUS Detected Spam*Re: [r6rs-discuss] returning back to pattern matching

[Vincent Manis <vmanis@x>]

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
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports