gmane.comp.lang.haskell.prime

Creating a list of extensions to add to Haskell'

Henk-Jan van Tuyl — 2012-04-19T21:50:54

L.S.,

Many libraries on Hackage use language extensions, or depend on other
libraries that use extensions. When an extension is no longer supported,
or another Haskell compiler must be used,
this may lead to a lot of maintenance work.

To prevent an extreme amount of maintenance, I try to avoid using language
extensions, but many libraries on Hackage use them.

My proposal is:
Make an inventory, of the most used language extensions (based
on the number of Hackage downloads of packages depending directly or
indirectly on them).  If the most used extensions are theoretically sound
and improve software developed with them, they should be included in the
next Haskell standard.

Packages, using rejected extensions, should be redesigned or shunned
(marked as such in Hackage).

Regards,
Henk-Jan van Tuyl

Faça parte da minha rede no LinkedIn

Carlos Camarao Figueiredo — 2012-03-29T18:02:06

LinkedIn
------------



Eu gostaria de adicioná-lo à minha rede profissional no LinkedIn.
-Carlos Camarao

Carlos Camarao Figueiredo
Professor na UFMG
Belo Horizonte e Região, Brasil

Confirme que você conhece Carlos Camarao Figueiredo:
https://www.linkedin.com/e/g4afbk-h0e41yt6-n/isd/6485083729/t-WWDysg/?hs=false&tok=1Rt6jCLOCW0Bc1

--
Você está recebendo convites de conexão por e-mail. Clique aqui para parar de recebê-los:
http://www.linkedin.com/e/g4afbk-h0e41yt6-n/TxW8ibFUf804HWGRSSBmLzVTlbMbbXm3PVJ5g9-/goo/haskell-prime%40haskell%2Eorg/20061/I2249830483_1/?hs=false&tok=1uXcs9Xx6W0Bc1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043 - EUA.

_______________________________________________
Haskell-prime mailing list
Haskell-prime-HC+Z4NTRIlBAfugRpC6u6w< at >public.gmane.org
http://www.haskell.org/mailman/listinfo/haskell-prime

String != [Char]

Greg Weber — 2012-03-17T01:44:33

the text library and Text data type have shown the worth in real world
Haskell usage with GHC.
I try to avoid String whenever possible, but I still have to deal with
conversions and other issues.
There is a lot of real work to be done to convert away from [Char],
but I think we need to take it out of the language definition as a
first step.

I can only see one issue with the proposal: it can be convenient to
operate on a list of characters.
But I think there are plenty of solutions at our disposal. A simple
conversion from Text to a list of characters might suffice. In GHC,
OverloadedStrings means users would still be free to use String the
same way they are now.

What is a punctuation character?

Gabriel Dos Reis — 2012-03-16T18:08:09

Hi,

The lexical structure chapter defines the non-terminal uniSymbol as

     uniSymbol ::= any Unicode symbol or punctuation

There is a slight ambiguity here: is that description supposed to
be parsed as:
   (a) "Unicode (symbol or punctuation)", or
   (b) "(Unicode symbol) or punctuation"?

If (b), then what qualifies as "punctuation"?  As far as I can tell,
that is not defined anywhere in the Report.  Is it "punctuation" in the
basic ASCII charset or in the extended ASCII charset?  Everywhere
else the Report has been careful in listing which ASCII characters
are meant.

Thanks,

Hierarchical module broken link

Gabriel Dos Reis — 2012-03-15T17:14:12

Hi,

The page with link

  http://www.haskell.org/hierarchical-modules/

from

  http://hackage.haskell.org/trac/haskell-prime/wiki/HierarchicalModules

is broken (404 error).

Thanks,

simple extension to ghc's record disambiguation rules

John Meacham — 2012-02-18T02:01:23

Hi, I'd like to propose an extremely simple extension to ghc's record
disambiguation rules,

my motivation is that I often have record types with multiple constructors
but common fields.

so the handy idiom of

f Rec { .. } = do
        blah
        return Rec { .. }

won't work, because I don't know the specific constructor.

so, my proposal is that when you come across something like

(e::RecType) { blah = foo }

(with an explicit type signature like shown)

You interpret 'blah' as if it is a field of the record of type 'Rec'. This
gives the advantages of record field names being scoped by type but without
you having to specify the precise constructor.

It is also backwards compatible for expressions, but would be a new thing
for patterns which generally don't allow type signatures there.

