Re: [Haskell-cafe] Re: How to do this in FP way?
One half of all Haskell coders will tell you that mutable state isn't a good starting point to learn Haskell, the other half will tell you the same because they want to be cool kids, too. And the one left over will point out that he asked how to do this the FP way, not the imperative way? If it was me btw, I'd take a stab at the problem being that each time we do something a time gets updated and we want to know how much time has passed since we last did "something". I'd approach this by generating a lazy list of times at which we started doing "something", and then generating a lazy list of time differences. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory profiling
2008/6/16 Pieter Laeremans <[EMAIL PROTECTED]>: > Hi, > > Which tools do you recommand for memory profiling haskell programs > on a *nix system. > I'm using haskell to develop a CGI program/script. > > The application has to be deployed on shared hosting infrastructure. > Since I would like to be a good citizen , > I would need to meassure the maximum amount of memory allocated to the > program during execution. > The best I can do now is look at top but that 's not satisfactory. Are you aware that by calling the program with the correct RTS options you can have memory profiling ? http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime-control.html (see option -s for simple statistics) http://www.haskell.org/ghc/docs/latest/html/users_guide/prof-heap.html -- Jedaï ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to do this in FP way?
"Magicloud Magiclouds" <[EMAIL PROTECTED]> writes:
> static int old;
> int diff (int now) { /* this would be called once a second */
> int ret = now - old;
> old = now;
> return ret;
> }
> Because there is no "variable" in Haskell. So how to do this in a FP way?
I would claim the FP way is like this:
-- | Repeatedly subtract values from a baseline, returning a list
-- containing each intermediate result
diff :: Int -> [Int] -> [Int]
diff = scanl (-)
Prelude> diff 100 [1..10]
[100,99,97,94,90,85,79,72,64,55,45]
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Design your modules for qualified import
Am Sonntag, 15. Juni 2008 23:17 schrieb Duncan Coutts: > […] > If we get a proper way to export a non-flat namespace then Gtk2Hs will > certainly switch to using it. Using 'buttonBlah' is horrible but there > is currently nothing better. So is there anyone who wants to file a feature request? > […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to do this in FP way?
On Mon, 2008-06-16 at 10:19 +0200, Ketil Malde wrote:
> "Magicloud Magiclouds" <[EMAIL PROTECTED]> writes:
>
> > static int old;
> > int diff (int now) { /* this would be called once a second */
> > int ret = now - old;
> > old = now;
> > return ret;
> > }
>
> > Because there is no "variable" in Haskell. So how to do this in a FP
> > way?
>
> I would claim the FP way is like this:
>
> -- | Repeatedly subtract values from a baseline, returning a list
> -- containing each intermediate result
> diff :: Int -> [Int] -> [Int]
> diff = scanl (-)
>
> Prelude> diff 100 [1..10]
> [100,99,97,94,90,85,79,72,64,55,45]
Better yet, you could create a recursive type that reflects what you are
actually doing:
newtype Step a = Step (a -> (a, Step a))
diff' :: Int -> Step Int
diff' x = Step (\a -> let r = a - x in (r, diff' r))
This way it will be easier to resume previous diff computations.
Best,
Michał
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lazy IO.
hGetContents reads the entire contents of the stream till the end (although lazily). The return value of hGetContents is logically the entire contents of the stream. That it has not read it completely is only a part of its laziness, so the result does not depend upon when the caller stops consuming the result. That is why the handle is semi-closed; logically the handle is already at the end of the stream. A complete parser to parse the header and the body has to be used on the entire contents, or some function which knows how to find the header end and stop there has to be used. Regards, Abhay On Sat, Jun 14, 2008 at 9:48 PM, Sebastiaan Visser <[EMAIL PROTECTED]> wrote: > Hi, > > I've got a question about lazy IO in Haskell. The most well known > function to do lazy IO is the `hGetContents', which lazily reads all the > contents from a handle and returns this as a regular [Char]. > > The thing with hGetContents is that is puts the Handle in a semi-closed > state, no one can use the handle anymore. This behaviour is > understandable from the point of safety; it is not yet determined when > the result of hGetContents will actually be computed, using the handle > in the meantime is undesirable. > > The point is, I think I really have a situation in which I want to use > the handle again `after' a call to hGetContents. I think I can best > explain this using a code example. > > readHttpMessage :: IO (Headers, Data.ByteString.Lazy.ByteString) > readHttpMessage = do >myStream <- >request <- hGetContents myStream >header <- parseHttpHeader request >bs <- Data.ByteString.Lazy.hGetContents myStream >return (header, body) > > The Data.ByteString.Lazy.hGetContents in the example above obviously > fails because the handle is semi-closed. > > So, what I am trying to do here is apply a parser (on that consumes > Char's) to the input stream until it has succeeded. After this I want to > collect the remainings of the stream in a lazy ByteString, or maybe even > something else. > > I tried to open the handler again using some internal handle hackery, > but this failed (luckily). In the module GHC.IO there is a function > `lazyRead' that more or less seems to do what I want. But I'll guess > there is a good reason for not exporting it. > > Does anyone know a pattern in which I can do this easily? > > Thanks, > > -- > Sebastiaan > > ___ > 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] Design your modules for qualified import
Henning Thielemann wrote: On Mon, 9 Jun 2008, Duncan Coutts wrote: On Mon, 2008-06-09 at 16:04 +0200, Ketil Malde wrote: And - is there a way to make GHCi use aliased qualification? I find my self typing detailed taxonomies all the time there. The ghci syntax currently is: :m Data.Set wouldn't it be much nicer as: import Data.Set then we could have the obvious: import Data.Set as Set This would be nice! Feature request? feature request filed for this, http://hackage.haskell.org/trac/ghc/ticket/2362 . For extending the import syntax in general, I wasn't sure we knew quite what we wanted yet, so it seemed a little premature for a feature request. (the first step in "implementing" the feature request would have to be specifying an exact design and probably asking for community feedback). So let's talk about what we do or don't want for that one some more, perhaps. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Design your modules for qualified import
Duncan Coutts wrote: Right. That's exactly why we've not done something like that. With 100+ modules in the Gtk package it's totally infeasible to do qualified imports of them all. If we get a proper way to export a non-flat namespace then Gtk2Hs will certainly switch to using it. Using 'buttonBlah' is horrible but there is currently nothing better. okay, it's horrible! It's no more manually-traceable than anything else either, if you just import Gtk2Hs unqualified. Is there any way it could possibly be acceptably concise *and* traceable? let's see If "GTK" appears in every usage (e.g. GTK.buttonBlah, gtkButtonBlah...), probably not at all concise enough for GUI code! But if it doesn't, then we would need at minimum to list each of those ones that we used (probably not all 100 of them). It couldn't get any more concise than this to use Button.blah etc.: import GTK.modules (Button, Window, ...) never mind the exact syntax yet -- is listing them acceptable? (and if there are so many, is it practically traceable by humans anyway? Perhaps we're assuming that these humans at least have "search this file" editor-capabilities?) Are there multiple "blah" functions among the GTK modules? I.e. would GTK.blah be unambiguous, not mentioning that it's a button function. (And would it be too confusing not to mention that it's a button function...) If it would be ambiguous, would typeclasses work to fix that (or renaming functions that have no good reason to have the same name, or occasionally including blahButton sort of names)? If 100 modules is too much, would it be a reasonable compromise between clarity and conciseness to export coarser-grained, so there are only maybe half a dozen GTK modules that your typical program imports? There have been a few suggestions along these lines. Check the archives. I'm not sure what is proposed for haskell', probably nothing since nothing is currently implemented and we're only supposed to be standardising existing practise. I had trouble in my first attempt to search the archives... Googling for "import" in haskell-cafe found too much code, and my personal e-mail records back to March 2007 found nothing else relevant with "import" in the title. -Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Design your modules for qualified import
Hello Isaac, Monday, June 16, 2008, 4:02:10 PM, you wrote: > Are there multiple "blah" functions among the GTK modules? I.e. would > GTK.blah be unambiguous, not mentioning that it's a button function. yes. actually, gtk2hs uses typeclasses to overload functions over various types -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal-install failure
The main point of the Program abstraction is about configuring and running programs. As it happens some programs are provided by some haskell packages (but not all, eg ld, ar, etc). option to get version info and code to extract it (with one apparently very special case being hsc2hs). And ld.exe on windows (we find it in ghc's gcc-lib bin dir). I didn't notice this special case in Program.hs - are my sources just out of date, or is this special handling encoded elsewhere? Btw, most of the version extraction code looks like a regular expression match - wouldn't that make the specification easier (and turn the comments into part of the spec)? True, in most cases finding the name of the program involves running it with some --version flag and matching some part of the output. However that's not always the case. Some programs do silly things like produce the version output on stderr instead of stdout. We figured the most general thing was just a function FilePath -> IO (Maybe Version) which is what we've got. I'm not sure what the advantage would be to make it more declarative by making it into data rather than a extraction function. Usually, the most general approach for this kind of problem is good as a default/backup, but not so good for maintenance. The more cases can be handled with dedicated declarative specs, the smaller the risk of accidental/hidden breakage (eg, moving the comments into regex patterns), the more compact and understandable the specs (a line per tool, with option and regex, all in one place would be easier to comprehend than the current free-coding style). More importantly, concise declarative specs are easier to update and extend (could be done by users rather than Cabal maintainers, and preferably outside of Cabal sources). Also, the Cabal lib cannot depend on any regular expression library because they are not part of the bootstrapping library set. Sigh. I've heard that one before, and the ghc-pkg bulk queries are not as flexible as they could be because I had to use less expressive functions instead of regexes. Since Haskell-only regex packages exist, perhaps one should just be added to the bootlib set? After all, we bother with regexes because they are so frequently useful. 1. Haskell tools should register with Cabal, whether built with it (such as Alex, Happy, ..) or not (such as GHC, ..). That registration should include any build-relevant information (versions/variants, ..). 2. When checking a build-tools dependency, Cabal checks (a) whether the tool is registered with Cabal I'm not sure this helps. We want to know what to install when it's missing. We can already tell if a program (not package) is available by searching for it. But that means either configure or a subset of special configure rules baked into Cabal's sources, combined with fragile Setup.hs extensions to that subset. IMHO, the less of configure/hardcoded rules/Setup.hs, the better (simpler, less breakage with Cabal updates, etc.). How about this: instead of baking rules for those tools into the Cabal sources, why not have a single "known-tools" package? On (re-)installing that package, its configure/Setup is run once, to register availability and build-related information for all those tools with Cabal (currently, that would mean a package per tool; later, the known-tools package itself could expose multiple tools, but Cabal would still need to be able to check which of the "exposed-tools" have been found). That way, the known-tools could be updated independently, instead of requring Cabal source hacking and releases, and instead of spreading special configure rules for common tools over all packages, they'd be located in a single package (easier to maintain and improve, and improvements are shared). (b) whether the tool is registered with the system installation manager This is hard. Why? Because there are more installation managers than OSs, or because so many program installs bypass them? Querying an installation manager shouldn't be any more difficult than querying ghc-pkg, say. If a program is registered with, eg. Windows Add/Remove Programs, I can use "reg query " to find its registration info, and if I don't know the key, I can use reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall /s to list all registered programs, or reg export HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall to get all registration info dumped to a file, and look for DisplayNames of the tools I'm interested in: reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall /s | find "DisplayName" | find "Opera" DisplayName REG_SZ Opera 9.50 reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall /s | find "DisplayName" | find "Hugs" DisplayName REG_SZ WinHugs reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall /s | find "DisplayName" | find "Haskell" DisplayName REG_SZ Glasgow Hask
Re: [Haskell-cafe] Design your modules for qualified import
Duncan Coutts wrote: If we get a proper way to export a non-flat namespace then Gtk2Hs will certainly switch to using it. Using 'buttonBlah' is horrible but there is currently nothing better. Whilst I'm sure anyone who's used deep module structures has wondered about this feature, I've seen no serious proposal of any kind. Does anyone know what this should look like? Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lazy IO.
Sebastiaan Visser wrote: Does anyone know a pattern in which I can do this easily? Don't use hGetContents on a socket. That's asking for trouble. Use hGetContents either NEVER (easy option) or only on throwaway handles/files which won't be used again. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Design your modules for qualified import
Duncan Coutts wrote: If we get a proper way to export a non-flat namespace then Gtk2Hs will certainly switch to using it. Using 'buttonBlah' is horrible but there is currently nothing better. Whilst I'm sure anyone who's used deep module structures has wondered about this feature, I've seen no serious proposal of any kind. google for "haskell package mounting" or "haskell package grafting". Perhaps the discussion has appeared under other keywords, but those are the ones that spring to mind. Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lazy IO.
On Jun 16, 2008, at 2:58 PM, Jules Bean wrote: Sebastiaan Visser wrote: Does anyone know a pattern in which I can do this easily? Don't use hGetContents on a socket. That's asking for trouble. Can you please explain why? What is a more easier method to spool your HTTP post data to a file than: Bs.hGetContens sock >>= Bs.hPut fd ? Use hGetContents either NEVER (easy option) or only on throwaway handles/files which won't be used again. My sockets will be thrown away eventually. Isn't anything? I can imagine that this can be a problem when using Keep-Alive connections - or alike - but that is a whole different story. Jules Thanks, Sebas. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lazy IO.
Sebastiaan Visser wrote: On Jun 16, 2008, at 2:58 PM, Jules Bean wrote: Sebastiaan Visser wrote: Does anyone know a pattern in which I can do this easily? Don't use hGetContents on a socket. That's asking for trouble. Can you please explain why? Because it's a broken abstraction. It's only correct if all you will ever do is read all the data into one String and don't care about it after that. In my experience this is almost never true of sockets : there is always protocol overhead, handshaking, and the "next request". It might be fine for unusually simple socket setups. What is a more easier method to spool your HTTP post data to a file than: Bs.hGetContens sock >>= Bs.hPut fd ? Yes, that's fine. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: How to do this in FP way?
Thomas Davie <[EMAIL PROTECTED]> wrote: > > > > One half of all Haskell coders will tell you that mutable state > > isn't a > > good starting point to learn Haskell, the other half will tell you > > the same because they want to be cool kids, too. > > And the one left over will point out that he asked how to do this > the FP way, not the imperative way? > There's no difference, as you can't do time-accounting non-strict and still expect it to give meaningful results: I'm merely trying to be helpful. None of the other solutions allow for the IO Monad. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Lazy IO.
Jules Bean <[EMAIL PROTECTED]> wrote: > Sebastiaan Visser wrote: > > On Jun 16, 2008, at 2:58 PM, Jules Bean wrote: > > > >> Sebastiaan Visser wrote: > >>> Does anyone know a pattern in which I can do this easily? > >> > >> Don't use hGetContents on a socket. That's asking for trouble. > > > > Can you please explain why? > > Because it's a broken abstraction. > > It's only correct if all you will ever do is read all the data into > one String and don't care about it after that. > > In my experience this is almost never true of sockets : there is > always protocol overhead, handshaking, and the "next request". > It works for HTTP, as all responses MUST be in the same order as the requests. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Design suggestion for Data.Binary.Defer
Hi,
I'm in the process of updating the Deferred Binary library,
http://www-users.cs.york.ac.uk/~ndm/binarydefer/. The idea is that its
does serialisation, but certain elements can be marked as deferred -
instead of being written in the current file stream, they are merely
pointed at and if needed, that pointer will be followed.
Example:("hello","world"), where the first field is marked as deferred
would write out:
[6]"world""hello"
i.e. [skip 6 characters if you want hello], the "world" data, the
"hello" data we previously promised to put here. When reading, the
"hello" would only be seeked to and read if necessary.
So, its like binary, but some fields are lazy. The question is how to
indicate which fields are lazy. There are three schemes I can think
of:
== Simple Instances ==
put (a,b) = putDefer a >> put b
get = do a <- getDefer; b <- get; return (a,b)
If the put/get and putDefer/getDefer items do not line up perfectly it
will go very wrong at runtime - probably resulting in random values
being created. You also can't derive the instances automatically, with
something like Derive or DrIFT.
== Complex Instances ==
This is the current scheme, based on lazy pattern matching and
exceptions - very confusing, probably low performance.
deferBoth = [\~(a,b) -> unit (,) <<~ a << b]
Where <<~ a means write out the a field lazily, and << b means write
out the b field strictly. The advantage over the simple instances is
that a field being deferred is declared once.
== Lazy Data Type ==
Instead of customizing the instance, you can write a data Defer a =
Defer a type, and then instead of the original tuple write:
(Defer "hello","world")
But now the code must unwrap the Defer before accessing "hello", but
the instance becomes much simpler, and can be derived.
== The Question ==
Is there a simple way of tagging fields in a constructor as deferred,
just once for reading and writing, and ideally outside the instance
definition and not requiring additional code to unwrap? I can't think
of any, but there may be something I have missed.
Thanks
Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: How to do this in FP way?
On 16 Jun 2008, at 18:28, Achim Schneider wrote: Thomas Davie <[EMAIL PROTECTED]> wrote: One half of all Haskell coders will tell you that mutable state isn't a good starting point to learn Haskell, the other half will tell you the same because they want to be cool kids, too. And the one left over will point out that he asked how to do this the FP way, not the imperative way? There's no difference, as you can't do time-accounting non-strict and still expect it to give meaningful results: I'm merely trying to be helpful. None of the other solutions allow for the IO Monad. Firstly, I'd phrase that differently -- the IO Monad doesn't allow for the other solutions -- the other solutions are the truly functional ones. Secondly, I'm curious as to why you think that the two are incompatible, are you saying that for any meaningful kind of computation we need to resort to IORefs? I'd strongly contest that idea. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to do this in FP way?
2008/6/15 Magicloud Magiclouds <[EMAIL PROTECTED]>:
> Hello,
> I am getting familiar with FP now, and I have a "program design" kind of
> question.
> Say I have something like this in C:
> static int old;
> int diff (int now) { /* this would be called once a second */
> int ret = now - old;
> old = now;
> return ret;
> }
> Because there is no "variable" in Haskell. So how to do this in a FP
> way?
A better question would be to think about what you are trying to
accomplish, and then ask how to achieve that through functional
programming.
David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: How to do this in FP way?
Thomas Davie <[EMAIL PROTECTED]> wrote: > > On 16 Jun 2008, at 18:28, Achim Schneider wrote: > > > Thomas Davie <[EMAIL PROTECTED]> wrote: > > > >>> > >>> One half of all Haskell coders will tell you that mutable state > >>> isn't a > >>> good starting point to learn Haskell, the other half will tell you > >>> the same because they want to be cool kids, too. > >> > >> And the one left over will point out that he asked how to do this > >> the FP way, not the imperative way? > >> > > There's no difference, as you can't do time-accounting non-strict > > and still expect it to give meaningful results: I'm merely trying > > to be helpful. None of the other solutions allow for the IO Monad. > > Firstly, I'd phrase that differently -- the IO Monad doesn't allow > for the other solutions -- the other solutions are the truly > functional ones. Secondly, I'm curious as to why you think that the > two are incompatible, are you saying that for any meaningful kind of > computation we need to resort to IORefs? I'd strongly contest that > idea. > We have to resort to IO actions to get the time, and to IORefs because we need to chain up different calls to getCurrentTime using the IO Monad. The rest of the program can work with whatever you like best. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to do this in FP way?
On Mon, Jun 16, 2008 at 10:31:22AM +0800, Magicloud Magiclouds wrote:
> Hello,
> I am getting familiar with FP now, and I have a "program design" kind of
> question.
> Say I have something like this in C:
> static int old;
> int diff (int now) { /* this would be called once a second */
> int ret = now - old;
> old = now;
> return ret;
> }
> Because there is no "variable" in Haskell. So how to do this in a FP
> way?
>
> Thanks.
I think that "called once a second" suggests that you perhaps should
not do that in a FP way.
A state-changing function called frequently suggests that you are
perhaps doing something with a notion of time, maybe a game? Then FRP
is your FP approach.
Or I would recommend you to explain your problem, because FP approach
could lie on much more higher level than one can figure out looking at
your short snippet.
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
--
pierre
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: How to do this in FP way?
On Mon, 16 Jun 2008, Achim Schneider wrote: We have to resort to IO actions to get the time, and to IORefs because we need to chain up different calls to getCurrentTime using the IO Monad. The rest of the program can work with whatever you like best. Isn't (StateT s IO a) the cleaner alternative to IORef? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: How to do this in FP way?
Henning Thielemann <[EMAIL PROTECTED]> wrote: > > On Mon, 16 Jun 2008, Achim Schneider wrote: > > > We have to resort to IO actions to get the time, and to IORefs > > because we need to chain up different calls to getCurrentTime using > > the IO Monad. The rest of the program can work with whatever you > > like best. > > Isn't (StateT s IO a) the cleaner alternative to IORef? > Yes. But then using one IORef in one place won't make your program harder to understand, using Monad transformers quite certainly will. Admittedly, I'm becoming dodgy. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to do this in FP way?
On 6/16/08, Magicloud Magiclouds <[EMAIL PROTECTED]> wrote:
>
> Hello,
> I am getting familiar with FP now, and I have a "program design" kind
> of question.
> Say I have something like this in C:
> static int old;
> int diff (int now) { /* this would be called once a second */
> int ret = now - old;
> old = now;
> return ret;
> }
> Because there is no "variable" in Haskell. So how to do this in a FP
> way?
The short answer is that your question amounts to "How do I do imperative
programming in an FP way", to which the answer is "you really should try to
avoid it".
Longer answer:
I think you'll be bette served if you describe your problem on a much higher
level than this. Chances are that if you write your program in an FP way,
you wouldn't need a function like your diff.
That said, Haskell do have variables (in this case an IORef would do what
you want), but again, you probably don't want that, so if you post what
problem you're trying to solve using "diff", then it will be easier to help
you design it in an FP way. Doing things in an FP way tend to impact your
program a lot more than just some minor changes to the functions at the
"bottom", it will change the whole design.
--
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monomorphism restriction
On 6/11/08, Jonathan Cast <[EMAIL PROTECTED]> wrote: > This doesn't apply to f, though --- it has a function type, so the user > presumably already knows it won't be subject to updating, no? > Distinguishing functions from variables by the form of declaration, > rather than the type, seems somewhat questionable to me. Not necessarily, contrast these two definitions: f = foldr (+) 0 f_expensive = let n = head $ drop 10 $ fibs 1 1 in foldr (+) n With the monomorphism restriction in place, f_expensive only calculates n once. Without, it gets calculated each time f is instantiated. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to do this in FP way?
David Roundy wrote: A better question would be to think about what you are trying to accomplish, and then ask how to achieve that through functional programming. Amen! I was waiting for somebody to say that... There are a dozen situations in an imperative language where you'd write a loop. But in Haskell, you might well do something entirely different for each situation. So it really pays to focus on what the end result you're after is, rather than how to translate imperative code line-for-line into Haskell. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FunPtr error?
The simple explanation is "because the FFI standard says so";
primitive types wrapped in newtypes automatically get wrapped and
unwrapped during FFI calls. See
http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise3.html#x6-120003.2
; the FFI uses "renamed datatype" to mean newtype.
Consider the following declarations translated to C:
> type Weak = Word32
> {- typedef HsWord32 Weak; }
Weak is just a type alias; you can use Word32 and Weak interchangeably
in your code after delcaring this type.
> newtype Strong = Strong Word32
> {- doesn't really exist in C; google for "c strong typedef" -}
Strong behaves exactly like a Word32 at runtime, in terms of storage,
but the typechecker can distinguish it from Word32.
> data Holder = Holder Word32
> {- typedef struct { HsWord32 x; } Holder; -}
Holder, on the other hand, is entirely separate from Word32; in fact,
there are strictly more values in Haskell of type Holder than there
are of type Word32:
> ha, hb, hc :: Holder -- can all be distinguished at runtime
> ha = undefined
> hb = Holder undefined
> hc = Holder 0
> sa, sb :: Strong -- cannot be distinguished
> sa = undefined
> sb = Strong undefined
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] C-program calling Haskell program?
Hello, I am very new to Haskell, and I work in Windows XP. Can anyone please point me to a working C / Haskell program pair that does the following: 1) The C routine passes one or more scalars, arrays, or matrices to the Haskell routine. 2) The Haskell routine reads a comma-delimited, ASCII file from the path, C:\my_directory\input_data\. 3) The Haskell routine writes a comma-delimited, ASCII file to the path, C:\my_directory\output_data\. 4) The Haskell routine returns to the C routine one or more scalars, arrays, or matrices. 5) For what it's worth, I'm only using the C-routine as an interface between MATLAB and Haskell, because MATLAB can call C-routines. Has anyone written C / Haskell code that does the above tasks? If so, would you please be willing to pass it along to me? Thank you! Bob [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records. To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Design suggestion for Data.Binary.Defer
On Mon, 2008-06-16 at 17:43 +0100, Neil Mitchell wrote:
> Hi,
>
> I'm in the process of updating the Deferred Binary library,
> http://www-users.cs.york.ac.uk/~ndm/binarydefer/. The idea is that its
> does serialisation, but certain elements can be marked as deferred -
> instead of being written in the current file stream, they are merely
> pointed at and if needed, that pointer will be followed.
>
> Example:("hello","world"), where the first field is marked as deferred
> would write out:
>
> [6]"world""hello"
>
> i.e. [skip 6 characters if you want hello], the "world" data, the
> "hello" data we previously promised to put here. When reading, the
> "hello" would only be seeked to and read if necessary.
>
> So, its like binary, but some fields are lazy. The question is how to
> indicate which fields are lazy. There are three schemes I can think
> of:
>
> == Simple Instances ==
>
> put (a,b) = putDefer a >> put b
> get = do a <- getDefer; b <- get; return (a,b)
>
> If the put/get and putDefer/getDefer items do not line up perfectly it
> will go very wrong at runtime - probably resulting in random values
> being created. You also can't derive the instances automatically, with
> something like Derive or DrIFT.
>
> == Complex Instances ==
>
> This is the current scheme, based on lazy pattern matching and
> exceptions - very confusing, probably low performance.
>
> deferBoth = [\~(a,b) -> unit (,) <<~ a << b]
>
> Where <<~ a means write out the a field lazily, and << b means write
> out the b field strictly. The advantage over the simple instances is
> that a field being deferred is declared once.
>
> == Lazy Data Type ==
>
> Instead of customizing the instance, you can write a data Defer a =
> Defer a type, and then instead of the original tuple write:
>
> (Defer "hello","world")
>
> But now the code must unwrap the Defer before accessing "hello", but
> the instance becomes much simpler, and can be derived.
>
> == The Question ==
>
> Is there a simple way of tagging fields in a constructor as deferred,
> just once for reading and writing, and ideally outside the instance
> definition and not requiring additional code to unwrap? I can't think
> of any, but there may be something I have missed.
This isn't an answer to your question. This is just my opinion based on
my values.
I'd just immediately do option three. It seems the simplest, most
composable and most flexible, and I like having things reflected in my
types. It seems easy enough to code up the first option given the last.
I don't really understand what you are getting at with the second
option, but I suspect it too is easy to do on top of the third option.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] 1/0
So, I know this has been discussed before, but: > 1/0 Infinity > 0/0 NaN ... so I see from the archives that Infinity is mandated by ieee754 even though my intuition says both should be NaN. Every other language throws an exception, even C will crash the program, so I'm guessing it's telling the processor / OS to turn these into signals, while GHC is turning that off. Or something. But then what about this note in Control.Exception: (NOTE: GHC currently does not throw ArithExceptions except for DivideByZero) Doesn't this imply GHC should be throwing DivideByZero? Why is it in the stdlib if it's turned off? And why would it be turned off? I suppose I could accept the above since Infinity *is* an exceptional value meant to represent things like 1/0, and it can be nice to see NaNs in your output instead of crashing everything (this is, I assume, why ieee754 has these modes in the first place), but how about this: > round (0/0) :: Integer (huge negative number) Ok, so integral types don't have that exceptional value. Shouldn't trying to convert NaN or Infinity to an Integral throw something? Is it a performance thing? I'd think if you're converting to Integer you don't really need hardware level performance anyway, so a couple of checks wouldn't kill anyone. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Design suggestion for Data.Binary.Defer
On Mon, Jun 16, 2008 at 9:43 AM, Neil Mitchell <[EMAIL PROTECTED]> wrote: > == The Question == > > Is there a simple way of tagging fields in a constructor as deferred, > just once for reading and writing, and ideally outside the instance > definition and not requiring additional code to unwrap? I can't think > of any, but there may be something I have missed. Is there any reason not to just write all lazy fields of variable size in a deferred manner? That would seem like the best option to me, but maybe that's just because I don't see any downside besides the requirement that one use some space to write the size. But that seems like it would almost always be a trivial issue, as any small data element will have a fixed size (so that the deferred/non-deferred distinction doesn't exist). David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
On Mon, Jun 16, 2008 at 4:07 PM, Evan Laforge <[EMAIL PROTECTED]> wrote: > So, I know this has been discussed before, but: > >> 1/0 > Infinity >> 0/0 > NaN > > ... so I see from the archives that Infinity is mandated by ieee754 > even though my intuition says both should be NaN. There is a good reason for 1/0 being infinity, as it allows correct programs to give correct answers even in the presence of underflow and overflow. > Every other language throws an exception, even C will crash the > program, so I'm guessing it's telling the processor / OS to turn these > into signals, while GHC is turning that off. Or something. But then > what about this note in Control.Exception: That's just not true. It depends on how your system (compiler?) is configured, but the default on most systems that I've used is to return NaNs. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
On Mon, Jun 16, 2008 at 4:18 PM, David Roundy <[EMAIL PROTECTED]> wrote: > On Mon, Jun 16, 2008 at 4:07 PM, Evan Laforge <[EMAIL PROTECTED]> wrote: >> Every other language throws an exception, even C will crash the >> program, so I'm guessing it's telling the processor / OS to turn these >> into signals, while GHC is turning that off. Or something. But then >> what about this note in Control.Exception: > > That's just not true. It depends on how your system (compiler?) is > configured, but the default on most systems that I've used is to > return NaNs. Sorry, I just read my post, and realized I quoted too much. I was responding to the first sentence about other languages, thinking of octave, C and C++. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
On Mon, Jun 16, 2008 at 04:07:33PM -0700, Evan Laforge wrote: > So, I know this has been discussed before, but: > Every other language throws an exception, even C will crash the > program, so I'm guessing it's telling the processor / OS to turn these > into signals, while GHC is turning that off. Or something. But then > what about this note in Control.Exception: No, The issue is that '/' is always floating point division in haskell, for integer division, use `div`. 1 `div` 0 throws an exception like you expect. GHC behaves exactly the same as C here. But in C whether '/' means floating point or integral division depends on the types of its arguments, in haskell they are separate operators. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
"Evan Laforge" <[EMAIL PROTECTED]> writes:
> So, I know this has been discussed before, but:
>
>> 1/0
> Infinity
>> 0/0
> NaN
>
> ... so I see from the archives that Infinity is mandated by ieee754
> even though my intuition says both should be NaN.
>
> Every other language throws an exception, even C will crash the
> program, so I'm guessing it's telling the processor / OS to turn these
> into signals, while GHC is turning that off. [...]
No, C will not, with floating point type. The following
program prints out a string "inf\n".
#include
int main (void)
{
double a=1, b=0;
double i;
i = a / b;
printf ("%g\n",i);
return 0;
}
I believe Haskell is behaving rationally.
Cheers,
Xiao-Yong
--
c/*__o/*
<\ * (__
*/\ <
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
> No, The issue is that '/' is always floating point division in haskell, > for integer division, use `div`. > > 1 `div` 0 throws an exception like you expect. > > GHC behaves exactly the same as C here. But in C whether '/' means > floating point or integral division depends on the types of its > arguments, in haskell they are separate operators. Aha, I was missing something. Indeed, 1.0/0.0 gives me infinity with C. Thanks for the clarification. Python does throw for 1.0/0.0, but I think there's a (not very commonly used) module to turn that off. It might be nice for GHC to have a some way to turn exceptions on, but I can accept getting NaNs, and doing the ieee754 thing by default seems entirely reasonable. But what about that NaN->Integer conversion thing? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
On Monday 16 June 2008, Evan Laforge wrote:
> So, I know this has been discussed before, but:
> > 1/0
>
> Infinity
>
> > 0/0
>
> NaN
>
> ... so I see from the archives that Infinity is mandated by ieee754
> even though my intuition says both should be NaN.
>
> Every other language throws an exception, even C will crash the
> program, so I'm guessing it's telling the processor / OS to turn these
> into signals, while GHC is turning that off. Or something. But then
> what about this note in Control.Exception:
#include
#include
int main (int argc, char **argv)
{
float f1 = 1.0/0.0;
float f2 = 0.0/0.0;
printf("%f\n%f\n", f1, f2);
return EXIT_SUCCESS;
}
% ./Inf
inf
nan
In a Haskell program, 1/0 is floating point division. In C, 1/0 is integer
division, which may get implicitly converted to a floating point if you
say "float f = 1/0;". That's why you get the exception in C.
> but how about this:
> > round (0/0) :: Integer
>
> (huge negative number)
>
> Ok, so integral types don't have that exceptional value. Shouldn't
> trying to convert NaN or Infinity to an Integral throw something? Is
> it a performance thing? I'd think if you're converting to Integer you
> don't really need hardware level performance anyway, so a couple of
> checks wouldn't kill anyone.
This is a (known by some) bug of sorts in the various floating point ->
integral transformations (which ultimately boil down to decodeFloat or
something like that at some point). It apparently doesn't know about the
various exceptional values in the IEEE representation, so it just treats the
representation like any other value. Infinity and NaN look like various huge
numbers if you interpret them like any other value, so that's what you get
out of round/ceiling/floor/etc.
It's not ideal, but I guess no one's bothered to fix it. Might be something to
bring up on the libraries mailing list.
-- Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
On Mon, Jun 16, 2008 at 04:41:23PM -0700, Evan Laforge wrote: > But what about that NaN->Integer conversion thing? I think that may be a bug or at least a misfeature. The standard is somewhat vauge on a lot of issues dealing with floating point since it is such a tricky subject and depends a lot on the environment. The various rounding funcitons are particularly ugly IMHO. I added varients of them that preserved the floating point type and properly implemented IEEE behavior for jhc. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
On Mon, Jun 16, 2008 at 04:50:05PM -0700, John Meacham wrote: > On Mon, Jun 16, 2008 at 04:41:23PM -0700, Evan Laforge wrote: > > But what about that NaN->Integer conversion thing? > > I think that may be a bug or at least a misfeature. The standard is > somewhat vauge on a lot of issues dealing with floating point since > it is such a tricky subject and depends a lot on the environment. The > various rounding funcitons are particularly ugly IMHO. I added varients > of them that preserved the floating point type and properly implemented > IEEE behavior for jhc. I think the Data.Binary guys think it's a feature, since they rely in this behavior (well, they rely on the equivalently-foolish behavior of toRational). I think it's a bug. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
droundy: > On Mon, Jun 16, 2008 at 04:50:05PM -0700, John Meacham wrote: > > On Mon, Jun 16, 2008 at 04:41:23PM -0700, Evan Laforge wrote: > > > But what about that NaN->Integer conversion thing? > > > > I think that may be a bug or at least a misfeature. The standard is > > somewhat vauge on a lot of issues dealing with floating point since > > it is such a tricky subject and depends a lot on the environment. The > > various rounding funcitons are particularly ugly IMHO. I added varients > > of them that preserved the floating point type and properly implemented > > IEEE behavior for jhc. > > I think the Data.Binary guys think it's a feature, since they rely in > this behavior (well, they rely on the equivalently-foolish behavior of > toRational). I think it's a bug. You mean: instance Binary Double where put d = put (decodeFloat d) get = liftM2 encodeFloat get get ? if you've a portable Double decoding that works in GHC and Hugs, I'm accepting patches. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
On Mon, Jun 16, 2008 at 05:08:36PM -0700, Don Stewart wrote: > droundy: > > On Mon, Jun 16, 2008 at 04:50:05PM -0700, John Meacham wrote: > > > On Mon, Jun 16, 2008 at 04:41:23PM -0700, Evan Laforge wrote: > > > > But what about that NaN->Integer conversion thing? > > > > > > I think that may be a bug or at least a misfeature. The standard is > > > somewhat vauge on a lot of issues dealing with floating point since > > > it is such a tricky subject and depends a lot on the environment. The > > > various rounding funcitons are particularly ugly IMHO. I added varients > > > of them that preserved the floating point type and properly implemented > > > IEEE behavior for jhc. > > > > I think the Data.Binary guys think it's a feature, since they rely in > > this behavior (well, they rely on the equivalently-foolish behavior of > > toRational). I think it's a bug. > > You mean: > > instance Binary Double where > put d = put (decodeFloat d) > get = liftM2 encodeFloat get get > > ? > > if you've a portable Double decoding that works in GHC and Hugs, I'm > accepting patches. I really don't understand why being portable is such an issue. Is it really better to behave wrong on every platform rather than behaving wrong on a very small minority of platforms? Anyhow, I've not hacked on binary, because I've not used it, and have trouble seeing when I would use it. So maybe I shouldn't have brought the subject up, except that this use of decodeFloat/encodeFloat is a particularly egregious misuse of floating point numbers. decodeFloat really ought to be a partial function, and this should be a crashing bug, if the standard libraries were better-written. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
droundy: > On Mon, Jun 16, 2008 at 05:08:36PM -0700, Don Stewart wrote: > > droundy: > > > On Mon, Jun 16, 2008 at 04:50:05PM -0700, John Meacham wrote: > > > > On Mon, Jun 16, 2008 at 04:41:23PM -0700, Evan Laforge wrote: > > > > > But what about that NaN->Integer conversion thing? > > > > > > > > I think that may be a bug or at least a misfeature. The standard is > > > > somewhat vauge on a lot of issues dealing with floating point since > > > > it is such a tricky subject and depends a lot on the environment. The > > > > various rounding funcitons are particularly ugly IMHO. I added varients > > > > of them that preserved the floating point type and properly implemented > > > > IEEE behavior for jhc. > > > > > > I think the Data.Binary guys think it's a feature, since they rely in > > > this behavior (well, they rely on the equivalently-foolish behavior of > > > toRational). I think it's a bug. > > > > You mean: > > > > instance Binary Double where > > put d = put (decodeFloat d) > > get = liftM2 encodeFloat get get > > > > ? > > > > if you've a portable Double decoding that works in GHC and Hugs, I'm > > accepting patches. > > I really don't understand why being portable is such an issue. Is it > really better to behave wrong on every platform rather than behaving > wrong on a very small minority of platforms? The Binary instances are required to be portable, as that's the part of the definition of Binary's mandate: a portable binary encoding. > Anyhow, I've not hacked on binary, because I've not used it, and have > trouble seeing when I would use it. So maybe I shouldn't have brought > the subject up, except that this use of decodeFloat/encodeFloat is a > particularly egregious misuse of floating point numbers. > decodeFloat > really ought to be a partial function, and this should be a crashing > bug, if the standard libraries were better-written. It's a bug in the H98 report then: Section 6.4.6: "The function decodeFloat applied to a real floating-point number returns the significand expressed as an Integer and an appropriately scaled exponent (an Int). If decodeFloat x yields (m,n), then x is equal in value to mb^n, where b is the floating-point radix, and furthermore, either m and n are both zero or else b^d-1<=mhttp://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Haddock Trac
hi, I wasn't able to add an attachment to a ticket, is something wrong with permissions? Python Traceback Traceback (most recent call last): File "/var/lib/python-support/python2.4/trac/web/main.py", line 387, in dispatch_request dispatcher.dispatch(req) File "/var/lib/python-support/python2.4/trac/web/main.py", line 237, in dispatch resp = chosen_handler.process_request(req) File "/var/lib/python-support/python2.4/trac/attachment.py", line 361, in process_request self._do_save(req, attachment) File "/var/lib/python-support/python2.4/trac/attachment.py", line 494, in _do_save attachment.insert(filename, upload.file, size) File "/var/lib/python-support/python2.4/trac/attachment.py", line 180, in insert os.makedirs(self.path) File "os.py", line 156, in makedirs makedirs(head, mode) File "os.py", line 159, in makedirs mkdir(name, mode) OSError: [Errno 13] Permission denied: '/srv/trac/haddock/attachments/ticket' Cheers, Misha ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
On Mon, Jun 16, 2008 at 05:39:39PM -0700, Don Stewart wrote: > It's a bug in the H98 report then: Yes, I consider a whole lot of the floating point stuff in the report a bug of sorts IMHO :) It is certainly something that I hope to work on for Haskell'. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
On Mon, Jun 16, 2008 at 05:39:39PM -0700, Don Stewart wrote: > > decodeFloat really ought to be a partial function, and this should > > be a crashing bug, if the standard libraries were better-written. > > It's a bug in the H98 report then: > > Section 6.4.6: > > "The function decodeFloat applied to a real floating-point number returns > the significand expressed as an Integer and an appropriately scaled > exponent (an Int). If decodeFloat x yields (m,n), then x is equal in value > to mb^n, where b is the floating-point radix, and furthermore, either m > and n are both zero or else b^d-1<=m floatDigits x. encodeFloat performs the inverse of this transformation. > " Yes, it is a bug in the report, that it doesn't fully specify the behavior this function when given a NaN or infinity. There's also a bug in the standard libraries, which is that they don't conform to the report. let x = 0/0 let (m,n) = decodeFloat x Prelude> (m,n) (-6755399441055744,972) Prelude> let x = 0/0 Prelude> x NaN Prelude> let d = floatDigits x Prelude> let (m,n) = decodeFloat x Prelude> let x' = (fromInteger m :: Double)*2^n Prelude> x' -Infinity Prelude> 2^d-1<=m False Prelude> m<2^d True So for the ghc decodeFloat, when operating on a NaN, the specifications of decodeFloat are almost completely unsatisfied. On the plus side, at least it's true that mhttp://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: How to do this in FP way?
On 16 Jun 2008, at 19:24, Achim Schneider wrote: Thomas Davie <[EMAIL PROTECTED]> wrote: On 16 Jun 2008, at 18:28, Achim Schneider wrote: Thomas Davie <[EMAIL PROTECTED]> wrote: One half of all Haskell coders will tell you that mutable state isn't a good starting point to learn Haskell, the other half will tell you the same because they want to be cool kids, too. And the one left over will point out that he asked how to do this the FP way, not the imperative way? There's no difference, as you can't do time-accounting non-strict and still expect it to give meaningful results: I'm merely trying to be helpful. None of the other solutions allow for the IO Monad. Firstly, I'd phrase that differently -- the IO Monad doesn't allow for the other solutions -- the other solutions are the truly functional ones. Secondly, I'm curious as to why you think that the two are incompatible, are you saying that for any meaningful kind of computation we need to resort to IORefs? I'd strongly contest that idea. We have to resort to IO actions to get the time, and to IORefs because we need to chain up different calls to getCurrentTime using the IO Monad. The rest of the program can work with whatever you like best. And in what way is this incompatible with either FRP as pierre suggested, or with generating an infinite list of times at which we call the function, and scanning it to find the differences? Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
On 2008 Jun 16, at 19:18, David Roundy wrote: On Mon, Jun 16, 2008 at 4:07 PM, Evan Laforge <[EMAIL PROTECTED]> wrote: Every other language throws an exception, even C will crash the program, so I'm guessing it's telling the processor / OS to turn these into signals, while GHC is turning that off. Or something. But then what about this note in Control.Exception: That's just not true. It depends on how your system (compiler?) is configured, but the default on most systems that I've used is to return NaNs. It's how the system FPU is configured; most FPU hardware on Unixlike systems let you configure the FPU behavior on a per-process basis, although the amount of configurability may vary. That said, the divide by zero exception you get in both C and Haskell is *integer* divide-by-zero. Floating is mandated by IEEE standard to produce Inf (but as said above, can usually be configured). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
On 17 Jun 2008, at 11:07 am, Evan Laforge wrote: So, I know this has been discussed before, but: 1/0 Infinity 0/0 NaN ... so I see from the archives that Infinity is mandated by ieee754 even though my intuition says both should be NaN. Other people have other intuitions. It may be that your intuition is telling you that neither result should be an ordinary number, and if that's what it's really telling you, it's right: the C function isfinite(x) is true of all signed zero, subnormal, or normal x, false of signed infinities and NaNs. > Every other language throws an exception, even C will crash the program, Not true. C99 *definitely* allows both infinities and NaNs (see Annex F of the C99 standard) and C89 practice also allowed it. Some C89 systems required you to use signal() with SIGFPE to turn IEEE extended results into exceptions; others required you to use signal() to disable this; others used yet other means. The Scheme systems I tried turn (/ 1.0 0.0) into a printed representation of IEEE infinity. Of the Prolog systems I checked, some did and some didn't. The Standard ML system I tried gave "inf" as the response to 1.0/0.0. Basically, with any programming language implementation that truthfully claims conformance to IEEE 754 or a successor standard, x/0 MUST NOT crash unless your program explicitly asks for such behaviour. As for programming language implementations that do not make such a claim, who knows what they will do? Since integers do not have the special IEEE values, conversion of IEEE values to integral values really ought to be checked. (Of course, in C what you typically get is garbage, but that can be put more generally...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
>> ... so I see from the archives that Infinity is mandated by ieee754 >> even though my intuition says both should be NaN. > > Other people have other intuitions. It may be that your intuition > is telling you that neither result should be an ordinary number, > and if that's what it's really telling you, it's right: the C > function isfinite(x) is true of all signed zero, subnormal, or > normal x, false of signed infinities and NaNs. Yeah, on reflection, I think my "intuition" derives from me asking a math teacher back in high school "isn't n/0 infinity?" after looking at a graph, to which he said "no, it's undefined, you can only say it approaches infinity in the limit, but it isn't infinity". >> Every other language throws an exception, even C will crash the >> >> program, > > Not true. C99 *definitely* allows both infinities and NaNs (see > Annex F of the C99 standard) and C89 practice also allowed it. > Some C89 systems required you to use signal() with SIGFPE to > turn IEEE extended results into exceptions; others required you > to use signal() to disable this; others used yet other means. Yes, I was mistaken here, as has been pointed out. And I should definitely know better than to make some generalization about "every other language" among this crowd :) > (Of course, in C what you typically get is garbage, but that can > be put more generally...) Heh, one for the C-bashing quotes file... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: How to do this in FP way?
Thomas Davie <[EMAIL PROTECTED]> wrote: > > On 16 Jun 2008, at 19:24, Achim Schneider wrote: > > > Thomas Davie <[EMAIL PROTECTED]> wrote: > > > >> > >> On 16 Jun 2008, at 18:28, Achim Schneider wrote: > >> > >>> Thomas Davie <[EMAIL PROTECTED]> wrote: > >>> > > > > One half of all Haskell coders will tell you that mutable state > > isn't a > > good starting point to learn Haskell, the other half will tell > > you the same because they want to be cool kids, too. > > And the one left over will point out that he asked how to do this > the FP way, not the imperative way? > > >>> There's no difference, as you can't do time-accounting non-strict > >>> and still expect it to give meaningful results: I'm merely trying > >>> to be helpful. None of the other solutions allow for the IO Monad. > >> > >> Firstly, I'd phrase that differently -- the IO Monad doesn't allow > >> for the other solutions -- the other solutions are the truly > >> functional ones. Secondly, I'm curious as to why you think that > >> the two are incompatible, are you saying that for any meaningful > >> kind of computation we need to resort to IORefs? I'd strongly > >> contest that idea. > >> > > We have to resort to IO actions to get the time, and to IORefs > > because we need to chain up different calls to getCurrentTime using > > the IO Monad. The rest of the program can work with whatever you > > like best. > > And in what way is this incompatible with either FRP as pierre > suggested, or with generating an infinite list of times at which we > call the function, and scanning it to find the differences? > Argh. I should not have copypasted that GLUT code, as it introduces IORefs not because they're 100% necessary but because that code is called back from C. My main point is that his task, if it is as simple as he described it, will stay imperative. My point also depends on that code being part of a main driver loop, as you see it in games: It's just the thing I instantly recognised in his code. Consider this: update :: MyState -> Int -> MyState draw :: MyState -> IO () mainLoop :: MyState -> Int -> IO () mainLoop st old = do now <- getTimeOfDay let td = now - old st' = update st td draw st' mainLoop st' now This, to my understanding of things, is imperative, although there's no IORef to be found. OTOH, recursing like this is "the FP way" to do it. mainLoop's arguments are variables to my eyes. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
Since Haskell-Café often strays into mathematics, this may not be too far off topic. On 17 Jun 2008, at 2:29 pm, Evan Laforge wrote: Yeah, on reflection, I think my "intuition" derives from me asking a math teacher back in high school "isn't n/0 infinity?" after looking at a graph, to which he said "no, it's undefined, you can only say it approaches infinity in the limit, but it isn't infinity". Let's put this kindly: it is POSSIBLE that your maths teacher knew what he was talking about and was just telling what the "Science of Discworld" authors call "lies-to-children". It is certainly likely that it didn't occur to him that you might transfer what he said about the mathematical real numbers to a rather different algebraic system, IEEE floats. The usual "real numbers" R form an ordered field. *In that structure*, n/0 is undefined. But there is another algebraic structure which includes all the real numbers plus one more: infinity. It's call the real projective line. See http://en.wikipedia.org/wiki/Real_projective_line In that structure, n/0 is perfectly well defined, and is indeed infinity. That structure has all the properties you really need to do calculus, but isn't a field and isn't ordered. However, whenever an operation on elements of R is defined, the analogous operation on the corresponding elements of \hat R is defined and has the corresponding value. Basically, you can define operations any way you want as long as you are willing to live with the consequences. For example, it turns out to be possible to define an alternative arithmetic in which (-x)*(-y) = -(x*y) for positive x, y. The price is that it doesn't satisfy all the usual axioms, though it does satisfy other possibly useful ones that the usual systems don't. In an analogous way, the IEEE designers decided that it would be useful to have +/- epsilon instead of 0 and +/- (1/epsilon) instead of infinity, but then decided that the ordering operations should identify -epsilon with +epsilon, so the result still isn't quite a proper total order, even ignoring NaNs. (What happens if you sort a list of mixed +0.0 and -0.0? What, if anything, _should_ happen?) They obtained the benefits they wanted, at the price of making the resulting structure less like R. But then, floating point numbers never were _very_ much like R to start with. It's not clear to me that *R offers anything more than a heuristic analogy to IEEE arithmetic. For one thing, *R is ordered. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
答复: [Haskell-cafe] Re: How to do this in FP way?
Yes, that's it, State.
Thanks.
-邮件原件-
发件人: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 代表 Achim Schneider
发送时间: 2008年6月16日 12:01
收件人: haskell-cafe@haskell.org
主题: [Haskell-cafe] Re: How to do this in FP way?
"Magicloud Magiclouds" <[EMAIL PROTECTED]> wrote:
> static int old;
> int diff (int now) { /* this would be called once a second */
> int ret = now - old;
> old = now;
> return ret;
> }
>
You do it with variables, of course. This is out of some GLUT code,
using IORef's:
idle :: State -> IdleCallback
idle state = do
t0 <- get $ t state
t1 <- get elapsedTime
t state $= t1
let td = fromIntegral t1 - fromIntegral t0
fps state $= 1/td * 1000
angle' state $~! (+2)
(bpx, bpy) <- get $ ballPos state
(bvx, bvy) <- get $ ballVel state
ballPos state $= (bpx + bvx*td, bpy + bvy*td)
postRedisplay Nothing
One half of all Haskell coders will tell you that mutable state isn't a
good starting point to learn Haskell, the other half will tell you the
same because they want to be cool kids, too.
--
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited.
___
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
答复: [Haskell-cafe] Re: How to do this in FP way?
I think if I do not use a state, and the function would be called for many
times, it would waste memory, if using something like loop, right?
-邮件原件-
发件人: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 代表 Achim Schneider
发送时间: 2008年6月16日 12:01
收件人: haskell-cafe@haskell.org
主题: [Haskell-cafe] Re: How to do this in FP way?
"Magicloud Magiclouds" <[EMAIL PROTECTED]> wrote:
> static int old;
> int diff (int now) { /* this would be called once a second */
> int ret = now - old;
> old = now;
> return ret;
> }
>
You do it with variables, of course. This is out of some GLUT code,
using IORef's:
idle :: State -> IdleCallback
idle state = do
t0 <- get $ t state
t1 <- get elapsedTime
t state $= t1
let td = fromIntegral t1 - fromIntegral t0
fps state $= 1/td * 1000
angle' state $~! (+2)
(bpx, bpy) <- get $ ballPos state
(bvx, bvy) <- get $ ballVel state
ballPos state $= (bpx + bvx*td, bpy + bvy*td)
postRedisplay Nothing
One half of all Haskell coders will tell you that mutable state isn't a
good starting point to learn Haskell, the other half will tell you the
same because they want to be cool kids, too.
--
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited.
___
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] Re: How to do this in FP way?
"Magicloud" <[EMAIL PROTECTED]> wrote:
> I think if I do not use a state, and the function would be called for
> many times, it would waste memory, if using something like loop,
> right?
>
nope, at least not in general.
update :: MyState -> Int -> MyState
draw :: MyState -> IO ()
mainLoop :: MyState -> Int -> IO ()
mainLoop st old = do
now <- getTimeOfDay
let td = now - old
st' = update st td
draw st'
mainLoop st' now
runs in constant space. Look up "tail recursion" in wikipedia.
> -邮件原件-
> 发件人: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] 代表 Achim Schneider
> 发送时间: 2008年6月16日 12:01
> 收件人: haskell-cafe@haskell.org
> 主题: [Haskell-cafe] Re: How to do this in FP way?
>
> "Magicloud Magiclouds" <[EMAIL PROTECTED]> wrote:
>
> > static int old;
> > int diff (int now) { /* this would be called once a second */
> > int ret = now - old;
> > old = now;
> > return ret;
> > }
> >
> You do it with variables, of course. This is out of some GLUT code,
> using IORef's:
>
> idle :: State -> IdleCallback
> idle state = do
> t0 <- get $ t state
> t1 <- get elapsedTime
> t state $= t1
> let td = fromIntegral t1 - fromIntegral t0
> fps state $= 1/td * 1000
>
> angle' state $~! (+2)
>
> (bpx, bpy) <- get $ ballPos state
> (bvx, bvy) <- get $ ballVel state
>
> ballPos state $= (bpx + bvx*td, bpy + bvy*td)
> postRedisplay Nothing
>
> One half of all Haskell coders will tell you that mutable state isn't
> a good starting point to learn Haskell, the other half will tell you
> the same because they want to be cool kids, too.
>
--
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
答复: [Haskell-cafe] Re: How to do this in FP way?
But if there are some beautiful arithmetics that do not use something like
state, I won't say no to them.
-邮件原件-
发件人: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 代表 Achim Schneider
发送时间: 2008年6月16日 12:01
收件人: haskell-cafe@haskell.org
主题: [Haskell-cafe] Re: How to do this in FP way?
"Magicloud Magiclouds" <[EMAIL PROTECTED]> wrote:
> static int old;
> int diff (int now) { /* this would be called once a second */
> int ret = now - old;
> old = now;
> return ret;
> }
>
You do it with variables, of course. This is out of some GLUT code,
using IORef's:
idle :: State -> IdleCallback
idle state = do
t0 <- get $ t state
t1 <- get elapsedTime
t state $= t1
let td = fromIntegral t1 - fromIntegral t0
fps state $= 1/td * 1000
angle' state $~! (+2)
(bpx, bpy) <- get $ ballPos state
(bvx, bvy) <- get $ ballVel state
ballPos state $= (bpx + bvx*td, bpy + bvy*td)
postRedisplay Nothing
One half of all Haskell coders will tell you that mutable state isn't a
good starting point to learn Haskell, the other half will tell you the
same because they want to be cool kids, too.
--
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited.
___
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
答复: [Haskell-cafe] How to do this in FP wa y?
OK. Here it is.
I want to make a monitor tool for linux. It runs for a long time, and give
out a certain process's io stat per second. The way I get io stat is to read
from /proc/pid/io. But the data in this file is a total, I need to read it
first, then next second, read it again, and shows the difference, and go on.
So, what is your idea?
-邮件原件-
发件人: David Roundy [mailto:[EMAIL PROTECTED]
发送时间: 2008年6月17日 1:17
收件人: Magicloud Magiclouds
抄送: haskell-cafe@haskell.org
主题: Re: [Haskell-cafe] How to do this in FP way?
2008/6/15 Magicloud Magiclouds <[EMAIL PROTECTED]>:
> Hello,
> I am getting familiar with FP now, and I have a "program design" kind
of
> question.
> Say I have something like this in C:
> static int old;
> int diff (int now) { /* this would be called once a second */
> int ret = now - old;
> old = now;
> return ret;
> }
> Because there is no "variable" in Haskell. So how to do this in a FP
> way?
A better question would be to think about what you are trying to
accomplish, and then ask how to achieve that through functional
programming.
David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Topkata
> In the mean time -- who knows enough to make ghc target ARM, and get > this to link against the iPhone libraries? This would be quite a coup > if it could be made to run there! For that matter, there's another ARM-based target in which I'm interested: Nintendo DS. Has anyone got any Haskell code to run on one of these? PS: Maybe this discussion should be moved to a new "Haskell on ARM" thread? -- Ariel J. Birnbaum ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1/0
On Mon, 16 Jun 2008, Dan Doel wrote: On Monday 16 June 2008, Evan Laforge wrote: (huge negative number) Ok, so integral types don't have that exceptional value. Shouldn't trying to convert NaN or Infinity to an Integral throw something? Is it a performance thing? I'd think if you're converting to Integer you don't really need hardware level performance anyway, so a couple of checks wouldn't kill anyone. This is a (known by some) bug of sorts in the various floating point -> integral transformations (which ultimately boil down to decodeFloat or something like that at some point). It apparently doesn't know about the various exceptional values in the IEEE representation, so it just treats the representation like any other value. Infinity and NaN look like various huge numbers if you interpret them like any other value, so that's what you get out of round/ceiling/floor/etc. It's not ideal, but I guess no one's bothered to fix it. Might be something to bring up on the libraries mailing list. This could be combined with improving performance: http://hackage.haskell.org/trac/ghc/ticket/2281 http://hackage.haskell.org/trac/ghc/ticket/2271 http://hackage.haskell.org/trac/ghc/ticket/1434 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Design suggestion for Data.Binary.Defer
Hi, Derek: Yes, I was slowly coming round to the idea of the third option. It does mean that if you want to change the deferredness of a field, you have to change the type, which is a substantial alteration. David: > Is there any reason not to just write all lazy fields of variable size > in a deferred manner? I completely hadn't though of this! You will loose a bit of time, for example reading fields which were previously not deferred will require a file seek, but the effort/thought/efficiency trade-off is good. I think I will go with this. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
