Re: [Haskell-cafe] Features of Haskell
On Sun, Jun 04, 2006 at 05:17:02PM -0700, Jared Updike wrote: stumped as to how I'm going to do this. I've got about 15-20 minutes, so I can only discuss the major features. I was always impressed with Autrijus Tang's presentation here: Audrey I think he managed to explain very effectively what made Haskell ^^ she Peace, Dylan Thurston signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal for restructuring Number classes
On Mon, Apr 10, 2006 at 12:13:55PM +0200, Andrew U. Frank wrote: there has been discussions on and off indicating problems with the structure of the number classes in the prelude. i have found a discussion paper by mechveliani but i have not found a concrete proposal on the haskell' list of tickets. i hope i can advance the process by making a concrete proposal for which i attach Haskell code and a pdf giving the rational can be found at ftp://ftp.geoinfo.tuwien.ac.at/frank/numbersPrelude_v1.pdf if i have not found other contributions, i am sorry and hope to hear about them. i try a conservative structure, which is more conservative than the structure we have used here for several years (or mechveliani's proposal). It suggests classes for units (Zeros, Ones) and CommGroup (for +, -), OrdGroup (for abs and difference), CommRing (for *, sqr), EuclideanRing (for gdc, lcm, quot, rem, div...) and Field (for /). I think the proposed structure could be a foundation for mathematically strict approaches (like mechveliani's) but still be acceptable to 'ordinary users'. I agree with Henning Thielemann about putting 'zero' in 'CommGroup' and 'one' in 'CommRing'. What is your thinking here? I would also argue for putting 'fromInteger' in 'CommRing', as discussed in the NumPrelude proposal. 'EuclideanRing' is a misnomer; a Euclidean Ring is a particular type of ring where GCD, etc. can be defined (see http://planetmath.org/encyclopedia/EuclideanRing.html), but there are other such rings, namely any Principal Ideal Domain or PID. 'IntegralDomain' is also a misnomer; I don't know what you're getting at there, but there is a well-established mathematical term 'integral domain' that means something different. o On enforcing properties: there's not currently any way to enforce properties (e.g., monad laws are not enforced); however, I believe that expected properties should be documented. o ^ and ^^ (which can actually be combined, see our proposal) are in fact quite useful, and can be implemented considerably more efficiently than a general exponentiation. If you want a complete proposal, you do need to go further. o You do impose some additional burden by changing the name of the 'Num' class, and it is worth noting that. o Mechvelliani's implementation could not be built on top of your base, because he needs to have a sample argument to 'zero' to determine, e.g., the right zero for modular arithmetic. Henning mentioned this in his response. To implement modular arithmetic with these signatures, as far as I know, you need to either separate Zero constructors or do something like the Kiselyov-Shan paper. (See, e.g., Frederick Eaton's linear algebra library recently posted to the Haskell list.) Peace, Dylan Thurston signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Proposal for restructuring Number classes
On Sat, Apr 08, 2006 at 10:16:53PM +0400, Serge D. Mechveliani wrote: I think that without dependent types for a Haskell-like language, it is impossible to propose any adequate and in the same time plainly looking algebraic class system. Agreed. Is there anything really wrong with the Kiselyov-Shan approach to dependent types? Does it look too bizarre? http://okmij.org/ftp/Haskell/types.html#Prepose http://okmij.org/ftp/Haskell/number-parameterized-types.html Peace, Dylan Thurston signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Positive integers
On Mon, Mar 27, 2006 at 05:02:20AM -0800, John Meacham wrote: well, in interfaces you are going to end up with some specific class or another concretely mentioned in your type signatures, which means you can't interact with code that only knows about the alternate class. like genericLength :: Integral a = [b] - a if you have a different 'Integral' you can't call genericLength with it, or anything built up on genericLength. basically there would be no way for 'new' and 'old' polymorphic code to interact. I think the idea would be that the source for genericLength would compile using either class hierarchy with no change. For the case of genericLength, this is true for the proposed alternate prelude Hennig Theilemann pointed to. It would be mostly true in general for that proposal, with the exception that you would sometimes need to add Show or Eq instances. the inability to evolve the class hierarchy is a serious issue, enough that it very well could be impractical for haskell' unless something like class aliases were widely adopted. I think that as long as you're not defining classes source compatibility would not be hard. Of course you couldn't hope to link code written with one hierarchy against another. Peace, Dylan Thursto signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Alternatives to . for composition
At http://hackage.haskell.org/trac/haskell-prime/wiki/CompositionAsDot , there is a list of possible Unicode replacements for the '.' operator. Oddly, the canonical one is missing (from http://www.unicode.org/charts/PDF/U2200.pdf ): 2218 RING OPERATOR = composite function = APL jot 00B0 degree sign 25E6 white bullet I don't think any other Unicode character should be considered. (Is this the approved way to send minor updates like this?) Peace, Dylan Thurston signature.asc Description: Digital signature ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell] Re: (small) records proposal for Haskell '06
On Tue, Jan 03, 2006 at 02:41:40PM -0800, Ashley Yakeley wrote:
David Roundy wrote:
On Mon, Jan 02, 2006 at 04:23:32PM -0800, Ashley Yakeley wrote:
One open question (in my mind) would be whether we'd allow
data Foo = FooInt { foo :: Int } | FooChar { foo :: Char }
In the new system, there's no reason this need be illegal.
How would this behave?
data Foo a b = FooA {foo :: a} | FooB {foo :: b}
I'm not sure I understand the problem. Why would there be any difficulty
with this?
What type would foo have? ...
Nothing, since in David's proposal there would be no 'foo' defined on
the top level at all.
Peace,
Dylan
signature.asc
Description: Digital signature
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Project postmortem II /Haskell vs. Erlang/
On Sun, Jan 01, 2006 at 11:12:31PM +, Joel Reymont wrote:
Simon,
Please see this post for an extended reply:
http://wagerlabs.com/articles/2006/01/01/haskell-vs-erlang-reloaded
Looking at this code, I wonder if there are better ways to express
what you really want using static typing. To wit, with records, you
give an example
data Pot = Pot
{
pProfit :: !Word64,
pAmounts :: ![Word64] -- Word16/
} deriving (Show, Typeable)
mkPot :: Pot
mkPot =
Pot
{
pProfit = 333,
pAmounts = []
}
and complain about having to explain to the customer how xyFoo is
really different from zFoo when they really mean the same thing. I
wonder: if they really are the same thing, is there a way to get the
data types to faithfully reflect that? Can you post a few more
snippets of your data structures?
Peace,
Dylan
signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Progress on shootout entries
On Wed, Jan 04, 2006 at 03:02:29AM +0100, Sebastian Sylvan wrote: I took a stab at the rev-comp one due to boredom. It's not a space leak, believe it or not, it's *by design*... My god, I think someone is consciously trying to sabotage Haskell's reputation! Instead of reading input line-by-line and doing the computation, it reads a whole bunch of lines (hundreds of megs worth, apparently) and only does away with them when a new header appears. Anyway, I uploaded a dead simple first-naive-implementation which is significantly faster (and more elegant): ... The program is supposed to do reverse and complement. The code you posted just does complement. Peace, Dylan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] How to zip folds: A library of fold transformers
On Tue, Oct 11, 2005 at 05:25:24PM -0700, [EMAIL PROTECTED] wrote: First we define the representation of a list as a fold: newtype FR a = FR (forall ans. (a - ans - ans) - ans - ans) unFR (FR x) = x It has a rank-2 type. The defining equations are: if flst is a value of a type |FR a|, then unFR flst f z = z if flst represents an empty list unFR flst f z = f e (unFR flst' f z) if flst represents the list with the head 'e' and flst' represents the rest of that list Presumably you noticed that this is isomorphic to the representation of a list in lambda calculus, right? Peace, Dylan signature.asc Description: Digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Data types and Haskell classes
On Tue, May 17, 2005 at 01:13:17PM +0200, Jens Blanck wrote: How would I introduce number classes that are extended with plus and minus infinity? I'd like to have polymorphism over these new classes, something like a signature f :: (Real a, Extended a b) = b - b which clearly is not part of the current syntax, but I hope you get the picture. What are the elegant ways of doing this? How about f :: Real a = Extended a - Extended a Not quite what I had in mind. I'd like to have extended integers and extended rationals, and possibly extended dyadic numbers. So I can't have just a single type ExtendedRational (unless I'm prepared to do some ugly coersing). You're missing the point. Try: data Extended a = PlusInf | NegInf | Finite a Peace, Dylan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: mathematical notation and functional programming
On Fri, Feb 04, 2005 at 03:08:51PM +0100, Henning Thielemann wrote: On Thu, 3 Feb 2005, Dylan Thurston wrote: On Fri, Jan 28, 2005 at 08:16:59PM +0100, Henning Thielemann wrote: O(n) which should be O(\n - n) (a remark by Simon Thompson in The Craft of Functional Programming) I don't think this can be right. Ken argued around this point, but here's a more direct argument: in f(x) = x + 1 + O(1/x) all the 'x's refer to the same variable; so you shouldn't go and capture the one inside the 'O'. I didn't argue, that textually replacing all O(A) by O(\n - A) is a general solution. For your case I suggest (\x - f(x) - x - 1) \in O (\x - 1/x) This kind of replacement on the top level is exactly what continuations (which Ken was suggesting) can acheive. If you think carefully about exactly what the big-O notation means in general expressions like this, you'll be led to the same thing. I haven't yet seen the expression 2^(O(n)). I would interpret it as lifting (\x - 2^x) to sets of functions, then applying it to the function set O(\n - n). But I assume that this set can't be expressed by an O set. That's right; for instance, in your terminology, 3^n is in 2^(O(n)). But I see people writing f(.) + f(.-t) and they don't tell, whether this means (\x - f x) + (\x - f (x-t)) or (\x - f x + f (x-t)) Have you really seen people use that notation with either of those meanings? In principle, yes. I'm curious to see examples. That's really horrible and inconsistent. I would have interpreted f(.) + f(.-t) as \x \y - f(x) + f(y-t) to be consistent with notation like .*. , which seems to mean \x \y - x*y in my experience. The problems with this notation are: You can't represent constant functions, which is probably no problem for most people, since they identify scalar values with constant functions. But the bigger problem is the scope of the dot: How much shall be affected by the 'functionisation' performed by the dot? The minimal scope is the dot itself, that is . would mean the id function. But in principle it could also mean the whole expression. I think there are good reasons why such a notation isn't implemented for Haskell. But I have seen it in SuperCollider. I certainly don't want to defend this notation... Now that you mention it, Mathematica also has this notation, with explicit delimiters; for instance, `(#+2)' is the function of adding two. Peace, Dylan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: mathematical notation and functional programming
(Resurrecting a somewhat old thread...) On Fri, Jan 28, 2005 at 08:16:59PM +0100, Henning Thielemann wrote: On Fri, 28 Jan 2005, Chung-chieh Shan wrote: But I would hesitate with some of your examples, because they may simply illustrate that mathematical notation is a language with side effects -- see the third and fifth examples below. I can't imagine mathematics with side effects, because there is no order of execution. Not all side effects require an order of execution. For instance, dependence on the environment is a side effect (in the sense that it is related to a monad), but it does not depend on the order of execution. There are many other examples too, like random variables. O(n) which should be O(\n - n) (a remark by Simon Thompson in The Craft of Functional Programming) I don't think this can be right. Ken argued around this point, but here's a more direct argument: in f(x) = x + 1 + O(1/x) all the 'x's refer to the same variable; so you shouldn't go and capture the one inside the 'O'. This is established mathematical notation, it's very useful, and can be explained almost coherently. The one deficiency is that we should interpret 'O' as an asymptotically bounded function of... but that doesn't say what it is a function of and where we should take the asymptotics. But the patch you suggest doesn't really help. But what do you mean with 1/O(n^2) ? O(f) is defined as the set of functions bounded to the upper by f. So 1/O(f) has no meaning at the first glance. I could interpret it as lifting (1/) to (\f x - 1 / f x) (i.e. lifting from scalar reciprocal to the reciprocal of a function) and then as lifting from a reciprocal of a function to the reciprocal of each function of a set. Do you mean that? I think this is the only reasonable generalization from the established usage of, e.g., 2^(O(n)). In practice, this means that 1/O(n^2) is the set of functions asymptotically bounded below by 1/kn^2 for some k. Hm, (3+) is partial application, a re-ordered notation of ((+) 3), which is only possible if the omitted value is needed only once. But I see people writing f(.) + f(.-t) and they don't tell, whether this means (\x - f x) + (\x - f (x-t)) or (\x - f x + f (x-t)) Have you really seen people use that notation with either of those meanings? That's really horrible and inconsistent. I would have interpreted f(.) + f(.-t) as \x \y - f(x) + f(y-t) to be consistent with notation like .*. , which seems to mean \x \y - x*y in my experience. It seems to me that the dot is somehow more variable than variables, and a dot-containing expression represents a function where the function arguments are inserted where the dots are. Right. I don't know how to formalize this, but that doesn't mean it can't be done. Peace, Dylan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Real life examples
On Wed, Nov 24, 2004 at 01:34:31AM -0800, John Meacham wrote: Part of my current interest in #2 is that I have been experimenting with some full-program optimization algorithms which could perhaps give substantial gains but would pretty much obliterate any uses of the unsafePerformIO global variable hack, and no pragma can save them. Before this, I never realized just how uncorrect the global variable use of unsafePerformIO was :) That sounds fascinating. Can you say more about the optimizations in question, and why the hack is so incorrect? Peace, Dylan signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] implicit parameters and the paper prepose.pdf
On Sat, Nov 20, 2004 at 09:26:08AM -0800, John Velman wrote: In a recent message to this list (msg15410) Oleg referenced a paper comparing implicit parameters and implicit configurations with url http://www.eecs.harvard.edu/~ccshan/prepose/prepose.pdf . I'd like to read this, (and examine the companion literate haskell file prepose.lhs), but www.eecs.harvard.edu rejects my connection. Nor can I find it anywhere else. Is this paper still available somewhere, or is it possible for someone to send me a copy? There was a cracker that broke in to eecs.harvard.edu, so they took the web server down temporarily till they find and fix the hole. Meanwhile you can get it from http://donkeykong.eecs.harvard.edu/~ccshan/prepose/prepose.pdf Peace, Dylan signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] foldlWhile
On Sat, Nov 20, 2004 at 12:47:58PM +0300, Serge D. Mechveliani wrote: Is such a function familia to the Haskell users? foldlWhile :: (a - b - a) - (a - Bool) - a - [b] - a foldlWhilefp abs = case (bs, p a) of ([],_) - a (_, False) - a (b:bs', _) - foldlWhile f p (f a b) bs' foldl does not seem to cover this. Why not just foldlWhile f p a bs = takeWhile p $ foldl f a bs ? More `generic' variant: foldlWhileJust :: (a - b - Maybe a) - a - [b] - a foldlWhileJustf abs = case bs of []- a b:bs' - case f a b of Just a' - foldlWhileJust f a' bs' _ - a I don't know a short way to rewrite this one yet. Peace, Dylan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] foldlWhile
On Sat, Nov 20, 2004 at 03:48:23PM +, Jorge Adriano Aires wrote: On Sat, Nov 20, 2004 at 12:47:58PM +0300, Serge D. Mechveliani wrote: foldlWhile :: (a - b - a) - (a - Bool) - a - [b] - a foldlWhilefp abs = case (bs, p a) of ([],_) - a (_, False) - a (b:bs', _) - foldlWhile f p (f a b) bs' Why not just foldlWhile f p a bs = takeWhile p $ foldl f a bs Quite different. The former stops a foldl when the accumulating parameter no longer satisfies p, the later assumes the accumulating parameter of the foldl is a list, and takes the portion of the list that does satisfy p. Yes, this was a mistake. The following is closer to the original, but doesn't work when the whole list is folded (i.e., p always satisfied): foldlWhile f p a = head . dropWhile p . scanl f a Serge's version returns the last 'a' that satisfies 'p', while yours returns the first 'a' that does not satisfy 'p'. This should be an equivalent version: foldlWhile f p a = tail . takeWhile p . scanl f a But what about the version with Maybe? There ought to be a concise way to write that too. Peace, Dylan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: About Random Integer without IO
On Fri, Nov 12, 2004 at 02:15:51PM +0100, Jerzy Karczmarczuk wrote: First, we don't care about 'real random' numbers, actually there are problems even with their definition. We need sequences which *behave* randomly, from the point of view of feasible tests, spectral/statistical; correlational, etc. While this is true (and important) for the applications you have in mind, there are other applications. For instance, in cryptography there is often a need for true random numbers, or as close as you can get. I'm not sure what the whole discussion is about, anyway. Is it about dealing with random numbers practically in Haskell? Peace, Dylan signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Double - CDouble, realToFrac doesn't work
On Thu, Nov 04, 2004 at 08:32:52PM +0100, Sven Panne wrote: It's an old thread, but nothing has really happened yet, so I'd like to restate and expand the question: What should the behaviour of toRational, fromRational, and decodeFloat for NaN and +/-Infinity be? Even if the report is unclear here, it would be nice if GHC, Hugs, and NHC98 agreed on something. Can we agree on the special Rational values below? I would be very careful of adding non-rationals to the Rational type. For one thing, it breaks the traditional rule for equality a % b == c % d iffa*d == b*c You'd need to look at all the instances for Ratio a that are defined. For instance, the Ord instance would require at least lots of special cases. And when would you expect 'x/0' to give +Infinity and when -Infinity? For IEEE floats, there are distinct representations of +0 and -0, which lets you know when you want which one. But for the Rational type there is no such distinction. The behaviour that '1 % 0' gives the error 'Ratio.% : zero denominator' is clearly specified by the Library Report. In the meantime, there are utility functions for dealing with IEEE floats (isNaN, etc.) Peace, Dylan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Double - CDouble, realToFrac doesn't work
On Fri, Nov 05, 2004 at 02:53:01PM +, MR K P SCHUPKE wrote: My guess is because irrationals can't be represented on a discrete computer Well, call it arbitrary precision floating point then. Having built in Integer support, it does seem odd only having Float/Double/Rational... There are a number of choices to be made in making such an implementation. It would be handy, but it makes sense that it's more than the Haskell designers wanted to specify initially. It would make a nice library if you want to write it. Peace, Dylan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] Re: Double - CDouble, realToFrac doesn't work
On Thu, Nov 04, 2004 at 08:32:52PM +0100, Sven Panne wrote: It's an old thread, but nothing has really happened yet, so I'd like to restate and expand the question: What should the behaviour of toRational, fromRational, and decodeFloat for NaN and +/-Infinity be? Even if the report is unclear here, it would be nice if GHC, Hugs, and NHC98 agreed on something. Can we agree on the special Rational values below? I would be very careful of adding non-rationals to the Rational type. For one thing, it breaks the traditional rule for equality a % b == c % d iffa*d == b*c You'd need to look at all the instances for Ratio a that are defined. For instance, the Ord instance would require at least lots of special cases. And when would you expect 'x/0' to give +Infinity and when -Infinity? For IEEE floats, there are distinct representations of +0 and -0, which lets you know when you want which one. But for the Rational type there is no such distinction. The behaviour that '1 % 0' gives the error 'Ratio.% : zero denominator' is clearly specified by the Library Report. In the meantime, there are utility functions for dealing with IEEE floats (isNaN, etc.) Peace, Dylan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Double - CDouble, realToFrac doesn't work
On Fri, Nov 05, 2004 at 02:53:01PM +, MR K P SCHUPKE wrote: My guess is because irrationals can't be represented on a discrete computer Well, call it arbitrary precision floating point then. Having built in Integer support, it does seem odd only having Float/Double/Rational... There are a number of choices to be made in making such an implementation. It would be handy, but it makes sense that it's more than the Haskell designers wanted to specify initially. It would make a nice library if you want to write it. Peace, Dylan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: deriving...
On Tue, Oct 19, 2004 at 08:08:49PM +0200, Andres Loeh wrote: Simon Peyton-Jones wrote: derive( Typeable (T a) ) But that means adding 'derive' as a keyword. Other possibilities: deriving( Typeable (T a) ) ... Any other ideas? instance Typeable (T a) deriving Why not even simply instance Typeable (T a) This already has a meaning in Haskell 98: it means that all class members are undefined. This is sometimes useful. Peace, Dylan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] strictness and the simple continued fraction
On Mon, Oct 11, 2004 at 09:53:16PM -0400, Scott Turner wrote: Evenutally I realized that calculating with lazy lists is not as smooth as you might expect. For example, the square root of 2 has a simple representation as a lazy continued fraction, but if you multiply the square root of 2 by itself, your result lazy list will never get anywhere. The calculation will keep trying to determine whether or not the result is less than 2, this being necessary to find the first number in the representation. But every finite prefix of the square root of 2 leaves uncertainty both below and above, so the determination will never be made. Right, one way to think about this problem is that the representations by continued fractions are unique, so there's no way to compute the prefix of a representation for something right on the boundary. Representing numbers by lazy strings of, say, decimal digits has the same problem. There are known solutions, but they lack the elegance of continued fraction representations. You fundamentally have to have non-unique representations, and that causes some other problems. One popular version is to use base 2 with digits -1, 0, and +1. Simon Peyton-Jones already posted the references. These methods appear to lose out in practice to using a large fixed precision and interval arithmetic, increasing the precision and recomputing as necessary. Peace, Dylan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strings - why [Char] is not nice
On Mon, Sep 20, 2004 at 01:11:34PM +0300, Einar Karttunen wrote: Size Handling large amounts of text as haskell strings is currently not possible as the representation (list of chars) is very inefficient. You know about the PackedString functions, right? http://www.haskell.org/ghc/docs/6.0/html/base/Data.PackedString.html Peace, Dylan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] for large x, log (x::Integer) :: Double
On Tue, Jul 13, 2004 at 05:01:32PM +0800, Dylan Thurston wrote: This library will let you use a shift instead of a division, but won't give you a constant time size function for Integers. You can easily get a logarithmic time size function from the shift. But did you see Data.Bits.bitsize? My mistake, bitSize is not useful for this purpose. Peace, Dylan signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
'-fno-implicit-prelude' doesn't use local fromRational
The '-fno-implicit-prelude' flag uses the locally in scope fromInteger function for integer literals, but oddly always uses the global Prelude's fromRational function. Peace, Dylan signature.asc Description: Digital signature ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell] for large x, log (x::Integer) :: Double
On Mon, Jul 05, 2004 at 10:08:04AM +0100, Edmund GRIMLEY EVANS wrote: Does Haskell provide any means of determining the number of binary digits in an Integer other than by repeated division? See the Data.Bits library: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data.Bits.html Peace, Dylan signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] for large x, log (x::Integer) :: Double
On Wed, Jun 30, 2004 at 03:07:00PM -0700, Greg Buchholz wrote: -- Inspired from Mr. Howard Oakley. Might not qualify as good, -- but with this function I get log10(x)=849.114419903382 ... For those who aren't aware: working with logs base 2 internally will be very much faster than logs base 10, since the numbers are stored internally in a base-2 representation. (Note that 'show' converts to base 10, which involves a large number of divisions in the easy algorithm.) Peace, Dylan signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: HaRP (Haskell Regular Patterns) version 0.1
This looks very interesting! I sometimes wish Haskell had more powerful binding facilities, so that things like this don't need to be extensions to the language. (But I'm not sure exactly what I'm wishing for...) On Sat, May 15, 2004 at 12:08:53PM +, Niklas Broberg wrote: Introducing regular expressions into the pattern matching facility gives some extra nice features. One is that the regular patterns are type safe, i.e. they are not encoded in strings. Another is that identifiers can be named and bound inside regular patterns, examples: foo [/ _* a /] = ... = a is bound to the last element of the list foo [/ a@(/ _ _ /) _* /] = ... = a is bound to the list containing the first two elements foo [/ (/ a _ /)* /] = ... = a is bound to the list of the first, third, fifth etc elements of a list of even length What about foo [/ (/ 2 (/ a _ /)* 3 /)* /] = a ? What is the type of a here? I think it should be [[Int]]. And then which special syntax for implicit binding am I supposed to use? Is it foo [/ (/ 2 (/ a@:(/_ _/) _ /)* 3 /)* /] = a or maybe foo [/ (/ 2 (/ a@::(/_ _/) _ /)* 3 /)* /] = a ? And what's the type? [[[Int]]]? Peace, Dylan signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: HaRP (Haskell Regular Patterns) version 0.1
On Sat, May 15, 2004 at 04:42:03PM +, Niklas Broberg wrote: In non-linear context, the type is a list of what it would otherwise be, regardless of what and how many enclosing non-linear regular pattern operators. So I guess that in foo [/ a? 2 b /] = (a,b) the type of a is '[Int]', not 'Maybe Int', right? Hopefully I make sense (more than before?). Yes, I think that's clearer. I'm starting to think maybe our context dependent approach to implicit bindings isn't very good after all since it seems to confuse a lot of people. Perhaps variables bound inside regular patterns should always be non-linear... of course that would still be context dependent when compared to normal Haskell patterns, but perhaps still less confusing? Alternatively, you could forbid the use of simple variables nonlinearly, since there's an alternative way to write it. Or, you could make variables (and other pattern binding) more context dependent, recording all the relevant parts of the context (and not just whether the context is linear or not), if that makes sense. Interesting issues, anyway! By the way, are nested regular expression matches allowed? Something like: foo :: [[Int]] - Int foo [/ _* [/ 5* a 6* /] _* /] = a ? If so, what is the type of a in foo [/ _* [/ 5* a* /]* _* /] ? Peace, Dylan signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Dynamically loading wxhaskell?
On Wed, Apr 14, 2004 at 09:37:02AM +0100, Simon Marlow wrote: ... That symbol looks suspiciously like it comes from the separate OpenGL parts of WX, which reside in a separate library (/usr/lib/libwx_gtk_gl-2.4.so here). On my system, libwxc has an explicit dependency on libwx_gtk_gl, because it was linked against it. Did you configure wxHaskell with --with-opengl? No, and that fixed it, thanks! I was confused because I had gotten wx to work with ghc (not ghci) earlier. Peace, Dylan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Dynamically loading wxhaskell?
On Tue, Apr 13, 2004 at 03:53:31PM +0100, Simon Marlow wrote: I tried stripping /usr/lib/libwx_gtk-2.4.so.0.1.1 and libwxc-0.6.so, and GHCi was still able to load the wx package successfully. In fact, libwx_gtk appeared to be already stripped. What error messages do you get, specifically? Here it is: --- Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package lang ... linking ... done. Loading package concurrent ... linking ... done. Loading package QuickCheck ... linking ... done. Loading package readline ... linking ... done. Loading package unix ... linking ... done. Loading package posix ... linking ... done. Loading package util ... linking ... done. Loading package data ... linking ... done. Loading package wxcore ... ghc-6.2.1: can't load .so/.DLL for: wxc-gtk2.4.2-0.7 (/usr/local/stow/wxhaskell//lib/libwxc-gtk2.4.2-0.7.so: undefined symbol: _ZN10wxGLCanvasC1EP8wxWindowiRK7wxPointRK6wxSizelRK8wxStringPiRK9wxPalette) -- I suspect it's something funny with Debian's setup, and quite possibly a bug somewhere else in Debian. Peace, Dylan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Dynamically loading wxhaskell?
On Fri, Apr 02, 2004 at 01:59:08PM +0100, Simon Marlow wrote: Very strange. Is /usr/lib/libdl.so perhaps a symlink to a library that doesn't exist? That could happen if an upgrade had gone wrong, perhaps. Thanks, it was a dangling symlink due to my filesystem layout. Sorry for the stupidity. But it still won't run, because (apparently) ghci won't work with stripped .so files, and Debian policy is to strip them. From the Debian policy manual, section 10.2: All installed shared libraries should be stripped with strip --strip-unneeded your-lib (The option `--strip-unneeded' makes `strip' remove only the symbols which aren't needed for relocation processing.) Shared libraries can function perfectly well when stripped, since the symbols for dynamic linking are in a separate part of the ELF object file.[1] [1] You might also want to use the options `--remove-section=.comment' and `--remove-section=.note' on both shared libraries and executables, and `--strip-debug' on static libraries. Any chance of fixing this in ghci, or do I have to keep an extra copy of wxwidgets installed? What tool does ghci use for its dynamic loading? Peace, Dylan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Context for type parameters of type constructors
On Sat, Apr 03, 2004 at 01:35:44PM +0200, Henning Thielemann wrote: (I like to omit -fallow-undecidable-instances before knowing what it means) There's a nice section in the GHC user's manual on it. I can't add anything to that. -- a classical linear space class VectorSpace v a where zero :: v add :: v - v - v scale :: a - v - v You might want to add a functional dependency, if you only have one type of scalars per vertor space: class VectorSpace v a | v - awhere zero :: v add :: v - v - v scale :: a - v - v But then again, you might not. instance Num a = VectorSpace a a where zero = 0 add = (+) scale = (*) Here the compiler complains the first time: VectorSpace.lhs:27: Illegal instance declaration for `VectorSpace a a' (There must be at least one non-type-variable in the instance head Use -fallow-undecidable-instances to permit this) In the instance declaration for `VectorSpace a a' Well, you know how to fix this... Another way to fix it is to add a dummy type constructor: newtype Vector a = Vector a instance Num a = VectorSpace (Vector a) a Later: instance Num a = VectorSpace [a] a where By the way, depending how you resolve the issue above, you might want instead instance (RealFloat a, VectorSpace b a) = VectorSpace [b] a where ... Now I introduce a new datatype for a vector valued quantity. The 'show' function in this simplified example may show the vector with the magnitude separated from the vector components. ... The problem which arises here is that the type 'a' is used for internal purposes of 'show' only. Thus the compiler can't decide which instance of 'Normed' to use if I call 'show': This is exactly what is fixed by adding the functional dependency above. Alternatively, if you want to consider varying the scalars, you can add 'a' as a dummy type variable to 'Quantity': data Quantity v a = Quantity v instance (Show v, Fractional a, Normed v a) = Show (Quantity v a) where show (Quantity v) = let nv::a = norm v in (show (scale (1/nv) v)) ++ * ++ (show nv) GHC still won't accept this without prompting, but now at least you can provide a complete type: *VectorSpace show (Quantity [1,2,3] :: Quantity [Double] Double) [0.1,0.,0.5]*6.0 Note that this makes sense semantically: if you have a vector space over both, say, the reals and the complexes, you need to know which base field to work over when you normalize. So I tried the approach which is more similar to what I tried before with a single-parameter type class: I use a type constructor 'v' instead of a vector type 'v' ... data QuantityC v a = QuantityC (v a) instance (Fractional a, NormedC v a, Show (v a)) = Show (QuantityC v a) where show (QuantityC v) = let nv = normC v in (show (scaleC (1/nv) v)) ++ * ++ (show nv) It lead the compiler eventually fail with: VectorSpace.lhs:138: Non-type variables in constraint: Show (v a) (Use -fallow-undecidable-instances to permit this) In the context: (Fractional a, NormedC v a, Show (v a)) While checking the context of an instance declaration In the instance declaration for `Show (QuantityC v a)' Hmm, I don't know how to fix up this version. Peace, Dylan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Dynamically loading wxhaskell?
On Thu, Apr 01, 2004 at 10:00:23AM +0100, Simon Marlow wrote: Has anyone succeeded in getting wxhaskell to work under ghci on Linux? On my system, I get an error message Loading package unix ... ghc-6.2: can't load .so/.DLL for: dl (libdl.so: cannot open shared object file: No such file or directory) This sounds like it has nothing to do with wxhaskell, but is a GHC problem. Any pointers? Is libdl.so in the usual place? (/usr/lib on my system) Yes. (FYI, this is a Debian unstable system.) Everything works with GHC, by the way. Peace, Dylan signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Dynamically loading wxhaskell?
Has anyone succeeded in getting wxhaskell to work under ghci on Linux? On my system, I get an error message Loading package unix ... ghc-6.2: can't load .so/.DLL for: dl (libdl.so: cannot open shared object file: No such file or directory) This sounds like it has nothing to do with wxhaskell, but is a GHC problem. Any pointers? Thanks, Dylan signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Context for type parameters of type constructors
On Mon, Mar 29, 2004 at 06:00:57PM +0200, Henning Thielemann wrote: Thus I setup a type constructor VectorSpace in the following way: module VectorSpace where class VectorSpace v where zero :: v a add :: v a - v a - v a scale :: a - v a - v a I haven't added context requirements like (Num a) to the signatures of 'zero', 'add', 'scale' because I cannot catch all requirements that instances may need. The problematic part is the 'scale' operation because it needs both a scalar value and a vector. Without the 'scale' operation 'v' could be simply a type (*) rather than a type constructor (* - *). Right. I recommend you use multi-parameter type classes, with a type of the scalars and the type of the vectors. For the method you're using, you need to add a 'Num a' context. You say that you 'cannot catch all requirements that instances may need', but certainly any instance will need that context. If you use multi-parameter type classes, then in your instance declaration you can specify exactly what requirements you need. For instance: class VectorSpace v a where zero :: v add :: v - v - v scale :: a - v - v instance VectorSpace IntArray Int where ... instance (Num a) = VectorSpace (GenericArray a) a where ... Peace, Dylan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Proposal for a Standard of Abstract Collections (with Reference Implementation)
Another comment is that it looks too complicated. Your basic Collection class has 30 members, and some of them are clearly excessive: do you really need all of has, elem, (#), not_elem, and (/#) in the class (rather than defined as auxiliary functions, possibly optimised with fusion)? (Of course, these particular functions should be in a subclass that has equality on the arguments...) For another example, how could zip possibly be given a more efficient implementation than the one you provide? (And furthermore, a function 'zip' obviously doesn't make sense on general collections. Even for sequences, it can't be democratic, so probably doesn't belong in the class.) Please try to simplify the interface more! Peace, Dylan signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haddock, QuickCheck, and Functional Design by Contract
(Reviving an old message here. You can see the original message at http://www.stud.tu-ilmenau.de/~robertw/haskell/doc/contract_notations.lhs ) On Tue, Feb 17, 2004 at 10:50:30AM +0100, Robert Will wrote: 4. A notation for preconditions. ... Presently I use the following coding style: take n xs | not (n = 9) = error take.Precondition The precondition can simply be extracted as the bracketed expression behind @not@ in a line containing the words @error@ and Precondition. However it has the disadvantage that I can't simply disable run-time checking of the Precondition (as I could when using @assert@). Furthermore it is also rather ugly. Does anyone have a better idea? This doesn't help with ugliness, but you could define an auxiliary function: take n xs | check (n = 9) = error take.Precondition check :: Bool - Bool check = not or, for testing, check = const True 5. Default implementations of type class members are often a special case of specification functions: the overwriting provides the same semantics, more efficiently. (Occurs often in Abstract Data Structures, see [2].) A typical example is: is_empty coll = size coll == 0 -- || We can use the double bar (or whatever we decide to standardise), to mark the function definition for export to the documentation. However, it is more difficult to create test properties which compare the two implementations of a function, since the default implementation is no more accessible after having been overwritten. The property generator will have to copy the default definition to a definition with name @is_empty_spec@ (for example) and can then generate the usual @prop_is_empty_spec@ (as in point 2). The copying of the function definition happens only for testing and is not seen in normal code or documentation. I'm not sure how relevant it is, but one thing I found when working on revising the numeric hierarchy in the Standard Prelude was that I often wanted a default implementation that I had standard default definitions that I couldn't actually make a default class instance, because of the way the hierarchy was built up. For instace, with exponentiation, there are two default definitions, one that works with positive powers and one that works with positive and negative powers, but only in the subclass with division. The current standard has, in a fairly ugly way, two different operators for these two functions; I preferred to combine the two by making the operation a class member. I hope your standard would provide an obvious way to name such default definitions which work only in a subclass. Peace, Dylan signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Proposal for a Standard of Abstract Collections (with Reference Implementation)
It looks interesting and I'm still looking at it, although I think many of the language extensions need to be better thought out. But it exhibits the creeping Eq problem: your hierarchy starts class (Eq (coll a), Eq a) = Collection coll a where ... If this is to replace lists, this is unacceptable: I can't have lists of (say) functions? Collection classes should not require Eq instances on the members, except when necessary! Peace, Dylan signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Storing functional values
On Fri, Jan 30, 2004 at 09:21:58AM -0700, [EMAIL PROTECTED] wrote: Hi, I'm writing a game in Haskell. The game state includes a lot of closures. For example, if a game object wants to trigger an event at a particular time, it adds a function (WorldState - WorldState) to a queue. Similarly there are queues which contain lists of functions which respond to events. (CreatureAttackEvent - WorldState - WorldState) I'd like to be able to save the game state to disk so that it can be reloaded. Obviously, these closures are now a problem, as they can't be stored. It seems like there are two things you want to do with these functional closures: save them to disk, and run them as functions. Why not combine these two into a type class? Peace, Dylan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Type design question
On Mon, Jul 28, 2003 at 03:42:11PM +0200, Konrad Hinsen wrote: On Friday 25 July 2003 21:48, Dylan Thurston wrote: Another approach is to make Universe a multi-parameter type class: class (RealFrac a, Floating a) = Universe u a | u - a where distanceVector :: u - Vector a - Vector a - Vector a ... You need to use ghc with '-fglasgow-exts' for this. What is the general attitude in the Haskell community towards compiler-specific extensions? My past experience with Fortran and C/C++ tells me to stay away from them. Portability is an important criterion for me. I think it depends on the extension. I find multi-parameter type classes genuinely very useful, and the functional dependencies notation (the '| u - a' above) has been around for a while and seems to be becoming standard. Hugs, for instance, implements these same extensions, and it seems very likely to me to be part of the next Haskell standard. On the other hand, some ghc extensions, like generic Haskell, seem much more preliminary to me; if you want portable code, I would stay away from them. There was some discussion earlier about formalising some of these extensions. As far as I know, the FFI is the only one for which this has been completed; but I think multi-parameter type classes would be a natural next choice. Peace, Dylan pgp0.pgp Description: PGP signature
Re: Type design question
On Mon, Jul 28, 2003 at 11:59:48AM +1000, Andrew J Bromage wrote: G'day all. On Fri, Jul 25, 2003 at 03:48:15PM -0400, Dylan Thurston wrote: Another approach is to make Universe a multi-parameter type class: class (RealFrac a, Floating a) = Universe u a | u - a where distanceVector :: u - Vector a - Vector a - Vector a ... Actually, this is a nice way to represent vector spaces, too: class (Num v, Fractional f) = VectorSpace vs v f | vs - v f where scale :: vs - f - v - v innerProduct :: vs - v - v - f The reason why you may want to do this is that you may in general want different inner products on the same vectors, which result in different vector spaces. Hmm, that's an interesting technique, which I'll have to try out; there are several instances where you want different versions of the same structure on some elements. This is an interesting alternative to newtype wrapping or some such. However, I would be sure to distinguish between an inner product space and a vector space. A vector space has only the 'scale' operation above (beyond the +, -, and 0 from Num); you will rarely want to have different versions of the scale operation for a given set of vectors and base field. An inner product space has the 'innerProduct' operation you mention; as you say, there is very frequently more than one interesting inner product. Peace, Dylan pgp0.pgp Description: PGP signature
Re: Type design question
On Fri, Jul 25, 2003 at 08:31:26AM -0700, Hal Daume wrote: However, once we fix this, we can see the real problem. Your Universe class has a method, distanceVector, of type: | distanceVector :: Universe u, Floating a = u - Vector a - Vector a - Vector a And here's the problem. When 'u' is 'OrthorhombicUniverse x', it doesn't know that this 'x' is supposed to be the same as the 'a'. One way to fix this is to parameterize the Universe data type on the element, something like: class Universe u where distanceVector :: (RealFrac a, Floating a) = u a - (Vector a) - (Vector a) - (Vector a) ... Another approach is to make Universe a multi-parameter type class: class (RealFrac a, Floating a) = Universe u a | u - a where distanceVector :: u - Vector a - Vector a - Vector a ... You need to use ghc with '-fglasgow-exts' for this. Peace, Dylan pgp0.pgp Description: PGP signature
Re: Superclass Defaults
On Mon, Jul 21, 2003 at 06:21:33AM -0700, Ashley Yakeley wrote: Well I don't doubt this would be a very useful extension to the Haskell language: indeed it would eliminate code in all my Haskell projects. But before we can propose this, we have to work out what the syntax would look like. Here are some properties I think such a mechanism should have: 1. It should be possible to declare types as instances of Monad and Functor with a different definition of fmap overriding the default. 2. It should be possible to declare another subclass of Functor that also has a default for fmap. 3. The members of any existing class should be subclass-defaultable in another module; i.e., no special syntax should be involved in the class declaration of the superclass. 4. It should be possible to distinguish between different appearances of the same class in the superclass context. For instance: class C a where c :: Int - a class (C a,C b,C (a - b)) = D a b where ... I agree with all these desiderata. I don't think any new syntax is necessarily needed. With regards to point 4, note that just giving a type signature is guaranteed to be enough to tell you _which_ instance of class C you are referring to. I think there are likely to be subtle semantic issues, however. Also, it seems strange to have default methods in class declarations if you don't also allow such declarations in instance declarations. Peace, Dylan pgp0.pgp Description: PGP signature
Re: User-Defined Operators, Re: Function composition and currying
On Fri, Jul 18, 2003 at 11:39:48AM +1000, Andrew J Bromage wrote: Someone mentioned multiplying by a scalar. I think this is a good application, but what we need is to agree (somehow) on the symbol used. I've used (*.) and (.*), with the dot being on the side the scalar is on (on the grounds that . is a scalar product elsewhere), but without wide agreement I agree that this sort of thing reduces readability, because while I can read these programmes, it's harder for everyone else. Yuck. :-) What's wrong with that solution? You might hope for something better, but it seems like it would work for, e.g., your situation below. Here are my concrete suggestions, using a variant of this notation; however, I mark the side that does _not_ have the scalar, on the grounds that scalar * scalar should be the original operator, and use '*' or '*' to do it. I've run into the same problem with affine algebra, which has two types, the Point and the Vector, where a Vector is the difference between two Points: Vector + Vector = Vector v1 + v2 = v3 Vector + Point = Point v1 + p1 = p2 Point + Vector = Point p1 + v1 = p2 Point + Point is an error Vector - Vector = Vector v1 - v2 = v3 Point - Vector = Point p1 - v1 = p2 Vector - Point = Point -- (this rule is a bit controversial) This one is obviously an error. Add Point to both sides to get the error that you noted above. Point - Point = Vector p1 - p2 = v1 The other potential solution is to use an 'Additive' class class Additive a b c | a b - c, c a - b, c b - a where (+) :: a - b - c class (Additive c b a) = Subtractive a b c where (-) :: a - b - c One solution might be to relax the rules about how the types of operators are resolved. At the moment, you can define function names from different modules and all you need to do is qualify them when you use them. It's a little odd that you can't do something similar with operators, though no succinct syntax leaps to mind. But you can use qualified names for operators! It just looks incredibly ugly. But you could write, say, 1 Float.+ 2 Peace, Dylan pgp0.pgp Description: PGP signature
Re: User-Defined Operators, Re: Function composition and currying
On Sat, Jul 19, 2003 at 02:06:44PM +1000, Andrew J Bromage wrote: G'day all. On Fri, Jul 18, 2003 at 04:08:25AM -0400, Dylan Thurston wrote: What's wrong with that solution? Working with these operators, I would spend a significant amount of time getting the '' and '' notations right rather than writing code. I don't like that. For example, using the suggested notation: v1 + v2 = v3 v1 + p1 = p2 p1 + v1 = p2 Quickly, without thinking too much, where do the '' and '' signs go here? p1 + v1 + v2 v1 + v2 + p1 v1 + p1 + v2 Easy: p1 + (v1 + v2) or (p1 + v1) + v2 (v1 + v2) + p1 v1 + p1 + v2 The parens are slightly annoying (and to drop them I'd have to remember that the associativity of the operators), but they're mathematically clear. It's maybe easiest to think in terms of group theory with an action on a set: you're just distinguishing between the multiplication of group elements and the actual action. This distinction is not usually reflected in the notation, but it's really not such a hardship. p1 - v1 = p2 I'm pretty sure that's a syntax error. If not, it probably should be. Oh, I missed that. Yes. Vector - Point = Point -- (this rule is a bit controversial) This one is obviously an error. Add Point to both sides to get the error that you noted above. It depends. If you allow the parity inversion operator -Point, then this operation makes a certain amount of sense. Some implementations (e.g. RenderMan) allow it, some don't. But if you have -Point, then you have a 0 Point, and there's no distinction between Points and Vectors at all! (But then, RenderMan defines Point + Bivector = Point. Clifford algebraists may now run screaming.) I tried to think about what that should mean, and did not succeed. What is this operation? The other potential solution is to use an 'Additive' class class Additive a b c | a b - c, c a - b, c b - a where (+) :: a - b - c class (Additive c b a) = Subtractive a b c where (-) :: a - b - c Actually, that's not bad at all. It's certainly better than my previous suggestion of only putting a b - c on Additive typeclass. As I recall, the extra functional dependencies don't help very much in practice with the ambiguities previously noted. But you should try it for yourself. Peace, Dylan pgp0.pgp Description: PGP signature
Re: Arrow Classes
On Tue, Jul 15, 2003 at 01:07:12AM -0700, Ashley Yakeley wrote: In article [EMAIL PROTECTED], Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] wrote: It doesn't provide instances of Num for anything which is already an instance of the other classes. And in Haskell 98 they must be defined separately for each type, instance (...) = Num a doesn't work. It works in extended Haskell however, so I suspect it lays to rest the question of needing some other language extension. I disagree! This method (putting each function in its own class) does not address two related points: a) Being able to declare default values for a method declared in a superclass; b) Being able to refine a type heirarchy without the users noticing (and without explosion of the number of instance declarations required). Peace, Dylan pgp0.pgp Description: PGP signature
Re: How overload operator in Haskell?
On Fri, Jul 11, 2003 at 05:38:18PM +1000, Andrew J Bromage wrote: G'day all. On Thu, Jul 10, 2003 at 11:16:56PM -0700, Ashley Yakeley wrote: As written, this is _not_ a good idea. Trust me, you end up having to put type annotations everywhere. Even (3 + 4 :: Integer) is ambiguous, you have to write (3 :: Integer) + (4 :: Integer). But that's what default() is for! Don't be silly: the default mechanism is a very special case that is not good for general use. It would make all user-defined numeric types essentially unuseable, for one thing. (Unless you have a proposal to make the default mechanism more general?) Peace, Dylan pgp0.pgp Description: PGP signature
Costs of a class hierarchy
On Thu, Jul 10, 2003 at 02:33:25PM +0100, Ross Paterson wrote: Subclasses in Haskell cover a range of relationships, including this sense where things in the subclass automatically belong to the superclass. Other examples include Eq = Ord and Functor vs Monad. In such cases it would be handy if the subclass could define defaults for the superclass methods (e.g. Ord defining (==)), so that the superclass instance could be optional. I agree, but this needs to be carefully thought out. For instance, remember to consider the case that there is more than one default instance for a given method of a superclass. I am reminded of multiple inheritance considerations. (These difficulties came up before when I was thinking about the numeric heirarchy, and was the reason I proposed a heirarchy which was much less fine-grained than, e.g., in Mechvelliani's proposal.) Peace, Dylan pgp0.pgp Description: PGP signature
Re: Overlapping instances in existentials
On Thu, Jun 19, 2003 at 11:08:35AM -0500, Ed Komp wrote: | type BaseType = Either Integer ( Either Bool () ) | | type Value = (Either Double BaseType) | | data Foo = forall x. (SubType x BaseType) = MkFoo x | | test :: Foo - Value | test (MkFoo x) = inj x 'x' is the variable I am concerned about. Since it is an argument to MkFoo, we know that (SubType x BaseType) and we also know that: NOT (SubType Double BaseType), so 'x' cannot be instantiated as Double. I'm missing something. Why do we know NOT (SubType Double BaseType)? Nothing in the code above prevents you from having such an instance, does it? Peace, Dylan pgp0.pgp Description: PGP signature
Re: Naive question on lists of duplicates
On Sat, Jun 07, 2003 at 08:24:41PM -0500, Stecher, Jack wrote: It sounds like you're on the right track... You could get a moderately more efficient implementation by keeping the active list as a heap rather than a list. I had thought about that, and took the BinomialHeap.hs file from Okasaki, but I must have a typo somewhere, because I was having typing clashes that I couldn't easily clarify. At least, when I loaded the BinomialHeap.hs into Hugs, it didn't complain, but when I tried to create an empty heap using the heapEmpty function, Hugs screamed at me. I got scared and fled the scene, retreating into the safety of lists. I don't think you should worry about this now, but the problem was problem that heapEmpty returns something like 'Heap a', for an undetermined type variable 'a'; you may need to specify the type of your empty heap in order for Hugs not to complain. Peace, Dylan pgp0.pgp Description: PGP signature
Re: Multiparameter class confusion
On Wed, Jun 04, 2003 at 01:21:00PM +0100, Graham Klyne wrote: There is a recurring difficulty I'm having using multiparameter classes. Most recently, I have a class Rule: [[ class (Expression ex, Eq (rl ex)) = Rule rl ex where ... ]] Which I wish to instantiate for a type GraphClosure via something like: [[ instance (Label lb, LDGraph lg lb) = Expression (lg lb) where ... data (Label lb, LDGraph lg lb) = GraphClosure lg lb = ... instance Rule GraphClosure (NSGraph RDFLabel) where ... ]] ... I think that what I really *want* to do here is change the kind of GraphClosure to be (* - *) rather than (* - * - *). But if I try this: [[ data (Label lb, LDGraph lg lb) = GraphClosure (lg lb) = ... ]] a syntax error is reported by Hugs and GHC. You haven't quite shown enough of your code. One thing you might consider is dropping the context from the definition of the GraphClosure type. Class contexts in data declarations end up being largely useless, anyway, since the dictionary is never actually used for anything. (There was a thread a few years ago about this.) You could then write data GraphClosure lglb = ... But this only works if the definition of GraphClosure only uses (lg lb), not the individual pieces. Peace, Dylan pgp0.pgp Description: PGP signature
Re: Naive question on lists of duplicates
On Thu, Jun 05, 2003 at 08:09:02AM -0500, Stecher, Jack wrote:
I have an exceedingly simple problem to address, and am wondering if
there are relatively straightforward ways to improve the efficiency
of my solution.
Was there actually a problem with the efficiency of your first code?
The task is simply to look at a lengthy list of stock keeping units
(SKUs -- what retailers call individual items), stores, dates that a
promotion started, dates the promotion ended, and something like
sales amount; we want to pull out the records where promotions
overlap. I will have dates in mmdd format, so there's probably
no harm in treating them as Ints.
(Unless this is really a one-shot deal, I suspect using Ints for dates
is a bad decision...)
My suggestion went something like this (I'm not at my desk so I
don't have exactly what I typed):
I have a different algorithm, which should be nearly optimal, but I
find it harder to describe than to show the code (which is untested):
import List(sortBy, insertBy)
data PromotionRec = PR {sku :: String, store :: String, startDate :: Int, endDate
:: Int, amount::Float}
compareStart, compareEnd :: PromotionRec - PromotionRec - Ordering
compareStart x y = compare (startDate x) (startDate y)
compareEnd x y = compare (endDate x) (endDate y)
overlap :: [PromoRec] - [[PromoRec]]
overlap l = filter (lambda l. length l 1)
(overlap' [] (sortBy compareStart l))
overlap' _ [] = []
overlap' active (x:xs) =
let {active' = dropWhile (lambda y. endDate y startDate x) active} in
(x:active') : overlap' (insertBy compareEnd x active') xs
The key is that, by keeping a list of the currently active promotions
in order sorted by the ending date, we only need to discared an
initial portion of the list.
You could get a moderately more efficient implementation by keeping
the active list as a heap rather than a list.
Peace,
Dylan
pgp0.pgp
Description: PGP signature
Re: two easy questions
On Fri, Feb 21, 2003 at 12:14:04AM -0500, Mike T. Machenry wrote: Hmm, that does seem like alot of code to say such a little thing. Is it possible to come at the problem from the other direction? By this I mean I am trying to have two sets of symbols be enumerated together. This solution I asked for tries to impose the enumeration over the data. Can I define data Player = Red | Green | Blue | MrX deriving (Enum) and then use type classes or something else to say that MrX is a fugitive and the others are detectives such that I can pattern match on them? I have functions that recur over the Player argument and terminate at MrX, but I also want to be able to formally say that some functions cannot take a player that is Mrx, or can only take Mrx. I think type classes would be overkill here. What's wrong with isDetective :: Player - Bool isDetective MrX = False isDetective _ = True ? (The pattern matching doesn't work quite the same way, but you can use guards to acheive the same effect, especially with ghc's pattern guards extension.) Best, Dylan Thurston pgp0.pgp Description: PGP signature
Re: seeking ideas for short lecture on type classes
On Mon, Jan 27, 2003 at 12:25:52PM +0200, Lauri Alanko wrote: On Mon, Jan 27, 2003 at 08:37:06PM +1100, Fergus Henderson wrote: I agree. The above characterization is highly misleading. It would be more accurate and informative to say that both Haskell and OO languages dispatch on the dynamic type of a value. What is the dynamic type of a value in Haskell, apart from existentials and Dynamic? Ordinary type class dispatch is all done based on the types of variables, not their values. All the dispatching could even be done at compile time by specializing everything... I don't think this is true, even without existential types. Polymorphic recursion may involve building dictionaries at run time, which certainly approaches dynamic dispatch. (Polymorphic recursion is one of Chris Okasaki's favorite tricks. It involves definitions like data Tree a = Leaf a | Node (Tree [a]) (Tree [a]) in which the variable 'a' is used recursively at a different type.) Best, Dylan Thurston msg12142/pgp0.pgp Description: PGP signature
Re: Field labels must be globally unique?
On Wed, Jan 08, 2003 at 02:24:06PM +0100, Marc Ziegert wrote: It would be nice to be able to overload class-functions like classes: instance (+), (-) - Vector where (+) v1 v2 = ... (-) v1 v2 = ... ... You seem to be making a general complaint, but there's been extensive discussion about this particular instance. I agree with you that the numeric hierarchy is too coarsely grained right here; do a search on the archives for numeric prelude for an extensive discussion. Your proposals seem interesting, but seem hard to implement/make precise at first glance. Best, Dylan Thurston msg12043/pgp0.pgp Description: PGP signature
Re: infinite (fractional) precision
On Thu, Oct 10, 2002 at 02:25:59AM -0700, Ashley Yakeley wrote: At 2002-10-10 01:29, Ketil Z. Malde wrote: I realize it's probably far from trivial, e.g. comparing two equal numbers could easily not terminate, and memory exhaustion would probably arise in many other cases. I considered doing something very like this for real (computable) numbers, but because I couldn't properly make the type an instance of Eq, I left it. Actually it was worse than that. Suppose I'm adding two numbers, both of which are actually 1, but I don't know that: 1.0 + 0.9 ... The solution to such quandries is to allow non-unique representation. For instance, you might consider a binary system with allowed digits +1, 0, and -1, so that a number starting 0.xx can be anything between -1 and 1, and 0.1x can be anything between 0 and 1, etc. It is then possible to guarantee being able to output digits in a finite amount of time. With a scheme like this, the cases that blow up are ones you expect, like trying to compute 1/0; there are ways around that, too. As Jerzy Karczmarczuk mentioned, there is really extensive literature on this. It's beautiful stuff. Part of my motivation for revising the numeric parts of the Prelude was to make it possible to implement all this elegantly in Haskell. --Dylan Thurston msg02082/pgp0.pgp Description: PGP signature
Re: Monad Maybe?
On Sat, Sep 21, 2002 at 12:56:13PM -0700, Russell O'Connor wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [To: [EMAIL PROTECTED]] Is there a nicer way of writing the following sort of code? case (number g) of Just n - Just (show n) Nothing - case (fraction g) of Just n - Just (show n) Nothing - case (nimber g) of Just n - Just (*++(show n)) Nothing - Nothing You could write (using GHC's pattern guards): show g | Just n = number g = Just (show n) | Just n = fraction g = Just (show n) | Just n = nimber g = Just (*++show n) | Nothing = Nothing Do I detect a program for analyzing combinatorial games being written? --Dylan msg02002/pgp0.pgp Description: PGP signature
Re: Haskell 98
On Thu, Sep 19, 2002 at 02:36:01PM +0100, Simon Peyton-Jones wrote: The copyright notice is, I believe, agreed with CUP, but I must check that. The online versions will remain available. Will the online version be available with the current copyright, or will it only be available with the addition of 'non-commercial'? If the copyright on the online version includes non-commercial, there might be problems. For instance, Debian includes the Haskell report in its distribution, which some people put onto CDs and sell, which would be a violation of the non-commercial terms. Best, Dylan msg11554/pgp0.pgp Description: PGP signature
Re: A question concerning functional dependencies
On Mon, Sep 02, 2002 at 03:11:58AM -0700, Ashley Yakeley wrote: At 2002-09-02 02:46, Jerzy Karczmarczuk wrote: class Module v s | v-s . ... instance Num s = Module (v-s) s ... instance ...= Module ((v-s)-(v-s)) s ... But GHCi yells that two instances in view of the functional dependency declared are in conflict. GHCi is correct. Bear in mind GHC ignores contexts in instance declarations when calculating conflicts. This is unfortunate, but apparently fixing it would be hard. Even taking contexts into account, these two might still conflict: if you had instance Num ((v-s)-v) for some values of v and s, you would get a conflict. GHC (and Hugs) check for potential conflicts like this unless you explicitly allow overlapping instances. --Dylan msg11456/pgp0.pgp Description: PGP signature
Re: Evaluation order, ghc versus hugs, lazy vs. strict
On Tue, Aug 20, 2002 at 10:43:39AM +0200, Jan Kybic wrote: This is what I cannot do for the moment. How do I find out what is really going on. Any pointers to a relevant articles/literature? ... In addition to the other suggestions, see Chapter 6 (Advice on: sooner, faster, smaller, thriftier) of the GHC user's manual. --Dylan Thurston msg11412/pgp0.pgp Description: PGP signature
Re: zipWith, zipWith3, zipWith4.... looks gawky, IMHO
On Sun, Aug 18, 2002 at 06:32:27PM +0200, [EMAIL PROTECTED] wrote: Hi all. I'm new to this mailing list. (and still a relative newbie in Haskell - learning GraphicsLib) Because the Wish List did not work (maybe it is my browsers fault), I now write it to this list. I found the zipWithN functions in the standard libs, but imho it would be much more comfortable to use operators like in this example: ... infixl 123whatever (:), () -- lower priority than (++) (:) :: (a-b) - [a] - [b] (:) = map () :: [(a-b)] - [a] - [b] () = zipWith id Nice, except that operator names that start with ':' are constructors. Have you seen the paper Do we need dependent types http://www.brics.dk/RS/01/10/? They do the same trick, and go further. --Dylan msg11393/pgp0.pgp Description: PGP signature
Re: Evaluation order, ghc versus hugs, lazy vs. strict
On Mon, Aug 19, 2002 at 11:19:41PM +0200, Jan Kybic wrote: Hello, I am wrestling with having Haskell (using ghc(i) version 5.02.2) evaluate things in good order and to garbage collect what he no longer needs. I could simplify the problem to this simple example: main = print $ sum [0..100] When you use a sufficiently large number (perhaps 1000 instead of 100), both ghci and ghc terminate with Stack space overflow. On the other hand, Hugs (dated December 2001) runs the example OK and produces the result of 5050. ghc -O2 seems to run the program above in constant space. I guess strictness analysis (which knows how to evaluate the foldl) only happens at -O2 or above? Best, Dylan Thurston ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Evaluation order, ghc versus hugs, lazy vs. strict
On Mon, Aug 19, 2002 at 11:34:48PM +0100, Alastair Reid wrote:
main = print $ sum [0..100]
...
Hugs uses foldl' instead of foldl to define sum:...
Does it really? That's a violation of the standard: a user's instance
of (+) need not be strict in its left argument. Consider
data Foo = Foo Integer deriving (Eq, Show)
instance Num Foo where
fromInteger = Foo
a + b = b
v1 = undefined + Foo 2
v2 = sum [undefined, Foo 2]
Both v1 and v2 should have the value 'Foo 2'. However, hugs (December
2001) gives
Program error: {undefined}
in response to v2. ghci gets it right.
--Dylan
msg11397/pgp0.pgp
Description: PGP signature
Re: idiom for different implementations of same idea
On Thu, Aug 01, 2002 at 02:34:00PM -0700, Hal Daume III wrote: ... Now, I want in my executable my user to be able to say -model=0 and so on in the command line and for it to use the appropriate model. Each of these models will go in a separate module. One way to do this would be to import all of the models qualified and then if they choose Model0, pass to the go function Model0.prepareData, Model0.initialize, etc. This is fine, simple, good. But it doesn't enforce at all the types of the functions. I don't understand what you mean by this. Surely the go function is polymorphic over the types in the model, but requires matching types? I don't think you can get Haskell to not enforce at all the types of the functions. I must be missing something. --Dylan msg11314/pgp0.pgp Description: PGP signature
Re: replacing the Prelude (again)
On Tue, Jul 16, 2002 at 04:02:44PM +1000, Bernard James POPE wrote: I would like to use do-notation in the transformed program, but have it refer to Prelude.Monad and not MyPrelude.Monad which is also in scope. Why do you have a MyPrelude.Monad (different from Prelude.Monad) if you don't want to use it? --Dylan msg03803/pgp0.pgp Description: PGP signature
Re: replacing the Prelude (again)
On Sat, Jul 13, 2002 at 07:58:19PM +1000, Bernard James POPE wrote: ... I'm fond of the idea proposed by Marcin 'Qrczak' Kowalczyk: May I propose an alternative way of specifying an alternative Prelude? Instead of having a command line switch, let's say that 3 always means Prelude.fromInteger 3 - for any *module Prelude* which is in scope! That is, one could say: import Prelude () import MyPrelude as Prelude IMHO it's very intuitive, contrary to -fno-implicit-prelude flag. I don't agree with this, since the Haskell 98 standard explicitly contradicts it. I don't see what's wrong with a command line switch that would do this, anyway. Presuming of course that defaulting would follow this path and refer to the new Prelude. I never came up with a design that would allow this. Defaulting seems to be the one piece of the Haskell standard for which there is not yet a general solution. Although now that I think about it, if you could just specify which fromInteger you wanted (i.e., give that fromInteger a more specific type) the problem would go away. Perhaps that's really the better solution anyway: how often do people want to default to something that's not the first on the defaulting list? I think that might end up being less surprising to programmers, anyway. It might work as a temporary hack for you, anyway. (That is, add declarations like fromInteger :: Integer - Int fromRational :: Rational - Double in your new Prelude. This would work as long as users don't otherwise use fromInteger.) I don't know how you want to transform the types, but there are at least two areas where there are still special types: List and Bool. For List, I don't actually see any problem in principle with allowing other implementations of list comprehensions and whatnot, but Simon Peyton-Jones indicated that it would be difficult to actually implement; with Bool, one would need to define additional functions (like ifThenElse). Best, Dylan msg01816/pgp0.pgp Description: PGP signature
More on integer division
On Fri, Jun 28, 2002 at 03:54:50PM -0400, Dylan Thurston wrote: On Fri, Jun 28, 2002 at 10:24:13AM +0100, Malcolm Wallace wrote: Yes,-5`div`2 == -(5`div`2) == -2 but (-5)`div`2 == -3 Ghc 5.02.2 has the infix priority wrong, and interprets the former as the latter. But more bizarrely, ghc 5.02.2 gets this very wrong: Prelude (-1796254192) `div` 357566600 5 Thanks for the clear summary. After a looking a little more, there seem to be other problems (including errors in my proposed solution). I don't know where the code for quotRem is, but it is also buggy. For instance, Prelude 9 `quotRem` (-5) (-1,4) (The correct answer is (-1,-4).) I'm frankly astonished: has noone used these functions with negative arguments before? This happens with both ghci and compiled programs, both -fvia-C and -fasm. Hugs (see below) and nhc make the same error in this case. There seems to be too strong a reliance on C's operators '/' and '%', which give these results (with gcc on x86). This may be a bug in gcc. I'm using gcc 2.95.4; I'm not sure which version compiled the Debian packages I'm using. According to http://home.tiscalinet.ch/t_wolf/tw/c/c9x_changes.html#Semantics, the C9x standard specifies that division should truncate towards 0; I believe that earlier it was undefined. I'm shocked that non of the three Haskell implementations had a test suite that caught this problem. - __ __ __ __ ___ _ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2001 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Report bugs to: [EMAIL PROTECTED] || || Version: February 2001 _ Haskell 98 mode: Restart with command line option -98 to enable extensions Reading file /usr/share/hugs98/lib/Prelude.hs: Hugs session for: /usr/share/hugs98/lib/Prelude.hs Type :? for help Prelude 9 `quotRem` (-5) (-1,4) - msg04901/pgp0.pgp Description: PGP signature
Retraction
On Sat, Jun 29, 2002 at 12:23:27PM -0400, Dylan Thurston wrote: After a looking a little more, there seem to be other problems (including errors in my proposed solution). I don't know where the code for quotRem is, but it is also buggy. For instance, Prelude 9 `quotRem` (-5) (-1,4) (The correct answer is (-1,-4).) I'm frankly astonished: has noone used these functions with negative arguments before? I do apologise: what I wrote here is nonsense. (-1,4) is the correct answer to this problem. --Dylan msg04902/pgp0.pgp Description: PGP signature
-1796254192 `div` 357566600 == 5 ??
There seems to be some problem with the gmp interface: dpt@lotus:~$ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.02.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package std ... linking ... done. Prelude -1796254192 `div` 357566600 5 Prelude Has this been fixed already? I checked, and the gmp library itself (Debian version 4.0.1-3) does not have this problem. Best, Dylan Thurston msg04894/pgp0.pgp Description: PGP signature
Re: ANN: Functional Metapost 1.2
On Mon, May 27, 2002 at 04:34:23PM +0200, Ferenc Wagner wrote: Dear Haskell Community, version 1.2 of Functional Metapost is now available at http://afavant.elte.hu/~wferi/funcmp/ News: * This version includes English translations of the most important parts of the documentation! Thanks to Meik Hellmund, who contributed the translations. * 8-bit color depth bitmaps work. Great work! One documentation bug: Now it is time to discuss units. \MP\ uses as basic unit PostScript points which correspond to $1/72$ inch. We use them in \FMP, too. |hspace 8| defines a horizontal distance of $1/9$ inch or approximately $2.82$ mm. This contradicts the table that immediately follows, in which it is evident that a unit of '1' is one printer's point, 1/72.27 of an inch; the Postscript points are called 'bp'. Which is correct? Best, Dylan Thurston msg10989/pgp0.pgp Description: PGP signature
Re: State monads don't respect the monad laws in Haskell
On Tue, May 14, 2002 at 12:32:30PM -0400, Jan-Willem Maessen wrote: Chalk me up as someone in favor of laws without exceptions. Do you ever use floating point addition? I rarely use floating point, but it is sometimes more useful than the alternatives, as long as you bear in mind its limitations. In general, programmers should be allowed to do unsafe things, as long as they explicitly ask for it (by, say, using floating point). I guess these monad laws are not such a case. I'm very interested by your ideas to make Haskell better behaved: ... That said, seq is a big wart on Haskell to begin with. I might be willing to allow nice rules like the monad laws to apply *as long as the results are not passed (directly or indirectly) to seq*. But I'm not willing to go from the IO monad disobeys the laws in the presence of seq, and that might be OK to my monad disobeys the laws in code that never uses seq, and that's OK because even IO breaks the monad laws. And I'd really much rather we cleaned up the semantics of seq---or better yet, fixed the problems with lazy evaluation which make seq necessary in the first place. [Let me be clear: I believe hybrid eager/lazy evaluation, the subject of my dissertation, does eliminate the need for seq in most cases---so I'm a bit biased here.] This sounds very interesting! Is your dissertation available? My main complaint about Haskell at the moment is that it seems remarkably difficult to avoid space leaks due to laziness issues; your approach seems like a promising way to avoid that. Best, Dylan Thurston msg10904/pgp0.pgp Description: PGP signature
Re: Replacing the Prelude
On Sun, May 12, 2002 at 09:31:38PM -0700, Ashley Yakeley wrote:
I have recently been experimenting writing code that replaces large
chunks of the Prelude, compiling with -fno-implicit-prelude. I notice
that I can happily redefine numeric literals simply by creating functions
called 'fromInteger' and 'fromRational': GHC will use whatever is in
scope for those names.
I was hoping to do something similar for 'do' notation by redefining
(), (=) etc., but unfortunately GHC is quite insistent that 'do'
notation quite specifically refers to GHC.Base.Monad (i.e. Prelude.Monad,
as the Report seems to require). I don't suppose there's any way of
fooling it, is there? I was rather hoping 'do' notation would work like a
macro in rewriting its block, and not worry about types at all.
I accept that this might be a slightly bizarre request. There are a
number of things I don't like about the way the Prelude.Monad class and
'do' notation are set up, and it would be nice to be able to experiment
with alternatives.
A while ago, there were extensive discussions about replacing the
Prelude on this list. (Search for Prelude shenanigans.) I started
to write up a design document for how to enable replacing the Prelude.
This boiled down to taking most of the syntactic sugar defined in
the report seriously, ignoring the types (as you say).
I'm surprised that ghc uses the fromInteger and fromRational that are
in scope; I thought there was general agreement that it should use the
Prelude.from{Integer,Rational} in scope.
As I recall, there were several relevant bits of syntactic sugar:
- Numeric types, including 'fromInteger', 'fromRational', and
'negate'. This all works fine, except that the defaulting mechanism
is completely broken, causing a number of headaches.
- Monads. The translation given in the report is clean, and it seems
like it can be used without problems.
- Bools. There was a slight problem here: the expansion of
'if ... then ... else ...' uses a case construct referring to the
constructors of the Bool type, which prevents any useful
redefinition of Bool. I would propose using a new function,
'Prelude.ifThenElse', if there is one in scope.
- Enumerations. Clean syntactic sugar.
- List comprehensions. The report gives one translation, but I think
I might prefer a translation into monads.
- Lists and tuples more generally. At some point the translations
start getting too hairy; I think I decided that lists and tuples
were too deeply intertwined into the language to change cleanly.
I'll dig up my old notes and write more, and then maybe write a
complete design document and get someone to implement it.
--Dylan Thurston
msg03485/pgp0.pgp
Description: PGP signature
Re: preprocessing printf/regex strings (like ocaml)
On Tue, May 14, 2002 at 03:45:36PM +0100, Robert Ennals wrote: Just thought I would jump in and say that, unlike (it seems) everyone else, I hate printf in C. It is a horrible horrible inextensible hack of a function that I find extremely awkward to use. ... I personally much prefer the syntax currently used in Haskell, which is also essentially what is used in most other recent languages, including Java, C++, and (god help me) Perl. In the example given, I could write: I have ++ action ++ ++ number ++ ++ whatas where action = trained number = show 1 whatas = Jedi Which is IMHO rather more readable than a load of weird control codes hidden in a text string that one then has to match against a list. How would you deal with internationalisation issues? --Dylan msg10875/pgp0.pgp Description: PGP signature
Re: State monads don't respect the monad laws in Haskell
On Tue, May 14, 2002 at 04:57:12PM +0200, George Russell wrote: According to the report Instances of Monad should satisfy the following laws: return a = k = k m = return= m m = (\x - k x = h) = (m = k) = h so neither IO nor my events satisfy this. Up to now I haven't had any problems with this. Does GHC or any other Haskell compiler actually rely on instances of Monad satisfying left identity? If not, I would suggest dropping the requirement, if it can be done without upsetting category theorists. (What the hell, they stole the term Monad from philosophy and changed its meaning, so why shouldn't we?) I don't think this is necessarily wise to drop this from the report altogether. To me, it seems comparable to associativity of addition for instances of Num; many instances don't satisfy it (e.g., Float), but it's a useful guideline to keep in mind. I've often been bothered by the inconsistent treatment of laws in the report; why are there laws for functors, monads, and quot/rem and div/mod, and not much else? I'm pleased to see that the laws that are given actually do have exceptions. --Dylan msg10876/pgp0.pgp Description: PGP signature
Re: Replacing the Prelude
On Sun, May 12, 2002 at 09:31:38PM -0700, Ashley Yakeley wrote:
I have recently been experimenting writing code that replaces large
chunks of the Prelude, compiling with -fno-implicit-prelude. I notice
that I can happily redefine numeric literals simply by creating functions
called 'fromInteger' and 'fromRational': GHC will use whatever is in
scope for those names.
I was hoping to do something similar for 'do' notation by redefining
(), (=) etc., but unfortunately GHC is quite insistent that 'do'
notation quite specifically refers to GHC.Base.Monad (i.e. Prelude.Monad,
as the Report seems to require). I don't suppose there's any way of
fooling it, is there? I was rather hoping 'do' notation would work like a
macro in rewriting its block, and not worry about types at all.
I accept that this might be a slightly bizarre request. There are a
number of things I don't like about the way the Prelude.Monad class and
'do' notation are set up, and it would be nice to be able to experiment
with alternatives.
A while ago, there were extensive discussions about replacing the
Prelude on this list. (Search for Prelude shenanigans.) I started
to write up a design document for how to enable replacing the Prelude.
This boiled down to taking most of the syntactic sugar defined in
the report seriously, ignoring the types (as you say).
I'm surprised that ghc uses the fromInteger and fromRational that are
in scope; I thought there was general agreement that it should use the
Prelude.from{Integer,Rational} in scope.
As I recall, there were several relevant bits of syntactic sugar:
- Numeric types, including 'fromInteger', 'fromRational', and
'negate'. This all works fine, except that the defaulting mechanism
is completely broken, causing a number of headaches.
- Monads. The translation given in the report is clean, and it seems
like it can be used without problems.
- Bools. There was a slight problem here: the expansion of
'if ... then ... else ...' uses a case construct referring to the
constructors of the Bool type, which prevents any useful
redefinition of Bool. I would propose using a new function,
'Prelude.ifThenElse', if there is one in scope.
- Enumerations. Clean syntactic sugar.
- List comprehensions. The report gives one translation, but I think
I might prefer a translation into monads.
- Lists and tuples more generally. At some point the translations
start getting too hairy; I think I decided that lists and tuples
were too deeply intertwined into the language to change cleanly.
I'll dig up my old notes and write more, and then maybe write a
complete design document and get someone to implement it.
--Dylan Thurston
msg01674/pgp0.pgp
Description: PGP signature
Re: Proper scaling of randoms
(Redirected to haskell-cafe.) On Mon, May 06, 2002 at 04:49:55PM -0700, [EMAIL PROTECTED] wrote: Problem: given an integer n within [0..maxn], design a scaling function sc(n) that returns an integer within [s..t], t=s. The function sc(n) must be 'monotonic': 0=a b == sc(a) = sc(b) and it must map the ends of the interval: sc(0) - s and sc(maxn) - t. Just an aside (which Oleg surely knows): for actual random number generation, you often don't care about the monotonicity, and only care about uniform generation. In this case, there is a very simple algorithm: work modulo (s-t+1). scm(n) = (n `rem` (s-t+1)) + s Warning: some, broken, random number generators do not behave well when used like this. Also, although this is as uniform as possible, there is a systematic skew towards the lower end of the range [s..t]. --Dylan Thurston msg01661/pgp0.pgp Description: PGP signature
Re: Double - non-double function :)
On Wed, Apr 03, 2002 at 11:15:04AM -0800, Hal Daume III wrote:
I'm looking for a (not-necessarily Haskell 98 compliant, as long as it
works in GHC) way to get at the internal representation of Doubles. I can
use decodeDouble# to get at it, but I need something equivalent to
encodeDouble# to go the other way, and I cannot find such a function
anywhere. Any suggestions are welcome (yes, I know I can use show and
read, but I'm looking for something which will keep the # of bytes down).
What's wrong with {de,en}codeFloat? Not fast enough? Or is this not
what you mean by the internal representation?
--Dylan Thurston
msg10624/pgp0.pgp
Description: PGP signature
Re: and do notation
On Tue, Apr 02, 2002 at 08:48:41PM +0100, Jon Fairbairn wrote: Point taken, but I remain unconvinced. What comes out of the monad /isn't/ abstract; there's nothing to ensure that subsequent use respects the abstraction. Sure. That's the programmer's responsibility to keep track of. To me the situation seems entirely analogous to defining a '+' operation that is not associative; if the programmer wants to do it, more power to her. (In fact, the standard '+' on floating point numbers is not associative. Sometimes it matters!) These considerations are the reasons compilers are typically prohibited from taking advantage of such laws, and why the translation from the 'do' notation should be the obvious one (using ''). Best, Dylan Thurston msg10610/pgp0.pgp Description: PGP signature
Re: sort inefficiency
On Wed, Apr 03, 2002 at 09:35:51AM +0400, Serge D. Mechveliani wrote: The Standard library specifies only the map related to the name `sort'. This map can be described, for example, via sort-by-insertion program. And the algorithm choice is a matter of each particular implementation. Implementation has right to change the algorithm. Reading this, it occurred to me that if you're very picky the implementation probably isn't allowed to pick the algorithm: you need to assume that '' is actually a total order to have much leeway at all. (Suppose, e.g., that comparing two particular elements yields an exception.) It seems to me this is a problem with providing code as specification: you probably fix the details more than you want. Best, Dylan Thurston msg01575/pgp0.pgp Description: PGP signature
Re: Congrats to Mandrake
On Wed, Feb 20, 2002 at 03:45:15PM +0200, Lauri Alanko wrote: On Wed, Feb 20, 2002 at 01:37:52PM -, Simon Marlow wrote: Could someone who is Debian-compliant tell me where I should be pointing for Debian packages? http://ftp.debian.org/debian/pool/main/g/ghc5/ Though of course any debian user should just be able to say apt-get install ghc5 to get the latest package from the nearest mirror... Better: http://packages.debian.org/testing/devel/ghc5.html http://packages.debian.org/unstable/devel/ghc5.html --Dylan Thurston msg03123/pgp0.pgp Description: PGP signature
Re: Survival of generic-classes in ghc
On Wed, Feb 20, 2002 at 01:15:36PM -0800, Simon Peyton-Jones wrote:
Another possiblity would be to make the ConCls class look like this
class ConCls c where
name :: String
arity :: Int
...etc...
Now we'd have to give an explicit type argument at the call site:
show {| Constr c t |} (Con x) = (name {| c |}) ++ show x
I quite like the thought of being able to supply explicit type
arguments
but I don't konw how to speak about the order of type parameters.
What order does map takes its two type parameters in?
Sorry, this seems like a non-sequitur to me?
'map' has type '(a-b) - [a] - [b]'; supplying explicit type
parameters would mean giving values to 'a' and 'b'. If I wanted to
propose notation for this, I would suggest, e.g.,
(map :: (String - Int) - [String] - [Int]) length [Hello, World]
'name' (above) has type 'String'; the '{| c |}' is not providing a type
parameter in the same sense.
What am I missing?
Best,
Dylan
msg01379/pgp0.pgp
Description: PGP signature
Re: ideas for compiler project
On Thu, Jan 24, 2002 at 03:38:59PM +0100, Bjorn Lisper wrote: I think MATLAB's matrix language provides about the right level of abstraction for a high-level matrix language. You can for instance write things like Y = inv(A)*B to assign to Y the solution of Ax = B. ... Just a comment on a long post... I am personally found of MetaFont's approach, where you write Ax = B to find the solution to Ax = B. When working with transformations and such, being able to write all your equations forwards makes it much easier to keep everything straight; plus, if you have several equations for a variable, you don't have to figure out how to gather them together. Can anyone see a way to implement something like this in Haskell? Or is it better to make a small interpreted language? Best, Dylan Thurston msg10237/pgp0.pgp Description: PGP signature
Re: RFC: Syntax for implicit parameter bindings
On Mon, Feb 04, 2002 at 01:33:54PM -0800, Ashley Yakeley wrote:
At 2002-02-04 01:45, Koen Claessen wrote:
| addBase{?base=7} 5
I like this! It is the least polluting syntax of all.
Hmm... you have braces without following a keyword. I think in all other
cases, braces follow a keyword (where, let, do, of).
Field updates use braces which do not follow a keyword, with very
similar syntax. I don't know about all the implications, but I do like
the proposal.
--Dylan
msg10123/pgp0.pgp
Description: PGP signature
Re: FFI
On Sat, Jan 12, 2002 at 01:24:54PM +1100, Manuel M. T. Chakravarty wrote: Mark Conway Wirt [EMAIL PROTECTED] wrote, I'm looking for opinions as to the best way to do a C (or C++) foreign interface to GHC haskell code. It looks like there are three options. I think, there are five options: * H/Direct (you mentioned that already) * GreenCard (ditto) * C-Haskell http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ * hsc2hs (comes with GHC) * Plain FFI And what are the pros and cons of each? Presumably you recommend C-Haskell, since you wrote it; what makes it better? (My situation: I want to interface to C code with several rather large structures, so plain FFI is not very attractive. I've started using C-Haskell, but am curious about other people's experiences.) --Dylan Thurston msg02917/pgp0.pgp Description: PGP signature
Re: gcd 0 0 = 0
On Tue, Dec 18, 2001 at 06:00:30PM +0100, Kent Karlsson wrote: Why? If EVERY natural number is to have a prime factorisation, then BOTH 0 AND 1 have to be promoted to prime numbers; 1 has a perfectly fine prime factorization. It is the product of 0 primes, the null product. (A null product is defined, for very good reasons, to be 1, just like a null sum is defined to be 0.) I could see defences of calling 0 a prime, although it is not standard mathematical practice. The ideal generated by 0 is a prime ideal, for one thing. 0 would still not have a unique prime factorization, however. (But Haskell should not unilaterally decide to violate standard mathematical terminology!) ... But there is a fundamental reason to say that 0 can never be a divisor (i.e. 0|0 is false; x|y is true iff x is a *non-zero* factor of y; the 'non-zero' part is often left implicit (e.g. one is only talking about strictly positive integers), which is part of the reason why we are having this discussion). What fundamental reason do you have in mind? Why do you use this definition of divisibility? (I'm curious; other mathematicians give the same definition, and I can't see why.) This thread made me curious, so I did a little library research. I was surprised to discover that mathematicians discover on this, the domain of definition of gcd a b: DomainReferences ---- a /= 0, b /= 0Lang, Algebra, 3rd Edition Hasse, Number Theory a, b not both 0 Koblitz, A Course on Number Theory and Cryptography all a, b allowed MacLane and Birkhoff, Algebra, 2nd Edition Koch, Number Theory At least the books by Lang and MacLane-Birkhoff are standard references. Note that the definitions all agree when they are defined (with gcd 0 0 = 0). As I said, I was surprised; to me, the definiton with all a and b is the more natural one. I still recommend using the full domain (especially since exceptions are awkward to deal with in Haskell), but I'm not as certain. Best, Dylan Thurston ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Functional Metapost maintained?
On Sat, Nov 24, 2001 at 04:52:00PM +0100, Ferenc Wagner wrote: BTW, I didn't notice import problems. They may be specific to GHC... I have got 5.02-1 now, I'll check later. I don't know if it's specific to GHC, but it's definitely a bug in Functional MetaPost (although probably easy to fix). For instance: a) FMPPicture exports the data type 'Tension' b) FMPMpsyntax does a restricted import of FMPPicture, not including 'Tension', and reexports 'module FMPPicture' c) FMPResolve imports and exports FMPMpsyntax d) FMPCore imports FMPResolve and expects 'Tension' to be defined The situation is a little more complicated, but I think any reasonable interpretation would give an import problem. The key problem is in (b). Unless this was some recent change in the report? Isn't Hugs enough for you for a while? Probably; I'll try it out. Thanks for the work! Best, Dylan msg09598/pgp0.pgp Description: PGP signature
Re: [ketil@ii.uib.no: Re: Enum class]
(I want to trim the headers, but don't know the history of this thread. Also cc:ed back to the Haskell list.) On Thu, Oct 25, 2001 at 11:11:42AM +0200, Ketil Malde wrote: Dylan Thurston [EMAIL PROTECTED] writes: I agree that Enum instances for Float/Double are not likely to be useful. From a gut feeling, I could see a use for expressions like [1.5, 1.6..] and [1.5, 1.6..2.0] (i.e. enumFromThen and enumFromThenTo) but enumFrom and enumFromTo making list of rounded integers seems strange to me. It seems to me that enumFromThen and -To could be implemented something like: enumFromThen beg next = beg : enumFromThen next (next+delta) where delta = next-beg similarly for enumFromThenTo, of course. i.e. depending only on functionality found in Num. Why not put these functions there, and remove Float and Double as Enum instances? What am I missing? Currently you can write data Day = Sunday | Monday | Tuesday | Wednesday | Thursday | Friday | Saturday weekdays = [Monday..Friday] which has nothing to do with Num. Best, Dylan Thurston PGP signature
Re: Haskell 98: Enum class
On Wed, Oct 24, 2001 at 07:51:12AM -0700, Simon Peyton-Jones wrote: The Report is (regrettably) silent about what the Integer instances for succ and pred should be, but they should definitely simply add 1 (resp subtract 1). They should emphatically not use the default methods. I will add something to that effect in 6.3.4. ... 3. Specify that succ and pred on numeric types just add/subtract 1 (subject to (2) above). Can you write some code people can cutpaste for instance of Enum on ordered numeric types, just so this is crystal clear? You might even put in some bounds checking: succ x = let y = x+1 in if y x then y else error succ overflowed --Dylan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell 98 - Standard Prelude - Floating Class
On Mon, Oct 15, 2001 at 06:27:52PM +0200, George Russell wrote: Simon PJ wrote: Fpr the Revised Haskell 98 report, Russell O'Connor suggests: =20 | Also, I understand you are reluctant to make library changes,=20 | but sinh and cosh can easily be defined in terms of exp |=20 | sinh x =3D (exp(x) - exp(-x))/2 | cosh x =3D (exp(x) + exp(-x))/2 |=20 | (source: Calculus Third Edition by Michael Spivak, page 349,=20 | or any decent calculus book) |=20 | I suggest removing sinh and cosh from the minimal complete=20 | definition, and add the above defaults. This looks pretty reasonable to me. We should have default methods for anything we can. Comments? No. As has been pointed out, this is a bad idea numerically because it will give the wrong answer for sinh x for very small values of x. As a matter of fact, you will also get the wrong answer for very large values of x, where exp(x) can overflow even though sinh x and cosh x don't, meaning you get an incorrect answer of positive infinity. Err, what? Surely sinh x is at least 1/2 of exp x, leaving only a very narrow range for this to happen. Behaviour of sinh x near 0 is more important, unless I'm missing something? I suggest saying as little about the transcendental functions as possible, rather than forcing incorrect rules on the implementor. The suggestions are for default methods, which force nothing on anybody. They would be suggestions, in case anyone writes their own instances of these classes; the question should be whether they are useful suggestions. For instance, if you have a class of computable reals (increasingly good approximations), the default definitions of sinh and cosh are excellent. I don't think it's worth worrying about much. (They don't work for floating point numbers because of the special behaviour near 0.) Best, Dylan Thurston ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell 98 - Standard Prelude - Floating Class
On Mon, Oct 15, 2001 at 03:52:06PM +0200, Kent Karlsson wrote: Simon Peyton-Jones: Russell O'Connor suggests: | but sinh and cosh can easily be defined in terms of exp | sinh x = (exp(x) - exp(-x))/2 | cosh x = (exp(x) + exp(-x))/2 ... This looks pretty reasonable to me. We should have default methods for anything we can. Mathematically, yes. Numerically, no. Even if 'exp' is implemented with high accuracy, the suggested defaults may return a very inaccurate (in ulps) result. Take sinh near zero. sinh(x) with x very close to 0 should return x. With the above 'default' sinh(x) will return exactly 0 for a relatively wide interval around 0, which is the wrong result except for 0 itself. Hmm, on these grounds the current default definition for tanh x is even worse behaved: tanh x = sinh x / cosh x For moderately large floating point x, this will overflow. Frankly, I don't think the whole discussion matters very much; nobody who cares will use the default definitions. But remember to think about branch cuts. And why not go further? cos x = (exp (i*x) + exp (-i*x))/2 where i = sqrt (-1) etc. In general, this is why LIA-2 (Language Independent Arithmetic, part 2, Elementary numerical functions, ISO/IEC 10967-2:2001) rarely attempts to define one numerical operation in terms of other numerical operations. That is done only when the relationship is exact (even if the operations themselves are inexact). That is not the case for the abovementioned operations. But it is the case for the relationship between the complex sin operation and the complex sinh operation, for instance. (Complex will be covered by LIA-3.) This sounds like a very interesting standard. I am constantly annoyed by ISO's attempts to hide their standards; one might wonder what the purpose is of having unavailable standards. Is the content available somewhere? Best, Dylan Thurston ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Arrow notation, etc.
On Fri, Oct 12, 2001 at 12:39:09PM +0100, Keith Wansbrough wrote: Dylan writes: Incidentally, it seems to me that this is one case where a Lisp-like macro facility might be useful. With Haskell, it is impossible to play with bindings, while presumably you can do this with good Lisp macro systems. Yes, this is one thing you can do with good macro systems as are found in Lisp and Dylan (the language, not the person!). See the references in my http://www.cl.cam.ac.uk/~kw217/research/paper-abstracts.html#Wansbrough99:Macros Wansbrough, 1999. Macros and Preprocessing in Haskell especially section 8. Very good. Is there a concrete proposal for such macros? I think the arrow notation would be a harder test case than any of the existing syntactic sugar; I'd be curious to see what it looked like. (And is there support for adding these macros to Haskell?) Hygiene is a key concept here; that variables bound in a macro should not clash with other variables in the program (unless this is explicitly required). Off to read some Dylan manuals, Dylan msg09685/pgp0.pgp Description: PGP signature
Re: Arrow notation, etc.
On Fri, Oct 12, 2001 at 01:02:07PM +0100, Keith Wansbrough wrote: Sadly, there's not a concrete proposal - it seems that no one sees a need for macros in a lazy language. Most of what they do can be achieved through laziness - you can write if in Haskell already, for example, whereas you need a macro for it in Lisp. Your arrow notation example may provide some motivation, though. I wonder if macros could also be used to implement views. I think there were other times I wanted to play similar tricks with scoping, but I don't remember right now. Best, Dylan Thurston msg09687/pgp0.pgp Description: PGP signature
Re: Unicode support
On Sun, Sep 30, 2001 at 11:01:38AM -0700, John Meacham wrote: seeing as how the haskell standard is horribly vauge when it comes to character set encodings anyway, I would recommend that we just omit any reference to the bit size of Char, and just say abstractly that each Char represents one unicode character, but the entire range of unicode is not guarenteed to be expressable, which must be true, since haskell 98 implementations can be written now, but unicode can change in the future. The only range guarenteed to be expressable in any representation are the values 0-127 US ASCII (or perhaps latin1) I agree about the vagueness, but I believe the Unicode consortium has explicitly limited itself to 21 bits; if they turn out to have been lying about that (which seems unlikely in this millenium), we can hardly be blamed for believing them. I think all that should be required of implementations is that they support 21 bits. Best, Dylan Thurston ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: UniCode
On Fri, Oct 05, 2001 at 11:23:50PM +1000, Andrew J Bromage wrote: G'day all. On Fri, Oct 05, 2001 at 02:29:51AM -0700, Krasimir Angelov wrote: Why Char is 32 bit. UniCode characters is 16 bit. It's not quite as simple as that. There is a set of one million (more correctly, 1M) Unicode characters which are only accessible using surrogate pairs (i.e. two UTF-16 codes). There are currently none of these codes assigned, and when they are, they'll be extremely rare. So rare, in fact, that the cost of strings taking up twice the space that the currently do simply isn't worth the cost. This is no longer true, as of Unicode 3.1. Almost half of all characters currently assigned are outside of the BMP (i.e., require surrogate pairs in the UTF-16 encoding), including many Chinese characters. In current usage, these characters probably occur mainly in names, and are rare, but obviously important for the people involved. However, you still need to be able to handle them. I don't know what the official Haskell reasoning is (it may have more to do with word size than Unicode semantics), but it makes sense to me to store single characters in UTF-32 but strings in a more compressed format (UTF-8 or UTF-16). Haskell already stores strings as lists of characters, so I see no advantage to anything other than UTF-32, since they'll take up a full machine word in any case. (Right?) There's even plenty of room for tags if any implementations want to use it. See also: http://www.unicode.org/unicode/faq/utf_bom.html It just goes to show that strings are not merely arrays of characters like some languages would have you believe. Right. In Unicode, the concept of a character is not really so useful; most functions that traditionally operate on characters (e.g., uppercase or display-width) fundamentally need to operate on strings. (This is due to properties of particular languages, not any design flaw of Unicode.) Err, this raises some questions as to just what the Char module from the standard library is supposed to do. Most of the functions are just not well-defined: isAscii, isLatin1 - OK isControl - I don't know about this. isPrint - Dubious. Is a non-spacing accent a printable character? isSpace - OK, by the comment in the report: The isSpace function recognizes only white characters in the Latin-1 range. isUpper, isLower - Maybe OK. toUpper, toLower - Not OK. There are cases where upper casing a character yields two characters. etc. Any program using this library is bound to get confused on Unicode strings. Even before Unicode, there is much functionality missing; for instance, I don't see any way to compare strings using a localized order. Is anyone working on honest support for Unicode, in the form of a real Unicode library with an interface at the correct level? Best, Dylan Thurston ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Strange error in show for datatype
On Wed, Oct 03, 2001 at 11:52:30AM -0400, Jan-Willem Maessen wrote: Earlier, Simon says: Indeed, if none of the classes have a method that returns an a-value without also consuming one (urk-- strictly, I think, sigh) then the same holds. Strictness alas matters. Here's the witness: class Num a = ZeroList a where consZero :: a - [a] consZero _ = 0:xs Err, Num a is already a bad context by Simon's criterion because of fromInteger, which is what ultimately causes the problem in this case. I don't see how strictness can be relevant, since it is a property of a class instance, not a class. Best, Dylan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Strange error in show for datatype
On Thu, Oct 04, 2001 at 12:36:55AM -0700, Simon Peyton-Jones wrote: So in fact, all we need do is: for each class, find the variance of each of its parameters in an ambiguous type, zap any positive parameters to Empty That sounds pretty easy. We don't need Haskell 2 for that. I feel a little implementation coming on. This is, nevertheless, an extension to the language, right? Or is the class system poorly enough specified that it's unclear? Void was a type with one element. What we really want here is a type with no elements. It's also useful to be able to introduce such empty types for phantom-type purposes, so GHC now lets you say data T and get a type T with no values. Ah, excellent! I've frequently wanted to do this. Best, Dylan Thurston ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: H98: specialids and specialops
On Thu, Oct 04, 2001 at 01:08:03AM -0700, Simon Peyton-Jones wrote: 2. Instead, add the following paragraph to 5.3 (Import declarations) Lexically speaking, the terminal symbols ``as'', ``qualified'' and ``hiding'' are each a varid rather than a reservedid. They have special significance only in the context of an import declaration; in other contexts they may be used as variables. I do hope that I can import variables named as, qualified, or hiding; your text is slightly ambiguous. What about: Lexically speaking, the terminal symbols ``as'', ``qualified'' and ``hiding'' are each a varid rather than a reservedid. They have special significance only in the context of an import declaration; they may also be used as variables. Best, Dylan Thurston ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: always new instance?
On Tue, Oct 02, 2001 at 01:09:28PM +0300, Cagdas Ozgenc wrote: Do I ALWAYS need to create a new instance if I want to modify the state of an instance? For example, if I design an index for a simple database with an recursive algebric Tree type, do I need to recreate the whole Tree if I insert or remove an element? How can I improve performance, what are common idioms in these situations? For trees, if you want to change a node you typically have to recreate the nodes along the path to the root; that is, all the ancestors of the node. If your tree is well-balanced, this is only logarithmic in the size of your data, and automatically gives you other benefits, like persistence. (That is, you only need to change the nodes when the corresponding subtree has actually changed, which makes some sense.) I second Mark Carroll's recommendation for Okasaki's book. Best, Dylan Thurston ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
