- Haskell-prime - Haskell.org

On the Meaning of Haskell 3
by John D. Earle 28 Nov '09

28 Nov '09

I believe Simon got right what he got right, but nothing more. Haskell is an experimental language that is taking off prematurely. In my opinion it needs to be taken back to the drawing boards and overhauled before it is too late. It may already be too late unfortunately. We may have to live with whatever mistakes that were made for the next 100 years. Sometimes success is not a good thing. Haskell can easily become yet another defective language. Backward compatibility will likely need to be thrown out the door if Haskell is to ever stand for the "truth". Greater rigor in getting it right is needed.

2 1

Re: DoAndIfThenElse
by Christian Maeder 27 Nov '09

27 Nov '09

S. Doaitse Swierstra schrieb: [..] >> \begin{code} >> main = do >> if True then putStrLn "1"; >> else putStrLn "2" >> \end{code} >> >> This does also not work with hugs (";" at the end) > > This does not work since now you have two ";"'s; one because you wrote > one and one because you did not indent the else. Allowing this > additional ; was done to prevent confusion, and as you can see even more > confusion pops up now;-{{ That is why I expressed my concerns about this > grammar patch. > > Doaitse Indeed, these semicolons are confusing. I think it should be possible to allow "then" and "else" starting in the same column as "if" without these ";"s (in a do block). Christian

3 3

DoAndIfThenElse
by Christian Maeder 26 Nov '09

26 Nov '09

Hi, seeing Haskell 2010 and http://hackage.haskell.org/trac/haskell-prime/wiki/DoAndIfThenElse saying: Compiler support ¶ GHC full (no flag) I wonder why I still get a "parse error (possibly incorrect indentation)" for: \begin{code} main = do if True then putStrLn "1" else putStrLn "2" \end{code} Can I try out this feature somehow? Cheers Christian

3 5

On support of C99 complex numbers
by Maurício CA 23 Oct '09

23 Oct '09

Hi, I would like to make a formal request for inclusion of complex numbers in Foreign.C.Types. Which steps should I follow? Here is a start on what I would write in such request. ----- Motivation: As complex is available in C, libraries can pass then by value in function calls, making it difficult to directly wrap such functions in Haskell. GNU GSL, for instance, even if actually using C < 99, does that with a struct type that is supposed to be binary equivalent to C99 double complex. Syntax: My sugestion is to add these: CFComplex --> for 'float complex' CDComplex --> for 'double complex' CLDComplex --> for 'long double complex' I believe this is better than trying to use a kind *->* type, as that would bring little help when actually wrapping C functions. Also, I think it's not important to have field names for real and imaginary, as long as we have an easy convertion for Data.Complex. Also, if we want to take imaginary and real parts in "pure C" Haskell code, we can use available C functions like cimag, creal, cimagf, crealf etc. ----- Thanks for your attention, Maurício

1 0

Unsafe hGetContents
by oleg＠okmij.org 20 Oct '09

20 Oct '09

Simon Marlow wrote: > Ah yes, if you have two lazy input streams both referring to the same > underlying stream, that is enough to demonstrate a problem. As for > whether Oleg's example is within the rules, it depends whether you > consider fdToHandle as "unsafe" I wasn't aware of the rules. Fortunately, UNIX (FreeBSD and Linux) give plenty of opportunities to shoot oneself. Here is the code from the earlier message without the offending fdToHandle: > {- Haskell98! -} > > module Main where > > import System.IO > > -- f1 and f2 are both pure functions, with the pure type. > -- Both compute the result of the subtraction e1 - e2. > -- The only difference between them is the sequence of > -- evaluating their arguments, e1 `seq` e2 vs. e2 `seq` e1 > -- For really pure functions, that difference should not be observable > > f1, f2:: Int ->Int ->Int > > f1 e1 e2 = e1 `seq` e2 `seq` e1 - e2 > f2 e1 e2 = e2 `seq` e1 `seq` e1 - e2 > > read_int s = read . head . words $ s > > main = do > let h1 = stdin > h2 <- openFile "/dev/stdin" ReadMode > s1 <- hGetContents h1 > s2 <- hGetContents h2 > -- print $ f1 (read_int s1) (read_int s2) > print $ f2 (read_int s1) (read_int s2) It exhibits the same behavior that was described in http://www.haskell.org/pipermail/haskell/2009-March/021064.html I think Windows may have something similar. > The reason it's hard is that to demonstrate a difference you have to get > the lazy I/O to commute with some other I/O, and GHC will never do that. The keyword here is GHC. I may well believe that GHC is able to divine programmer's true intent and so it always does the right thing. But writing in the language standard ``do what the version x.y.z of GHC does'' does not seem very appropriate, or helpful to other implementors. > Haskell's IO library is carefully designed to not run into this > problem on its own. It's normally not possible to get two Handles > with the same FD... Is this behavior is specified somewhere, or is this just an artifact of a particular GHC implementation?

6 9

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 05 Sep '09

05 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 01 Sep '09

01 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

Announcing the new Haskell Prime process, and Haskell 2010
by Simon Marlow 20 Aug '09

20 Aug '09

At last year's Haskell Symposium, it was announced that we would change the Haskell Prime process to make it less monolithic. Since then, everyone has been busy using Haskell (or implementing it), and we haven't made much progress on the standardisation side of things. Well, with ICFP and the Haskell Symposium approaching we felt it was time to get the new process moving and hopefully produce a language revision this year. I've updated the Haskell' wiki with the new information; in particular the process is documented here: http://hackage.haskell.org/trac/haskell-prime/wiki/Process We're aiming to announce the list of accepted proposals at the Haskell Symposium this year. However, owing to the short timescale, the list is going to be correspondingly short, and limited to extensions which are either already fully specified (i.e. the FFI) or are small and well-understood. The following list is very provisional; we'll be making the final decisions next month. ForeignFunctionInterface LineCommentSyntax PatternGuards DoAndIfThenElse Remove n+k patterns RelaxedDependencyAnalysis EmptyDataDeclarations HierarchicalModules NonDecreasingIndentation remove FixityResolution from the context-free grammar change the syntax of QualifiedOperators In the coming weeks we'll be refining proposals in preparation for Haskell 2010. By all means suggest more possibilities; however note that as per the new process, a proposal must be "complete" (i.e. in the form of an addendum) in order to be a candidate for acceptance. I have updated the status page http://hackage.haskell.org/trac/haskell-prime/wiki/Status marking everything except the proposals that have been already implemented in the draft Report as "old". The new process requires a proposal to have an owner or owners in order to make progress; once a proposal has an owner it will move into the "under discussion" state. To take up ownership of an existing proposal, or to start a new proposal, ask on the mailing list. There are other ways you can get involved; some suggestions are on the Haskell' main page: http://hackage.haskell.org/trac/haskell-prime/wiki (hmm, I suppose we should fix that logo too...) Cheers, Simon

16 35