It sidesteps type checker interactions by only being triggered when an
explicit type annotation is included.

ideally it would be combined with the 'update' and 'label-based
pattern-matching' extensions from this page
ht

Proposal: require spaces around the dot operator

Greg Weber — 2012-02-10T02:11:47

Similar to proposal #20, which wants to remove it, but immediately
less drastic, even though the long-term goal is the same.
This helps clear the way for the usage of the unspaced dot as a record
field selector as shown in proposal #129.

After this proposal shows clear signs of moving forward I will add a
proposal to support a unicode dot for function composition.
After that we can all have a lively discussion about how to fully
replace the ascii dot with an ascii alternative such as <~ or <<<
After that we can make the dot operator illegal by default.

This has already been discussed as part of a records solution on the
ghc-users mail list and documented here:
http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator

FW: 7.4.1-pre: Show & Integral

Simon Peyton-Jones — 2011-12-23T17:41:23

I'm confused too.  I'd welcome clarification from the Haskell Prime folk.

S

-----Original Message-----
From: Serge D. Mechveliani [mailto:mechvel-p4AAo9Fem04< at >public.gmane.org] 
Sent: 23 December 2011 17:36
To: Simon Peyton-Jones
Subject: Re: 7.4.1-pre: Show & Integral

On Thu, Dec 22, 2011 at 08:14:54PM +0000, Simon Peyton-Jones wrote:

I am confused.
I am looking now at the on-line specification of  Haskell-2010, 
6.3 Standard Haskell Classes.
It shows that  Integral  includes  Show:  

                           Eq     Show 
                             \   /
                              Num 
                              |
                       Enum  Real 
                          \   |
                           Integral

This is also visible in the further standard class declarations in this chapter.

