Re: [Haskell-cafe] Re: Where do I put the seq?
Peter Verswyvelen wrote: Not at all, use it for whatever you want to :-) I'm writing this code because I'm preparing to write a bunch of tutorials on FRP, and I first wanted to start with simple console based FRP, e.g. making a little text adventure game, where the input/choices of the user might be parsed ala parsec, using monadic style, applicative style, and arrows, and then doing the same with FRP frameworks like This is a really bad place to start a FRP tutorial IMO. The interface for 'interact' does not make any promises about the relative evaluation order of the input list / production order of the output list. That's why you are having to play horrible tricks with seq to try to force the order to be what you want. I don't think this is the basis of a robust system or a sensible tutorial. Just my 2c. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
John D. Ramsdell wrote: On Wed, Aug 19, 2009 at 8:32 AM, Jules Beanju...@jellybean.co.uk wrote: Do not blame haskell, blame emacs, if emacs is so stupid. How can you blame emacs? Do you expect emacs to read programmer's minds? No, I expect emacs to select a suitable first indentation guess and give the programmer a natural way to choose alternative ones. I don't think the initial haskell-mode implementation had that property. I don't find layout a problem, with good editor support. I agree it's a problem, with poor editor support. That's all I meant. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
John D. Ramsdell wrote: On Thu, Aug 20, 2009 at 9:08 AM, Jules Beanju...@jellybean.co.uk wrote: I don't find layout a problem, with good editor support. I agree it's a problem, with poor editor support. That's all I meant. Let's put this issue in perspective. For those few Haskell programmers that do find layout irritating, I'm sure we would all agree it's but a minor irritation. The real downside of layout is if non-Haskell programmers use it as an excuse to dismiss the language. I happen to think that Data Parallel Haskell has great potential for use in high performance computations. I'd hate to see a bunch of Fortraners not try DPH because of Haskell syntax. Well that's a reasonable point. They can still use the non-layout form if it bothers them that much? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unifcation and matching in Abelian groups
John D. Ramsdell wrote: On Wed, Aug 19, 2009 at 6:16 AM, Neil Mitchellndmitch...@gmail.com wrote: Why not: if done then return () else do prob - getLine test prob main I've given up on using if-then-else in do expressions. They confuse emacs. There is a proposal for Haskell' to fix the problem, but until then, I will not use them in do expressions. Do not blame haskell, blame emacs, if emacs is so stupid. Fortunately there is a better emacs mode which understands layout and if: http://kuribas.hcoop.net/haskell-indentation.el I'm so glad new languages do not use the offset rule. I get tired typing tab in emacs, especially since for most other languages, emacs does so well at picking a good indent. Requiring coders to spend so much time choosing indents reminds me of the days when I wrote C code with vi. I've been there, done that, and moved on to emacs. Do not blame haskell, blame emacs. The layout rule is simple to understand and I think it makes attractive code. It's not haskell's fault that the emacs mode chooses a bad indent so often. There is a better emacs mode which gets the indentation right more often, I find ;) http://kuribas.hcoop.net/haskell-indentation.el Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
Peter Verswyvelen wrote: I kind of agree with the DDC authors here; in Haskell as soon as a function has a side effect, and you want to pass that function to a pure higher order function, you're stuck, you need to pick the monadic version of the higher order function, if it exists. I just want to point out that you could *always* use the monadic version. That is, mapM subsumes map. Just use the Identity monad if you don't have anything really monadic going on. The reason we don't is that that looks + feels ugly. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: TypeDirectedNameResolution
Cale Gibbard wrote: What do people think of this idea? Personally, it really annoys me whenever I'm forced to give explicit module qualifications, and I think this would really help. It would also subsume the DisambiguateRecordFields extension rather handily. A disadvantage - and this is not a No vote, just a remark - is that when trying to debug the expression: foo bar baz quux if I type :t bar I will presumably get an ambiguity error, and I may have no easy way of working out *which* bar was actually intended in this line of code. I don't know how much of a burden this is, but it feels like a burden to writing/debugging/understanding code. Jules ___ 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?
Job Vranish wrote: I was needing a way to zip generic data structures together today and was very annoyed to find that there is no Zippable class, or variant there of. Notice that you can always do this if the LHS is traversable and the RHS is Foldable (as a special case the RHS is the same as the LHS, since all foldables are traversable) : http://www.haskell.org/haskellwiki/Foldable_and_Traversable#Generalising_zipWith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monoid wants a (++) equivalent
Ross Paterson wrote: On Wed, Jul 01, 2009 at 10:55:39AM -0700, Bryan O'Sullivan wrote: Okay, here's a tentative plan that will help to figure out the answer. I'll build a fiddled base package that rewires the Monoid class to have (++) be the binary operator, and mappend as a synonym for it. I'll import the Monoid (++) into the Prelude. I'll see how much breaks. If that much builds smoothly, I'll see how much of the rest of Hackage builds, both with and without this custom base package. I'll follow up here with the results, along with a suggestion of how acceptable I think the observed level of breakage is. Generalizing (++) will break some Haskell 98 code, e.g. append = (++) I think that's a show-stopper. I agree it's an issue; and it's the reason I didn't even suggest it myself, favouring a new symbol. I don't think it's a show stopper, in principle. In principle you can imagine a -h98 flag which you pass to compilers which choose a strictly h98-compliant prelude as opposed to a slightly generalised newer one. I'm not the person who would have to maintain that arrangement. I guess that's a call for the people who would have to do the work. There is already a haskell98 package, I think, which is the first step? Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monoid wants a (++) equivalent
Duncan Coutts wrote: I agree, if we can't use ++ then is the next best thing. As John says it's already a monoid operator for Data.Sequence and Text.PrettyPrint. I agree, if we can't use + and + then is the next best thing. ;) Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Magnus Therning wrote: Also from experience, I get a good feeling about software that compiles without warnings. It suggests the author cares and is indicative of some level of quality. In contrast, I find almost all the GHC warnings to be useless, and therefore turn them off. I don't find they have a significant correlation with code quality. YMMV :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coding standard question
Miguel Mitrofanov wrote: I so don't want to be the one supporting your code... Well, that's lucky. Because you aren't. However, that's an easy arrow to fling. I say I don't find warnings useful so you suggest my code is unmaintainable. Is that based on any knowledge of my code, or the GHC warnings? I've been using GHC for years and my honest opinion is that the warnings very rarely flag an actual maintainability problem in the code I write, and very frequently annoying highlight something I knew I was doing, and did quite deliberately - most often inexhaustive patterns or shadowing. Maybe there are mistakes which you can make which the warnings usefully highlight, and maybe I just never make that kind of mistake. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Logo
Ashley Yakeley wrote: I rather like the fact that the Haskell Platform logo is distinct from the Haskell logo. I think it helps prevent confusion (even though the Platform logo is based on one of the Haskell logo competition entrants). http://haskell.org/haskellwiki/Haskell_Platform Well, I disagree. Even though I do not like the new haskell logo, I prefer consistency. I like the black/gold version proposed. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: vacuum-cairo: a cairo frontend tovacuum for live Haskell data visualization
Peter Verswyvelen wrote: Something like this? http://en.wikipedia.org/wiki/Force-based_algorithms Yes, I'm all for it :-) The only problem is finding time to do it :-( Although QuickSilver might be able to pull this off easily? A basic version is easy, yes. http://roobarb.jellybean.co.uk/~jules/forces.1.tgz It makes no attempt to analyze when stable state is reached, has no way to add heuristics, has no output or save format, or indeed input format. I haven't hacked it into vacuum because I don't have GHC 6.10 installed. All that being said, it's a quick proof of concept, it comes with some fun examples including most of the platonic solids and a couple of chemical modules. It may be a starting point for someone wanting to do something cleverer. Compile with -threaded. It bundles my simple Reactive implementation which separates the framerate from the simulation speed and lets you rotate / zoom in/out. obligatory screenshot: http://roobarb.jellybean.co.uk/~jules/Picture%2012.png Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
Achim Schneider wrote: Don Stewart d...@galois.com wrote: This means that 'cabal install' works out of the box on every system, without needing admin/root privs (esp. important for students). ...and people who were bitten by sanity and thus never, ever touch /usr manually, only through their distribution's package manager. This is good advice (/usr/local is fine though). However, the point here is surely that the de-facto default for all other downloaded programs - standard makefile setups, automake, autoconf, perl package, python packages, graphic installers like firefox - is do to what cabal calls a 'global' install by default. This makes cabal's inversion of default a violation of least surprise, however easy it may be to justify that user installs are better. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
Richard O'Keefe wrote: However, the point here is surely that the de-facto default for all other downloaded programs - standard makefile setups, automake, autoconf, perl package, python packages, graphic installers like firefox - is do to what cabal calls a 'global' install by default. The assumption here seems to be that everyone owns their own machine or has a system adminstrator with large amounts of free time on their hands. Just because a lot of other people are doing something crazy doesn't mean we have to copy them. No. It's not an assumption, it's a default. No one is assuming anything. Both options are available. The point I was making, which is scarcely important enough to bother explaining again, is that having the same *default* as other software is a virtue. In point of fact, I'm sure that a larger proportion of haskell users have their own machine than don't. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Looking for the fastest Haskell primes
Eugene Kirpichov wrote: The parameterless version is a top-level definition and won't get garbage-collected, IIRC. This has not-much to do with CAFs and is really just about scope + values + liveness. live values (those which a program still refers to, e.g. from a function which might get called in the future) don't get GCed. CAFs are just in the top-most scope and particularly likely to get held live in this fashion. As Lennart points out, optimisations occasionally increase sharing, although GHC tries fairly hard not to do this. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ambiguous reified dictionaries
Simon Peyton-Jones wrote: Yes, Haskell says that in any program there should be only one instance for any particular type (here Monoid Int). GHC doesn't check that, but it should really do so. It's not necessary for soundness (ie no runtime crash) but it is necessary for coherence (ie when you run the program the answer you get doesn't depend on which dictionary the typechecker arbitrarily chose). Unless of course, your program implicitly depends on the coherence of dictionary choice for its own soundness, for example, a program using Data.Typeable to implement Dynamic or similar. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
Cristiano Paris wrote: On Tue, Apr 14, 2009 at 5:09 PM, Luke Palmer lrpal...@gmail.com wrote: ... Please don't say that. He's a beginner. You realize that the path of least resistance will be to use it, right? You see why that's not a good thing? Even experts don't use this function. (To the O.P.: don't use it) Mmmh, sorry Luke but I don't understand this ostracism. unsafePerformIO is not evil by itself, it's there for a purpose and, as for anything else in the language, it's better to understand when to use it and when not rather than just knowing that is something that MUST not be used, without any further explanation. Sure, the explanation is there if people are interested in it. However, in context, your answer was wrong. It is like someone asking: How do I get hold of a new phone and the answer Pull a gun on someone walking down the street and demand they give you their phone ...that is, the answer was solving the wrong problem, or solving it in the wrong context. If you have IO [XmlTree], then you don't have an [XmlTree] at all - rather you have a description of an (IO-involving) action which you need to run to get one. You can run it many times, or once, or never. It will (in general) give different results depending exactly when you run it. Therefore you need to carefully decide when to run it - i.e. attach it indirectly or directly into your main action, as the various other answers have shown. unsafePerformIO is not part of the haskell language - it does not respect the type system. It is an extension mechanism which allows us to add hooks into the RTS; effectively a way to extend the language. This is a useful and powerful thing, but nothing in the questioner's question suggested that language extension was what they wanted. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Buster 0.99.1, a library for application orchestration that is not FRP
Jeff Heard wrote:
It is parametrically polymorphic in a. And no, it's an arbitrary
decision, BUT... it allows me and other users to define generally
useful behaviours and widgets to package with the library using the
basic types without locking down 'a'. The EventData type looks like
this:
data Event a { ..., edata :: EData a, ... }
data EData a = EChar Char
| EString String
| EStringL [String]
| EByteString ByteString
| EByteStringL [ByteString]
| EInt Int
| EIntL [Int]
| EDouble Double
| EDoubleL [Double]
| EBool Bool
| EBoolL [Bool]
| EOther a
| EOtherL [a]
Maybe I wasn't clear, and probably I'm being dense. I understand what
you've done - I looked at the type declarations before commenting - but
I don't understand why.
Why is it useful to be able to use basic types without locking down 'a'?
Why is it useful to have a value of type Event FooBar which, in
apparent defiance of the FooBar parameter, actually contains a value of
type Double?
Jules
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Buster 0.99.1, a library for application orchestration that is not FRP
Jeff Heard wrote: A last but somewhat minor thing is that the Event type is fairly general, allowing for multiple data to be attached to a single event and this data to be of many of the standard types (Int, String, Double, ByteString, etc) as well as a user-defined type. Of course, such an event type could be defined for other FRP frameworks as well. That sounds the opposite of general. That sounds specific. (Int, String, Double, ByteString as well as a user-defined type). Can you explain the reason for the EDouble, EString (etc.) alternatives as opposed to making the event simply (parametrically) polymorphic in a ? Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Use unsafePerformIO to catch Exception?
wren ng thornton wrote: The type of head should not be [a] - a + Error, it should be (a:[a]) - a. With the latter type the compiler can ensure the precondition will be proved before calling head, thus eliminating erroneous calls. Yes, but you know and I know that's not haskell. I'm talking about haskell. In haskell - a language which does not fully support dependent types - head is both necessary and useful. It's a static error, detectable statically, and yet it's deferred to the runtime. I'd much rather the compiler catch my errors than needing to create an extensive debugging suite and running it after compilation. It is not detectable statically. It is only detectable statically for a class for programs. Admittedly, for that class of programs, ndm's fine tool Catch is a very clever thing. Is this not the promise of purity? No. Purity and partiality are orthogonal. Nobody promised pure languages would be total. Functions like uncons and viewL are nicer (because they're safe), but they can have overhead because they're unnecessarily complete (e.g. the Maybe wrapper can be avoided if we know a-priori that Just will be the constructor used). uncons and viewL are totally irrelevant. They're just a convenient syntax around case matching. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Use unsafePerformIO to catch Exception?
wren ng thornton wrote: I have long been disappointed by a number of `error`s which shouldn't be. For example, the fact that `head` and `div` are not total strikes me as a (solvable) weakness of type checking, rather than things that should occur as programmer errors/exceptions at runtime. The use of `error` in these cases muddies the waters and leads to a laissez-faire attitude about when it's acceptable to throw one's hands up in despair and use `error` rather than writing a better function. head uses error in precisely the correct, intended fashion. head has a precondition (only call on non-empty lists) and the error is just there to give you some hint that you made a mistake - got the precondition wrong. It's certainly not intended to be catchable. And that is a correct use of error. There are programming styles which avoid using 'head'. You are free to use those if you don't like it. I myself am content to use 'head' on lists which I know are guaranteed to be non-empty. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hugs on iPhone
Rick R wrote: The agreement doesn't specifically prohibit the use of interpreters (just those than run external code). It also doesn't say anything about machine generated code. The only thing one would have to ensure is that the dependencies of JHC are all compiled in, or statically linked. Shared libs are disallowed in any app. If it has a runtime dependency on gcc (is there such a thing?) Then you would have to statically link it and therefore couldn't sell your application. (gotta love GPL) Not true. GPL doesn't forbid selling and never has. RMS used to make money selling emacs tapes. All it requires is that you accompany your sale either with a copy of the source code, or a promise to make source available. Posting the source on a public web site would meet this requirement. Does anything in the iPhone SDK forbid you from posting your source? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Does anybody dislike implicit params as much as I do?
Thomas Hartman wrote: http://blog.patch-tag.com/2009/03/09/implicitparams-are-evil-thoughts-on-adapting-gitit/ I understand there are arguments for using IPs, but after this experience, the ImplicitParams extension is a code smell for me. It's not just you. Implicit parameters are a scourge on the language. I think there are also some subtle annoyances with how they make apparently 'safe' program rearrangements unsafe, by pushing around let ?foo = bar in ... bindings. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle and Network.Socket
Thomas DuBuisson wrote: 2) Detect the OS (when possible - perhaps difficult for the web/JS interface) and display the functions specific to the platform requesting the search. That kind of magic would really annoy me. I might browse on one of several platforms, and I don't expect a search engine to give me different results just because I happen to launch the web browser on a different computer. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Logos of Other Languages
Ashley Yakeley wrote: All of these get one thing right that the current and most of the proposed Haskell logos do not: they don't make any reference to the syntax of the language itself. Doing so seems to miss the point of a logo: it's supposed to appeal visually, rather than semantically. So I'd like to see some submissions that don't use lambdas. [The following is my opinion, I don't intend to suggest it as objective fact] The first duty of a logo is to be memorable and distinctive, and work at a variety of sizes and colours (including black and white). The second duty is to be attractive. The third duty is to actually convey some kind of message about the thing the logo pertains to. The more famous you are as a brand, the more you can neglect the third point (you don't need to educate, people know what you are). So I agree with Ashley insofar as, there is no *need* for the logo to incorporate a lambda or a or suchlike devices. On the other hand, I think it's not necessarily a bad thing either, as long as it works with (1) and (2) above. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Associated data types
Lennart Augustsson wrote: For an associated data type D, we know that the type function D is injective, i.e., for different indicies given to D we'll get different data types. This makes much more powerful reasoning possible in the type checker. If associated data types are removed there has to be some new mechanism to declare an associated type as injective, or the type system will lose power. Interesting. Are you able to give an example which exploits this known distinct types effect? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to define Show [MyType] ?
Dmitri O.Kondratiev wrote: I am trying to define instance Show[MyType] so show (x:xs :: MyType) would return a single string where substrings corresponding to list elements will be separated by \n. This would allow pretty printing of MyType list in several lines instead of one, as default Show does for lists. You're doing it wrong. Show is not for pretty-printing. Show is for the production of haskell syntax for debugging and copy-pasting into test cases, as well as for use with 'Read'. If you want to pretty print, use a different function name. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers
John Meacham wrote: I never was opposed to a cabal 'target' for jhc. I have 'make dist' 'make dist-rpm' and hopefully 'make msi' soon, adding a 'make dist-hackage' alongside is not a bad thing, however, it is if it complicates the standard build or comes to dominate development effort or can't be done without duplication of functionality. My understanding is that you can have a .cabal file which merely specifies the dependency information and metadata, but delegates all the actual building to your existing configure and make infrastructure. It could then be entirely ignored (by someone who chose to type ./configure make) but it would still work for someone who wanted to use cabal (using the metadata to get any dependencies, and then thereafter using the make-based build). Is this not a good path for a project like JHC? Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers
John Meacham wrote: I never was opposed to a cabal 'target' for jhc. I have 'make dist' 'make dist-rpm' and hopefully 'make msi' soon, adding a 'make dist-hackage' alongside is not a bad thing, however, it is if it complicates the standard build or comes to dominate development effort or can't be done without duplication of functionality. My understanding is that you can have a .cabal file which merely specifies the dependency information and metadata, but delegates all the actual building to your existing configure and make infrastructure. It could then be entirely ignored (by someone who chose to type ./configure make) but it would still work for someone who wanted to use cabal (using the metadata to get any dependencies, and then thereafter using the make-based build). Is this not a good path for a project like JHC? Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Real World Haskell, now shipping
Andrew Coppin wrote: What I *haven't* done yet is read the chapters where they try to claim that database programming is possible in Haskell. I'll have to do that at some point. Maybe this is where they reveal the Secret Formula that makes this stuff actually work properly... but somehow I doubt it. What a ridiculous comment. Are you hoping to provoke people into helping you by sounding more stupid than you are? Database programming is obviously possible in haskell. Many many people are doing it. The documentation may be patchy, the libraries may be hard to install (often the case with free software for databases, for some reason) but that's quite a long way from impossible. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Suggestion: Syntactic sugar for Maps!
Don Stewart wrote:
bulat.ziganshin:
Hello circ,
Thursday, November 27, 2008, 9:59:08 PM, you wrote:
So why not {hello: 1, there: 2} ?
mymap hello:1 there:2
where mymap implementation is left to the reader :)
I can't see the context of the beginning of this thread, but I've always
found:
fromList [(hello,1),(there,2)]
to be a relatively simple syntax, and still checked at compile time.
Anonymous sum + product types plus lists are a pretty good approximation
for lots of concrete syntax, and they're type checks.
(Anonymous sum, Either, is slightly more syntactically heavy than you'd
like, though...)
Jules
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monads with take-out options
Greg Meredith wrote: Haskellians, Some monads come with take-out options, e.g. * List * Set In the sense that if unit : A - List A is given by unit a = [a], then taking the head of a list can be used to retrieve values from inside the monad. Some monads do not come with take-out options, IO being a notorious example. Some monads, like Maybe, sit on the fence about take-out. They'll provide it when it's available. To amplify other people's comments: List A is just as on the fence as Maybe. [] plays the role of Nothing. Some monads require that you put something in, before you take anything out [r - a, s - (a,s), known to their friends as reader and state] Error is similar to Maybe, but with a more informative Nothing. Most monads provide some kind of runM :: ## - m a - ## a where the ## are meta-syntax, indicating that you might need to pass something in, and you might get something slightly 'funny' out. Something based upon 'a' but not entirely 'a'. The taxonomy of monads is pretty much expressed in the types of these 'run' functions, I think. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
Andrew Birkett wrote: Hi, Is a formal proof that the Haskell language is referentially transparent? Many people state haskell is RT without backing up that claim. I know that, in practice, I can't write any counter-examples but that's a bit handy-wavy. Is there a formal proof that, for all possible haskell programs, we can replace coreferent expressions without changing the meaning of a program? The (well, a natural approach to a) formal proof would be to give a formal semantics for haskell. Referential transparency would be an obvious property of the semantics. Soundness would show that it carried over to the language. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Malcolm Wallace wrote: Jules Bean [EMAIL PROTECTED] wrote: GHC's scheduler lacks any hard timeliness guarantees. This is probably not a fundamental problem with haskell. It's a problem with the compiler/RTS which we happen to be using. Actually, I would say it is much worse than that. It is not merely a question of implementation. We do not have _any_ predictable theory of resource usage (time, memory) for a lazy language. There is no analysis (yet) which can look at an arbitrary piece of Haskell code and tell you how long it will take to execute, or how much heap/stack it will eat. What is more, it is very hard to do that in a modular way. The execution time of lazy code is entirely dependent on its usage/demand context. So you can't just apply WCET to single functions, then combine the results. That's true but I'm not sure you need to solve that (hard, interesting) problem just to get *some* kind of timeliness guarantees. For example the guarantee that a thread is woken up within 10us of the MVar it was sleeping on being filled doesn't require you to solve the whole problem. It requires you to be able to bound GC time, or preempt the GC, but that's feasible isn't it? Then there is the possibility of a strict DSL (probably but not necessarily a Monad) within haskell which has strong timeliness guarantees. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Dave Tapley wrote: Hi everyone So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) GHC's scheduler lacks any hard timeliness guarantees. Thus it's quite hard to use haskell in realtime or even soft-realtime environments. This is probably not a fundamental problem with haskell. It's a problem with the compiler/RTS which we happen to be using. It may be true that it's harder to write an RTS with realtime guarantees but I doubt it's impossible. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Monad.Reader with updates
Mauricio wrote:
Is there some abstraction in current ghc library
that implements something like Reader, but where
the value of the environment is updated at every
step?
do-it-yourself? you can start from reader definition and add what you
need. you just need to make initial state consisting from state
itself and update function so `run` will have just one initialization
argument
Sure. I've done a few versions, trying to change
the way (=) is defined, and learned a lot with
that. But I wanted to know if there's already the
right way to do it instead of my newbie way to
do it :)
It doesn't quite make sense, because one step isn't well defined.
How many steps is return (f x) ? how about return x = \y -
return (f y) ?
Because the monad laws guarantee those two things should be the same,
and yet the first is zero steps and the second is one step, going by the
crude counting =s method I'm guess you were thinking of.
So I think you'd have to make the steps explicit.
You could do this with a custom version of () and (=) which
automatically do a step, for example.
So
advance :: m () -- your primitive which changes the environment
a * b = a advance b
a *= f = do { r - a; advance; f r }
Does that help?
Jules
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Monad.Reader with updates
Mauricio wrote: The problem is that I need 'a' or 'b' above to sometimes also change the environment. I think with this method I could not get that. I no longer understand what you want. I thought you wanted an environment which automatically changed every step. I showed you how you can do that, although it requires making explicit what a step is, which you could do with custom combinators. Now you want any part of the action to change the environment? In this case, use the state monad, not the reader monad. That is what it's for. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why 'round' does not just round numbers ?
This behaviour is not what I expect after reading the description at http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:round . Given that this behaviour has caused a bit of confusion I think a change to the documention might be in order. The authority here is the report which says round x returns the nearest integer to x, the even integer if x is equidistant between two integers. However I agree the haddock ought to mirror the report. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell newbie indentation query.
Svein Ove Aas wrote: On Wed, Oct 15, 2008 at 5:25 PM, Jules Bean [EMAIL PROTECTED] wrote: There is a new indentation module which does much better at the indentation stuff: http://kuribas.hcoop.net/haskell-indentation.el I didn't realize until I tried to use yours that there are two indentation modules in haskell-mode, and I'd been using the inferior one. This one isn't mine. It was written by the IRC nick 'kuribas'. His real name is in the elisp. This does mean I can't tell what changes you have made, though. If it's not too much trouble, could you summarize your changes? Basically it has a more accurate haskell parser, and it has a simpler way of cycling through possible indentations: TAB moves to the right and BACKSPACE to the left. Also, is this code going to make it into haskell-mode proper, or are there issues preventing that? If the latter, I wouldn't mind having a darcs repository to pull from. Good question. I don't know. I don't know if haskell-mode is actively maintained. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell newbie indentation query.
Simon Michael wrote: Does that help? It helps me a lot. I never clearly understood that there are these two different layout modes in my code (coddled by haskell-mode!) This will cut down some more guesswork. Thanks! There is a new indentation module which does much better at the indentation stuff: http://kuribas.hcoop.net/haskell-indentation.el Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.
John Van Enk wrote: Could you, perhaps, outline a little more of what you're trying to do? I'm having a hard time seeing what exactly you're doing, and why you can't use the package provided by your distribution. We'd love to help you, but you're not being very clear with what your problem is. As far as I can see, his problem was cabal update cabal upgrade which seems like a sensible command to run, but actually isn't. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell newbie indentation query.
Ramaswamy, Vivek wrote:
Hello All~
I have just started with Haskell, and I must confess; I am in love with it.
However one area that I am really confused about is indentation.
Lets take a look at if-else if- else block.
Important point 1.
There are two contexts in haskell programs. Layout and non-layout.
In a non-layout context you can do whatever you like with indentation.
You can put the newlines wherever you want.
In practice, almost everyone uses layout for the 'top-level' of a
module. That means that anything flush to the left margin starts a new
declaration. However, making sure we are not flush to the left margin,
the following are all fine
x = if True then 1 else 2
x = if True
then 1
else 2
x =
if True
then 1
else 2
x =
if True
then 1
else 2
because, layout is not relevant in expressions.
Now, do blocks are layout blocks. So what you really want us to look
at is the use of if/then/else in do blocks.
x =
do
if True
then (return 1)
else (return 2)
The first line in the do block defines the left margin for this block.
In this example, the first line is the if line, that defines the left
margin. Since the then and the else are also both on the left
margin, they are new statements. So, the layout interprets as:
do {if True; then (return 1); else (return 2)}
...which is a parse error, because a statement cannot begin with 'then'
or 'else'.
any pattern of indentation which keeps the if expression indented
further to the right will be OK, such as
x =
do
if True
then (return 1)
else (return 2)
x =
do
if True
then (return 1)
else (return 2)
..are both fine.
Does that help?
Jules
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linking and unsafePerformIO
Mauricio wrote: Hi, If I have a Haskell wrapper (with unsafe...) over a function that's never going to return different values and is always side-effect free, but can change depending on compile time options of its library; my program is running, and then the version of my library is updated by my distribution smart instalation system, which does update versions of libraries in use; is it possible that I get a wrong behavior of my program? I do not understand enough about package management to understand how running programs or libraries are updated, and less about how linking works between Haskelll and libraries on other languages, so I don't know if my program is guaranteed to stay with a single version of a library for each run. (Sure this is a weird situation, but I do like to think about worst cases.) In practice that is fine, with current RTSes and so on. In principle it's not fine. A 'constant' should be constant over all time, not just constant over a particular library version or sub-version or a particular program invocation or OS or Who knows, maybe some future haskell runtime will be able to perform the trickery you describe and will cause this to break ;) Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linking and unsafePerformIO
David Roundy wrote: On Tue, Oct 14, 2008 at 04:05:23PM +0100, Jules Bean wrote: David Roundy wrote: Constants are mathematical and universal, like pi. That is what the semantics of haskell say. Where do the semantics of haskell say this? You should better ask 'which semantics?'. The semantics in which a value of type Int - Int is denoted by a mathematical function from Int to Int. In that semantics a value of type Int denotes a specific Int. And that denotation is, of course, entirely independent of compiler or OS or package or dynamic loading or any concern like that. This is, to my mind the often assumed but never written down semantics of haskell. It's certainly the semantics *I* want haskell to have. How does it interact with fixing bugs (which means changing mathematical and universal constant functions--since all functions are constants)? That's fine. Changing a program changes it denotation. Running a program on a different interpreter or compiler had better not change its denotation, otherwise it [the denotation] is not much use as a basis for reasoning. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linking and unsafePerformIO
David Roundy wrote: (Sure this is a weird situation, but I do like to think about worst cases.) In practice that is fine, with current RTSes and so on. In principle it's not fine. A 'constant' should be constant over all time, not just constant over a particular library version or sub-version or a particular program invocation or OS or No, constants don't have to constant over all time. e.g. it's perfectly fine for compilers to implement System.Info, whose sole purpose to provide constants that are different in different library versions and OSs. http://haskell.org/ghc/docs/latest/html/libraries/base/System-Info.html#v:os I entirely disagree. That API is broken. All those things should be in the IO monad. I might have code which migrates at runtime between different OSes. Of course i can't, and even if I did, it would probably return something different like 'virtual haskell migration pseudo-OS', but that's not the point. Constants are mathematical and universal, like pi. That is what the semantics of haskell say. However, I don't claim this is terribly important. Or even a very interesting debate ;) Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linking and unsafePerformIO
David Roundy wrote: On Tue, Oct 14, 2008 at 05:20:35PM +0100, Jules Bean wrote: Running a program on a different interpreter or compiler had better not change its denotation, otherwise it [the denotation] is not much use as a basis for reasoning. But you're saying above that we can't change programs, right? You probably won't be surprised to hear that different compilers are different programs. And different packages are also different programs. Are you the only one who's allowed to fix bugs? No. I think we must be at cross purposes. I'm saying that we can change programs, and that changes their denotation, and that's fine, and anyone can do that. But the denotation of a program is supposed to be something independent of a particular compiler or OS or MAC address or RAM size or any of the millions of other things which probably don't change during the single run of a program. Putting these things into the IO monad is not an abuse of the IO monad. It is simply an acknowledgement that they are runtime things, and not denotational constructs. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] synchronous channels in STM
roger peppe wrote: By the way, where does FRP (which I haven't got my head around yet) sit with respect to STM? Entirely orthogonal. FRP is not generally thought of as (explicitly) threaded at all. It's more declarative than that. It's also supposed to be deterministic (up to the determinism of input events) which STM is not. However an elegant, efficient, implementation of FRP in pure haskell evades us, so people discuss different ways to implement it which use, possibly, concurrency such as STM or otherwise, under the hood. So STM may or may not be a good tool to implement FRP, but at the level that you *use* FRP, any threading should be entirely implicit. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class Quantification
Bas van Dijk wrote:
On Wed, Oct 1, 2008 at 3:01 AM, Reiner Pope [EMAIL PROTECTED] wrote:
I believe there is no way to simply express this abstraction over classes,
but the Scrap your boilerplate with class[1] paper discusses this same
problem and present a workaround by defining the class's dictionary of
methods as an explicit type.
What follows is the code to implement their workaround for your example.
First some fairly standard extensions:
{-# LANGUAGE Rank2Types, EmptyDataDecls, FlexibleInstances, KindSignatures
#-}
And some more controversial, but necessary ones:
{-# LANGUAGE UndecidableInstances, OverlappingInstances #-}
Just an observation:
That terrifying list of extensions is needed for this 'full' solution.
To just literally encode what the OP wanted you just need a concrete
dictionary and existentials, AFAIK.
Jules
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] if - then - else layout
leledumbo wrote:
consider this partial program:
if n5 then
putStrLn big
else
putStrLn small
this works fine in hugs, but in ghc I must change it to:
if n5
then
putStrLn big
else
putStrLn small
Actually both of those are valid expressions.
And they both work in hugs and ghc.
The question I imagine you're asking involves layout mode:
do
if n5 then
putStrLn big
else
putStrLn small
this is shorthand for
do { if n 5 then putStrLn big ; else putStrLn small }
which is a syntax error. A statement in a do block cannot begin with the
keyword else.
If you indent the else a bit further than it counts and a continuation
of the enclosing expression (beginning with if) so it desugars to
do { if n 5 then putStrLn big else putStrLn small }
which is fine.
Haskell' is apparently going to include a hack to permit this case. I
think that's a poor decision, because including a hack to the layout
rule makes it harder to understand and explain the layout rule.
Jules
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Climbing up the shootout...
Bulat Ziganshin wrote: and this work obviously doesn't speed up every Haskell program. so that we have in Haskell world now is heroic efforts to speed up shootout test which doesn't say anything about real Haskell performance. what we have on prcatice is 10-20% speedup of ghc 6.8 and several libs which may improve speed in some usages If you understand performance as well as you claim to - and from your previous postings, I believe you *do* understand performance well - then you will know that 10-20% speedup is almost entirely meaningless in isolation. Any given particular program has a bottleneck; this bottleneck may be different depending on the OS/hardware configuration, although normally it won't be. Improvements which touch that bottleneck can have staggering benefits in the 40-500% range; improvements which are elsewhere have tiny 5% or non-measurale effects. In fact, various improvements made to GHC in the 6.4-6.10 timeline have had enormous, order-of-magnitude improvements to particular code patterns which had particular bottlenecks. Meanwhile they may well have had no effect at all on other code patterns which had different bottlenecks. You may ask, what are the common code patterns? What are the common bottlenecks? I'm not aware of good studies to answer these questions although they probably exist; I don't read widely the research in this area. [Naive C programs tend to IO bottleneck or Memory bottleneck; I strongly suspect naive haskell programs tend to GC bottleneck; but I don't think either of these observations is particularly profound or useful] What matters to a particular programmer of course it not actually common patterns and common bottlenecks. It is the bottleneck in his particular program. However: The Shootout is a *game*. It even says that in its name. It's a game which many of us enjoy playing; if you don't enjoy, please feel free not to play. Many of us find that, by playing the game, we learn a lot of interesting things about the low-level performance of GHC in interesting edge-cases. The quad-core machine recently added to the benchmark has enabled us to learn interesting things about `par` and Control.Parallel. Learning these things, and sharing them, may help us write better programs, help us teach other people to write better programs, and help the GHC team write a better compiler. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] piping to system call
Marc Weber wrote: On Tue, Sep 23, 2008 at 01:37:56PM +0200, Janis Voigtlaender wrote: Hi, assume I have a program taking input from stdin. How do I call it from Haskell while feeding to it a string as input. Sure, have a look at http://hackage.haskell.org/packages/archive/process/1.0.0.0/doc/html/System-Process.html#v:runInteractiveProcess rnuInteractiveCommand does would you want (in,out,err,pId) - runInteractiveProcess cat ... hPutStrLn test in hClose in outContents - hGetContents out print outContents Beware. The above code is broken. Whether it appears to work depends on your OS, buffering settings, and the size of any underlying buffers. The simplest safe way to do this is to fork a separate thread for one side or the other of the handle. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] piping to system call
Janis Voigtlaender wrote: Jules Bean wrote: Marc Weber wrote: On Tue, Sep 23, 2008 at 01:37:56PM +0200, Janis Voigtlaender wrote: Hi, assume I have a program taking input from stdin. How do I call it from Haskell while feeding to it a string as input. Sure, have a look at http://hackage.haskell.org/packages/archive/process/1.0.0.0/doc/html/System-Process.html#v:runInteractiveProcess rnuInteractiveCommand does would you want (in,out,err,pId) - runInteractiveProcess cat ... hPutStrLn test in hClose in outContents - hGetContents out print outContents Beware. The above code is broken. Whether it appears to work depends on your OS, buffering settings, and the size of any underlying buffers. Thanks for the warning. I needed it only for a small scripting task, and it seems to work well enough. Actually, I am not even interested in the output, so I just went for waitForProcess. This comes with additional warnings in the docs, but I did not experience any problems in my concrete setting so far. If you don't care about the output, it's fine if you send the output to /dev/null. The deadlock is when you try to read the output and send the input from the same thread. However if the output is to out and you never read it then that *will* deadlock, but probably only when some OS buffer gets full (e.g. after 8k of output) Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Float instance of 'read'
Mauricio wrote: Do you think 'read' (actually, 'readsPrec'?) could be made to also read the international convention (ie., read 1,5 would also work besides read 1.5)? I'm happy to finaly use a language where I can use words of my language to name variables, so I wonder if we could also make that step. The purpose of 'read' is to read haskell notation, not to read locally-sensitive notation. So the right question to ask is should we change haskell's lexical syntax to support locally-sensitive number notation. IMO, the answer is no. (1,3) would start to mean (13/10) and we'd need another notational rule (whitespace around commas) for numeric tuples. Feels like a painful special case to me. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] system in forkIO
Andrea Rossato wrote: On Sun, Sep 14, 2008 at 02:24:23PM -0300, Marco Túlio Gontijo e Silva wrote: and the result of ls only after I press a key. Does getChar blocks the other threads? yes, but you can use forkOS from Control.Concurrent and compile with -threaded. See the relevant documentation for the details. forkOS not relevant here. -threaded is necessary to allow haskell code to run whilst FFI calls are blocked. getChar doesn't count as an FFI call (the RTS does its own IO multiplexing) but system does. forkOS is to do with bound threads, that's something else. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] STM and FFI
Arnar Birgisson wrote: On Tue, Sep 9, 2008 at 11:36, Jules Bean [EMAIL PROTECTED] wrote: ...not only must it be safe to be called with invalid inputs, but it most not have any long-term effects, whether the input is valid or invalid, since I do not believe that there is any way for the function to 'undo' its effect at 'retry' time. Maybe this is an idea for an extension to the STM system, adding something like unsafeIOToSTM, except that in addition to the main IO action, it also takes two more IO actions that are invoked on rollback and commit, respectively. This might allow for integration with transactional systems (e.g. a remote transaction on an rdbms), although to support two-phased commit we'd need a third action for the prepare step. That would be an absolutely killer feature. A common problem in large systems is that the underlying RDBMS supports transactionality, but then the software layer has to handle its own rollbacks. I've seen some nasty bugs when the DB rolled back and the software didn't. If we could have a transactional RDBMS linked into STM with matching semantics, that would be a very nice thing. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] STM and FFI
Ryan Ingram wrote: If the function isn't pure, you need to do a lot more proofs to assure that this is safe. In particular, the function must be able to be called with invalid input. If you are confident that this is the case, you can use unsafeIOToSTM to convert a call to that function into an STM primitive. ...not only must it be safe to be called with invalid inputs, but it most not have any long-term effects, whether the input is valid or invalid, since I do not believe that there is any way for the function to 'undo' its effect at 'retry' time. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [haskell-cafe] Monad and kinds
Jake Mcarthur wrote: On Sep 4, 2008, at 9:52 PM, Tim Chevalier wrote: I'm no master, but I've never encountered a situation where strictness annotations would be useful as documentation, nor can I imagine one. I'm no master either, but how about these simple examples? data Stream a = Cons !a (Stream a) data Vector3 a = Vector3 !a !a !a The compiler will certainly be able to infer the strictness itself in most uses, so obviously the purpose for these annotations is not for optimization, but I still would find these annotations useful. As far as I am aware this statement is false. I do not believe the compiler infers strictness in common uses of either of these cases, and I have seen space blowups / stack blowups because of it. I use the rule of thumb : simple 'scalar' field components should be strict. Scalar is an ill-defined term but typically means non-recursive data types, like Int and Bool. The most natural exception to this rule is the 'memoizing constructor' idiom. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional references
You should package this up and put it on hackage. It is nice, but there is already another FRef package on hackage (Data.Accessor) and I have a home-grown one of my own, which uses different notation / combinators to either the hackage one or Tim's. There are also fragments of FRef-like things in some of the big libraries like OpenGL and GTK. I think it would be worth spending some time (on this mailing list, perhaps, or in another forum) trying to hash out a decent API which meets most people's requirements, rather than ending up with 4 or 5 slightly different ones. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure hashtable library
Jason Dusek wrote: Jules Bean [EMAIL PROTECTED] wrote: Jason Dusek wrote: I would much rather have a pure Trie that is foldable. If we have a Trie, we get a space efficient sorted list, too. Well, Data.Sequence can be used as a space efficient sorted list which is Foldable - if you make the decision to insert elements into it in a sorted way, obviously. What advantages would a Trie have over Data.Sequence? A trie is guaranteed sorted -- so using a trie amounts to a type level guarantee for binary search and any other algorithm that relies on sortedness. ...No more so than a simple wrapper over a Data.Sequence which puts the elements in the right place. Insert for Data.Sequence is log(i) where i is the position of the insertion; clearly bounded by log(n). toList is O(n) and index is (at worst) log(i). I think the corresponding operations with tries are log(n), so asymptotically tries are identical for 'uniformly distributed' keys although fingertrees are faster if there is a bias towards elements near the ends of the lists. So, it's all in the constants, isn't it? Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure hashtable library
Bulat Ziganshin wrote: Hello haskell-cafe, solving one more task that uses English dictionary, i've thought: why we don't yet have pure hashtable library? There is imperative hashtables, pretty complex as they need to rebuild entire table as it grows. There is also simple assoc lists and tree/trie implementations, but there is no simple non-modifiable hashes. how should it look: * hashtable is represented as an array of assoc lists: Array Int [(a,b)] * interface to extract data from ht is the same as from assoc list: lookup :: HT a b - a - Maybe b * ht may be built from assoc list. we should just know it's size beforehand in order to create Array of reasonable size. constructor also need a hashing function: create :: [(a,b)] - Int - (a-Int) - HT a b given these constraints, it should be just a 10-20 lines of code, and provide much better efficiency than any tree/trie implementations Prove it. To get much better efficient than a trie, the hash function has to be so fast that it is faster than following (log n) pointers, and yet also so perfect that it doesn't generate too many collisions. As you correctly say, a simple implementation is easy to do, so why not do it and see how it performs? :) Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure hashtable library
Bulat Ziganshin wrote: Hello Jules, Wednesday, August 27, 2008, 7:21:46 PM, you wrote: given these constraints, it should be just a 10-20 lines of code, and provide much better efficiency than any tree/trie implementations Prove it. To get much better efficient than a trie, the hash function has to be so fast that it is faster than following (log n) pointers afaiu, trie search follows n pointers No. n is the number of strings in my data set (dictionary). If I have n strings the average string length is asymptotically, in some sense, log n. Of course for particular data sets it's may be more . But log n is the length of the shortest unique coding, it's also the number of characters you typically need to traverse before you have reached a unique prefix, at which point your trie can short-circuit. I appreciate that I didn't define my terminology ;) You might have a different n. I repeat my challenge Prove it. I will be interested to see how much a good immutable hash outperforms Data.Map. I would then also be interested to see how much it outperforms a decent Data.Map (such as your own AVL one) and a decent trie. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure hashtable library
Jason Dusek wrote: I would much rather have a pure Trie that is foldable. If we have a Trie, we get a space efficient sorted list, too. Well, Data.Sequence can be used as a space efficient sorted list which is Foldable - if you make the decision to insert elements into it in a sorted way, obviously. It's a fingertree not a trie, of course. What advantages would a Trie have over Data.Sequence? Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Phantoms
Malcolm Wallace wrote:
Andrew Coppin [EMAIL PROTECTED] wrote:
instnace Show (Foo Int) ...
instnace Show (Foo Double) ...
...WHY did I not think of this myself? o_O
Because it is not Haskell'98?
It requires {-# LANGUAGE OverlappingInstances #-}
No it doesn't?
It requires the much more semantically simple -XFlexibleInstances, as
far as I know.
Overlapping would only be needed if there was also a polymorphic
instance on Foo a?
Jules
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Phantoms
Henning Thielemann wrote: instance on Foo a? Btw. was anything bad about the suggested Haskell98 solution? You called it 'non-hacky'; I would call it 'slightly hacky' since, IMO, it qualifies as a hack around a deficiency in the class system. However, I don't think there is anything wrong with it. After all it's the same trick the Prelude uses for instance Show [Char]. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GLfloat on a Mac
Conor McBride wrote: This sounds like bad news to me. I wonder how broken this G5 ghc is for a G4. Perhaps it should be labelled G5 rather than PowerPC in the large print. I'm quite scared about trying to build ghc: I worry that it may involve confronting large areas of my ignorance. I'm running Mac OS X 10.4.11 on a 1.5GHz PowerPC G4 PowerBook with 768MB of memory. I've got gcc 4.0.0. I'm using the 6.8.3 build whose entry on this page FWIW, I use ghc on my G4 and I got it by compiling from MacPorts. It took the best part of day, but the resulting binary works. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GLfloat on a Mac
Conor McBride wrote: After a very long time, it fell over with a large error message that I don't understand. Somehow, I'll get over it. I can't help thinking that this stuff shouldn't be hard. And yet it is. Sorry to anyone for whom this is just spam, and much gratitude to clued in people who can tell me in which particular way I'm being an idiot at the moment. It used to be easier. I don't know why it isn't any more. This trac bug seems relevant http://hackage.haskell.org/trac/ghc/ticket/2262 There is a workaround suggested there. I don't know why this happens for you and not for the port uploader. There are many things I fail to understand about building on OSX :( Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the Haskell with pattern?
Johan Tibell wrote: 2008/8/6 Galchin, Vasili [EMAIL PROTECTED]: Hello, 1) Is there a common assumed semantics across all of the Haskell with things? withString? withData? You probably knew this already but there's nothing in the with idiom that prevents the resource to escape. And, it doesn't always matter. Some withs are more unsafe that others :) if the 'with' constructs a nice ordinary heap allocated haskell structure from the external resource then it may not matter one jot if it escapes: it may be out-of-date, perhaps, but still a useful data value. On the other hand sometimes it does matter Oleg recently wrote about (lightweight) monadic regions and how they can statically assure that this doesn't happen. Which is clever. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] uvector and the stream interface
Don Stewart wrote: sk: currently i'm working on stuff that looks something like this: 1 read soundfile from disk in blocks of N samples (IOCArray, hsndfile package) 2 convert to CArray with unsafeFreeze (simple O(1) cast, carray package) 3 perform FFT (CArray, fftw package) 4 convert to UArr (uvector package) 5 do some stuff with vectors [snip] It would be helpful to see the programs people are writing with uvector, so I can polish up the API some more :) It would also be helpful to have someone explain why we have: Ptr a ByteString IOUArray IOCArray Data.Storable.StorableArray UArr Of course, I know the answers to some of those questions, ByteString is obviously less polymorphic than all the others there, and Ptr a doesn't contain size information. But it seems we have a rapidly bifurcating profusion of 'typed interfaces to chunks of memory' with no obvious consistency to their naming scheme and I think it's starting to get confusing... Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting feature
fero wrote: Hi I have read in one tutorial (I can't find it again, but it was probably either one on ibm, gentle introduction or yaht), that it is possible to define relationships between free variables and the same program can be used to calculate either first variable when second is set or second when first is set. I have understood this as if I set first free variable, run program and write name of second variable and I get result, and vice versa. I don't know if I understood it well. It looks really interesting but I can't figure out how to do it. Is this really possible? (I doubt.) If yes show example please. See also metafont, which defines equational relationships between variables and solves. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] http://www.haskell.org/ghc/reportabug
Galchin, Vasili wrote: Jules, Currently guest/guest doesn't work. Works For Me (tm) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] http://www.haskell.org/ghc/reportabug
Galchin, Vasili wrote: TICKET_CREATE privileges are required to perform this operation I read some of the Trac documentation but didn't see what privilege I am missing. ?? Registered user or not? If you have a trac user, log in at the trac home page and then revisit reportabug. If you do not, login as guest/guest. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: HDBC converting a date sql value to UTCTime
George Moschovitis wrote: Alternatively is there a way to create a UTCTime value from an epoch integer (no of seconds since epoch). I can't find a suitable constructor with Hoogle. http://www.haskell.org/ghc/docs/latest/html/libraries/time/Data-Time-Clock-POSIX.html posixSecondsToUTCTime probably in combination with fromIntegral Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lambda and closures in PHP -- could someone please comment?
Derek Elkins wrote:
Lambda abstractions should close over bindings. Full stop.
Interesting. I agree with your analysis. I don't think I agree with your
conclusion.
The first surprising behaviour is the correct one. The latter would
be broken.
In my opinion, the reason this behaviour is surprising isn't
mutability, but -implicit- mutability. Let's make bindings immutable,
but add ML-style references to your example.
char ref c = ref(undefined);
while(!eof(fp)) {
c := getChar(fp);
bind_event( ... print !c; ... );
}
compare this to
while(!eof(fp)) {
char c = getChar(fp);
bind_event( ... print c; ...);
}
or
while(!eof(fp)) {
char ref c = ref(getChar(fp));
bind_event( ... print !c; ...);
}
Each of these examples makes it clearer what is going on.
Agreed.
I think where I differ on you is how to map the semantics of a C-like
language to explicit references.
I would argue that the glyph c in a C-like language denotes the value
of C, not the reference to it. C-like languages have, for the most part,
value semantics, and call-by-value.
The exception of course is what C-like languages called lvalues, but
lvalues are only really on the left of the = sign and a few other
special positions. I think that's the exception and not the rule. I
think the rule is that c denotes the value of c, and that's why I
expect a closure to capture the value, not the reference.
In C, of course, if you want to capture the reference you do it
explicitly with c.
Jules
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Wrapping FTGL in FFI calls
Jefferson Heard wrote: Oh, and I should say the function I want to implement is getFontBBox :: Font - String - IO [Float] I do know how to marhsal/unmarshal the String. Just not the CFloat array to Haskell [Float] import Foreign.C import Foreign.Ptr import Foreign.Marshal.Array import Control.Applicative(($)) oneway :: Ptr CFloat - IO [Float] oneway p = map real2Frac $ peekArray 4 p the other way you would probably want withArray, but I think this is the way you need? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Wrapping FTGL in FFI calls
Sorry, it's realToFrac. Typo! Jefferson Heard wrote: Exactly. thanks! On Fri, Jun 20, 2008 at 4:26 PM, Jules Bean [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Jefferson Heard wrote: Oh, and I should say the function I want to implement is getFontBBox :: Font - String - IO [Float] I do know how to marhsal/unmarshal the String. Just not the CFloat array to Haskell [Float] import Foreign.C import Foreign.Ptr import Foreign.Marshal.Array import Control.Applicative(($)) oneway :: Ptr CFloat - IO [Float] oneway p = map real2Frac $ peekArray 4 p the other way you would probably want withArray, but I think this is the way you need? -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards ___ 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] Lambda and closures in PHP -- could someone please comment?
Richard A. O'Keefe wrote: - what you get is a reference to a variable (as you do in Scheme) but loop variables really are variables, not names for values, so lambdas created in different iterations of the same loop point so the same loop variable, and do not remember the value it had when they were created. The proposal explains how to work around this. This one trips everyone up in Javascript. I think I'm of the opinion that variable capture from lambda formation should always be by value. However you can certainly make an argument that that's inconsistent in a language which generally has mutation/reference semantics. Whichever choice you make, though, document it loudly I predict it will be a source of confusion. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lambda and closures in PHP -- could someone please comment?
Richard A. O'Keefe wrote:
The mutablity of r here really isn't a problem. Nor is the mutability
of variables _as such_ really the problem in the PHP proposal.
The problem is that it's the *same* variable every time. If PHP
loops introduced new bindings on every iteration, this particular
problem would not exist.
Well, arguably it's not only the loop variable that can be susceptible
to this problem. There could be other variables in the loop body which
change each time through (e.g. while loops). Consider this pseudo-code
(sorry, my PHP is a bit rusty, this syntax is C really)
char c;
while (!eof(fp)) {
c = getChar(fp);
bind_event(... some lambda expression referencing c ...);
}
It's pretty surprising to the programmer if all that family of lambda
expressions reference the *variable* c (and hence, in practice, its
final value) rather than the *value* c.
Well, maybe that doesn't surprise everyone. It surprised me the first
time I used closures in Javascript and judging by a few google searches
I wasn't alone in that.
Jules
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lambda and closures in PHP -- could someone please comment?
PR Stanley wrote: With respect, do you not think it'd be wiser for the community [snip] *disgusted* This is exactly the sort of message that haskell-cafe does not normally contain. Let's not start now. This is a civilized mailing list. Either comment on the nice gentlemen's PHP closure proposal from a language point of view, or don't say anything. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] blas bindings, why are they so much slower the C?
Anatoly Yakovenko wrote:
#include cblas.h
#include stdlib.h
int main() {
int size = 1024;
int ii = 0;
double* v1 = malloc(sizeof(double) * (size));
double* v2 = malloc(sizeof(double) * (size));
for(ii = 0; ii size*size; ++ii) {
double _dd = cblas_ddot(0, v1, size, v2, size);
}
free(v1);
free(v2);
}
Your C compiler sees that you're not using the result of cblas_ddot,
so it doesn't even bother to call it. That loop never gets run. All
your program does at runtime is call malloc and free twice, which is
very fast :-)
C doesn't work like that :).
C compilers can do what they like ;)
GCC in particular is pretty good at removing dead code, including entire
loops. However it shouldn't eliminate the call to cblas_ddot unless it
thinks cblas_ddot has no side effects at all, which would be surprising
unless it's inlined somehow.
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. 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] 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
Re: [Haskell-cafe] Re: [Haskell] ANN: random-access-list-0.1
Whether fail should be in Monad, or whether we really want MonadZero,
MonadPlus, MonadError, or something else entirely has been open for
discussion, but it is easily shown
that Maybe is not the most general abstraction - it loses information
wrt to (Either String), for instance:
Prelude let {f [] = fail empty; f [_] = fail singleton; f l =
Yes. But that's not what we're talking about.
We're talking about lookup and index which both have one and exactly one
failure mode : not found.
For these functions, Maybe a is both the most general and the most
precise type.
It is trivial to upgrade Maybe a by decorating it with an error should
you choose to do so:
maybe (throwError better error message here) return
which I sometimes define as 'withError' or similar.
d - M.lookup foo `withError` Variable foo not in symbol table
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
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. For Haskell', I would relly like to have good, generic classes/interfaces for this, so that a) code becomes readable (including import lists), and b) code can be written more generically, and c) it becomes easier to switch between e.g. different string types. Class abstraction is not zero cost. Abstract far enough that GHC can't see how to resolve dictionaries at compile time (insufficient inlining) and you will not only slow things down just because of the dictionary cost, you'll also break all those nice RULES and lose your fusion. As for import syntax / readability, whilst I'm familiar with the problems (most are mentioned in this thread) I'm not aware of any concrete proposal to improve the situation. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness leaks
Achim Schneider wrote: You don't come across space-leaks in strict programs often because data is usually allocated statically even if execution is non-strict. Piping /dev/zero into a program that just sleeps does leak space, though. It only leaks 8K or whatever size your system buffers pipes until it suspends the writer though... or do I misunderstand your analogy? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: How would you hack it?
Achim Schneider wrote: If you run one over obscure academic papers, you can even generate publishable results. I don't have a link ready, but there was a fun incident involving this. http://www.physics.nyu.edu/faculty/sokal/dawkins.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Laziness leaks
Ronald Guida wrote: [snip] By default, a lazy language will procrastinate. By default, a strict language will anticrastinate. Either way, I can waste resources by blindly accepting the default time management plan. Nice analysis. Would you like to put that (the whole thing, not just that last para) on the wiki? Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHCi panic
Andrew Coppin wrote: I don't suppose this will surprise anybody greatly, but... Apparently if you write a Haskell module that is 400 KB in size and defines a single CAF consisting of a 45,000-element [String], GHCi panics when attempting to load it interpretted, and hits a stack overflow attempting to load it compiled. qv http://hackage.haskell.org/trac/ghc/ticket/2002 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Tree.Zipper in the standard libraries
Krasimir Angelov wrote: The monads design is used in Data.Map i.e. lookup :: (Monad m, Ord k) = k - Map k a - m a which is widely considered a poor design decision and a wart on Data.Map. :-) Seriously, if you don't return a useful error message, then Maybe is as good as it gets, why not use it? (And there really is only one kind of error possible here, in each case) 'fail' only adds information in the case it has a useful error message (in which case I'd encourage MonadError m =) Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Newbie: State monad example questions
Dmitri O.Kondratiev wrote:
Thanks everybody for your help!
Oliver, you provided an excellent write-up on State monad without
going into 'scary' :) details, great work indeed!
Alas, in this case I need the details, and in particular the most scary
ones!
So let's start with fundamental and most intriguing (to me) things:
getAny :: (Random a) = State StdGen a
getAny = do g - get -- magically get the current StdGen
First line above declares a data type:
State StdGen a
which is constructed with the function:
State {runState :: (StdGen - (a, StdGen))}
Q1: Where in the example
(http://www.haskell.org/all_about_monads/examples/example15.hs) data of
this type *actually gets constructed* ?
Actually get constructed?
It gets constructed by = and return, both of which construct state
objects:
instance Monad (State s) where
return a = State $ \s - (a, s)
m = k = State $ \s - let
(a, s') = runState m s
in runState (k a) s'
How do = and return get called? Well you can see explicit calls to
return. The = is implicit in the way do-notation is desugared.
getAny = do g - get
let (x,g') = random g
put g'
return x
rewrites to
getAny = get = \g - ( let (x,g') = random g in (put g' return x) )
where I have added some not strictly necessary ()s and taken the liberty
of changing the confusing a - return x idiom to let a = x.
So the *actually gets constructed* part is that use of = .
HTH,
Jules
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Newbie: State monad example questions
Dmitri O.Kondratiev wrote: Jules, Stupid question, please bear with me: x :: Int -- x declared, but not constructed x = 1 -- x constructed s1 :: State StdGen a -- s1 declared, yes, but why s1 is *also already constructed* ? it's not. it's constructed when you do s1 = return 1 ... or ... s1 = get = put .. or some other more complex interaction, perhaps using do notation. It's the = or the return that construct the State, just as the '1' is enough to construct the Int. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance: MD5
Andrew Coppin wrote: So all that bravado about Haskell enabling higher-level optimisations to produce a result faster than C is actually complete nonesense? Nonsense? No. Something that actually exists? No. Haskell enables optimisations. Writing a SufficientlySmartCompiler ( http://c2.com/cgi/wiki?SufficientlySmartCompiler ) still requires work. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe a, The Rationale
PR Stanley wrote: Paul: What is the underlying rationale for the Maybe data type? It is the equivalent of a database field that can be NULL. Paul: shock, horror! the null value or the absence of any value denoted by null is not really in harmony with the relational model. Ketil should have said: It is the equivalent of the extremely common way of misusing NULL. It doesn't bring in all the unpleasant baggage of three valued logic, but simple indicates an exceptional value. This use of NULL, very common in practical databases, frowned on by DB designers who understand about relational theory and normalisation, is prevalent precisely because common SQL dialects really make it a pain to invent your own datatypes, so it's hard to add an exceptional value. Practical programming needs a particular exceptional value very often indeed, to model things like optional parameters. If common SQL dialects supported types like 'Maybe Int' natively, then NULL could be used much less. Jules PS Students of NULL and 3-valued logic will note that some of the problem therein can be studied in Haskell by comparing (==) and liftM2 (==) as functions on Maybe Bool, or () vs liftM2 () on Maybe Int. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Data.Dynamic over the wire
{-# LANGUAGE ScopedTypeVariables #-}
Data.Dynamic gives a passable impression of adding support for
dynamically typed code and runtime typing to GHC, without changing
the basic statically typed, all types known at runtime nature of the
language.
Note that Data.Dynamic relies upon two things: it relies upon a
concrete representation of types, given by TypeRep, and a primitive
which has to be provided by the compiler to actually implement
fromDynamic. (In GHC it uses unsafeCoerce# which is already
available, but you could imagine providing other primitives).
In principle TypeReps could be derived by hand, although if you do so
you can break everything by providing invalid instances. In practice
we'd rather the compiler did it for us and guaranteed safety.
You can do all sorts of things with Dynamic, but the general pattern
is that data which has some fixed, known type, can be passed through
a chunk of code which doesn't know its type (wrapped in Dynamic) and
then eventually consumed by another piece of code which *does* know
the type, and can unwrap it. The consuming code has to know the type
to unwrap it, although it can 'guess' various alternatives if it
wants, and thus type safety is preserved.
One thing which you can't obviously do is write Read or Show instances
for Dynamic. So can we pass Dynamic data over the wire? If not,
Dynamic is limited to the context of within a single program, and
can't be used over the network between cooperating programs, or in
file formats, etc.
You can try this:
import Data.Typeable
data SerialisedDynamic = SD TypeRep String deriving (Show)
freeze :: (Show a, Typeable a) = a - SerialisedDynamic
freeze x = SD (typeOf x) (show x)
thaw :: forall a . (Read a, Typeable a) = SerialisedDynamic - Maybe a
thaw (SD t s) = if typeOf (undefined :: a) == t then
Just (read s)
else Nothing
This is close, and works as far as it goes. It is a limited
reimplementation of Dynamic which uses show/read instead of
unsafeCoerce#. As such it is pure haskell (but relies on Typeable
instances).
You can't finish it off because you can't derive a 'Read' instance for
SD, because there is no read instance for TypeRep. Off-hand I can't
think of any reason why there can't be a Read instance for TypeRep,
but it would be a bit tricky with the current TypeRep because of the
way its implemented, I think. You need to take care about globally
qualified types and might want to use package names like ghc does in
its linking phase, but those are definitely surmountable problems.
Having said all that, I'm not sure how useful this really is. Most of
the time you could use this, you could equally just pass around the
String and 'read' it once you get to the place where you want to use
the value. Practical over-the-wire protocols necessarily have some
kind of tagging mechanism, and all this adds is a global tag table
for Typeable types via TypeRep.
Jules
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List concat
Andrew Coppin wrote: The function (++) :: [x] - [x] - [x] has O(n) complexity. If somebody were to invent some type that looks like [x] but actually uses some sort of tree rather than a linked list, you should be able to get O(1) concatenation. Has anybody ever implemented such a thing? See also Data.Sequence, which is not O(1) append, but it is O(log something), and also O(1) cons and snoc and has lots of other nice complexities including fast update of a single cell. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-Overlapping Patterns
PR Stanley wrote: Hi isZero :: Int - Bool isZero 0 = True isZero n | n /= 0 = False The order in which the above equations appear makes no difference to the application of isZero. Does the Haskell interpreter rewrite patterns into one single definition using some sort of switch or if construct? Something a bit like that. Why does an equation without a guard have to be placed after the more specific cases? It doesn't. You could write the above the other way around if you wished. To put it another way, why doesn't the interpreter identify the more specific cases and put them before the general ones. Because it general it's convenient to have overlapping cases, where the order matters, and be able to choose the order. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Figuring out if an algebraic type is enumerated through Data.Generics?
Alfonso Acosta wrote: It would certainly be difficult map any Haskell type to VHDL, so, by now we would be content to map enumerate algebraic types (i.e. algebraic types whose all data constructors have arity zero, e.g. data Colors = Green | Blue | Red) Wouldn't it be much simpler to use the standard deriveable classes Bounded and Enum, instead of an admittedly very clever trick using Data? Metaprogramming comes in many shapes and sizes, and even the humble deriving (Show,Enum,Bounded,Ord,Eq) gives you quite some leverage.. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Control.Exception.evaluate - 'correct definition' not so correct
apfelmus wrote: Bryan Donlan wrote: evaluate x = (return $! x) = return However, if = is strict on its first argument, then this definition is no better than (return $! x). According to the monad law f = return = f every (=) ought to be strict in its first argument, so it indeed seems that the implementation given in the documentation is wrong. But it is known that the monad laws only apply up to some weaker equivalence than 'seq-equivalence'. This has been discussed here countless times by people who understand it better than me. As I understand the summary the = sign in the monad laws mean represent identical actions, in terms of the effects produced and the result returned. A kind of observational-equivalence for monad execution, but weaker than direct equational equivalence in the presence of seq. (Some people view this as more of a bug in seq than in the monad laws) Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Monad m = Functor m
Hans Aberg wrote: Using 'hugs -98', I noticed it accepts: instance Monad m = Functor m where fmap f x = x = return.f Has this been considered (say) as a part of the upcoming Haskell Prime? This forbids any Functors which are not monads. Unless you allow overlapping instances (which of course would not be h98 any more!). Other solutions, such as class Functor m = Monad m are frequently discussed. I see no H' ticket for it, though. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
