September 2009 - Haskell-prime

Unsafe hGetContents
by Florian Weimer 23 Jan '10

23 Jan '10

Are there any plans to get rid of hGetContents and the semi-closed handle state for Haskell Prime? (I call hGetContents unsafe because it adds side effects to pattern matching, stricly speaking invalidating most of the transformations which are expected to be valid in a pure language.)

5 15

Strongly Specify Alignment for FFI Allocation
by Thomas DuBuisson 30 Sep '09

30 Sep '09

Aside from section 5.7 (storable) and comments on 'alignPtr', the only mention of alignment in the FFI addendum is on mallocBytes/allocaBytes: "The block of memory is sufficiently aligned for any of the basic foreign types (see Section 3.2) that fits into a memory block of the allocated size" It would be beneficial if this wording was applied to all allocation routines - such as mallocForeignPtrBytes, mallocForeignPtrArray, etc. For the curious, this proposal was born from the real-world issue of pulling Word32's from a ByteString in an efficient but portable manner (binary is portable but inefficient, a straight forward unsafePerformIO/peek is efficient but need alignment). If no glaring issue comes up then I'll formalize / make a ticket, Thomas

7 8

Standarize GHC.Prim.Any
by Maciej Piechotka 06 Sep '09

06 Sep '09

I'm so sorry if I've done it wrong - it's my first contact with Haskell standardization and I base on http://hackage.haskell.org/trac/haskell-prime/wiki/Process . I hope it is not too late as well. Any from GHC.Prim makes unsafeCoerce much useful and safe. Can it be included in Unsafe.Coerce module? Pros: - unsafeCoerce is much more useful with Any (it's a safe placeholder for any value and therefore can be passed simply in/out FFI). Cons: - unsafeCoerce is useful, but not very nice, platorm-dependent low-level anyway. Best regards

4 7

Allowing safe cast by default
by Maciej Piechotka 06 Sep '09

06 Sep '09

As far as I underspend all checks of Data.Typeable.cast can be done by compiler in compile-time. While it impose partially what one may consider syntax sugar I believe that there is no restriction that would not allowed compiler to behave like that: cast :: forall a b. a -> Maybe b -- Pseudo-haskell cast x = staticIf a == b then Just x else Nothing [1] Also I may not grasp every element of Haskell but what is the reason of not implementing Typeable by default? Regards [1] You may say that I need unsafeCoerce but 1. I'd prefere to write let x = fromMaybe (error "Wrong types") $ cast x' :: a instead of let x = unsafeCoerce x' :: a in case when I (not compiler) know that x and x' have the same type (a) as it makes the crash big and in Haskell instead of possible some problems with GC or something which I'll find in totally unrelated piece of program. 2. I may want different actions

1 0

bug in language definition (strictness)
by Malcolm Wallace 02 Sep '09

02 Sep '09

It has been brought to my attention (as errata editor of the revised H'98 report) that there is a bug in the language definition, concerning strictness annotations on datatypes. In section 4.2.1, the translation of strict components of a data constructor is defined as > (\ x1 ... xn -> ( ((K op1 x1) op2 x2) ... ) opn xn) > > where opi is the non-strict apply function $ if si is of the form > ti, and opi is the strict apply function $! (see Section 6.2) if si > is of the form ! ti. Pattern matching on K is not affected by > strictness flags. > yet, because of the definition of $!, this applies the constructor to its arguments right-to-left instead of the intuitive left-to-right. All extant compilers in fact evaluate the strict fields left-to-right in violation of the Report. The same non-intuitive behaviour can be seen more clearly in the simple expression: (f $! x) $! y in which you might expect x to be evaluated before y, but in fact it is the other way round. (And here, the compilers do follow the Report.) The fix I propose for H'98 (and equally for Haskell Prime) is to change the definition of $! as follows Replace f $! x = x `seq` f x with f $! x = f `seq` x `seq` f x in section 6.2 Regards, Malcolm

13 25