- Haskell-prime - Haskell.org

patch applied (haskell-prime-report): make it work with recent GHCs
by Simon Marlow 07 Nov '06

07 Nov '06

Tue Nov 7 08:10:45 PST 2006 Simon Marlow <simonmar(a)microsoft.com> * make it work with recent GHCs M ./tools/Makefile -3 +2

1 0

Re[2]: [Haskell-cafe] Fractional/negative fixity?
by Bulat Ziganshin 07 Nov '06

07 Nov '06

Hello Henning, Monday, November 6, 2006, 1:27:54 PM, you wrote: >> print msg `on` mode==debug >> >> but failed because my code frequently contains '$' and there is no way >> to define operation with a lower precedence > This could be solved by the solutions proposed in this thread: > > http://www.haskell.org/pipermail/haskell-cafe/2006-October/018923.html it's too complex for my purposes. -1 priority is enough -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 2

Importing and Exporting Instance Declarations
by Bas van Dijk 04 Nov '06

04 Nov '06

Hello, Can anybody explain or point me to previous discussions about why it isn't allowed to import and export instance declarations? See: section 5.4 of http://haskell.org/onlinereport/modules.html I don't want to propose this for Haskell' (yet) because I think there has to be some very good reasons why this seemingly very obvious feature is missing. regards, Bas van Dijk

2 1

Re: Proposal for stand-alone deriving declarations?
by John Hughes 03 Nov '06

03 Nov '06

What I implemented in GHC is an extension of the proposal below. The proposal just mentions: deriving Class for Type In GHC I also added a form for newtype deriving of multi-parameter type classes: deriving (Class t1 ... tn) for Type I think that it's close to what we ended up with when talking about it at the Hackathon. My intuition about this syntax is that except for the "for Type" part, it looks the same as a normal deriving clause. The "for" part is just there to connect it to a data/newtype declaration. This lets it pretty much use the normal code for deriving declarations. Stand-alone deriving declarations are currently a little bit weaker than normal deriving clauses, since the current implementation does not let you reference the type arguments of a newtype in the arguments of an MPTC. See my response to Bulat on cvs-ghc(a)haskell.org for more details. /Björn > > > A suggestion re syntax: With the newtype-deriving extension, the instances named in a deriving clause are not just class names, but partial applications of class names to all but the last argument. Why all but the last one? Because the last one is the type being defined. Once deriving clauses are separated from type definitions, then there is no type being defined any more--hence the need for "for Type" in your syntax, and the introduction of another keyword. But why single out one class parameter, once deriving clauses are separated from type definitions? Why not simply write the FULL application of the class in the deriving list? Thus: deriving (Eq Foo, Ord Foo) instead of deriving (Eq, Ord) for Foo I find the former syntax clearer and more readable, actually. John

10 20

Re[2]: [Hugs-users] Record puns, time for removal?
by Bulat Ziganshin 01 Nov '06

01 Nov '06

Hello Simon, Monday, October 30, 2006, 3:11:23 PM, you wrote: > I always thought it was a mistake to remove record puns in H98. I would > not be against re-introducing them into GHC, since they appear to remain > in Hugs and are in Yhc. what you (and all) think about wildcarded puns: data Command = Command { cmd_name :: !String , cmd_arcspec :: String , cmd_arclist :: [FilePath] , cmd_arcname :: FilePath , cmd_arc_filter :: !(FileInfo -> Bool) , cmd_filespecs :: ![String] , cmd_added_arcnames :: !(IO [FilePath]) , cmd_diskfiles :: !(IO [FileInfo]) , cmd_subcommand :: !Bool .... } process_cmd (Command{*}) = do print cmd_name ... because Haskell encourage using of structure name as part of field's name, this will not create mess (at least for my programs), it will work like Pascal's 'with' operator -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 3

Indentation of If-Then-Else
by Henning Thielemann 30 Oct '06

30 Oct '06

I object strongly to the proposal http://hackage.haskell.org/trac/haskell-prime/wiki/DoAndIfThenElse because it solves problems with syntactic sugar with even more sugar, where no sugar is needed at all. In order to solve the trouble I propose enhancements to teachers, compilers and standard libraries: 1. 'if' syntax should be teached as if a then b else c This indentation makes pretty clear, what is condition, and what is the result in both cases. It just resembles case a of True -> b False -> c . 2. Add 'if :: Bool -> a -> a -> a' or '(?) :: Bool -> (a,a) -> a' or both to the standard library, as discussed in the thread starting with http://www.haskell.org/pipermail/haskell-cafe/2006-July/016914.html 3. If a compiler suspects that a parsing problem is related to 'do' and 'if' it should suggest indentation if a then b else c or even better, the usage of if- or (?)-function. So, please add this to the 'Cons' list.

18 38

Proposal for stand-alone deriving declarations?
by Bjorn Bringert 30 Oct '06

30 Oct '06

On http://hackage.haskell.org/trac/haskell-prime/wiki/ DerivedInstances it says: "- There is no way to derive an instance of a class for a data type that is defined elsewhere (in another module)." Though there is no proposal to fix this. Would such a proposal be appropriate for Haskell'? If so, I propose to add a top-level declaration on the form: 'deriving' qtycls 'for' qtycon which produces the same instance as a deriving clause in the declaration of the datatype or newtype would. I have recently (thanks to the GHC Hackathon) implemented this in GHC. /Björn

9 16

Re: seq vs. pseq
by Malcolm Wallace 27 Oct '06

27 Oct '06

Simon Marlow <simonmarhaskell(a)gmail.com> wrote: > The difference is subtle. The semantics of seq and pseq are > identical; however, GHC can see that seq is strict in both its > arguments and hence could choose to evaluate them in either order, > whereas pseq is only strict in its first argument as far as the > strictness analyser is concerned. The point is that pseq is useful > for controlling evaluation order, which is what you want for adding > parallelism to a program. seq, on the other hand, is not useful for > controlling evaluation order. This is a rather weird thing, and I would consider it a bug in the Haskell Report, rather than a bug in ghc. (It bites hard when you are trying to implement something like HPC.) The very name 'seq' surely suggests that you are controlling the evaluation order. "Please evaluate this thing on the left first". But that is _not_ what the Haskell Report says! Ghc takes the Report literally, and so the thing on the right is just as likely to be evaluated before the thing on the left! Surely the language designers did not intend this consequence. For Haskell-prime, can we fix this bug, and ensure that 'seq' really implies ordering of evaluation? [ If you just want strictness annotations, with the compiler free to reorder computations, I would say ($!) is a better bet, and could be redefined to use not the natural `seq`, but the strict-in-both-arguments variation. ] Regards, Malcolm

1 0

Re: Indentation of If-Then-Else
by Neil Mitchell 25 Oct '06

25 Oct '06

> > Actually if-then-else isn't used that often today. Most programmers > > gave it up in favor of guards. > > I question both these statements. Can you cite some evidence here? I have 501 if statements in my current project. Yhc has 626. Hoogle has 101. If's seem pretty well used to me! Thanks Neil

5 5

Module imports anywhere
by Henning Thielemann 24 Oct '06

24 Oct '06

I don't see the benefit of allowing imports anywhere at top-level. http://hackage.haskell.org/trac/haskell-prime/wiki/AllowImportAnywhere As with declarations I expect that imported identifiers are visible everywhere in a module. Thus the search for an imported identifier becomes even more complicated as it is today (due to anonymously imported identifiers and re-exported modules). Sometimes I missed a feature from the Modula-2 derivative named "Cluster", namely local imports of modules. Locally imported identifiers would be invisible to other functions. However I don't think that it is so important to be worth the trouble of implementing it.

4 4