Re: [Haskell-cafe] ANNOUNCE: graphviz-2999.0.0.0
Two clarifications I'd like to add to my previous announcement (both of which were prompted by Zsolt :p ): 1. Some Attribute values take something like (Either Bool String); this is used when upstream indicates that two different types of values are allowed. Typically in this kind of situation, the allowed String values are limited to a few specific values, so the usage of Either typically indicates that they should be replaced with a custom value type. 2. When considering the new representation of DotGraph, this isn't limited to just people who wish to parse Dot code: if you want to do anything out of the ordinary/fancy, then unfortunately you will need this imperative usage (as the indicated way to have global attributes to a graph but not to its subgraphs is to list all the subgraphs, and then define the graph attribute). For an example of this, consider the layout of Andy Gill's dotgen library [1]. If you look at the internals, he does consider graphs to be a list of statements. This amongst other things allows him to have a monadic interface for building graphs with much greater flexibility in what you can do, whereas graphviz limits you to either converting a pre-existing graph or else creating one within the limits of specifying it as a list of global attributes, a list of nodes/clusters and a list of edges between the nodes. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dotgen What I'm considering is that if I internally represent DotGraph as a list of statements, then I will have getNodes and getEdges functions to extract the nodes and edges (with their attributes) out. This also simplifies some of the definitions, as a subgraph/cluster is then also just a list of statements. Zsolt Dollenstein zsol.zs...@gmail.com writes: Hi, On Sat, Jul 18, 2009 at 10:23 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: I am pleased to announce a new release of the graphviz package for Haskell, which provides bindings to the GraphViz [1] suite of tools. Nice work! As the way of defining an attribute for a specific grouping of nodes/edges/subgraphs is to have them all listed after the attribute definition (whereas those beforehand do not have this attribute), the imperative nature of the Dot language does not allow us to split these statements up as we currently do. [3] http://graphviz.org/doc/info/lang.html As such, I'm asking which of the following two choices people would prefer: 1. Follow upstream so that it can fully parse a Dot graph 2. Keep it as it is, so that it is possible to consider all edges, etc. easily. I would vote for the second one since I think that is the most widely used feature of this package. Cheers, Zsolt -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: can there be (hash-table using) O(n) version of this (I think currently) n log n algo?
Thomas Hartman wrote: The code below is, I think, n log n, a few seconds on a million + element list. I wonder if it's possible to get this down to O(N) by using a hashtable implemementation, or other better data structure. -- findsums locates pairs of integers in a list that add up to a wanted sum. findsums :: [Int] - Int - S.Set (Int,Int) findsums xs wanted = snd . foldl' f (S.empty,S.empty) $ xs where f (candidates,successes) next = if S.member (wanted-next) candidates then (candidates, S.insert (next,wanted-next) successes) else (S.insert next candidates,successes) Remember that hash tables are actually O(key length) instead of O(1), so I don't think you can break the log n for really large lists this way since the key length increases as well (unless most elements are equal anyway). In any case, I have this conjecture On which I will lecture: A Set of some things Is sorting for kings. ;-) findsums goal = uncurry sweep . (id reverse) . sort where sweep [] _ = [] sweep _ [] = [] sweep (x:xs) (y:ys) = if x y then [] else case compare (x+y) goal of LT - sweep xs (y:ys) EQ - (x,y) : sweep xs ys GT - sweep (x:xs) ys This algorithm needs a proof of correctness, though. And it's longer that the Data.Set version, too. Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is there no Zippable class? Would this work?
On Fri, Jul 17, 2009 at 10:37 PM, por...@porg.es wrote: 2009/7/18 Edward Kmett ekm...@gmail.com: I wrote a short blog post on this: http://comonad.com/reader/2008/zipping-and-unzipping-functors/ and one on the less powerful dual operations (less powerful because while every Haskell Functor is strong, much fewer are costrong): http://comonad.com/reader/2008/cozipping/ -Edward Kmett This is getting a bit OT, but I just wanted to comment that attempting to remove polymorphism from the Functor class (see thread a couple of days ago) means that not every Functor is strong. So strength for Functor would seem to require a fully polymorphic type. I don't know if costrength is 'easier' to derive for those 'restricted' Functors.. Continuing the OT aside... Well, the monomorphic not-quite-Functor from that post is a pretty ugly concept categorically, and obviously doesn't qualify as a Hask endofunctor, given its limited scope. That isn't to say that occasionally you don't want a function that can map a ByteString to a ByteString a byte at a time -- merely that it is a different animal. ;) Strength does require polymorphism... which comes for free if we're talking about an actual endofunctor. The ad-hoc not-quite-Functor provides no guarantee that a member of that you have an instance of the class supporting pairs instance Functor' F (X,Y) or that if you do that you have an instance for the class supports pairs that you have one for the left side of the pair instance Functor' F X let alone that these definitions are consistent. But even if you grant all of that, regarding costrength, it makes things no easier. Costrength is effectively about the ability to check inside of a functor and see if in some Functor f, a value f x where x = Either a b has any b's and if so, it gives you one, otherwise it gives you an f a, because no b's occurred. Clearly for some simple functors you can complete this operation. But, there are many for which you cannot. The most obvious problem case is f = (-) a, because you need an oracle that knows the outcome of an arbitrary Haskell function; Kurt Godel would roll over in his grave. Similarly you run into problems deciding the outcome of costrength on a stream of Eithers even if you limit your instances to the bare minimum of () and Either () (), because you'd need to decide equality of streams, which leads to a need for a halting problem oracle. See http://comonad.com/reader/2008/deriving-strength-from-laziness/ for more details. -Edward Kmett ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] is closing a class this easy?
On 18 Jul 2009, at 16:49, Wolfgang Jeltsch wrote: Am Samstag, 18. Juli 2009 08:58 schrieb Miguel Mitrofanov: Oops... Sorry, wrong line. Should be isAB :: forall p. p A - p B - p x Is this a well-known approach for closing classes? I have an impression that this is kinda folklore. But I can't provide any references; I don't even remember if I invented it myself or not. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: graphviz-2999.0.0.0
On Jul 19, 2009, at 04:13 , Ivan Lazar Miljenovic wrote: 1. Some Attribute values take something like (Either Bool String); this is used when upstream indicates that two different types of values are allowed. Typically in this kind of situation, the allowed String values are limited to a few specific values, so the usage of Either typically indicates that they should be replaced with a custom value type. Shouldn't String then be replaced by a sum type? In fact, as described this would subsume the Either as well. -- replace Either Bool String: AttrN are the strings, AltValue the bool data upstreamValue = AttrA | AttrB | AltValue -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Implicit concatenation in list comprehensions
Dear Cafe, For fun, I spent a few hours yesterday implement support for this syntax in GHC, originally propsed by Koen Claessen: [k, =, v, | (k, v) - [(foo, 1), (bar, 2)] [foo, =, 1, , bar, =, 2, ] This is a generalisation of list comprehensions that allows several items to be concatenated onto the result list at once, by having several comma-separated items before the pipe. One situation where I have found this to be useful is when you are writing Haskell programs that call lots of external programs and you need to set the flags based on some tests, like so: rawSystem myProgram $ [foo | fooing_enabled] ++ [bar1, bar2 | baring_enabled] I have submitted a ticket to GHC HQ with the patch (http://hackage.haskell.org/trac/ghc/ticket/3380#comment:5), but as it is just a small convenience it most likely won't make it in unless there is more demand for the feature. So, now is the time to speak up in favour of (or indeed, against) the added syntax! All the best, Max P.S. I also implemented tuple sections (http://hackage.haskell.org/trac/ghc/ticket/3377#comment:3) which are a lot more useful: (, True, Hello, ) 1 World (1, True, Hello, World) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Problem with lazy IO
Maciej Piechotka uzytkownik2 at gmail.com writes:
Hello.
I've tried to combine lazy IO and parsec. The hole process is done by
network.
Currently I have implemented 'short parsers' so I enter them on need. To
update state I have following code:
parser2nntp :: Monad m = NntpParser m a - NntpT m a
parser2nntp p = do s - NntpT (gets $ input . connection)
e - runParserT (do v - p
i - getInput
return (v, i)) () s
case e of
Left er - error $ show er
Right (v, i') - (NntpT (modify (pNI i')) return
v)
where pNI :: Monad m = ByteString -NntpState m -
NntpState m
pNI i s = s {connection = (connection s) {input =
i}}
However the 4 line (i - getInput) blocks the execution as trace
indicated. String returned have no input available so it should block on
evaluation - and here I pass only a reference to it (or rather I think
so). What's wrong?
PS. Full code is in darsc nntp repository http://code.haskell.org/nntp/
- please note that it seems to require network compiled against parsec 3
- not 2.
This code seems to work:
parser2nntp :: Monad m = NntpParser m a - NntpT m a
parser2nntp p = do s - NntpT (gets $ input . connection)
r - parserRep = runParsecT p (State s (initialPos ) ())
case r of
Ok v (State i _ _) _ - NntpT (modify $ pNI i) return v
Error e - error $ show e
where parserRep (Consumed x) = x
parserRep (Empty x) = x
pNI i s = s {connection = (connection s) {input = i}}
Regards
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit concatenation in list comprehensions
Hi Max, For fun, I spent a few hours yesterday implement support for this syntax in GHC, originally propsed by Koen Claessen: [k, =, v, | (k, v) - [(foo, 1), (bar, 2)] [foo, =, 1, , bar, =, 2, ] This is a generalisation of list comprehensions that allows several items to be concatenated onto the result list at once, by having several comma-separated items before the pipe. I like the power this feature gives, and if it was already in Haskell 98 I'd certainly have used it a few times. I can't think of anything else the syntax could mean, so I don't see a potential for it stealing syntax that might otherwise be reused. However, it doesn't seem that discoverable or natural - I'm not sure I'd have ever guessed that such a feature might exist. P.S. I also implemented tuple sections (http://hackage.haskell.org/trac/ghc/ticket/3377#comment:3) which are a lot more useful: Yay! Discoverable, useful and really common in practice - a brilliant extension :-) Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit concatenation in list comprehensions
I vote for tuple sections. Very nice! I don't really see immediate places where I would use the list comprehension improvement so I guess I don't vote for that. 2009/7/19 Neil Mitchell ndmitch...@gmail.com: Hi Max, For fun, I spent a few hours yesterday implement support for this syntax in GHC, originally propsed by Koen Claessen: [k, =, v, | (k, v) - [(foo, 1), (bar, 2)] [foo, =, 1, , bar, =, 2, ] This is a generalisation of list comprehensions that allows several items to be concatenated onto the result list at once, by having several comma-separated items before the pipe. I like the power this feature gives, and if it was already in Haskell 98 I'd certainly have used it a few times. I can't think of anything else the syntax could mean, so I don't see a potential for it stealing syntax that might otherwise be reused. However, it doesn't seem that discoverable or natural - I'm not sure I'd have ever guessed that such a feature might exist. P.S. I also implemented tuple sections (http://hackage.haskell.org/trac/ghc/ticket/3377#comment:3) which are a lot more useful: Yay! Discoverable, useful and really common in practice - a brilliant extension :-) Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit concatenation in list comprehensions
I really like tuple sections and I've wanted them for years. I never use comprehensions though, so I abstain from the other vote. -- Robin On Sun, 19 Jul 2009 08:18:48 -0700 Thomas Hartman tphya...@gmail.com wrote: I vote for tuple sections. Very nice! I don't really see immediate places where I would use the list comprehension improvement so I guess I don't vote for that. 2009/7/19 Neil Mitchell ndmitch...@gmail.com: Hi Max, For fun, I spent a few hours yesterday implement support for this syntax in GHC, originally propsed by Koen Claessen: [k, =, v, | (k, v) - [(foo, 1), (bar, 2)] [foo, =, 1, , bar, =, 2, ] This is a generalisation of list comprehensions that allows several items to be concatenated onto the result list at once, by having several comma-separated items before the pipe. I like the power this feature gives, and if it was already in Haskell 98 I'd certainly have used it a few times. I can't think of anything else the syntax could mean, so I don't see a potential for it stealing syntax that might otherwise be reused. However, it doesn't seem that discoverable or natural - I'm not sure I'd have ever guessed that such a feature might exist. P.S. I also implemented tuple sections (http://hackage.haskell.org/trac/ghc/ticket/3377#comment:3) which are a lot more useful: Yay! Discoverable, useful and really common in practice - a brilliant extension :-) Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Ambiguous type variable - help!
Hi,
I'm trying to work out how to handle a choice at runtime which
determines what instance of a State monad should be used. The choice
will dictate the internal state of the monad so different
implementations are needed for each. I've concocted a very simple
example to illustrate this (below) - but it doesn't compile because
ghc complains that my type is ambiguous arising from my use of
'fromSeq'. I can kind-of see what the compiler is complaining about,
I'm guessing because it is the internals of my type which dictate
which state Monad to use and it can't know that?
Thinking about it I tried making SeqType an instance of Sequence
class, but had no luck here.
I understand that haskell is static at compile time, so I'm looking
for something like a template solution in C++ (rather than a virtual
function style implementation). I see there are libraries out their
which do this, but I was wondering in my simple example if there was a
way of doing this without writing a load of boilerplate code in main
(this would get ugly very quickly if you had loads of choices). If
this is impossible does anyone have an example / advice of
implementing simple template style code in Haskell?
Any help or suggestions would be really appreciated.
Many Thanks,
Phil.
Thus just implements a state Monad which counts up from 1 to 10, using
either an Int or a Double depending on user choice. It's pointless of
course, but illustrates my point.
{-# LANGUAGE TypeSynonymInstances #-}
import Control.Monad.State.Strict
data SeqType = SeqDouble Double | SeqInt Int
class SequenceClass a where
nextSeq :: State a Int
fromSeq :: SeqType - a
instance SequenceClass Int where
nextSeq = State $ \s - (s,s+1)
fromSeq (SeqInt i) = i
fromSeq _ = 0
instance SequenceClass Double where
nextSeq = State $ \s - (truncate s,s+1.0)
fromSeq (SeqDouble d) = d
fromSeq _ = 0.0
chooser :: String - SeqType
chooser inStr | inStr == Double = SeqDouble 1.0
| inStr == Int= SeqInt 1
| otherwise = SeqInt 1
main :: IO()
main = do userInput - getLine
let result = evalState (do replicateM 10 nextSeq) $ fromSeq
$ chooser userInput
print result
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ambiguous type variable - help!
Hi Phil, I'm trying to work out how to handle a choice at runtime which determines what instance of a State monad should be used. First of all, you should realize that you'll almost never want to do something like that in Haskell. In my opinion, if you're coming from an OO language, you should ban yourself from defining Haskell classes or using existential types until you are completely comfortable with how different Haskell is from OO. You can get along fine without them. I've concocted a very simple example to illustrate this (below) - but it doesn't compile because ghc complains that my type is ambiguous arising from my use of 'fromSeq'. Notice that you have given two completely separate sets of instructions of what to do depending on whether Int or Double is selected. You have not given any indication of how to choose between them, even at runtime. Of course, the compiler doesn't care that your string constants Int and Double happen also to be the names of types if unquoted. The way you avoid boilerplate in Haskell in these kinds of cases is by using polymorphism. Note that there could still remain a small amount of boilerplate - you move the actual hard work into a single polymorphic function, but then you may still need to mention that function once for each type. If that bothers you, there are more advanced tools to get rid of that last bit of boilerplate, like Template Haskell or Scrap Your Boilerplate. Below is one way to fix up your example, with a few other minor bits of polish. Regards, Yitz import Control.Monad.State -- Why Strict? Haskell is lazy by default. data SeqType = SeqInt Int | SeqDouble Double class SequenceClass a where nextSeq :: State a Int instance SequenceClass Int where nextSeq = State $ \s - (s, s + 1) instance SequenceClass Double where nextSeq = State $ \s - (truncate s, s + 1) chooser :: String - SeqType chooser inStr | inStr == Double = SeqDouble 1 | otherwise = SeqInt 1 -- Here is the polymorphism. -- Make this a function so that we can move it -- out of main. result :: SequenceClass a = a - [Int] result = evalState $ replicateM 10 nextSeq -- Here is the only boilerplate needed printResult :: SeqType - IO () printResult (SeqInt i)= print $ result i printResult (SeqDouble x) = print $ result x main :: IO() main = do userInput - getLine printResult $ chooser userInput -- or you could just say -- main = getLine = printResult . chooser ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
On Jul 18, 2009, at 9:26 PM, Wolfgang Jeltsch wrote: I don’t think, it’s a good idea to have German identifiers, since Haskell’s keywords are English. Put it this way: if Haskell's keywords were in German, do you suppose I would write my Haskell code in anything but English? Does the fact that 'data' is a Latin word mean that some fraction of our Haskell identifiers should be in Latin? Some say ita, some say minime. On the other hand, I strongly argue that a library about Bézier curves uses the identifier Bézier, not Bezier. So non- ASCII identifiers are useful even if identifiers are in English. Indeed, you need non-ASCII letters to write English well. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit concatenation in list comprehensions
2009/7/19 Max Bolingbroke batterseapo...@hotmail.com Dear Cafe, For fun, I spent a few hours yesterday implement support for this syntax in GHC, originally propsed by Koen Claessen: [k, =, v, | (k, v) - [(foo, 1), (bar, 2)] [foo, =, 1, , bar, =, 2, ] Given that this can easily be simulated via: [ x | (k, v) - [(foo, 1), (bar, 2)], x - [k, =, v, ]] [foo,=,1, ,bar,=,2, ] I believe that the added syntax (which every complete tool operating on Haskell code would have to support) is not worth its price. This is a generalisation of list comprehensions that allows several items to be concatenated onto the result list at once, by having several comma-separated items before the pipe. One situation where I have found this to be useful is when you are writing Haskell programs that call lots of external programs and you need to set the flags based on some tests, like so: rawSystem myProgram $ [foo | fooing_enabled] ++ [bar1, bar2 | baring_enabled] I have submitted a ticket to GHC HQ with the patch (http://hackage.haskell.org/trac/ghc/ticket/3380#comment:5), but as it is just a small convenience it most likely won't make it in unless there is more demand for the feature. So, now is the time to speak up in favour of (or indeed, against) the added syntax! All the best, Max P.S. I also implemented tuple sections (http://hackage.haskell.org/trac/ghc/ticket/3377#comment:3) which are a lot more useful: They are indeed, and here I would be inclined to consider the added cost worth it. -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: cautious-file 0.1.1: Ways to write a file cautiously, to avoid data loss
I'm pleased to announce the first public release of cautious-file: http://hackage.haskell.org/package/cautious-file This library currently provides a writeFile function that is intended to have three advantages over Prelude.writeFile: 1. There was a controversy a few months ago about the new Linux filesystem ext4, and how existing applications which write certain files naively might expose their users to the risk of data loss after a crash or power failure. (Actually, it turns out that this is not a new issue - certain other filesystems or filesystem mount options can cause similar issues, but few people made a fuss about it.) cautious-file uses the recommended way of writing a file on POSIX (more or less). On non-POSIX systems (i.e. Windows), it tries to do something sensible, but it may not be the best way to do it, and I've only ran the tests on Linux. 2. With almost any filesystem or operating system, saving a file by overwriting it exposes the user to the risk of data loss if there is a crash or power failure. cautious-file creates a temporary file first and only overwrites the file when it has finished writing (on POSIX systems with sane filesystems, at least). 3. Prelude.writeFile is supposed to lock files so that they at least cannot be written to simultaneously in multiple threads. This is good for safety, but might lead to avoidable problems with IO exceptions when one thread tries to open a file for writing which is still being written to by another thread. Again, the use of a randomly-named temporary file avoids this problem (not with certainty, but with a high probability, which is good enough for some applications). It does not prevent all file-related race conditions (nothing with its type signature could!), but if you are sure you don't care which thread wins, you should be able to use cautious-file's writeFile. A variant, writeFileWithBackup, also allows you to supply a custom backup computation to backup old copy(ies) of the destination file (which is not necessary with Prelude.writeFile, because you can just do it before you call Prelude.writeFile, but is necessary with cautious-file). cautious-file is obviously not appropriate for all circumstances - for instance, it's not needed for writing truly temporary files. But of course if it's close to what you need, you can adapt it (and send me a patch if you like). There is a test runner that can be run by running runhaskell Setup.lhs test or cabal test in a built copy of the source distribution. The tests do not actually verify that data loss doesn't happen if there's a crash! Indeed, attention should be drawn to the standard BSD license - despite the name cautious-file, there is no warranty. If in doubt, I suggest you take a close look at the source code - it's very short. I'd appreciate comments, patches, pointers to Haskell code that does the same thing already, etc. Thanks, -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
Am Sonntag, 19. Juli 2009 23:42 schrieben Sie: On Jul 18, 2009, at 9:26 PM, Wolfgang Jeltsch wrote: I don’t think, it’s a good idea to have German identifiers, since Haskell’s keywords are English. Put it this way: if Haskell's keywords were in German, do you suppose I would write my Haskell code in anything but English? At least, many people all over the world write their code in something other than their native language. :-) Does the fact that 'data' is a Latin word mean that some fraction of our Haskell identifiers should be in Latin? data is also an English word nowadays. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: graphviz-2999.0.0.0
2009/7/20 Brandon S. Allbery KF8NH allb...@ece.cmu.edu: Shouldn't String then be replaced by a sum type? In fact, as described this would subsume the Either as well. -- replace Either Bool String: AttrN are the strings, AltValue the bool data upstreamValue = AttrA | AttrB | AltValue Yes, as I said. I didn't for a few reasons: 1. I was running out of time and wanted to make a release on the weekend (I'm heading overseas in just over a week and have a fair few things to do before then). In future, this will probably be improved. 2. I forgot to replace those ones with the custom constructors :s Though IIRC, most of those that still have Either are those which probably aren't likely to be used, etc. Note also that (and this is also a problem with using Either) I have to think of a way to parse the values with a possible Bool field properly, since if a Bool is a valid value then just the attribute name is equivalent to name = true. At the moment, most attributes use a parseField function (that consumes the attribute name, the equals sign and then parses and returns the result) but those with just Bool attributes use a slight variant where if there is no equals sign, then True is returned. This will obviously not work too well with sum types :s. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com Pablo Picasso - Computers are useless. They can only give you answers. - http://www.brainyquote.com/quotes/authors/p/pablo_picasso.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem resizing widget contained in window
On Tue, Jul 14, 2009 at 5:46 PM, Jeff Heardjefferson.r.he...@gmail.com wrote: Now, if someone resizes the window, the GLArea does not appear to resize along with it. Did I screw something up? You need to call the opengl glViewport function(I don't remember what the haskell binding is called) in your resize handler so that opengl knows about the new viewport size. And you are also probably going to want to update the opengl projection matrix to prevent distortion as a result of a changed aspect ratio. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
