Re: suggestion
On 23 Oct 2001 08:11:59 +0200, Ketil Malde wrote: >> I'd personally prefer to get a proper Reply-To: >> header so replies go to the list by default, not to the original >> sender. > >This is a lot worse. On the lists I subscribe to that have this kind >of configuration, the lists are riddled with personal mail that >accidentally got sent to the list. Most - if not all - mail reader >software has an option to reply to all recipients. Yes, I know about the dilemma. But when people do "reply to all" on my postings, it causes duplicate messages to be sent, which I really don't like. >Few mail readers have options to override the Reply-To: field. Yes, that kind of sucks too. Salutaciones, JCAB email: [EMAIL PROTECTED] ICQ: 101728263 The Rumblings are back: http://www.JCABs-Rumblings.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: suggestion
On Tue, 23 Oct 2001 00:38:23 -0400 (EDT), Mark Carroll wrote: >On Tue, 23 Oct 2001, Andre W B Furtado wrote: > >> What do you all think about activating the mechanism that automatically >> includes the name of the list before the subject of a mailing list email? > >I like the idea. I guess it helps. I'd personally prefer to get a proper Reply-To: header so replies go to the list by default, not to the original sender. We probably shouldn't be discussing this here... O:-) Salutaciones, JCAB email: [EMAIL PROTECTED] ICQ: 101728263 The Rumblings are back: http://www.JCABs-Rumblings.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Monomorphism, monomorphism...
On 6 Oct 2001 09:31:54 GMT, Marcin 'Qrczak' Kowalczyk wrote: First of all, thanks a lot for the detailed response. >Yes, ... yes ... yes Well, I'm glad I got some of it right. Gives me hope :) >>>"contains a pattern binding with a nonvariable pattern" >> >> Meaning... what exactly? > >A pattern which is something other than an identifier. Like defining a function, as opposed to defining a constant? >> Hmmm... This still sounds like nonsensical (as in counterintuitive >> and artificial) to me. In a definition like "let g = isNil" >> there cannot be any compelling reason to give "g" any type >> different than the type of "isNil". > >There are two reasons for the monomorphism restriction: > >- isNil (or any value with a non-empty context in its type) doesn't > really behave like a constant, but as a function taking a dictionary > of 'IsNil a' as an implicit argument, so it's recomputed each time > it it used... Ok... This is an angle I hadn't even approached yet. We're talking about the internal implementation of the compiler here. Hmmm... Shouldn't the compiler be able to limit the recomputations to one per instance of the class? That sounds perfectly appropriate to me, and it would solve this particular problem. Unless I'm missing something here... > This point is silly in this case, because it is already a function > with an explicit argument! It makes more sense however when the type > is not of the form a->b. For example in 'n = 7*11*13' letting n have > the type 'Num a => a' implies that it is recomputed each time it > is used. Again, what about recomputing it once per instance of Num? > Unless the compiler manages to optimize this, but it can't > in all cases (n can be used with different types in various places). I guess I'm biased here by my knowledge of templates in C++, which can be used to implement something very similar to type classes in Haskell. This would be akin to different instantiations of a single template, which should not present any problems for the compiler. So, 'n = 7*11*13' would have type 'Num a => a', which would mean that it has a different value for each instantiation of the context 'Num a'. So, where's the problem? It's not as if Haskell didn't already have this functionality in the members of a type class: class Num a where n :: a n = 7*11*13 'n' here has that type 'Num a => a', doesn't it? Don't tell me compilers will compute it twice if we use it twice, as in: n1 = n n2 = n >- When a pattern binds several variables, it can happen that their > types need different sets of class constraints. Using such a variable > doesn't fully determine the type to perform the computation in. > It's thus ambiguous and an error. You're talking about the case '(var1, var2) = expr', right? That's because var1 and var2 cannot have different contexts? That still sounds unnecessary to me. I mean, the tuple result should have its own context, necessary to resolve the tuple itself, and each of its elements should acquire its own context as appropriate. Then all contexts should be unambiguous. In this case, 'expr' should be able to have type: expr:: => ( => TypeOfVar1, => TypeOfVar2) I'm guessing from what I learn that this is not possible in Haskell, right? > It's not ambiguous with monomorphic restriction, where all uses of > all variables contribute to finding the single type to perform the > computation in. Exactly. I think I'm starting to get a reasonable handle on this. > Even with a single variable it can happen that some uses will > constrain the type enough to determine the instance, and some will > not. Without monomorphic restrictions some uses are OK, but others > will stop the compilation. With monomorphic restriction all uses > contribute to a single type and typing might succeed. So it is. I just tried, with Hugs: --- intToBool :: Int -> Bool intToBool a = a == 0 numToBool :: Num a => a -> Bool numToBool a = a == 0 h :: Num a => a h = 4 g = h f = (intToBool g) && (numToBool g) --- It complained with: --- ERROR E:\JCAB\Haskell\TestMonomorphic.hs:14 - Type error in application *** Expression : intToBool g *** Term : g *** Type : Integer *** Does not match : Int --- You're saying that this is because, when seeing the line 'g = h', the compiler immediately and arbitrarily picks a type for 'g', right? In this case, it's 'Integer'. Arbitrarily but not randomly, right? What rules does it follow? >The general trouble with monomorphic restriction is that let bindings >can mean two similar things: > >1. Create a single lazily evaluated object with the given definition > and make it or its components available through variables (pattern > binding). > >2. Define a possibly polymorphic function and perform the given > computation when it is applied (function binding). In case 2 we wouldn't need the restriction, right? I guess the only benefit from all this is ef
Monomorphism, monomorphism...
On Fri, 05 Oct 2001 21:25:57 +0200, Karl-Filip Faxen wrote: >The monomorphism restriction goes like this in my inference rules: > >If a declaration group contains a pattern binding with a nonvariable pattern >or one where there is no type signature for the variable, then the context >parts of the type schemes derived for the bound variables must be empty. > >class IsNil a where > isNil :: a -> Bool > >f x y = let g = isNil > in (g x, g y) I'm still having a lot of trouble grasping and comprehending this "monomorphism restriction". It just doesn't feel right, and I keep having a lot of trouble juggling all the descriptions I found on the web. So, I'll don my newbie hat and start asking all the obvious questions. I hope I don't annoy too much. I know there are people tired of discussing this, but the thing is that this monomorphism restriction is something very easy to bump into (I have), but all the definitions out there seem to be unable to seep in. Especially the one in the Haskell Report, BTW. >"If a declaration group" Meaning something like "let g = isNil" up there? >"contains a pattern binding with a nonvariable pattern" Meaning... what exactly? >"or one [pattern binding] where there is no type signature for the variable" Meaning "g = isNil" above, without type signature for "g"? >"then the context parts of the type schemes derived for the bound variables must be >empty" Meaning that in "let g = ...", "g" cannot be "g :: => " unless the context is explicitly given? Hmmm... This still sounds like nonsensical (as in counterintuitive and artificial) to me. In a definition like "let g = isNil" there cannot be any compelling reason to give "g" any type different than the type of "isNil". >The monomorphism restriction applies to the binding of "g" since >there is no type signature. Thus it is not legal to derive >"forall a . IsNil a => a -> Bool", Ok... This is probably the one explanation that has begun to make an impact in my mind. >but two legal possibilities are >- forall b . [b] -> Bool, and Choosing an explicit instance of IsNil. But this sounds nonsensical to me, too. No instance should be choosing unless the specific instance type is forced by the definition. Otherwise, if there are two insances, which one would it choose? >- a -> Bool (without quantification and with "IsNil a" among the predicates). This is something I didn't understand either. Which predicates? Thanx for your patience O:-) Salutaciones, JCAB email: [EMAIL PROTECTED] ICQ: 101728263 The Rumblings are back: http://www.JCABs-Rumblings.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: RFC: GUI Library Task Force
On Tue, 25 Sep 2001 17:41:06 +1000, Manuel M. T. Chakravarty wrote: >> Many applications where GUIs are used require a canvas/scribble field >> with the following basic functionality: >> >> - set a point in a particular color; if speed is an issue, >> mapping a 2D-array content to the canvas would be useful > >Sure - such functionality needs to be included. However, a >canvas widget is just one among many. IMHO, the main interest on having this kind of functionality singled out is that this allows any other drawing primitive to be implemented in a generic way. You wouldn't have fast implementations, but this will allow complete implementations of the drawing portion of the GUI to be done real quickly, and it would also provide a reference implementation for all the basic drawing primitives. Any implementation that uses hardware acceleration or that defers rendering of primitives to the operating system can then be checked against that reference implementation. It's kind of like what I believe the Haskell Kernel to be: everything can be implemented using that subset of Haskell, and everything else is either syntactic sugar or library functions. Implementations can then optimize those sugar extensions and library functions or implement them as primitives for performance reasons, but they don't have to. Call this the Haskell GUI Kernel. Only this time, I believe it should be formally documented. Make sense? It will mean some more work than if we just jumped into the GUI and did it as a whole, but it'll save time and pain down the line. Salutaciones, JCAB email: [EMAIL PROTECTED] ICQ: 101728263 The Rumblings are back: http://www.JCABs-Rumblings.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
