Re: Ranges and the Enum class
On 2006-03-18, Jim Apple [EMAIL PROTECTED] wrote: On 3/18/06, Aaron Denney [EMAIL PROTECTED] wrote: Rational _could_ be added here by the diagonal representation, but probably sohuldn't. We could also add an actual enumeration of rationals, as in http://web.comlab.ox.ac.uk/oucl/work/jeremy.gibbons/publications/rationals.pdf It would be quite confusing to write, say, [1%2 .. 3%2] and get 2%1 and 1%3 in the middle! Right, hence my desire to make it a sequence, but not Enumerable, since it has quite a few different quasi-natural ways of doing so. -- Aaron Denney -- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Ranges and the Enum class
On 2006-03-18, Aaron Denney [EMAIL PROTECTED] wrote: class ArithmeticSequence a where stepFrom :: a - [a]-- [n..] stepFromBy:: a - a - [a] -- [n,n'..] stepFromTo:: a - a - [a] -- [n..m] stepFromByTo :: a - a - a - [a] -- [n,n'..m] Whoops, it was a big thinko to change Then to By here. These should be stepFromThenTo, etc. -- Aaron Denney -- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: the MPTC Dilemma (please solve)
Claus Reinke: however, the underlying problem is not limited to MPTCs, and FDs are not the only attempt to tackle the problem. so I agree with Isaac: getting a handle on this issue is imperative for Haskell', because it will be the only way forward when trying to standardize at least those of the many extensions that have been around longer than the previous standard Haskell 98. and if Haskell' fails to do this, it fails. Please keep things in perspective: (A) It's not as if every interesting program (or even the majority of interesting programs) use(s) MPTCs. (B) I don't think the time for which an extension has been around is particularly relevant. One of the big selling points of Haskell is that it's quite well defined, and hence, its semantics is fairly well understood and sane - sure, there are dark corners, but compared to other languages of the same size, we are in good shape. If we include half-baked features, we weaken the standard. In fact, it's quite worrying that FDs have been around for so long and still resisted a thorough understanding. Manuel ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: the MPTC Dilemma (please solve)
Isaac Jones: I'm forwarding an email that Martin Sulzmann asked me to post on his behalf. From: Martin Sulzmann [EMAIL PROTECTED] Subject: MPTC/FD dilemma - ATs (associated types) will pose the same challenges. That is, type inference relies on dynamic termination checks. Can you give an example? Manuel ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Re[2]: [Haskell-cafe] STUArray
Bulat Ziganshin: Hello Chris, Sunday, March 12, 2006, 2:05:09 PM, you wrote: CK Is GHC.PArr documented? it's perfectly documented in module sources itself :) you can also look at the ndpFlatten directory in ghc compiler's sources. i've successfully used them in my program, of course this makes program faster but only-GHC compatible. so i plan to document it on http://haskell.org/haskellwiki/Arrays and incorporate it in Data.Array.* infrastructure so that strict arrays will be emulated under Hugs. CK The -fparr option is not in the 6.4.1 User's Guide. they just forgot to do this :) btw, strict arrays will be a good candidate for Haskell-prime library standard No, it's not an oversight. The implementation is not complete. Just last week, we have started a second go at a complete implementation of fast arrays. Don't hold your breath though, it's a lot of work. The interface of GHC.PArr will not change very much, but it'll use type classes and associated types in a very essential way. Underneath, a lot of GHC specific will be used to optimise code, such as rewrite rules. So, I don't think this is suitable for Haskell'. Manuel ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: the MPTC Dilemma (please solve)
I have to agree with Manuel. I write a lot of Haskell code. People even pay me to do it. I usually stay with Haskell-98, and I don't think it's a great hardship. Sure, there's fancy stuff I can't do then, but I'd much rather have a well understood somewhat less powerful language. I think the right way forward is more along the lines of associated type and type level functions rather than MPTC and FDs. -- Lennart Manuel M T Chakravarty wrote: Claus Reinke: however, the underlying problem is not limited to MPTCs, and FDs are not the only attempt to tackle the problem. so I agree with Isaac: getting a handle on this issue is imperative for Haskell', because it will be the only way forward when trying to standardize at least those of the many extensions that have been around longer than the previous standard Haskell 98. and if Haskell' fails to do this, it fails. Please keep things in perspective: (A) It's not as if every interesting program (or even the majority of interesting programs) use(s) MPTCs. (B) I don't think the time for which an extension has been around is particularly relevant. One of the big selling points of Haskell is that it's quite well defined, and hence, its semantics is fairly well understood and sane - sure, there are dark corners, but compared to other languages of the same size, we are in good shape. If we include half-baked features, we weaken the standard. In fact, it's quite worrying that FDs have been around for so long and still resisted a thorough understanding. Manuel ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Strict tuples
Loosely related to Ticket #76 (Bang Patterns) is the question of whether we want the language to include strict tuples. It is related to bang patterns, because its sole motivation is to simplify enforcing strictness for some computations. Its about empowering the programmer to choose between laziness and strictness where they deem that necessary without forcing them to completely re-arrange sub-expressions (as seq does). So what are strict tupples? If a lazy pair is defined in pseudo code as data (a, b) = (a, b) a strict pair would be defined as data (!a, b!) = ( !a, !b ) Ie, a strict tuple is enclosed by bang parenthesis (! ... !). The use of the ! on the rhs are just the already standard strict data type fields. Why strict tuples, but not strict lists and strict Maybe and so on? Tuples are the Haskell choice of returning more than one result from a function. So, if I write add x y = x + y the caller gets an evaluated result. However, if I write addmul x y = (x + y, x * y) the caller gets a pair of two unevaluated results. Even with bang patterns, I still have to write addmul x y = let !s = x + y; !p = x * y in (s, p) to have both results evaluated. With strict tuples addmul x y = (!x + y, x * y!) suffices. Of course, the caller could invoke addmul using a bang patterns, as in let ( !s, !p ) = addmul x y in ... but that's quite different to statically knowing (from the type) that the two results of addmul will already be evaluated. The latter leaves room for more optimisations. Syntax issues ~ * In Haskell (,) is the pair constructor. What should be use for strict tuples? (!,!) ? * With strict tuples (! and !) would become some sort of reserved/special symbol. That interferes with bang patterns, as (!x, y!) would be tokenized as (! x , y !). We could use ( ... !) for strict tuples to avoid that conflict, or just requires that the user write ( !x, !y ) when they want a bang pattern. (Just like you cannot write `Just.x' to mean `Just . x' as the former will always be read as a qualified name and not the application of function composition. Bang patterns enable the programmer (among other things) to define functions with strict arguments. Strict tuples enable to define strict results. Manuel PS: IIRC Clean supports strict tuples. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Time Library
I propose the following for Haskell': 1. Adding my Data.Fixed module to the base package. http://semantic.org/TimeLib/doc/html/Data-Fixed.html http://darcs.haskell.org/packages/time/fixed/Data/Fixed.hs 2. Adding my package time to the standard libraries. http://semantic.org/TimeLib/doc/html/ http://darcs.haskell.org/packages/time/ 3. Deprecating System.Time. http://haskell.org/ghc/dist/current/docs/libraries/base/System-Time.html I'm not sure what form deprecating takes. If this is OK, I'll create a ticket for it, and also make these changes in darcs and get it working with default-packages. More info: http://semantic.org/TimeLib/ -- Ashley Yakeley, Seattle WA WWED? http://www.cs.utexas.edu/users/EWD/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
