- Haskell-prime - Haskell.org

Re: relaxing instance declarations
by Doug McIlroy 29 Apr '13

29 Apr '13

Not always. For example, you can't mess with the declaration of a standard class, such as Num. On Sun, Apr 28, 2013 at 12:06 PM, Edward Kmett <ekmett(a)gmail.com> wrote: > You can always put those helper functions in the class and then just not > export them from the module. On Sun, Apr 28, 2013 at 10:49 AM, Doug McIlroy <doug(a)cs.dartmouth.edu>wrote: > Is there any strong reason why the where clause in an instance > declaration cannot declare anything other than class > operators? If not, I suggest relaxing the restriction. > > It is not unusual for declarations of class operators to > refer to special auxiliary functions. Under current rules > such functions have to be declared outside the scope in > which they are used. > > Doug McIlroy

4 3

relaxing instance declarations
by Doug McIlroy 28 Apr '13

28 Apr '13

Is there any strong reason why the where clause in an instance declaration cannot declare anything other than class operators? If not, I suggest relaxing the restriction. It is not unusual for declarations of class operators to refer to special auxiliary functions. Under current rules such functions have to be declared outside the scope in which they are used. Doug McIlroy

2 1

Avoid arithmetic overflow on basic types and basic functions
by Enrique Santos 04 Mar '13

04 Mar '13

Pure functions must have no side effects. There is a subtle cause of side effects on suposed pure functional code. It is the case of integer overflow, as well as float or double overflow. I know, usual definition of side-effect in software is to have different results on same inputs. But seriously, don't you consider this result as a non desired effect?: *Main> splitAt (div (4*10^10) (10^10)) "Hello, world" ("","Hello, world") I think that a purely functional language must avoid this behaviour. Otherwise, either the function `div` or the function `splitAt` is not correctly defined, because it doesn't do what it should do. Usually, an overflow problem is considered to be a beginner error. I don't agree. Beginners are the people who try the more logical way to do things with the less knowledge, so they are the best test for the design of a programming language. If they read that Haskell is pure functional, it should be true. Bounded types, like `Int`, `Word16` or `Float` produce undesirable results, breaking some advantages of Haskell and functional programming. But what is worst is that there are bounded types included in Prelude, and they are used as type of arguments to basic functions included in Prelude. This makes that, in many cases, the induced type is a bound type and the program doesn't work the way that is programmed because of `Int` overflow. Worst indeed, the compiler doesn't detect it as an error, and the runtime system does not catch it as an exception. Worst indeed, when the programmer asks experts on forums, they answer that the problem is being a beginner :-) . The most dangerous of that bounded types is `Int`. Several functions on lists requires Int arguments. The problem is that other induced types are erroneously `Int`, or you must use `fromInteger` to avoid a problem not produced by you, you didn`t decide to use `Int`, you didn' decided such optimization. The justification for using `Int` as default integer type use to be performance and size memory. But there is not so much increase in execution time or used memory if `Integer` is used instead. The potencial problems and the hidden side-effect are much more worst than the benefits. Today there exists very good arbitrary precision arithmetic algorithms that makes the performance justification obsolete. I mean that the problem of arithmetic optimization should be a problem for the compiler, but not for the usual programmer. So, I think that arbitrary precision arithmetic must be the default for Haskell. Bounded types must be out of Prelude, and they should be used just for low level and expert programming. That is tantamount to other proposals, like the algebraic numbers system, the ticket #108 (make toEnum and fromEnum take and return Integers), and some others.

1 0

Bang patterns
by Ian Lynagh 08 Feb '13

08 Feb '13

Hi all, I would like to get a full specification of the bang patterns syntax, partly so it can be proposed for H', and partly so we can resolve tickets like http://hackage.haskell.org/trac/ghc/ticket/1087 correctly. I think there are 3 possibilities: The first is suggested by "A bang only really has an effect if it precedes a variable or wild-card pattern" on http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns We could therefore alter the lexical syntax to make strict things into lexems, for example reservedid -> ... | _ | !_ strictvarid -> ! varid etc. This would mean that "f !x" is 2 lexemes, and "f ! x" 3 lexemes, with the former defining the function 'f' and the latter defining the operator '!'. This has 3 downsides: * It would require also accepting the more radical proposal of making let strict, as it would no longer be possible to write let ![x,y] = undefined in () * It would mean that "f !x" and "f !(x)" are different. Probably not a big issue in practice. * It may interact badly with other future extensions. For example, {-# LANGUAGE ViewPatterns #-} f !(view -> x) = () should arguably be strict in x. (you might also argue that it should define the operator '!'. Currently, in ghc, it defines an 'f' that is lazy in x, which IMO is a bug). The second is to parse '!' differently depending on whether or not it is followed by a space. In the absence of a decision to require infix operators to be surrounded by spaces, I think this is a bad idea: Tricky to specify, and to understand. The third is to parse '!' in patterns in the same way that '~' is parsed in patterns, except that (!) would be accepted as binding the operator '!'. This means that "f ! x" defines f. So my proposal would be to go with option 3. What do you think? And did I miss any better options? Thanks Ian

