[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haskell
Subject:    Re: SYNTAX BUT NOT ONLY
From:       Joe Fasel <jhf () chaco ! c3 ! lanl ! gov>
Date:       1991-03-15 2:25:41
Message-ID: 9103142128.AA15776 () chaco ! c3 ! lanl ! gov ! 
[Download RAW message or body]

Original-Via: uk.ac.nsf; Fri, 15 Mar 91 01:27:39 GMT
Date: Thu, 14 Mar 91 14:28:31 MST
From: Joe Fasel <jhf@chaco.c3.lanl.gov>
To: haskell <haskell%edu.yale.cs@yalevm.ycc.yale.edu>
Subject: Re: SYNTAX BUT NOT ONLY
Original-Sender: jhf <jhf%gov.lanl.c3.chaco%edu.yale.ycc.yalevm@cs.yale.edu>
Sender: haskell-request@cs.glasgow.ac.uk

| From: "Igor L. Bel'chinskiy" <bil%jumbo.hq.demos.su
|
| 1. On Haskell character set (HCS).
|   I think it's unwise to limit HCS to ASCII. This limitation necessary
|   would arise numerous problems while using Haskell in non-english-speaking
|   countries (especially with another alphabets).

When we started designing Haskell, we briefly discussed the issue of a
standard character set.  Not being sure where various 8-bit and larger
character set standards were going at the time, we decided to be
conservative and go with ASCII.  Thomas Johnsson concurred in this,
saying that Scandinavian programmers were used to this limitation
anyway, because of C.  We recognized that the choice of ASCII was not
ideal, but it seemed a reasonable, conservative decision at the time.

More recently, Lennart Augustsson has suggested that we adopt ISO
8859-1 (Latin-1), which now seems to be the obvious choice of an 8-bit
extension of ASCII.  Lennart pointed out that this would only cover
western Europe, though.  (And I understand, that it doesn't quite do
that either, omitting Welsh and Lappish.)  Nonetheless, I supported
this idea, supposing that it would hold us until we come out with
Haskell 2.

I am pleased to discover that this position is already obsolete.
Thank you for letting us know that, Igor!

| 1.1 Possibility to use native alphabets in strings.
|   Current decision - to code characters greater than 128 by numbers
|   is not too handy.
|   I propose to use characters between 128 and 256 in strings without
|   limitations (expand HCS for strings to full 256).

I agree completely.  The only disadvantage might be that ASCII users
would prefer to get an error if a string contains a strange byte,
but this could be handled with a compiler option.

Presumably, we would want the Text instance of Char to handle extended
character sets in a similar way.  As it turns out, readsPrec already
does so, since readLitChar simply passes through any character that
is not escaped.  Since I wrote this code, I suppose I should claim
that this represents foresight, rather than a failure to be consistent
with the syntax of strings.  ;-)

Unfortunately, showsPrec does (and must, in general) convert characters
with codes greater than 127 to escape codes.  I don't see any way around
this except to modify the standard prelude for use with an extended
character set.

| 1.2 Possibility to use native alphabets in program texts.
|   To allow it we can simply add two following directives
|
|   small "string of native characters to expand ASCII small letters' set"
|   capital "string of native characters to expand ASCII capital letters' set"

I think this might be a good idea.  Lennart's suggestion that we just
consider anything greater than 127 to be alphabetic won't quite do
the job, since we do distinguish identifiers by the case of the first letter.
Perhaps we also need to be able to declare what the extended nonalphabetic
graphic characters are, so that the compiler knows what is allowed in
strings.  (I think it's a bad idea to allow control characters.)

For Haskell 2, I think we need to consider multiple character sets,
perhaps along the lines of the Ada solution that Reginald Meeson
describes.  This would be a major undertaking, however, since it
would probably require subtypes, overloaded constructors, and/or
coercions.

--Joe



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic