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
http://hackage.haskell.org/trac/haskell-prime/wiki/ExistingRecords

    John

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 that
this break is done deliberately.

Am I missing something?

I witness this for the first time: that GHC deliberately breaks the current 
Haskell standard.
Probably, many people (as myself) dislike this point of the standard.
Well, they can write a dummy Show implementation for their type T:
      showsPrec _ _ = showString "(<t> :: T)",

and wait for an improved standard, say, Haskell-II

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, but it just
came up again for me, and I decided that I was sufficiently irritated
by it to post again.

Another thing perhaps worth pointing out is that the parameters to
mapAccumR have always been backwards (compare it with foldr). Few
enough people use this function that I'm fairly sure we could just
change it without harm.

 - Cale

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 variables to values.  A /simple/
pattern binding is one in which the pattern consists of a
single variable, yielding a declaration of the form /var/
/rhs/.  Recall from section 3.17 that such a pattern is always
irrefutable.

In section 4.5.1, replace this text:

-A binding b1 depends on a binding b2 in the same list of
-declarations if either
-
-1. b1 contains a free identifier that has no type signature
-   and is bound by b2, or

with the following:

A binding b1 depends on a binding b2 in the same list of
declarations if either

1. b1 contains a free identifier v, v is bound by b2, and the
   list of declarations does not contain a type signature for
   v; or

Add the following text to the end of section 4.5.1:

For example, the following two bindings form a single
declaration group, as each contains a free identifier bound by
the other and, despite the presence of expression
type-signatures, the declaration list contains no type
signatures:

(x, y) = (z :: Int, 1 :: Int)  -- binds y, has z free
(z, t) = (2 :: Int, y :: Int)  -- binds z, has y free

Conversely, the following two bindings constitute two
different declaration groups.  Even though f and g contain
each other as free identifiers, the declaration list contains
a type signature for f, so g does not depend on f.

f :: (Eq a) => (a, a) -> (Bool, a)
f = \(x, y) -> (x == y, snd (g (x, y)))
g pair = (fst (f pair), snd pair)

Note that if b is a function binding or simple pattern binding
and b is accompanied by a type signature, then b always
constitutes a /singleton/ declaration group, regardless of
what free identifiers it contains.  (If b is a non-simple
pattern binding, it may bind multiple variables
simultaneously.)

Finally, change Rule 1 of the monomorphism restriction in section
4.5.5, by replacing the following text:

-We say that a given declaration group is unrestricted if and
-only if:
-
-(a): every variable in the group is bound by a function
-     binding or a simple pattern binding (Section 4.4.3.2),
-     and
-
-(b): an explicit type signature is given for every variable in
-     the group that is bound by simple pattern binding.

with the following:

We say that a given declaration group is unrestricted if and
only if:

(a): every variable in the group is bound by a function
     binding, or

(b): the group consists of exactly one binding, the binding is
     a simple pattern binding of some variable v, and the
     binding's declaration list contains an explicit type
     signature for v.

If there is agreement on these changes or something along these lines,
I can create a ticket and/or wiki page.  I propose the name
SimplePatternBinding for the change.

David

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

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 deriving (Show)
infixr 2 :*

data A = A deriving (Show)
data B = B deriving (Show)
data C = C deriving (Show)

abc :: HCons (A, Int) (HCons (B, Int) (HCons (C, Int) HNil))
abc = (A, 1) :* (B, 2) :* (C, 3) :* HNil

class HLookup k l v | k l -> v where
    hLookup :: k -> l -> v
instance HLookup k (HCons (k, v) l) v where
    hLookup _ (h :* t) = snd h
instance (HLookup k l v) => HLookup k (HCons h l) v where
    hLookup k (h :* t) = hLookup k t

b :: Int
b = hLookup B abc               -- Returns 2

The key to hLookup is that OverlappingInstances selects the most
specific match, thereby breaking the recursion when the requested key
type matches the key of the pair at the head of the list.  By
contrast, TypeFamilies cannot permit a function such as hLookup.  One
may try something along the lines of:

class HLookup k l where
    type HLookupResult k l
    hLookup :: k -> l -> HLookupResult k l
instance HLookup k (HCons (k, v) l) where
    type HLookupResult k (HCons (k, v) l) = v
    hLookup _ (h :* t) = snd h
instance (HLookup k l) => HLookup k (HCons h l) where
    type HLookupResult k (HCons h t) = HLookupResult k t
    hLookup k (h :* t) = hLookup k t

But now you have overlapping type synonyms, which pose a safety threat
where the more-specific instance is not in scope.  Therefore, Haskell
likely cannot be extended to accept code such as the above.

One possible extension that *would* enable type-level recursive
programming is the ability to constrain by inequality of types.  I
noticed GHC is on its way to accepting "a ~ b" as a constraint that
types a and b are equal.  If there were a corresponding "a /~ b", then
one might be able to say something like:

