> Ok, I can give you permissions on the wiki. What is your username on the
> haskell-prime wiki?
Great! My haskell-prime username is "roelvandijk".
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-
On Thu, 2011-04-07 at 15:44 +0200, Roel van Dijk wrote:
> On 7 April 2011 14:11, Duncan Coutts wrote:
> > I would be happy to work with you and others to develop the report text
> > for such a proposal. I posted my first draft already :-)
>
> What would be a good way to proceed? Looking at the pr
On 7 April 2011 14:11, Duncan Coutts wrote:
> I would be happy to work with you and others to develop the report text
> for such a proposal. I posted my first draft already :-)
What would be a good way to proceed? Looking at the process I think we
should create a wiki page and a ticket for this p
On 7 April 2011 15:03, Christian Maeder wrote:
> The code would not suffer much if it were pure ASCII. I would prefer (ascii)
> haddock links to explain the various code points.
The code in question contains Chinese characters like '三', which in a
US-ASCII encoded Haskell file must be written as
Am 07.04.2011 13:09, schrieb Roel van Dijk:
Please take a look at the following file:
http://code.haskell.org/numerals/src/Text/Numeral/Language/ZH.hs
The code would not suffer much if it were pure ASCII. I would prefer
(ascii) haddock links to explain the various code points.
C.
__
On 7 April 2011 14:33, Doug McIlroy wrote:
> This supposition is unwarranted. We have all seen relative naming
> systems that run both ways: a.b.c versus c(b(a)). And Haskellites
> would simplify the latter to c$b$a. Secondary storage may be
> organized by files, segments, objects, etc. Combina
This suggestion supposes that every system names files in
the same way modulo choice of "directory separator":
> To find a source file corresponding to a module name used in an import
> declaration, the following mapping from module name to OS file name is
> used. The '.' character is mapped to th
2011/4/7 Christian Maeder
> Am 07.04.2011 11:29, schrieb Christian Maeder:
>
> So my view is: Stick to ASCII and only if you must (not just for casual
>> reasons) use UTF-8.
>>
>
> This means all comments in haskell sources (for hackage) should be in
> English, exclusively! Supply separate docum
On Thu, 2011-04-07 at 09:07 +0200, Roel van Dijk wrote:
> On 6 April 2011 15:13, Duncan Coutts wrote:
> > So since the goal is interoperability of source files then perhaps we
> > should also have a section somewhere with interoperability guidelines
> > for implementations that do store Haskell pr
Am 07.04.2011 13:24, schrieb Christian Maeder:
Am 07.04.2011 13:09, schrieb Roel van Dijk:
Please take a look at the following file:
http://code.haskell.org/numerals/src/Text/Numeral/Language/ZH.hs
Great, that file made my firefox open infinitely many tabs (so that I
had to close it).
Well,
> "Christian" == Christian Maeder writes:
Christian> Am 07.04.2011 13:09, schrieb Roel van Dijk:
>> Please take a look at the following file:
>> http://code.haskell.org/numerals/src/Text/Numeral/Language/ZH.hs
Christian> Great, that file made my firefox open infinitely many
Am 07.04.2011 13:09, schrieb Roel van Dijk:
Please take a look at the following file:
http://code.haskell.org/numerals/src/Text/Numeral/Language/ZH.hs
Great, that file made my firefox open infinitely many tabs (so that I
had to close it).
C.
___
H
On 7 April 2011 11:29, Christian Maeder wrote:
> I agree that Haskell files should be UTF-8, but I also agree that it is only
> relevant for Hackage (and Cabal) and already enforced by ghc-6.12. or
> higher.
It is relevant for all tools and systems which process Haskell sources.
> The motivation
> "Roel" == Roel van Dijk writes:
Roel> On 6 April 2011 20:42, Colin Paul Adams
wrote:
Roel> It seems you have a problem with the word "allowed". What do
Roel> you think of the interoperability guidelines as proposed by
Roel> Duncan? They are less stringent while having the
Hi,
Jason Reich wrote:
Tillmann Rendel wrote:
How would that affect the non-code parts of literate Haskell (*.lhs)
files? In particular, would it place any burden on third-party tools
processing these files?
lhs2TeX already has limited support for UTF-8 for the rendering of
Literate Agda file
Am 07.04.2011 11:29, schrieb Christian Maeder:
So my view is: Stick to ASCII and only if you must (not just for casual
reasons) use UTF-8.
This means all comments in haskell sources (for hackage) should be in
English, exclusively! Supply separate documentation in your mother
tongue if require
Am 06.04.2011 20:02, schrieb Bas van Dijk:
On 6 April 2011 17:34, Colin Paul Adams wrote:
[...]
I think the real place to mandate UTF-8 would be for Hackage. That's
where it matters (an alternative design would be to add an encoding
field in the .cabal file, but I don't think this has much mer
On 6 April 2011 20:42, Colin Paul Adams wrote:
>> "Bas" == Bas van Dijk writes:
> Bas> On 6 April 2011 17:34, Colin Paul Adams
> wrote:
> >> Allowed? Allowed for what?
> Bas> Allowed to be called a Haskell file.
> Well, what the report says on that is irrelevant. If I see a file
>
On 6 April 2011 15:13, Duncan Coutts wrote:
> So since the goal is interoperability of source files then perhaps we
> should also have a section somewhere with interoperability guidelines
> for implementations that do store Haskell programs as OS files.
I think a set of interoperability guideline
> "Bas" == Bas van Dijk writes:
Bas> On 6 April 2011 17:34, Colin Paul Adams
wrote:
>> Allowed? Allowed for what?
Bas> Allowed to be called a Haskell file.
Well, what the report says on that is irrelevant. If I see a file
containing Haskell code, I shall call it a Haskell fil
On 6 April 2011 17:34, Colin Paul Adams wrote:
> I forgot to CC the list:
>
>> "Roel" == Roel van Dijk writes:
>
> Roel> I propose to make UTF-8 the only allowed encoding for Haskell
> Roel> source files. Implementations must discard an initial Byte
> Roel> Order Mark (BOM) if presen
On Wed, 2011-04-06 at 16:09 +0100, Ben Millwood wrote:
> On Wed, Apr 6, 2011 at 2:13 PM, Duncan Coutts
> wrote:
> >
> > Interoperability Guidelines
> >
> >
> > [...]
> >
> > To find a source file corresponding to a module name used in an import
> > declaration, the followi
I forgot to CC the list:
> "Roel" == Roel van Dijk writes:
Roel> I propose to make UTF-8 the only allowed encoding for Haskell
Roel> source files. Implementations must discard an initial Byte
Roel> Order Mark (BOM) if present [3].
Roel> * Pros - Ensures that Haskell source
On Wed, Apr 6, 2011 at 2:13 PM, Duncan Coutts
wrote:
>
> Interoperability Guidelines
>
>
> [...]
>
> To find a source file corresponding to a module name used in an import
> declaration, the following mapping from module name to OS file name is
> used. The '.' character is
On 4 April 2011 23:48, Roel van Dijk wrote:
> * Proposal
>
> The Haskell 2010 language specification states that: "Haskell uses the
> Unicode character set" [2]. It does not state what encoding should be
> used. This means, strictly speaking, it is not possible to reliably
> exchange Haskell sourc
Tillmann Rendel wrote:
How would that affect the non-code parts of literate Haskell (*.lhs)
files? In particular, would it place any burden on third-party tools
processing these files?
lhs2TeX already has limited support for UTF-8 for the rendering of
Literate Agda files.
Jason
Roel van Dijk wrote:
> I propose to make UTF-8 the only allowed encoding for Haskell source
> files. Implementations must discard an initial Byte Order Mark (BOM)
> if present
I am in favor of this proposal.
However, you wrote:
> "GHC assumes that source files are ASCII or UTF-8 only, other
> en
Hi,
Roel van Dijk wrote:
I propose to make UTF-8 the only allowed encoding for Haskell source
files. Implementations must discard an initial Byte Order Mark (BOM)
if present [3].
How would that affect the non-code parts of literate Haskell (*.lhs)
files? In particular, would it place any burd
Per the Haskell Prime process I would like to make an official
proposal [1].
* Proposal
The Haskell 2010 language specification states that: "Haskell uses the
Unicode character set" [2]. It does not state what encoding should be
used. This means, strictly speaking, it is not possible to reliably
29 matches
Mail list logo
