From rfhayes at reillyhayes.com Tue Apr 3 00:46:34 2007 From: rfhayes at reillyhayes.com (R Hayes) Date: Tue Apr 3 00:46:20 2007 Subject: Mathematics in Haskell In-Reply-To: <001801c77575$cf72d020$5b66ce57@bzdryk> References: <20070324024812.GA3712@localhost.localdomain><005501c76e83$4403a850$6601a8c0@box> <46067F44.2010404@mcmaster.ca><00ca01c76ef2$d4a6a320$32377ad5@cr3lt> <46069EEE.70500@mcmaster.ca> <9795282.post@talk.nabble.com> <001801c77575$cf72d020$5b66ce57@bzdryk> Message-ID: Wouldn't this be a good discussion for the Haskell Prime List? Reilly Hayes +1 415 388 3903 (office) +1 415 846 1827 (mobile) rfh@ridgecrestfinancial.com On Apr 2, 2007, at 3:24 PM, Andrzej Jaworski wrote: >> I too was put off by the Num issues though--strange mixture of >> sophisticated >> category theory and lack of a sensible hierarchy of algebraic >> objects. > > Perhaps we should replace CT with lattice theoretic thinking (e.g. > functor = monotonic > function) before cleaning up the type-related mess? > See: http://citeseer.ist.psu.edu/269479.html > >> so count me in on an effort to make Haskell more mathematical. >> For me that >> probably starts with the semigroup/group/ring setup, and good >> arbitrary-precision as well as approximate linear algebra support. > > I agree: semigoups like lattices are everywhere. > Then there could be a uniform treatment of linear algebra, > polynomial equations, operator > algebra, etc. So, perhaps haste is not a good advice here? > > -Andrzej > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20070402/aae74f7d/attachment.htm From isaacdupree at charter.net Fri Apr 6 15:07:28 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Apr 6 15:05:04 2007 Subject: Literate Haskell specification Message-ID: <46169A70.80909@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As I brought up earlier in Haskell-cafe http://thread.gmane.org/gmane.comp.lang.haskell.cafe/20026 , the Haskell98 specification for literate haskell (report section 9.4) could use some work, at least clarifications (existing haskell implementations differ in some ways) - see that thread for details. Since I haven't successfully gotten to writing a concrete revision of that section, I thought I'd at least bring the issue to the attention of specifically haskell-prime people, as it is an issue that "should definitely" be addressed in the Report. Hopefully there's someone around here who might tackle it :) Good luck, Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGFppvHgcxvIWYTTURAgoqAKDKFXaVBVeSfodzlgEte5Loy42unACfXfbl qDlxnSUaNH5rg8r58KAkKl8= =UVvx -----END PGP SIGNATURE----- From twanvl at gmail.com Fri Apr 13 21:43:03 2007 From: twanvl at gmail.com (Twan van Laarhoven) Date: Fri Apr 13 21:40:54 2007 Subject: General pattern bindings Message-ID: <462031A7.6040703@gmail.com> In the interest of removing things from the standard, I found this in the Haskell 98 report (section 4.4.3.2): > The general form of a pattern binding is p match, where a match is the > same structure as for function bindings above; in other words, a > pattern binding is: > > p | g1 = e1 > | g2 = e2 > ... > | gm = em > where { decls } I did not even know these things existed, is there anyone who actually uses general pattern bindings? If not, the question becomes whether removing these bindings would improve the language. It can be argued that it makes the language less consistent. Declarations would change from > decl -> (funlhs | pat0) rhs > rhs -> = exp [where decls] > | gdrhs [where decls] to something like > decl -> funlhs rhs > | pat0 srhs > srhs -> = exp [where decls] > rhs -> srhs > | gdrhs [where decls] On the other hand, we can remove most of section 4.3.2.2. Any opinions? Twan From stefanor at cox.net Fri Apr 13 22:24:51 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Fri Apr 13 22:23:09 2007 Subject: General pattern bindings In-Reply-To: <462031A7.6040703@gmail.com> References: <462031A7.6040703@gmail.com> Message-ID: <20070414022451.GA12391@localhost.localdomain> On Sat, Apr 14, 2007 at 03:43:03AM +0200, Twan van Laarhoven wrote: > In the interest of removing things from the standard, I found this in > the Haskell 98 report (section 4.4.3.2): > > > The general form of a pattern binding is p match, where a match is the > > same structure as for function bindings above; in other words, a > > pattern binding is: > > > > p | g1 = e1 > > | g2 = e2 > > ... > > | gm = em > > where { decls } > > I did not even know these things existed, is there anyone who actually > uses general pattern bindings? > > If not, the question becomes whether removing these bindings would > improve the language. It can be argued that it makes the language less > consistent. Declarations would change from > > > decl -> (funlhs | pat0) rhs > > rhs -> = exp [where decls] > > | gdrhs [where decls] > > to something like > > > decl -> funlhs rhs > > | pat0 srhs > > srhs -> = exp [where decls] > > rhs -> srhs > > | gdrhs [where decls] > > On the other hand, we can remove most of section 4.3.2.2. > > Any opinions? At one point vty defined the standard colors using the following wonderfully elegant code: [black, red, green, yellow, blue, magenta, cyan, white] = map Color [0..7] Unfortunately ghc generated hideous code for this, so I had to inline it manually. So it goes. (yow, what got into me there?) I'm pretty sure I've seen this once or twice: (x,y) | someCondition = x y z | otherwise = b a r Stefan From ndmitchell at gmail.com Sat Apr 14 06:45:44 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Apr 14 06:44:01 2007 Subject: General pattern bindings In-Reply-To: <20070414022451.GA12391@localhost.localdomain> References: <462031A7.6040703@gmail.com> <20070414022451.GA12391@localhost.localdomain> Message-ID: <404396ef0704140345k6d4b3072t50be2577761aac95@mail.gmail.com> Hi Twan, > > In the interest of removing things from the standard, I found this in > > the Haskell 98 report (section 4.4.3.2): Great idea to remove things, but keep your hands off extended pattern guards! I've got at least 3 instances of that in the module that is currently open on my screen. I've got loads of it everywhere, its great. If you are looking for things to remove, I'd look in the direction of n+k patterns :-) Thanks Neil From bulat.ziganshin at gmail.com Sun Apr 15 05:06:28 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Apr 15 05:51:20 2007 Subject: General pattern bindings In-Reply-To: <462031A7.6040703@gmail.com> References: <462031A7.6040703@gmail.com> Message-ID: <352891206.20070415130628@gmail.com> Hello Twan, Saturday, April 14, 2007, 5:43:03 AM, you wrote: > I did not even know these things existed, is there anyone who actually > uses general pattern bindings? b:kb:mb:gb:_ = iterate (1024*) 1 unfortunately, they got monotypes, so at last end i finished with simpler definitions nevertheless, i think that this feature should remain. in particular, it may be required for initialization via unsafePerformIO: (hin,hout) = unsafePerformIO $ do runProcess "sh" -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From Malcolm.Wallace at cs.york.ac.uk Mon Apr 16 07:04:01 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Apr 16 07:06:24 2007 Subject: General pattern bindings In-Reply-To: <462031A7.6040703@gmail.com> References: <462031A7.6040703@gmail.com> Message-ID: <20070416120401.50635c0b.Malcolm.Wallace@cs.york.ac.uk> Twan van Laarhoven wrote: > > The general form of a pattern binding is p match, where a match is > > the same structure as for function bindings above; in other words, > > a pattern binding is: > > > > p | g1 = e1 > > | g2 = e2 > > ... > > | gm = em > > where { decls } > > I did not even know these things existed, is there anyone who actually > uses general pattern bindings? It is worth mentioning that such pattern bindings are not only used at the top-level - they are also valid in local definitions, where the guards may involve variables bound at an outer scope. This makes them highly useful. Regards, Malcolm From ndmitchell at gmail.com Tue Apr 17 20:18:27 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Apr 17 20:16:32 2007 Subject: Relax the restriction on Bounded derivation Message-ID: <404396ef0704171718p1455cb79v532f6aa3e2196071@mail.gmail.com> Hi, >From Section 10 of the Haskell report, regarding automatic derivation: to derive Bounded for a type: "the type must be either an enumeration (all constructors must be nullary) or have only one constructor." This seems a very artificial restriction - since it allows you to be in any one of two camps, but no where in between. It also means that Either doesn't derive Bounded, while it could easily do so: instance (Bounded a, Bounded b) => Bounded (Either a b) where minBound = Left minBound maxBound = Right maxBound So I propose that this restriction be lifted, and that the obvious extension be given such that minBound is the lowest constructor with a pile of minBounds, and maxBound is the highest constructor with a pile of maxBound. This proposal has been implemented in Derive: http://www-users.cs.york.ac.uk/~ndm/derive/ Thanks Neil From stefanor at cox.net Tue Apr 17 20:41:42 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue Apr 17 20:39:48 2007 Subject: Apparent contradiction in H98 prescribed behavior of 'data X = (:+){ x :: Int, y :: Int } deriving(Show)' Message-ID: <20070418004142.GA3376@localhost.localdomain> Given: data X = (:*){ x :: Int, y :: Int } deriving(Show) which is syntactically correct: > constr -> con { fielddecl[1] , ... , fielddecl[n] } (n>=0) > con -> ( consym ) and the following from 10.4: * If the constructor is defined to be an infix operator, then the derived Read instance will parse only infix applications of the constructor (not the prefix form). * If the constructor is defined using record syntax, the derived Read will parse only the record-syntax form, and furthermore, the fields must be given in the same order as the original declaration. the behavor of the Show instance seems to be contradicted, since :+ is an infix operator and is defined using record syntax. Suggested resolution: * If the constructor is defined using infix syntax, then the derived Read instance will parse only infix applications of the constructor (not the prefix form). Thus, 'data X = Int :+ Int' would show infix but 'data X = (:+) Int Int' would not. Alternatively, change the con in the above production for constr to conid, thus banning infix record constructors. Status: stefan@stefans:/tmp$ cat Main.hs data X = (:*) { x :: Int, y :: Int } deriving(Show) main = print ((:*) 2 2) stefan@stefans:/tmp$ runghc Main.hs (:*) {x = 2, y = 2} stefan@stefans:/tmp$ runhugs Main.hs :* {x = 2, y = 2} stefan@stefans:/tmp$ yhc Main.hs Compiling Main ( Main.hs ) stefan@stefans:/tmp$ yhi Main.hbc 2 :* 2 stefan@stefans:/tmp$ Note that the hugs output for this corner case is unparseable and thus buggy! Stefan From ravi at bluespec.com Tue Apr 17 23:05:15 2007 From: ravi at bluespec.com (Ravi Nanavati) Date: Tue Apr 17 23:03:24 2007 Subject: Relax the restriction on Bounded derivation In-Reply-To: <404396ef0704171718p1455cb79v532f6aa3e2196071@mail.gmail.com> References: <404396ef0704171718p1455cb79v532f6aa3e2196071@mail.gmail.com> Message-ID: <7b977d860704172005g62a62dc2y5fba9713cdaea139@mail.gmail.com> On 4/17/07, Neil Mitchell wrote: > > Hi, > > >From Section 10 of the Haskell report, regarding automatic derivation: > > to derive Bounded for a type: "the type must be either an enumeration > (all constructors must be nullary) or have only one constructor." > > This seems a very artificial restriction - since it allows you to be > in any one of two camps, but no where in between. It also means that > Either doesn't derive Bounded, while it could easily do so: > > instance (Bounded a, Bounded b) => Bounded (Either a b) where > minBound = Left minBound > maxBound = Right maxBound > > So I propose that this restriction be lifted, and that the obvious > extension be given such that minBound is the lowest constructor with a > pile of minBounds, and maxBound is the highest constructor with a pile > of maxBound. In general, I like the idea of of allowing more flexible derivation of Bounded, but I'm worried your specific proposal ends up mandating the derivation of Bounded instances for types that aren't really "bounded" (used in a deliberately loose sense). Consider the following type: data Foo = A Char | B Integer | C Int On some level, there's no real problem in creating a Bounded instance as follows (which is how I interpret your proposal): instance Bounded Foo minBound = A (minBound :: Char) maxBound = C (maxBound :: Int) On the other hand, there's a real sense in which the type isn't actually "bounded". For instance, if it was also an instance of Enum, enumerating all of the values from minBound to maxBound might not terminate. I'm not sure what to do about the scenario. Should we (unnecessarily) insist that all of the arguments of all of the constructors be Bounded to avoid this? Should Bounded more explicitly document what properties the minBound, maxBound and the type should satisfy? Or something else? - Ravi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20070417/68556fc3/attachment.htm From isaacdupree at charter.net Wed Apr 18 08:02:31 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Apr 18 07:59:30 2007 Subject: Relax the restriction on Bounded derivation In-Reply-To: <7b977d860704172005g62a62dc2y5fba9713cdaea139@mail.gmail.com> References: <404396ef0704171718p1455cb79v532f6aa3e2196071@mail.gmail.com> <7b977d860704172005g62a62dc2y5fba9713cdaea139@mail.gmail.com> Message-ID: <462608D7.6060703@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ravi Nanavati wrote: > On 4/17/07, Neil Mitchell wrote: >> >> Hi, >> >> >From Section 10 of the Haskell report, regarding automatic derivation: >> >> to derive Bounded for a type: "the type must be either an enumeration >> (all constructors must be nullary) or have only one constructor." >> >> This seems a very artificial restriction - since it allows you to be >> in any one of two camps, but no where in between. It also means that >> Either doesn't derive Bounded, while it could easily do so: >> >> instance (Bounded a, Bounded b) => Bounded (Either a b) where >> minBound = Left minBound >> maxBound = Right maxBound >> >> So I propose that this restriction be lifted, and that the obvious >> extension be given such that minBound is the lowest constructor with a >> pile of minBounds, and maxBound is the highest constructor with a pile >> of maxBound. > > > In general, I like the idea of of allowing more flexible derivation of > Bounded, but I'm worried your specific proposal ends up mandating the > derivation of Bounded instances for types that aren't really "bounded" > (used > in a deliberately loose sense). Consider the following type: > > data Foo = A Char | B Integer | C Int > > On some level, there's no real problem in creating a Bounded instance as > follows (which is how I interpret your proposal): > > instance Bounded Foo > minBound = A (minBound :: Char) > maxBound = C (maxBound :: Int) > > On the other hand, there's a real sense in which the type isn't actually > "bounded". For instance, if it was also an instance of Enum, enumerating > all > of the values from minBound to maxBound might not terminate. I'm not sure > what to do about the scenario. Should we (unnecessarily) insist that all of > the arguments of all of the constructors be Bounded to avoid this? Should > Bounded more explicitly document what properties the minBound, maxBound and > the type should satisfy? Or something else? IMO, Bounded only needs to satisfy (if Foo is in Ord) forall a::Foo, a >= minBound && a <= maxBound . I want to be able to define bounded for data ExtendedInteger = NegativeInfinity | PlainInteger Integer | PositiveInfinity . Preferably by deriving, because it's easier. If we require properties of Enum... Enum _already_ has problems with instances like Integer where fromEnum :: a -> Int only has a limited possible output; there is little reasonable meaning for (fromEnum (100000000000000000000000000000000000000000000000000000 :: Integer)) (hugs: Program error: arithmetic overflow) (Float and Double *aren't* in Bounded. Then again, Haskell98 doesn't require them to contain non-_|_ values of +-infinity.) Furthermore, there are bounded things that aren't enumerable anyway (I think) (such as some lattices), so it would be odd to add that restriction just because the type might also be in Prelude.Enum. However there is a good argument for having some sort of bounded-enum class for things that have a finite number of discrete positions. These have log(number of possibilities) information content and can (in theory) be serialized with such a number of bits known from the type. Designing such a class could be interesting... Rather, I would ask "Must any inhabitant of a type in Enum be reachable by pred or succ from an arbitrary inhabitant of the type?" For example, I could declare an instance of Enum that contradicted that: data Something = Some Integer | Another Integer where pred and succ always stayed within the same constructor, and for fromEnum/toEnum I would just find some way to encode some common (i.e. relatively small magnitude, just as the usual instance Enum Integer is limited this way) values of Something into an Int. Or are fromEnum/toEnum supposed to obey some sort of properties, when they are defined, relative to the rest of the methods? I would guess not, given the comment - -- NOTE: these default methods only make sense for types - -- that map injectively into Int using fromEnum - -- and toEnum. (hugs: fromEnum (2.6 :: Double) ---> 2) Cheers, Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJgjWHgcxvIWYTTURAlL/AJ97SilRhmd8B59TAAX+Hcyjly5oHQCff0fa 5B4Y9m0Zb3vQtilZr4lRQs0= =Qn2+ -----END PGP SIGNATURE----- From isaacdupree at charter.net Wed Apr 18 08:29:25 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Apr 18 08:26:28 2007 Subject: Relax the restriction on Bounded derivation In-Reply-To: <462608D7.6060703@charter.net> References: <404396ef0704171718p1455cb79v532f6aa3e2196071@mail.gmail.com> <7b977d860704172005g62a62dc2y5fba9713cdaea139@mail.gmail.com> <462608D7.6060703@charter.net> Message-ID: <46260F25.5080302@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Isaac Dupree wrote: > However there is a good argument for having some sort of bounded-enum > class for things that have a finite number of discrete positions. These > have log(number of possibilities) information content and can (in > theory) be serialized with such a number of bits known from the type. > Designing such a class could be interesting... In particular, this hypothetical class could be derived more generally than Enum: data Blah a b = Baz Int a Bool | Quux | Quuuux b derived instance (Finite a, Finite b) => Finite (Blah a b) since Int and Bool are in this class. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJg8lHgcxvIWYTTURAln7AJ49TOSqXbx4GNzYti0GVuYBDPjDXQCfcDQz BPbBk1M9cZRS24Dt6b+0inQ= =X+1X -----END PGP SIGNATURE----- From wnoise at ofb.net Wed Apr 18 10:24:29 2007 From: wnoise at ofb.net (Aaron Denney) Date: Wed Apr 18 10:22:57 2007 Subject: Relax the restriction on Bounded derivation References: <404396ef0704171718p1455cb79v532f6aa3e2196071@mail.gmail.com> <7b977d860704172005g62a62dc2y5fba9713cdaea139@mail.gmail.com> <462608D7.6060703@charter.net> Message-ID: On 2007-04-18, Isaac Dupree wrote: > (Float and Double *aren't* in Bounded. Then again, Haskell98 doesn't > require them to contain non-_|_ values of +-infinity.) And they're only in Enum to support the [a..b] syntax, whose semantics can't really sanely be supported for Float and Double anyways. > Furthermore, there are bounded things that aren't enumerable anyway (I > think) (such as some lattices), so it would be odd to add that > restriction just because the type might also be in Prelude.Enum. I'd really like to see one. Unless you're just talking about a set with a partial order, in which case, yes, many are bounded. e.g. reals in [0, 1], as when being used for probabilities. > Rather, I would ask "Must any inhabitant of a type in Enum be reachable > by pred or succ from an arbitrary inhabitant of the type?" That would make sense to me (when restricted to non-bottom inhabitants), and is essentially the objection that many have to Float and Double being in Enum. > For example, > I could declare an instance of Enum that contradicted that: > data Something = Some Integer | Another Integer > where pred and succ always stayed within the same constructor, and for > fromEnum/toEnum I would just find some way to encode some common (i.e. > relatively small magnitude, just as the usual instance Enum Integer is > limited this way) values of Something into an Int. Or are > fromEnum/toEnum supposed to obey some sort of properties, when they are > defined, relative to the rest of the methods? I would guess not, given > the comment > - -- NOTE: these default methods only make sense for types > - -- that map injectively into Int using fromEnum > - -- and toEnum. > (hugs: fromEnum (2.6 :: Double) ---> 2) > > > Cheers, > Isaac The default implementation for the class assumes fromEnuw (succ x) = 1 + fromEnum x and similar things. That's a pretty strong argument that all types should obey that. -- Aaron Denney -><- From haskell.vivian.mcphail at gmail.com Sat Apr 21 00:33:01 2007 From: haskell.vivian.mcphail at gmail.com (Vivian McPhail) Date: Sat Apr 21 00:30:59 2007 Subject: Why Mathematical Soundness Matters. Message-ID: <7b03b3c60704202133h6164e38nae2afa16c4514f4d@mail.gmail.com> Hi All, This is in regard to previous posts about mathematical preludes. > class Set a > > class (Set s) => SemiGroup s o where > semigroup_op :: o -> (s,s) -> s > -- closure > -- associative > > class (SemiGroup s o) => Monoid s o where > identity :: o -> s > > class (Monoid s o) => Group s o where > inverse :: o -> s -> s > > class Optimisable a where > cost :: Set b => a -> b First, consider a semigroup, which is a set with an associative operation. Into this structure falls Matrices with multiplication. There is scope for optimisation of a series of multiplications. Inductively for each m1 * m2 * m3 compare the cost of m1 * m2 versus m2 * m3 which can be simply obtained from the size of the index of the matrix. Thus expressions like (14,3) x (3,15) x (15,2) can be computed as (14,3) x ((3,15) x (15,2)) and not in a more expensive way. Furthermore, if we tag identities with a phantom type, we can eliminate needless operations like 3 + 0. Not as much optimisation can be achieved with inverses (3 + -3) because it might be just as expensive to calculate that something is an inverse as to do actual calculation. So how can this optimisation be performed? Well this is a question that I put forward to you, Gentle Reader. Static: It seems to me that expressions the types of which are known at compile-time can be optimised by using type-level programming in combination with compiler rewrite rules, e.g. if we have a type class SizeLarger then the expression > semigroup_op (semigroup_op m1 m2) m3 can be rewritten as > semigroup_op m1 (semigroup_op m2 m3) depending upon the SizeLarger types of the various (semigroup_op _ _) function calls. Another method is to manipulate the expressions as ASTs and convert to the concrete using TH. But what about dynamic data? Dynamic: These are terms whose types are not known until run-time (such as would happen when loading an arbitrary matrix from a file). In this case we can't use compiler term-rewriting or TH, but what options are there? Depending upon the speed/complexity of type-checking versus computation would it not be feasible to use run-time type checking (a polymorphic Dynamic type) to achieve this optimisation? Yes there is a lot to said in favour of static type-checking, but there are cases in which it is not feasible, witness type-level bounds checking of run-time loaded matrices of unknown shape. In a program that used run-time typechecking (yes there would be a computational overhead) the dynamic stuff would be isolated from the 'trusted' statically checked program and values could only be injected through trusted entry points (e.g. get4SquareDoubleMatrix :: Dynamic -> IO (Array ((D4 $ Sz),(D4 $ Sz)) Double). In any case, writing 'simple' arithmetic expressions would become more cumbersome because of the overhead of annotating types and possibly moving between ASTs and the concrete. But if we a had collection of mathematically sound classes like SemiGroup, Monoid, Group, Field, etc... then these optimisations could be built into the compiler and we could sugar the programmer-side just as it has been for Monads. In conclusion, I put this forward as a reason for Mathematically Meaningful Numeric Classes and in obiter I am putting forward support for polymorphic Dynamic types (run-time typechecking). Cheers, Vivian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20070421/fcf1cc1f/attachment.htm From haskell.vivian.mcphail at gmail.com Sun Apr 22 22:39:23 2007 From: haskell.vivian.mcphail at gmail.com (Vivian McPhail) Date: Sun Apr 22 22:37:13 2007 Subject: Literate Haskell specification Message-ID: <7b03b3c60704221939m6bdbc511w8e0045421b855cda@mail.gmail.com> Dear Committee If I recall correctly, in the tex-style literate haskell specification, code is delimited by a \begin{code} \end{code} This does not allow for multilanguage support in a single source file. It would be nice to have a single document in which we could mix English, Haskell, and, for example, Coq proofs. To this end, would it make more sense to delimit haskell code by \begin{haskell} \end{haskell} ? Cheers, Vivian Date: Fri, 06 Apr 2007 15:07:28 -0400 > From: Isaac Dupree > Subject: Literate Haskell specification > To: haskell-prime@haskell.org > Message-ID: <46169A70.80909@charter.net> > Content-Type: text/plain; charset=ISO-8859-1 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > As I brought up earlier in Haskell-cafe > http://thread.gmane.org/gmane.comp.lang.haskell.cafe/20026 > , the Haskell98 specification for literate haskell (report section 9.4) > could use some work, at least clarifications (existing haskell > implementations differ in some ways) - see that thread for details. > Since I haven't successfully gotten to writing a concrete revision of > that section, I thought I'd at least bring the issue to the attention of > specifically haskell-prime people, as it is an issue that "should > definitely" be addressed in the Report. Hopefully there's someone > around here who might tackle it :) > > > Good luck, > Isaac > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGFppvHgcxvIWYTTURAgoqAKDKFXaVBVeSfodzlgEte5Loy42unACfXfbl > qDlxnSUaNH5rg8r58KAkKl8= > =UVvx > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20070423/2d198bf8/attachment-0001.htm From isaacdupree at charter.net Tue Apr 24 06:29:06 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Apr 24 06:25:38 2007 Subject: Literate Haskell specification In-Reply-To: <7b03b3c60704221939m6bdbc511w8e0045421b855cda@mail.gmail.com> References: <7b03b3c60704221939m6bdbc511w8e0045421b855cda@mail.gmail.com> Message-ID: <462DDBF2.3050308@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vivian McPhail wrote: > Dear Committee > > If I recall correctly, in the tex-style literate haskell specification, > code > is delimited by a > > \begin{code} > \end{code} > > This does not allow for multilanguage support in a single source file. It > would be nice to have a single document in which we could mix English, > Haskell, and, for example, Coq proofs. > > To this end, would it make more sense to delimit haskell code by > > \begin{haskell} > \end{haskell} > > ? It very well could make sense, but we are not in re-designing here (it would likely never be finished). For example, a quote from http://hackage.haskell.org/trac/haskell-prime "Haskell' will be a conservative refinement of Haskell 98. ... We will strive to only include tried-and-true language features" BTW, if other languages such as Coq have any other convention than exactly the name \begin{code} / \end{code} , they could be mixed in the same source-file anyway, I suppose. Which could be nice, as you note. Thanks, Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLdvyHgcxvIWYTTURAmvsAJ0Q11sJPmwHM/ORNeE9hqO04ePGaQCdGekm HbMeOpa4X2pPlDp6ePbtzYs= =pQu+ -----END PGP SIGNATURE----- From iavor.diatchki at gmail.com Mon Apr 30 22:47:55 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon Apr 30 22:45:17 2007 Subject: Polymorphic strict fields Message-ID: <5ab17e790704301947od2d0038ydd7121f6a6bb0243@mail.gmail.com> Hello, At present, the Haskell report specifies the semantics of strict datatype fields (the ones marked with !) in terms of the strict application operator $! [Section 4.2.1, paragraph "Strictness flags"]. However, if we were to add polymorphic fields to Haskell, then we cannot use this definition anymore because the application operator (or ``seq`` for that matter) does not have the correct type---we would need many rank-2 versions, one for each possible type scheme. Notice, furthermore, that the behavior of such constructors may be a bit unexpected when combined with overloading. Consider, for example, the following declarations: > data T = T !(forall a. Eq a => a) > test = seq (T undefined) True In GHC 6.6 ``test`` evaluets to ``True`` because ``undefined`` is converted to a function that expects its implict evidence argument. Hugs does not support strictness annotations on polymorphic fields (I thought that this was a bug but, perhaps, it was a delibarate choice?) It seems that even without overloading, we may think of polymorphic values as being parameterized by their type arguments, so that they are always in head-normal form. All of this leads me to think that perhaps we should not allow strictness annotations on polymorphic fields. Would people find this too restrictive? If so, does anoyone have ideas about what should happen and how to specify the behavior? -Iavor