instance HLookup k (HCons (k, v) l) where
  ...
instance (h /~ (k, v), HLookup k l) => HLookup k (HCons h l) where
  ...

Of course, I have no idea how the compiler could know such constraints
are sufficient to avoid overlapping types.  I suspect figuring it out
would be hard given that instance matching happens before context
verification and that the overlapping errors must happen at instance
matching time.

My bigger point is that if the Haskell' committee ever considers
adopting one of these proposals or one intended to supersede them, I
hope there is a way to do recursive type-level programming.  A likely
corollary is the need for a mechanism to avoid instance overlap
between recursive and base cases by asserting type inequality in the
recursive case.

David

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.

Cons: ?
I'm not aware of any, the change shouldn't break existing code, since that
would have to check for the special case anyway.

Daniel

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.us
_______________________________________________
Haskell-prime mailing list
Haskell-prime-HC+Z4NTRIlBAfugRpC6u6w< at >public.gmane.org
http://www.haskell.org/mailman/listinfo/haskell-prime

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 file, but I don't think this has much merit).

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 UTF-8 sequences will be
ignored in comments, so it is possible to use other encodings such as
Latin-1, as long as the non-comment source code is ASCII only." [4]

From this I deduce that all current code accepted by GHC is compatible
with UTF-8. No working code will be broken.

** JHC
"JHC allows unrestricted use of the Unicode character set in Haskell
source, treating input as UTF-8." [5]

** Hugs
Hugs treats input as being in the encoding specified by the current
locale, but permits Unicode only in comments and character and string
literals. [6]

* Related proposal

There is one, 5 year old, proposal that is related:
"SourceEncodingDetection" [5]. There it is proposed to detect the
encoding using an algorithm which can distinguish between UTF-8,
UTF-16 and (not always) UTF-32. It can also detect the endianness of
the document, if applicable.

I think choosing just UTF-8 is a better choice than a detection
algorithm. It places less burden on implementation writers and is even
more portable.

* Next step

Discussion! There was already some discussion on the haskell-cafe
mailing list [7].

Attached is a patch for the Haskell Report which adds a note stating
that source encodings must be UTF-8.

Regards,
Roel van Dijk

[1] - http://hackage.haskell.org/trac/haskell-prime/wiki/Process
[2] - http://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-150002.1
[3] - http://www.unicode.org/faq/utf_bom.html#bom5
[4] - http://www.haskell.org/ghc/docs/7.0-latest/html/users_guide/separate-compilation.html#source-files
[5] - http://hackage.haskell.org/trac/haskell-prime/wiki/SourceEncodingDetection
[6] - http://cvs.haskell.org/Hugs/pages/users_guide/locale.html
[7] - http://article.gmane.org/gmane.comp.lang.haskell.cafe/87815
_______________________________________________
Haskell-prime mailing list
Haskell-prime-HC+Z4NTRIlBAfugRpC6u6w< at >public.gmane.org
http://www.haskell.org/mailman/listinfo/haskell-prime

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 IO operation that does not obey these rules results in
undefined behaviour.
It is expected that this operation will be replaced in a future revision of
Haskell


I found a more complete explanation at the bottom of:

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

(Scroll to "Considerations for the future".)

The notion seems to be that we would create a new monad that only allows
specific actions to be taken.

This is great as far as it goes.  I very much support the idea, and would
switch my code to use it if it were developed.  However, I think the
restrictions as given in the text I quoted above are too tight.  Ideally we
want something that would be suitable for libraries such as ByteString,
which I believe wraps the allocation of data on the foreign heap in pure
functions.  This would not be allowed by unsafeLocalState in the form given,
because the only pointer operations allowed by clause (b) are those on
memory that is allocated in temporary fashion as by clause (a).  I'm not
sure quite how to word this, but I think perhaps broadening clause (a) to
also allow allocation of ForeignPtrs, effectively changing the restriction
from "anything you allocate must be freed by the time you return" to
"anything you allocate must be known to the garbage collector".

I have a practical use for this; I am working on a binding to libffi,
pursuant to developing a better ObjC/Cocoa binding.  To use libffi, it is
necessary to build complicated structs.  So I have the definition type
ComplicatedStruct = ForeignPtr (), and a function, currently wrapped in
unsafePerformIO, which constructs a new complicated struct given a
description of what it should contain.  This is, in my understanding, a
"safe" usage of unsafePerformIO, but really it would be nice to use
something safer.

So I don't know that I have an action item, I just wanted to make sure that
if and when future development on this happens, it takes this concern into
account.  Um, thanks for reading?

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 evaluation, allowing for the places
where type classes prevent this.  If necessary, make it clear that local
optimizations not affecting asymptotic behavior are permitted.

This would not eliminate struggles with evaluation order. The intent
would be to clarify expectations.