Hence, for  `x :: Integral a => a'  it is correct to write  (shows x "").
And  ghc-7.4.0.20111219  does not allow this.
So,  ghc-7.4.0.20111219  breaks the 2010 standard. Now, Edward Kmett writes tha

left and right sections extended

Christian Maeder — 2011-09-30T12:21:52

Hi,

the following sections are currently legal in Haskell:

   (a + b +) and (++ a ++ b)

because + is left and ++ is right associative.

I would like to write

    (+ 1 +) and (++ " " ++)

as legal generalized sections, too, to stay for (\ a -> (a + 1 +)) and 
(\ a b -> a ++ " " ++ b) respectively.

The right-associative case would be "flip (\ b -> (++ " " ++ b))"

Such an extension would be easy to implement and it would also be a 
generalization of putting parenthesis around symbols as in (+) or (++).

Extending the grammar is easy:

aexp -> ...
| ( infixexp qop )     (left section)
| ( qop⟨-⟩ infixexp )     (right section)

Some thoughts are needed to exclude the illegal cases (as done for left 
and right sections).

Is this worth a formal proposal or is this too confusing?

Cheers Christian

_______________________________________________
Haskell-prime mailing list
Haskell-prime< at >haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Please apply the comparison function given to nubBy to elements ofthe list in the order in which they occur in the list.

Cale Gibbard — 2011-09-08T00:07:39

I just tried this in ghci-7.0.3:

ghci> nubBy (>=) [1,2,3,4]
[1]

Think about what this is doing: it is excluding 2 from the list
because 2 >= 1, rather than including it because 1 >= 2 fails.

I think an important convention when it comes to higher order
functions on lists is that to the extent which is possible, the
function parameters take elements from the list (or things computed
from those) in the order in which they occur in the original list.

If we reimplement it in the obvious way:
ghci> let nubBy f [] = []; nubBy f (x:xs) = x : filter (not . f x) (nubBy f xs)
ghci> nubBy (>=) [1,2,3,4]
[1,2,3,4]

I'm aware that the Report (strangely!) explicitly leaves the behaviour
of nubBy unspecified for functions which are not equivalence
relations, but the behaviour given by the Report implementation (the
opposite of the current behaviour in GHC) is useful and desirable
nonetheless.

I'm sure I've written about this before. I'm not entirely sure what
happened to the previous thread of discussion about this, b

Proposal: fix "simple pattern binding" and "declaration group"

2011-06-26T18:57:01

The Haskell 2010 report contains ambiguous and sometimes contradictory
definitions of the terms "simple pattern binding" and "declaration
group". The confusion is compounded by the phrasing of the
monomorphism restriction, which is carried over from the Haskell98
report in which a different definition of declaration group required a
more complicated description of the monomorphism restriction.

A recent thread on the haskell cafe mailing list summarizes the
problem:

http://www.haskell.org/pipermail/haskell-cafe/2011-June/093488.html

To resolve this confusion, I propose applying the following changes to
the Haskell 2010 report for the next revision of the language:

In section "4.4.3.2 Pattern bindings", replace:

-A pattern binding binds variables to values. A simple pattern
-binding has form p = e. The pattern p is matched “lazily” as
-an irrefutable pattern, as if there were an implicit ~ in
-front of it. See the translation in Section 3.12.

With the following:

A pattern binding binds variab

TypeFamilies vs. FunctionalDependencies & type-level recursion

2011-06-15T02:52:00

Dan Doel wrote:

The instance 'C a b' blatantly violates functional dependency and
should not have been accepted. The fact that it was is a known bug in
GHC. The bug keeps getting mentioned on Haskell mailing lists
about every year. Alas, it is still not fixed. Here is one of the
earlier messages about it:

  http://www.haskell.org/pipermail/haskell-cafe/2007-March/023916.html

HList does NOT depend on that invalid behavior. The bug is relatively
recent (introduced around 2006); HList worked in 2004.

TypeFamilies vs. FunctionalDependencies & type-level recursion

David Mazieres — 2011-05-29T18:59:44

I'm not sure if these extensions are still under discussion or if the
topic is dead (wiki pages 5 years old).  However, the Haskell' wiki
page for FunctionalDependencies suggests AssociatedTypes is a more
promising approach, yet the AssociatedTypes page misses a major Con
compared to FunctionalDependencies that I think should be there.

One of the more disgusting but also powerful implications of
FunctionalDependencies is that, in conjunction with
OverlappingInstances and UndecidableInstances, you can do recursive
programming at the type level.  This has been (ab)used to do some cool
things (e.g., HList, HaskellDB, OOHaskell).

As an example, consider the following simple (key, value) lookup
function that operates at the type level (inspired by HList):

{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE OverlappingInstances #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE UndecidableInstances #-}

data HNil = HNil deriving (Show)
data HCons h t = h :* t deri

Proposal: Make gcd total

Daniel Fischer — 2011-05-09T22:49:14

I would like to propose the elimination of the special error case

gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined"

to replace it with

gcd 0 0 = 0

(which would be an automatic consequence of removing the above line).

Rationale:

1. It makes gcd a total function.
2. It makes gcd associative.
3. It makes folding gcd over a list safe.
4. It conforms to common mathematical practice:

In a commutative ring, a greatest common divisor of two elements a, b is
a common divisor g of a and b such that every common divisor d of a and b
also divides g (if R is a commutative ring, a \in R, d \in R is a divisor
of a iff there exists c \in R with a = d*c [leaving out noncommutative
rings for simplicity]).
Since every ring element divides 0, the above definition entails
gcd 0 0 = 0.

Further, in a principal ideal ring, the greatest common divisors of two
elements a and b are the generators of the ideal (a,b), again that
characterisation of greatest common divisors says gcd 0 0 = 0:
(0,0) = {0} = (0).

Pros: see above.

TypeSynonymInstances should be enabled by default

Andrew Pennebaker — 2011-04-20T19:38:38

Source: https://github.com/mcandre/genetics

With {-# LANGUAGE TypeSynonymInstances #-} , my genetic algorithm code
compiles and runs perfectly.

$ make
$ ./helloga
...
hellowobld
helloworyd
helloporld
hellyworld
helloworrd
hellowofld
hellpworld
Best candidate: helloworld

Without it, Haskell refuses to declare an instance on Strings.

$ make
ghc --make -O2 -fforce-recomp helloga.hs
[1 of 2] Compiling Genetics ( Genetics.hs, Genetics.o )
[2 of 2] Compiling Main ( helloga.hs, helloga.o )

helloga.hs:27:10:
     Illegal instance declaration for `Gene String'
       (All instance types must be of the form (T t1 ... tn)
       where T is not a synonym.
       Use -XTypeSynonymInstances if you want to disable this.)
     In the instance declaration for `Gene String'
make: *** [all] Error 1

The fix is easy to discover and apply, but this is my first typeclass,
nothing complicated. As a newbie I prefer that it "just works" without my
having to use the special compile flag.

Cheers,

Andrew Pennebaker
www.yellosoft

minor bug in Haskell 2010 standard

Peter Klausler — 2011-04-14T22:09:26

A brief correction to a problem that may have already been noticed and
rectified:
on page 84 (being page 104 of the PDF), in the last sentence of section
6.4.3, it reads:
"0**y is 1 if y is 1, and 0 otherwise."

Surely this should read "0**y is 1 if y is 0, and 0 otherwise", yes?

Best regards,
Peter Klausler at Google in Madison
_______________________________________________
Haskell-prime mailing list
Haskell-prime-HC+Z4NTRIlBAfugRpC6u6w< at >public.gmane.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Proposal: add ghc -fwarn-non-ascii warning flag

Christian Maeder — 2011-04-07T10:32:06

similar in spirit to the -fwarn-tabs warning.

C.

P.S. In the mean time you may use 
http://projects.haskell.org/style-scanner/ (Caveat, it crashes on latin1 
files when compiled with ghc-6.12 or greater.)

[Colin Paul Adams] Re: Proposal: Define UTF-8 to be the encoding ofHaskell source files

Colin Paul Adams — 2011-04-06T15:34:13

I forgot to CC the list:


    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 can be reliably exchanged
    Roel> on the byte level.  - Disallows implicit ISO-8859-* encodings
    Roel> in source code, ensuring portability.  - Little or no
    Roel> implementation burden for compiler writers.

Having thought this over a bit more, I don't think it's a good idea.

Allowed? Allowed for what?

What does it achieve? Nothing, as far as I can see. Authors will still
be able to write their Haskell code in any encoding they like. And any
compiler can have a front-end script with an option to specify the
encoding used by source files, which simply uses iconv on the fly to
translate. 

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

Proposal: Define UTF-8 to be the encoding of Haskell source files

Roel van Dijk — 2011-04-04T22:48:25

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
exchange Haskell source files on the byte level.

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].


* Pros
- Ensures that Haskell source can be reliably exchanged on the byte
  level.
- Disallows implicit ISO-8859-* encodings in source code, ensuring
  portability.
- Little or no implementation burden for compiler writers.


* Cons

- Existing code relying on a non-UTF8, locale-/implementation-specific
  encoding will need conversion. (Only relevant for Hugs-only code).


* Implementation status

** GHC
"GHC assumes that source files are ASCII or UTF-8 only, other
encodings are not recognised. However, invalid

Thoughts on unsafeLocalState

Dan Knapp — 2011-02-19T23:10:03

Hi,

First off, this is my first time posting to this list.  I hope my post is
appropriate!

I noticed in going through the API docs that we now have unsafeLocalState in
Foreign.Marshal, which currently is defined as equivalent to
unsafePerformIO, but with a note that it "is likely to be replaced".  I did
look through the archives of this list, but found no discussion of it.  The
description of it in the API docs is simply:

Sometimes an external entity is a pure function, except that it passes
arguments and/or results via pointers. The function unsafeLocalState permits
the packaging of such entities as pure functions.
The only IO operations allowed in the IO action passed to unsafeLocalState
are (a) local allocation (alloca, allocaBytes and derived operations such as
withArray and withCString), and (b) pointer operations (Foreign.Storable and
Foreign.Ptr) on the pointers to local storage, and (c) foreign functions
whose only observable effect is to read and/or write the locally allocated
memory. Passing an

specify call-by-need

Scott Turner — 2011-02-16T01:53:59

In practice, Haskell a call-by-need language.  Still, software
developers are not on firm ground when they run into trouble with
evaluation order, because the language definition leaves this open. Is
this an underspecification that should be fixed?

  1. Haskell programmers learn the pitfalls of sharing as soon
     as they cut their teeth on 'fib',
  2. Virtually all significant-sized Haskell programs rely on
     lazy evaluation and have never been tested with another
     evaluation strategy,
  3. Questions come up on Haskell-Café, infrequently but regularly,
     regarding whether a compiler optimization has altered sharing
     of values within a program, causing it to fail,
  4. The rationale for the monomorphism restriction assumes
     lazy evaluation,
  5. It is the effect on asymptotic behavior that matters,
  6. Portable Haskell code should not have to allow for the
     variety of non-strict evaluation strategies, as the Haskell
     Report currently implies.

I suggest specifying call-by-need e