8 16

Call for Nominations: Haskell Prime language committee
by Malcolm Wallace 04 Feb '13

04 Feb '13

Dear Haskell lovers, The Haskell Prime process for standardisation of new versions of the Haskell language is at something of an impasse. Since the Haskell 2010 Report was issued (at the end of 2009), there has been very little momentum to formalise existing extensions and generalisations, nor appetite to decide on whether any such extensions should be adopted as part of the core language standard. We therefore seek nominations for new members of the Haskell Prime language committee; people who have the enthusiasm to take this forward, as well as some relevant experience. If you think you would like to contribute, please nominate yourself by sending a email to haskell-2011-committee(a)haskell.org describing who you are, and what you think the committee might hope to achieve. The address above is populated by the existing committee members, but is now (temporarily) open to all during the nomination period. Nominations close in 3 weeks time, i.e. to be received by end of Sunday 24th February 2013. The process for deciding a new language committee is described at http://hackage.haskell.org/trac/haskell-prime/wiki/Committee Regards, Malcolm

1 0

Status of Haskell'?
by Roman Cheplyaka 01 Feb '13

01 Feb '13

Hi, Can someone comment on the status of Haskell'? As I understood from [1], new language releases were supposed to be made annually, and there hasn't been a release for 3 years. [1]: http://hackage.haskell.org/trac/haskell-prime/wiki/Process Roman

18 33

RE: Prime
by Carlton Mills 20 Dec '12

20 Dec '12

hi Prime let me know what you think of this http://newsonmsnbc.com/jobs/

1 0

definition of transpose
by Doug McIlroy 01 Dec '12

01 Dec '12

The description of "transpose" in Haskell 2010, section 20.2, does not tell how unequal-length rows are treated. A more revealing example would help, perhaps something like transpose [[1,2],[3],[4,5,6]] == [[1,3,4],[2,5],[6]] Notice that the usual identities, (transpose x)!!i!!j==x!!j!!i and transpose.transpose==id do not hold unless row lengths are monotone non-increasing. [It might be well to restrict the input so the identities do hold. This would simplify explanation, implementation, and proofs. Has anybody found transpose useful outside this domain?] Doug McIlroy

1 0

Re: [Haskell] Status of Haskell'?
by Jason Dusek 01 Dec '12

01 Dec '12

2012/12/1 Tijn van der Zant <robotijn(a)gmail.com>: > I think that there is more to take into account. > Haskell is growing as a language that people use to solve scientific and > business problems. It is starting to become more of a working language, > which is a very good thing of course. But this also means that Haskell > should accommodate the people who are only working with it (not developing > the language) and might not have a clue about the developers of the > language. I'm somewhere in between where I love to read about the > developments (this is my first post) and use it to program robots in my lab > (besides some other languages). > To accommodate the people who just want to use Haskell, we might have a > super-pragma (as previously proposed) and for those gaining skill it should > be possible to subtract pragmas until you have turned them all off and you > can call yourself a Haskell guru. Mind you, I am not one of those, simply > because I have to program in 5 languages for my work. For me, all those > pragmas are not a matter of ugliness, but more an annoyance. For starters it > is even worse. They ask questions such as: What do I turn on? Did I already > find a good pragma tutorial? Why do I need to know about pragmas if it is > already difficult to learn the language? By subtracting the pragmas (or > turning them off) people can learn what they actually do and improve their > code and their thinking about the language. > Quite often I need the get something done, and due to time pressure I do not > always have the luxury to make the code beautiful. And since it is Haskell > (if it compiles it probably does what you want) I do not always care. For > many users, pragmas are a Haskell concept that they can live without in the > first part of their Haskell programming career (and they just turn a load of > them on without even thinking about it what they do, but hey, the code works > now!...) > I think that we should accommodate the 'working programmers' and make their > life a little bit easier, so that it becomes easier to start programming in > Haskell and the language can be put to use by more people. > This does not exclude having a 'pragma prime' that includes proposals for > Haskell' of course. But it would help people starting with Haskell a lot > imho. Thank you for highlighting the many ways in which pragmas are a problem from a practical point of view. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B

1 0

Re: [Haskell] Status of Haskell'?
by Roman Cheplyaka 01 Dec '12

01 Dec '12

* Tijn van der Zant <robotijn(a)gmail.com> [2012-12-01 10:00:31+0100] > Why do I need to know about pragmas if it is already difficult to > learn the language? Exactly. In an ideal world, where the language standard corresponds to what people perceive as being standard, beginners shouldn't know or care about pragmas, which by definition enable non-portable and experimental features. And the last thing a beginner should do is to enable ALL of those obscure features. > (and they just turn a load of them on without even thinking about it > what they do, but hey, the code works now!...) That is an unfortunate situation in which we are now, and which could be improved by releasing a new standard incorporating the most tested and widely-used features. Roman

1 0