[Haskell-cafe] Re: ANNOUNCE: GHC version 6.12.1
If you need an update of a package to make it build/run on GHC 6.12.1, or if you have modified someone else's package to do so, please feel free to use this wiki page to coordinate: http://haskell.org/haskellwiki/Patches_and_forks_for_GHC_6.12 I suggest that those who have patches to contribute add a link to their patches or forks from that page[*], *and* submit their patches to the package maintainer(s). That way, we can avoid duplication of effort, while not having to wait for package maintainers to get around to applying our patches. This may sound trivial, but it can be annoying waiting for a whole chain of packages to "catch up" before you can even build your own package. So you may end up fixing other people's packages - which can easily lead to substantial duplication of effort. [*] or you can email me links/patches and I'll add them for you ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why?
At Thu, 10 Dec 2009 12:07:32 +, Magnus Therning wrote: > As I understand it it all started with laziness. I don't know if > laziness is impossible without purity More or less. Haskell is a language where anything can be evaluated lazily by default. Unlike say Scheme, where if you want something to be evaluated lazily you have to be explicit about it, in Haskell it's the opposite - if you want something to be evaluated _strictly_ you have to be explicit about it. If you write an impure expression in Haskell (e.g. using unsafePerformIO) the side-effects of it might be executed once, twice, or never, depending on the Haskell implementation in use, the optimisation flags, or even other Haskell code in the system. And the side-effects might be executed at unpredictable times, in an unpredictable order, and only some of them might occur. Now, this might be fine for debugging purposes, where you want to see what is being done under the hood - but for most other side-effects, you really want them to occur in a more controllable way. Hence, to answer John's question, a lazy language _has_ to be pure (apart from the unsafe functions) because laziness (or, to be more technically correct, non-strict evaluation) is incompatible with good control of the side-effects arising from impure code. Both Clean and Haskell deal with side-effects by allowing the programmer to write imperative code in a pure way - in Haskell, by using monads or FRP, and in Clean by using world-passing and uniqueness types. Now, that answer probably suffices for a Haskell beginner. Of course eventually you realise time and space usage is a side-effect, and _that_ needs to be controlled as well... but despite this, I think my answer is basically right. However, that's not the _only_ reason why you might want purity. Even in a strict language, purity makes it easier to reason about code, because you don't have to consider the environment, only the parameters that are passed in. Of course, it gets more complicated with monads, because the Environment monad and the IO monad both give you implicit environments at the level of "running the monadic actions". But even then, it's supposed to be easier to reason about (once you get the hang of it), and I'd broadly agree with this. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Patches and forks for GHC 6.12
Some packages will need modifications to build or work with GHC 6.12 (in some cases, just modifications to the .cabal file). I've created this wiki page to track work people have done on that which hasn't yet been included into official packages or repositories: http://haskell.org/haskellwiki/Patches_and_forks_for_GHC_6.12 Please add any ones you know of (or just email me and I'll add them for you). -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Command-line options idea
This is not in any way specific to Haskell, but I know a number of packages on Hackage have executables with command-line options, so: The non-Haskell program get_iplayer has an excellent idea for command-line options parsing. Rather than having to remember two separate syntaxes, one for command line options and one for a preferences file, the user can simply type get_iplayer --prefs-add --OPTION[=VALUE] which will add the equivalent of --OPTION[=VALUE] to the get_iplayer preferences file (and do nothing else). So it's like a special "preferences file manipulation mode" of the program. There are also the following options, as described by --help: --prefs-clearRemove *ALL* saved user or preset options --prefs-del Remove specified saved user or preset options --prefs-show Show saved user or preset options (This also means that the user doesn't have to remember the filename of the preferences file.) I think this sort of thing would be a good idea for *any* program that has command-line options that some user might want to hold constant across several runs. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
At Thu, 15 Oct 2009 10:15:46 +0400, Eugene Kirpichov wrote: > but I don't know in what respect these two packages differ and why Don > decided to create 'judy' despite the existence of HsJudy. HsJudy doesn't compile against the latest judy library (as Don knew) - presumably he had a good reason to start a new package instead of patching the old one. There should be a way to mark packages as deprecated on hackage, and at the same time direct people to a more suitable alternative. Aside from uploading a dummy new version (ugh!), I don't see a way to do that currently. -- Robin ___ 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?)
On Wed, 12 Aug 2009 08:34:28 -0500 Derek Elkins wrote: > On Tue, Aug 11, 2009 at 3:51 PM, Robin Green > wrote: > > On Wed, 12 Aug 2009 11:37:02 +0200 > > Peter Verswyvelen wrote: > > > >> Yes, sorry. > >> > >> But I think I already found the answer to my own question. > >> > >> DDC functions that are lazy don't allow side effects: > >> http://www.haskell.org/haskellwiki/DDC/EvaluationOrder > >> > >> Anyway it would be cool if the DDC EffectSystem would also work on > >> lazy functions :) > > > > As was just pointed out in the unsafeDestructiveAssign thread from > > which this thread was forked, effects are incompatible with > > non-strict evaluation. > > No, they aren't. At least, they aren't in any technical way. There > have been more than a few languages supporting both laziness and > mutation starting with Algol. OK, explicitly creating thunks, like in Algol, LISP and CAL, can work, because you can either prevent the programmer from using mutation inside a thunk (as in the CAL approach), or rely on the programmer to ensure that mutations are only done in a safe order (as in the "callback as thunk" approach, which can be done in almost any impure language). But if almost *every* expression is a thunk, as in a non-strict language like Haskell, and if moreover evaluation order can differ depending on the compiler/interpreter, or compiler version, or compiler flags, it becomes impractical to combine them. So yes, I agree, it's not an absolute technical incompatibility, it's a practical one. > > Also, effects would destroy modular reasoning. > > Again, it is purity, not laziness, that allows compositional > reasoning. Effects destroy compositional reasoning in a strict > language just as much. Not really - in a strict language, if in method M action A always happens before action B, then that fact will remain true in whichever context M is called (ignoring threading issues). In a non-strict, impure language, assuming monads are not used, if you have a function f which performs actions A and B, and two other functions g and h which both call f, the actions could happen in one order in g, and in the opposite order - or not at all - in h, because of a difference in data demanded by each function. Indeed, unless g and h are "top-level" functions (in the sense that they are main functions or invoked from some ghci-equivalent) the notion of "the" order the actions are performed in is ill-defined, because it could vary depending on which function g or h is being called from. Now, you could say, the strict order of evaluation can be simulated in a non-strict language on a case-by-case basis by using monads or whatever. Well, yes, but that would be missing the point, because the original point of this discussion was to avoid having to use monads. -- Robin ___ 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?)
On Wed, 12 Aug 2009 11:37:02 +0200 Peter Verswyvelen wrote: > Yes, sorry. > > But I think I already found the answer to my own question. > > DDC functions that are lazy don't allow side effects: > http://www.haskell.org/haskellwiki/DDC/EvaluationOrder > > Anyway it would be cool if the DDC EffectSystem would also work on > lazy functions :) As was just pointed out in the unsafeDestructiveAssign thread from which this thread was forked, effects are incompatible with non-strict evaluation. The compiler is supposed to be able to reorder non-strict evaluation to do optimisations, but that can't be done if effects could happen. Also, effects would destroy modular reasoning. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
And even if you don't agree with that, it would likely lead to accidental use of GPL software in proprietary software, which is not a good thing. -- Robin On Wed, 5 Aug 2009 09:33:34 -0700 "John A. De Goes" wrote: > > Tom is exactly right here. GPL is the kiss of death in the > commercial world. Haskell Platform exists in part to encourage > industry use of Haskell -- and to encourage "braindead" use of > blessed libraries. GPL libraries have no place in HP. > > Regards, > > John A. De Goes > N-Brain, Inc. > The Evolution of Collaboration > > http://www.n-brain.net|877-376-2724 x 101 > > On Aug 5, 2009, at 9:03 AM, Tom Tobin wrote: > > > On Wed, Aug 5, 2009 at 10:46 AM, Colin Paul > > Adams wrote: > >>> "Tom" == Tom Tobin writes: > >> > >>>> This can surely be tackled by cabal, as it already has the > >>>> license information. > >> > >>Tom> I don't see this as a real solution; why would a package be > >> > >> It should be done anyway, irrespective of the platform. > > > > Yes, that would be handy option for cabal-install in general. > > > > > >>Tom> added to the platform in the first place if a large > >>Tom> proportion of developers couldn't make use of it? > >> > >> Anyone can make use of it. You may choose not to (or your boss may > >> choose for you), but that doesn't mean you can't. > > > > The benefit of a standard library is that you can say "I need a > > library to handle X" and if a library addressing X is in the > > standard library, you're set. If you then need to worry about the > > GPL — and this is a reality that can't be written off as a mere > > "choice" — why bother with the platform in the first place? > > Non-GPL developers would be better off sticking with hackage in > > that case. ___ > > 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 -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Wed, 5 Aug 2009 11:03:55 -0500 Tom Tobin wrote: > On Wed, Aug 5, 2009 at 10:46 AM, Colin Paul > Adams wrote: > >> "Tom" == Tom Tobin writes: > > > > >> This can surely be tackled by cabal, as it already has the > > >> license information. > > > > Tom> I don't see this as a real solution; why would a package be > > > > It should be done anyway, irrespective of the platform. > > Yes, that would be handy option for cabal-install in general. My feature request for this is here: http://hackage.haskell.org/trac/hackage/ticket/481 where you can read a reply by Duncan listing some problems with this idea. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: cautious-file 0.1.1: Ways to write a file cautiously, to avoid data loss
I've since uploaded two new versions with the following changes: 0.1.2: Fixed an issue where it would clobber symbolic links to files, which is usually not what you want. Test case added for this. 0.1.3: ByteString support! FFI is also now used under the hood to do things in a slightly less hacky way. -- Robin On Sun, 19 Jul 2009 23:35:34 +0100 Robin Green wrote: > I'm pleased to announce the first public release of cautious-file: > > http://hackage.haskell.org/package/cautious-file ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage and version control
On Mon, 20 Jul 2009 10:03:56 +0100 Magnus Therning wrote: > On Mon, Jul 20, 2009 at 9:26 AM, Vasili I. > Galchin wrote: > > Hello, > > > > It seems to me that Hackage doesn't provide version control, > > e.g. check out and check in. Am I incorrect? > > Hackage is, AFAIU, a repository where _released_ versions of > libraries/tools/etc related to Haskell can be kept. It is not fully > comparable to SourceForge, Github, or any other _source hosting_ > service. > > If you are looking for source hosting then take a look at SF, Github, > Google Code, or something like that. Then upload _released_ versions > to Hackage. IIRC there is also the possibility of having a Darcs repo > on community.haskell.org. Yes, and darcs repos can also be hosted on patch-tag.com. community.haskell.org requires you to wait for a volunteer to review every new project request. Although, you don't need to make a project request if you only want a 1-developer repository. And by the way, it only hosts Haskell-related projects, not arbitrary darcs repositories. patch-tag.com doesn't have those constraints. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FFI problem - possibility of CStringLen overflow?
While rewriting cautious-file to use ByteStrings and FFI just now, I came across this potential problem: Why does the FFI specification define CStringLen as (Ptr CChar, Int)? As the FFI specification itself notes, Haskell 98 implementors are allowed to have a quite small range for Int (only up to 2^29-1) - so you could in principle have a very large String which cannot be represented as a CStringLen, or a very large CString which cannot be represented as a CStringLen. They would take up wads of memory, so this has probably never happened yet, but it's in principle possible, no? If so, what are the implications of this for code correctness? -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: cautious-file 0.1.1: Ways to write a file cautiously, to avoid data loss
I'm pleased to announce the first public release of cautious-file: http://hackage.haskell.org/package/cautious-file This library currently provides a writeFile function that is intended to have three advantages over Prelude.writeFile: 1. There was a controversy a few months ago about the new Linux filesystem ext4, and how existing applications which write certain files naively might expose their users to the risk of data loss after a crash or power failure. (Actually, it turns out that this is not a new issue - certain other filesystems or filesystem mount options can cause similar issues, but few people made a fuss about it.) cautious-file uses the recommended way of writing a file on POSIX (more or less). On non-POSIX systems (i.e. Windows), it tries to do something sensible, but it may not be the best way to do it, and I've only ran the tests on Linux. 2. With almost any filesystem or operating system, saving a file by overwriting it exposes the user to the risk of data loss if there is a crash or power failure. cautious-file creates a temporary file first and only overwrites the file when it has finished writing (on POSIX systems with sane filesystems, at least). 3. Prelude.writeFile is supposed to lock files so that they at least cannot be written to simultaneously in multiple threads. This is good for safety, but might lead to avoidable problems with IO exceptions when one thread tries to open a file for writing which is still being written to by another thread. Again, the use of a randomly-named temporary file avoids this problem (not with certainty, but with a high probability, which is good enough for some applications). It does not prevent all file-related race conditions (nothing with its type signature could!), but if you are sure you don't care which thread wins, you should be able to use cautious-file's writeFile. A variant, writeFileWithBackup, also allows you to supply a custom backup computation to backup old copy(ies) of the destination file (which is not necessary with Prelude.writeFile, because you can just do it before you call Prelude.writeFile, but is necessary with cautious-file). cautious-file is obviously not appropriate for all circumstances - for instance, it's not needed for writing truly temporary files. But of course if it's close to what you need, you can adapt it (and send me a patch if you like). There is a test runner that can be run by running "runhaskell Setup.lhs test" or "cabal test" in a built copy of the source distribution. The tests do not actually verify that data loss doesn't happen if there's a crash! Indeed, attention should be drawn to the standard BSD license - despite the name "cautious-file", there is no warranty. If in doubt, I suggest you take a close look at the source code - it's very short. I'd appreciate comments, patches, pointers to Haskell code that does the same thing already, etc. Thanks, -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit concatenation in list comprehensions
I really like tuple sections and I've wanted them for years. I never use
comprehensions though, so I abstain from the other vote.
--
Robin
On Sun, 19 Jul 2009 08:18:48 -0700
Thomas Hartman wrote:
> I vote for tuple sections. Very nice!
>
> I don't really see immediate places where I would use the list
> comprehension improvement so I guess I don't vote for that.
>
> 2009/7/19 Neil Mitchell :
> > Hi Max,
> >
> >> For fun, I spent a few hours yesterday implement support for this
> >> syntax in GHC, originally propsed by Koen Claessen:
> >>
> > [k, "=", v, " " | (k, v) <- [("foo", "1"), ("bar", "2")]
> >> ["foo", "=", "1", " ", "bar", "=", "2", " "]
> >>
> >> This is a generalisation of list comprehensions that allows several
> >> items to be concatenated onto the result list at once, by having
> >> several comma-separated items before the pipe.
> >
> > I like the power this feature gives, and if it was already in
> > Haskell 98 I'd certainly have used it a few times. I can't think of
> > anything else the syntax could mean, so I don't see a potential for
> > it stealing syntax that might otherwise be reused. However, it
> > doesn't seem that discoverable or natural - I'm not sure I'd have
> > ever guessed that such a feature might exist.
> >
> >> P.S. I also implemented tuple sections
> >> (http://hackage.haskell.org/trac/ghc/ticket/3377#comment:3) which
> >> are a lot more useful:
> >
> > Yay! Discoverable, useful and really common in practice - a
> > brilliant extension :-)
> >
> > Thanks
> >
> > Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
On Fri, 10 Jul 2009 10:44:51 +0200 Wolfgang Jeltsch wrote: > PASCAL > uses “program”, not “programme”, The word program (as in computer program) is spelled program in both British and American English. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: New release of ZeroTH
This announcement will only be of interest to Haskell programmers using, or thinking of using, Template Haskell. I am very pleased to announce a new release (2009.6.23.3) of ZeroTH (also known as zeroth), a tool for preprocessing Haskell code to run splices and remove Template Haskell dependencies: http://hackage.haskell.org/package/zeroth For example, you could use it to reduce the size of your Haskell program binaries, if you use Template Haskell. (zeroth now actually uses itself on itself, for this very purpose, and you can use the Distribution.ZeroTH module for that in your own cabal projects.) It's still very much a hack - in that it would probably be more efficient and clean to implement it as an option to GHC - but hopefully now at least it's a slightly *better* hack. Lemmih has kindly agreed to hand over the job of being maintainer of ZeroTH to me. So please send any patches or complaints my way. The new darcs repository for the project, which is a darcs 2 repository, is at: http://patch-tag.com/publicrepos/zerothDarcs2 For this release, the "cabal" command-line tool is the only officially supported means of installation. So you should do something like: cabal update cabal install zeroth to install it. To get a summary of command-line options, type: zeroth --help Major changes from previous releases: * Much more Haskell code is now supported. This is partly because the code has been updated to work with the just-released haskell-src-exts 1.0.0; and partly because it supports a wider variety of Template Haskell code, including code which refers to definitions declared in the same source file. * It is now compulsory to specify any Haskell language extensions you are using in the input file, with a LANGUAGE pragma. (For debugging purposes, zeroth prints to stderr the result of parsing the LANGUAGE pragma, if any. If haskell-src-exts doesn't understand the LANGUAGE pragma, this will be Nothing. But that shouldn't happen.) * Template Haskell imports are now *automatically* stripped by default by zeroth, and so cpphs doesn't need to be run if you aren't otherwise using CPP. * New command-line options have been added (see zeroth --help). * Error messages are now more informative. * Librification! Almost anything can benefit from being made into a library, and zeroth is no exception. Of course, the executable is still there. * You can still use it on certain code which doesn't compile in GHC (yes, really, I've tested this!) but you now have to use the --only-splices option if you want to do this. Obviously, the splices themselves have to compile. --only-splices also makes zeroth faster. It is very lightly tested, so it might not work for your code out of the box. Please let me know if you have any problems with it, no matter how small. Happy hacking, -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Updating HsJudy to work with the latest Judy
I would like to use the HsJudy bindings to the Judy high-performance trie library (on hackage), but unfortunately they have bitrotted. I can have a go at mending them but I have no experience with FFI. Any tips? -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Free theorems for dependent types?
On Sun, 17 May 2009 23:10:12 +0400 Eugene Kirpichov wrote: > Is there any research on applying free theorems / parametricity to > type systems more complex than System F; namely, Fomega, or calculus > of constructions and alike? Yes. I did some research into it as part of my master's thesis, the final version of which is not quite ready yet. Basically, free theorems in the Calculus of Constructions can be substantially more complicated, because they have to exclude certain dependent types in order to be valid. So much so that I do not think that they are necessarily worthwhile to use in proofs. But that is just an intuition, and I have not done enough different kinds of proofs to state this with any confidence. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: The HP and PackedString (was: Re: [Haskell-cafe] Removing mtl from the Haskell Platform)
On Wed, 13 May 2009 15:37:52 +0400 Bulat Ziganshin wrote: > Hello Duncan, > > Wednesday, May 13, 2009, 3:33:13 PM, you wrote: > > > I think it should remain deprecated and we should work on the > > replacement so that TH can switch its dependency. > > TH isn't high-performance package and i think that it should just > switch to use of String I don't agree. TH can sometimes slow down a build considerably. I don't want to see it getting even slower. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] google-like "do you mean?" feature
On Wed, 15 Apr 2009 23:31:50 -0700 Michael Mossey wrote: > I was thinking that it might be useful to have a Google-like "do you > mean this?" feature. If the field name is //customer=, then the > parser might recognize a huge list of variants > like //ustomer=, //customor=, etc... You could reduce the probability of such errors by providing a standard template that could be copy-pasted in wherever necessary. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Conditional compilation
I am writing some code for citation support in gitit, and all the #ifdefs I'm using to do conditional compilation are a bit tiresome. Suppose you have the requirement that a certain feature of your software be disable-able at compile time, to avoid having to pull in certain dependencies (which may not be available on all platforms). Disabling a feature may entail removing certain fields from certain constructors (again, to avoid pulling in certain dependencies), and/or removing certain functions from certain modules. What is the best way to do this in Haskell? This problem description suggests that perhaps insights from Aspect-Oriented Programming and/or Software Product Lines may be relevant. However, I haven't heard of much work that relates these concepts to Haskell. Maybe this would be a good topic for an enterprising student? -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: about Haskell code written to be "too smart"
On Wed, 25 Mar 2009 08:25:40 -0700 Jonathan Cast wrote: > Define > > swap (a, b) = (b, a) By the way, if you want to be "too smart", there's a generalised version of swap in Control.Category.Braided in the category-extras package. That might be a bit overkill though. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: hranker: Basic utility for ranking a list of items (e.g. for the logo poll)
hranker is a fun little command-line utility I have written to help a user rank a list of items (of any type implementing Show, Eq and Ord). I hope the code is sufficiently clear that it could also serve as an educational piece of code, especially for people wanting to learn how to use the HCL library. It is now available on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hranker Just typing hranker or hranker --help will yield a usage message. Here is an example usage of the program: In the unlikely event that anyone else wants to use it to help them prepare their votes in the Haskell logo poll (which is what I used it for just now), here is what to do: 1. cabal install hranker (or download it and runhaskell Setup.lhs etc.) 2. hranker 113 (because 113 is the number of items in the poll) 3. IMPORTANT: Read the warnings the program prints on startup! 4. To control the program, enter the first character of the command you wish to perform, and then press Enter. The command you have chosen may ask you for further information. Commands generally operate on the next unranked item, apart from annotate (which can operate on ranked or unranked items), remove (which always operates on ranked items), and quit. I recommend you use the annotate command a lot - it is really helpful for this kind of situation where you have a lot of numbered items to rank. If you use the remove command, don't remove *all* ranked items, because if you do you it may terminate. 5. If you rank *everything* somehow (remember, ties are allowed), the program will print an inverse mapping (items to ranks, instead of ranks to items) before terminating. If you choose to quit before that point, you won't get that inverse mapping, unless you explicitly invoke the mapping command. There is obvious room for improvement: apart from fixing the remove bug mentioned above, there is currently no simple way to remove or annotate just *one* item at a rank when multiple items are tied at that rank. Have fun! There are some hilarious entries in the logo poll, if you haven't yet voted. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell Logo Voting has started!
Firstly, apologies to everyone for sending the same message to the list five times, yesterday! The mailserver I use kept timing out, and I had thought that my mail client would handle attempts to resend an email appropriately, but apparently not. Time to put a paper bag over my head! On Wed, 18 Mar 2009 11:43:26 +0100 Wolfgang Jeltsch wrote: > If you announce it on the mailing list, I might use it. I'm afraid it is entirely terminal-based (i.e. text only), so it doesn't show the pictures. Someone could try and convert it into a web app and display the pictures, but I have no plans to do that. It is not working at the moment, but I hope to get it working and announce it later this week. > By the way, when will the voting period be over? The polling page says "The poll ends March 24, 2009 at 12:00 UTC". -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell Logo Voting has started!
On Tue, 17 Mar 2009 20:34:12 +0100 Daniel Schüssler wrote: > Hi, > > > Even worse, the buttons for moving items up and down are buggy - at > > least on my browser (Firefox 3.1 beta 2 on Linux). They sometimes > > reorder my other votes! Even assuming that the list box code is not > > buggy (which I now doubt), not being able to use the buttons makes > > this form almost unusable! > > I guess it works like this: > > "Move down" on an element X will make the /smallest/ change (with > respect to the abstract ordering) that makes X worse than it's > current value. This may require changing more than one number, for > example if we have: > > (105: ) (106: A) (107: X,B) (108: C,D) (109: E ) (110: ) > > moving down X will result in either > > (105: A) (106: B) (107: X ) (108: C,D) (109: D ) (110: ) > > or equivalently > > (105: ) (106: A) (107: B ) (108: X ) (109: C,D) (110: D) > > of course, maybe you already know that but you're saying that it is > doing this wrongly ;) Yes, I am saying that. To be more specific: I saw the current Haskell logo get put back in the top position even though I had pushed it down, and I saw three of my choices which I ranked quite highly, pushed down to the bottom. Scarily bad. However, I am now hacking together a quick-and-dirty utility for ranking things which I will put on hackage. I'm not sure that anyone other than myself will use it, but it's fun hacking it up. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell Logo Voting has started!
On Tue, 17 Mar 2009 20:34:12 +0100 Daniel Schüssler wrote: > Hi, > > > Even worse, the buttons for moving items up and down are buggy - at > > least on my browser (Firefox 3.1 beta 2 on Linux). They sometimes > > reorder my other votes! Even assuming that the list box code is not > > buggy (which I now doubt), not being able to use the buttons makes > > this form almost unusable! > > I guess it works like this: > > "Move down" on an element X will make the /smallest/ change (with > respect to the abstract ordering) that makes X worse than it's > current value. This may require changing more than one number, for > example if we have: > > (105: ) (106: A) (107: X,B) (108: C,D) (109: E ) (110: ) > > moving down X will result in either > > (105: A) (106: B) (107: X ) (108: C,D) (109: D ) (110: ) > > or equivalently > > (105: ) (106: A) (107: B ) (108: X ) (109: C,D) (110: D) > > of course, maybe you already know that but you're saying that it is > doing this wrongly ;) Yes, I am saying that. To be more specific: I saw the current Haskell logo get put back in the top position even though I had pushed it down, and I saw three of my choices which I ranked quite highly, pushed down to the bottom. Scarily bad. However, I am now hacking together a quick-and-dirty utility for ranking things which I will put on hackage. I'm not sure that anyone other than myself will use it, but it's fun hacking it up. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell Logo Voting has started!
On Tue, 17 Mar 2009 20:34:12 +0100 Daniel Schüssler wrote: > Hi, > > > Even worse, the buttons for moving items up and down are buggy - at > > least on my browser (Firefox 3.1 beta 2 on Linux). They sometimes > > reorder my other votes! Even assuming that the list box code is not > > buggy (which I now doubt), not being able to use the buttons makes > > this form almost unusable! > > I guess it works like this: > > "Move down" on an element X will make the /smallest/ change (with > respect to the abstract ordering) that makes X worse than it's > current value. This may require changing more than one number, for > example if we have: > > (105: ) (106: A) (107: X,B) (108: C,D) (109: E ) (110: ) > > moving down X will result in either > > (105: A) (106: B) (107: X ) (108: C,D) (109: D ) (110: ) > > or equivalently > > (105: ) (106: A) (107: B ) (108: X ) (109: C,D) (110: D) > > of course, maybe you already know that but you're saying that it is > doing this wrongly ;) Yes, I am saying that. To be more specific: I saw the current Haskell logo get put back in the top position even though I had pushed it down, and I saw three of my choices which I ranked quite highly, pushed down to the bottom. Scarily bad. However, I am now hacking together a quick-and-dirty utility for ranking things which I will put on hackage. I'm not sure that anyone other than myself will use it, but it's fun hacking it up. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell Logo Voting has started!
On Tue, 17 Mar 2009 20:34:12 +0100 Daniel Schüssler wrote: > Hi, > > > Even worse, the buttons for moving items up and down are buggy - at > > least on my browser (Firefox 3.1 beta 2 on Linux). They sometimes > > reorder my other votes! Even assuming that the list box code is not > > buggy (which I now doubt), not being able to use the buttons makes > > this form almost unusable! > > I guess it works like this: > > "Move down" on an element X will make the /smallest/ change (with > respect to the abstract ordering) that makes X worse than it's > current value. This may require changing more than one number, for > example if we have: > > (105: ) (106: A) (107: X,B) (108: C,D) (109: E ) (110: ) > > moving down X will result in either > > (105: A) (106: B) (107: X ) (108: C,D) (109: D ) (110: ) > > or equivalently > > (105: ) (106: A) (107: B ) (108: X ) (109: C,D) (110: D) > > of course, maybe you already know that but you're saying that it is > doing this wrongly ;) Yes, I am saying that. To be more specific: I saw the current Haskell logo get put back in the top position even though I had pushed it down, and I saw three of my choices which I ranked quite highly, pushed down to the bottom. Scarily bad. However, I am now hacking together a quick-and-dirty utility for ranking things which I will put on hackage. I'm not sure that anyone other than myself will use it, but it's fun hacking it up. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell Logo Voting has started!
On Tue, 17 Mar 2009 20:34:12 +0100 Daniel Schüssler wrote: > Hi, > > > Even worse, the buttons for moving items up and down are buggy - at > > least on my browser (Firefox 3.1 beta 2 on Linux). They sometimes > > reorder my other votes! Even assuming that the list box code is not > > buggy (which I now doubt), not being able to use the buttons makes > > this form almost unusable! > > I guess it works like this: > > "Move down" on an element X will make the /smallest/ change (with > respect to the abstract ordering) that makes X worse than it's > current value. This may require changing more than one number, for > example if we have: > > (105: ) (106: A) (107: X,B) (108: C,D) (109: E ) (110: ) > > moving down X will result in either > > (105: A) (106: B) (107: X ) (108: C,D) (109: D ) (110: ) > > or equivalently > > (105: ) (106: A) (107: B ) (108: X ) (109: C,D) (110: D) > > of course, maybe you already know that but you're saying that it is > doing this wrongly ;) Yes, I am saying that. To be more specific: I saw the current Haskell logo get put back in the top position even though I had pushed it down, and I saw three of my choices which I ranked quite highly, pushed down to the bottom. Scarily bad. However, I am now hacking together a quick-and-dirty utility for ranking things which I will put on hackage. I'm not sure that anyone other than myself will use it, but it's fun hacking it up. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell Logo Voting has started!
I am also concerned that the default behaviour of the buttons will lead to arbitrary preference rankings favouring those with entries that start more towards the top or bottom of the list. You shouldn't have to go to a lot of extra effort to create a tie between several entries, if you can't decide (or don't want to decide) between them. However, this isn't as significant as the buggy reordering behaviour I'm seeing. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell Logo Voting has started!
On Tue, 17 Mar 2009 16:11:54 +0100 Thomas Davie wrote: > I have to agree that the UI for voting is not the best I've ever > seen. On the other hand, it's pretty easy to select the few logos > that you like, and push them all to the top, select the ones you'd > accept, and push them up just below, and finally select the ones you > absolutely don't like and push them all the way down. > > That at least is what I did. Did you check that code bugs hadn't reordered your votes? I am worried about this destroying the validity of the election. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell Logo Voting has started!
On Tue, 17 Mar 2009 15:24:28 +0100 Heinrich Apfelmus wrote: > A simple majority vote is clearly inadequate for this vote, but I'm > afraid that without assisting technology (instant and visual > feedback), the voting process will more or less deteriorate to that > due to the difficulty of creating quality input votes. Even worse, the buttons for moving items up and down are buggy - at least on my browser (Firefox 3.1 beta 2 on Linux). They sometimes reorder my other votes! Even assuming that the list box code is not buggy (which I now doubt), not being able to use the buttons makes this form almost unusable! -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pointless functors
On Fri, 13 Mar 2009 14:32:23 + Ross Paterson wrote: > On Fri, Mar 13, 2009 at 03:18:15PM +0100, Martijn van Steenbergen > wrote: > > Are there any functors f for which no point/pure/return :: a -> f a > > exists? > > No. Choose an arbitrary element shape :: f () and define > > point x = fmap (const x) shape This suggests a fun way to define a monad for a functor F: -- Does nothing, has no effect, and returns () noOp :: F () noOp = ... instance Monad F where return x = fmap (const x) noOp (<<=) f x = ... I think noOp would be a nice addition to the Monad class, as well. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pointless functors
For most functors, that is equivalent to point x = undefined But by that logic, everything is a member of every typeclass... -- Robin On Fri, 13 Mar 2009 17:35:31 +0300 Eugene Kirpichov wrote: > 'An arbitrary element' means 'undefined will suffice' > > point x = fmap (const x) undefined > > > 2009/3/13 Ross Paterson : > > On Fri, Mar 13, 2009 at 03:18:15PM +0100, Martijn van Steenbergen > > wrote: > >> Are there any functors f for which no point/pure/return :: a -> f > >> a exists? > > > > No. Choose an arbitrary element shape :: f () and define > > > > point x = fmap (const x) shape > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Design Patterns by Gamma or equivalent
The concept of "design pattern" tends not to be used by Haskell programmers - it brings a lot of baggage with it (like being formally documented in a particular way, being "proven" by being used in production several times, etc.) and it doesn't seem to be particularly useful for us in this heavyweight form. However, we do have a more lightweight concept of an "idiom" and "idiomatic Haskell". See http://www.haskell.org/haskellwiki/Category:Idioms (Not all of these pages should probably be in this category, but it gives you an idea.) -- Robin On Wed, 11 Mar 2009 21:28:52 +1030 "Mark Spezzano" wrote: > Hi, > > > > I’m very familiar with the concept of Design Patterns for OOP in Java > and C++. They’re basically a way of fitting components of a program > so that objects/classes fit together nicely like Lego blocks and it’s > useful because it also provides a common “language” to talk about > concepts, like Abstract Factory, or an Observer to other programmers. > In this way one programmer can instantly get a feel what another > programmer is talking about even though the concepts are > fundamentally abstract. > > > > Because Haskell is not OO, it is functional, I was wondering if there > is some kind of analogous “design pattern”/”template” type concept > that describe commonly used functions that can be “factored out” in a > general sense to provide the same kind of usefulness that Design > Patterns do for OOP. Basically I’m asking if there are any kinds of > “common denominator” function compositions that are used again and > again to solve problems. If so, what are they called? > > > > Cheers, > > > > Mark Spezzano > > > > > > > No virus found in this outgoing message. > Checked by AVG. > Version: 7.5.557 / Virus Database: 270.11.9/1993 - Release Date: > 10/03/2009 7:19 AM > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mystified by Cabal
On Sat, 07 Mar 2009 17:30:43 + Colin Paul Adams wrote: > > "Svein" == Svein Ove Aas writes: > > >> Preprocessing library game-tree-1.0.0.0... Building > >> game-tree-1.0.0.0... > >> > >> Data/Tree/Game/Negascout.hs:31:0: Unrecognised pragma [1 of 2] > >> Compiling Data.Tree.Game.Tree ( Data/Tree/Game/Tree.hs, > >> dist/build/Data/Tree/Game/Tree.o ) > >> > >> Data/Tree/Game/Tree.hs:1:0: Failed to load interface for > >> `Prelude': it is a member of package base-3.0.3.0, which > >> is hidden > >> > Svein> What does your .cabal file look like? > > name:game-tree > version: 1.0.0.0 > cabal-version: >= 1.6 > synopsis:Searching game trees with alpha-beta pruning > description: A data type for game trees, as used in decision > theory and game theory, along with standard algorithms for searching > the tree using alpha-beta pruning. Can be used as the basis of an AI > for two-player zero-sum games, such as chess. category: > Data license: GPL > license-file:LICENSE > author: Colin Adams > maintainer: co...@colina.demon.co.uk > copyright: Copyright: 2009 Colin Adams > build-type: Simple > build-depends: base >= 4 > ghc-options: -Wall -fno-warn-unrecognised-pragmas > > Library > exposed-modules: Data.Tree.Game.Tree, Data.Tree.Game.Negascout > source-repository head > type: darcs > location: http://code.haskell.org/game-tree/ The build-depends line needs to go in the Library section, I think. It doesn't seem to be having any effect in its current location. Likewise for ghc-options. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: gitit 0.5.1
On Thu, 26 Feb 2009 14:30:17 + Hugo Pacheco wrote: > Hi all, > > Under gitit 0.5.3 I always get "Prelude.read: no parse" when trying to > load a configuration file. > My previous file goes attached, but the sample config file from > http://github.com/jgm/gitit/tree/master does not work also. I don't think you can actually do multiplication in the config file, as the sample config file tries to. Replace 2 * 1024 * 1024 with 200, and the sample config should work. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Paper draft: "Denotational design with type class morphisms"
On Fri, 20 Feb 2009 15:17:14 +0100 Achim Schneider wrote: > Conal Elliott wrote: > > > DRAFT version ___ comments please > > > Conal, please, PLEASE, never, EVER again use the word "meaning" if you > actually mean "denotation". It confuses the hell out of me, especially > the (I guess unintended) connotation that you analyse the meaning of a > particular instance's existence on a cosmic scale. It shouldn't confuse you. Using "means" for "denotes", and likewise "meaning" for "denotation", is correct English, and very common usage too. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language popularity
On Fri, 13 Feb 2009 15:52:48 +0100 "Henk-Jan van Tuyl" wrote: > > Yesterday I saw Haskell mentioned for the first time in a magazine, > Bits & Chips. It is a magazine for professionals, about hardware and > software; the article was about the domain specific language Cryptol > from Galois. > > In the same issue of the magazine, there was an article saying that > the company Tiobe has proclamed C the language of the year 2008, > because of it's growth in popularity of almost two percent. The > current statistics can befoud at [1]. The most popular functional > language at the moment is LOGO [2], at the 15th place in the top 50 > (from 22nd place a year ago). I think we can fairly safely discount the commercial relevance of any language ranking which places LOGO so highly. It may be that a lot of people *know* LOGO (or claim to know it), but that does not mean that is used a lot for commercial programming. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for pointfree version
On Mon, 9 Feb 2009 14:18:18 + Edsko de Vries wrote: > Hi, > > Is there a nice way to write > > down :: Focus -> [Focus] > down p = concat [downPar p, downNew p, downTrans p] > > in point-free style? I think this should work: down = concat . swing map [downPar, downNew, downTrans] swing is defined at http://www.haskell.org/haskellwiki/Pointfree#Swing -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lazy evaluation is not complete
On Mon, 09 Feb 2009 15:10:22 +0100 Peter Padawitz wrote: > A simplied version of Example 5-16 in Manna's classical book > "Mathematical Theory of Computation": > > foo x = if x == 0 then 0 else foo (x-1)*foo (x+1) > > If run with ghci, foo 5 does not terminate, i.e., Haskell does not > look for all outermost redices in parallel. Why? For efficiency > reasons? I believe * is implemented in the normal way and thus is always strict in both arguments. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Reminder about hard questions about GHC (was [Haskell-cafe] Temporarily overriding Data.Generics)
For low-level or obscure questions about GHC such as this, it might be better to use glasgow-haskell-us...@haskell.org. There are one or two people who don't read haskell-cafe because it's so busy (and they're so busy). -- Robin On Wed, 4 Feb 2009 22:54:15 +0100 Deniz Dogan wrote: > Hi > > I'm currently working on "hacking" Data.Generics for my master thesis. > I'm basically trying to find out whether it can be made a bit faster > using e.g. rewrite rules. The problem I'm having is that I need an > easy way to import my own modified version of Data.Generics (currently > located in the same directory as my testing program) without > unregistering or hiding syb-0.1.0.0 as base seems to depend on it. > > I've read the GHC user manual trying to find nice ways to do this > using a bunch of different parameters to ghc, but I can't figure it > out. Does anyone here know? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting Lists to Sets
On Tue, 3 Feb 2009 19:58:51 -0200
"rodrigo.bonifacio" wrote:
> Hi all,
>
> I'm trying to use the Funsat library. One of its data types is CNF:
>
> data CNF = CNF {
> numVars :: Int
> numClauses :: Int
> clauses :: Set Clause
> }
>
> I have a list of clauses, but I'm getting an error when converting
> such a list to a Set. Using the fromList function, the ghc compiler
> reports that the fromList function is not applicable to literals.
>
> type Clause = [Lit]
>
> newtype Lit = L {
> unLit :: Int
> }
>
You don't provide your code or the exact error message, which makes
it harder to diagnose - but I'd guess you are mistakenly trying to apply
fromList to a *single* literal, rather than a *list* of literals.
--
Robin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Colin Paul Adams] Re: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O
Colin, I really don't see the point of putting your own name at the front of the subject line. It is redundant because it's already in the email headers. Perhaps this was a technical glitch? -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HPC and literate haskell
Have you tried processing the file with lhs2tex first, to unlit it? (Or
is that what you are doing? It's unclear from your email.)
--
Robin
On Fri, 30 Jan 2009 16:02:08 +0300
Pavel Perikov wrote:
> Hi, list!
>
> I have a file:
>
> \begin{code}
> module Main where
> import MyModule
>
> main=do
> print "hello"
> \end{code}
>
> MyModule is in MyModule.lhs
>
> when building with
>
> ghc -o main -fhpc --make Main.lhs
>
> I get perfectly working code, but MyModule.mix lacks any usable
> coverage information:
>
> Mix "./MyModule.lhs" 1233320065 1385570408 1 []
>
> After renaming MyModule.lhs to MyModule.hs and unlitting it
> everything works fine:
>
> Mix "./MyModule.hs" 1233320249 3220649115 1 [(3:8-3:8,ExpBox False),
> (3:9-3:9,Exp
> Box False),(3:7-3:10,ExpBox False),(3:1-3:10,TopLevelBox ["func2"])]
>
> I'm using ghc 6.10.1 on Mac OSX.
>
> Does anyone have this problem? are any workarounds available?
>
> Pavel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
On Fri, 30 Jan 2009 15:21:05 +0800 Evan Laforge wrote: > Is there a description somewhere of what the > critical flaws have been and are, and what the current problems are to > solve before we can finally have a practical declarative and > compositional UI library? In *theory*, that should be in the (recent) research papers themselves, or perhaps in a paper cited by them. I don't know if that's the case, though. (Always annoys me when research papers don't include that.) -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Installing GHC with libedit in nonstandard location
On Sat, 24 Jan 2009 07:23:04 -0800 (PST) Grzegorz Chrupala wrote: > So GHC installs but when I try to run it is fails with: error while > loading shared libraries: libedit.so.0: cannot open shared object > file: No such file ordirectory > I tried setting LIBRARY_PATH and LD_RUN_PATH to $HOME/lib but it > doesn't help The variable you need to set is LD_LIBRARY_PATH -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make code least strict?
On Mon, 19 Jan 2009 17:36:30 + "Thomas DuBuisson" wrote: > On Mon, Jan 19, 2009 at 4:48 PM, Robin Green > wrote: > > What guidelines should one follow to make Haskell code least-strict? > > There was a great Cafe discussion started by Henning on just this. He > provided this link: > > http://www.haskell.org/haskellwiki/Maintaining_laziness Thanks - wow, my memory is terrible! I submitted this page to the Haskell reddit myself 20 days ago! I had a sneaking feeling of deja vu after I asked the question. :-D -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell WikiProject
Is anyone else interested in forming a Haskell WikiProject on Wikipedia, to collaborate on improving and maintaining the coverage and quality of articles on Haskell-related software and topics (broadly defined)? Not just programming topics specific to Haskell, but also ones of interest to the Haskell community. Some of you might already be doing this from time to time, but forming an explicit WikiProject might help to: * Highlight things that could use some attention * Divide up tasks (based on expertise or interest) * Recruit more editors (sticking a banner on article Talk pages can let editors know the WikiProject exists) * Eventually (something for the future, maybe!) work together on a Wikipedia Haskell Portal * And of course, improve the visibility of Haskell on Wikipedia, which should help our community Here's a good example to start with. The article on Eager evaluation could do with some improvement - and possibly should be merged into the Lazy evaluation article, I'm not sure: http://en.wikipedia.org/wiki/Eager_evaluation We could also probably create some more articles on projects written in Haskell, and add more references to Haskell research papers. Software projects don't have to be polished to be covered in Wikipedia - or even working! - they essentially just have to be "notable", as the Wikipedia guidelines define it. By the way (getting a bit offtopic here) an annoying limitation of the Wikipedia category system, that you couldn't run queries like "Give me all the articles in the Haskell category that are also in the Unreferenced category" has now been partially addressed by the experimental prototype of Category Intersection: http://toolserver.org/~dschwen/intersection/ This is slightly better than Googling, because crucially, it searches *recursively* through categories. That means it will turn up articles that are in a subcategory of "Category:Haskell programming language" but don't explicitly mention Haskell. Don't know if there any such articles yet, but it's worth bearing in mind that you can do this. I think it will, in principle, make topic-specific maintenance a bit more convenient - and it's what I've been waiting for before getting involved in topic-specific maintenance. If you want to just express interest in signing up for such a WikiProject (no commitment required whatsoever!), please reply privately via email or publicly on my User Talk page (User talk:Greenrd) - to avoid clogging up this mailing list. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to make code least strict?
What guidelines should one follow to make Haskell code least-strict? -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Sun, 18 Jan 2009 08:51:10 +0100 david48 wrote: > On Sat, Jan 17, 2009 at 11:19 PM, Dan Piponi > wrote: > > On Sat, Jan 17, 2009 at 1:47 AM, david48 > > wrote: > > >> why would I > >> need to write a running count this way instead of, for example, a > >> non monadic fold, which would probably result in clearer and > >> faster code? > > > > Maybe my post here will answer some questions like that: > > http://sigfpe.blogspot.com/2009/01/haskell-monoids-and-their-uses.html > > Just wow. Very very nice post. one to keep in the wikis. > Thank you *very* much, Dan, for writing this. Seconded. And I hope, Dan, that you will find time at some point to write about those other things you said at the end that you didn't have time to write about! -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] unfoldr [ANN: HLint 1.2]
On Mon, 12 Jan 2009 21:04:35 +0100 (CET) Henning Thielemann wrote: > > On Mon, 12 Jan 2009, Andrew Coppin wrote: > > > Off the top of my head, try this: > > > > convert b 0 = [] > > convert b n = n `mod` b : convert b (n `div` b) > > > > (Takes a number and yields the radix-B representation of it. > > Backwards.) > > > > convert b = unfoldr (\n -> if n > 0 then Just (n `mod` b, n `div` > > b) else Nothing) > > I have the nice function 'toMaybe' which simplifies this to: >unfoldr (\n -> toMaybe (n>0) (n `mod` b, n `div` b)) I would use the more general idiom: unfoldr (\n -> guard (n > 0) >> return (n `mod` b, n `div` b)) -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HLint 1.2
On Mon, 12 Jan 2009 19:43:00 +0100 "Bas van Dijk" wrote: > On Mon, Jan 12, 2009 at 6:47 PM, Max Bolingbroke > wrote: > > GHC should indeed be doing so. I'm working (on and off) to work out > > some suitable heuristics and put the transformation into ghc -O2. > > There are a few wrinkles that still need sorting out, but > > preliminary indications are that it decreases the runtime of our > > standard benchmark suite, nofib, by 12% or so. > > Great! > > In the Stream library I'm developing at http://code.haskell.org/Stream > I 'closurize' (for lack of a better name) all my functions. Here are a > few random examples: > > repeat :: a -> Stream a > repeat x = repeat_x > where > repeat_x = x ::: repeat_x > > cycle :: [a] -> Stream a > cycle xs = cycle_xs > where > cycle_xs = foldr (:::) cycle_xs xs > > deleteBy :: (a -> a -> Bool) -> a -> Stream a -> Stream a > deleteBy eq x = deleteBy_eq_x > where > deleteBy_eq_x (y ::: ys) > | eq x y= ys > | otherwise = y ::: deleteBy_eq_x ys > > Closurizing the functions in Data.Stream lead to 10% to 250% speedups! Awesome! I tend to use Control.Monad.Fix.fix (which actually has nothing to do with monads, despite the package name) sometimes, for "closurizing" a recursive function. I am curious as to whether the "fix" style of recursive programming is likely to result in the same speedups. The fix-style equivalent to your repeat above, would be something like this: repeat x = fix $ \me -> x ::: me (I use "me" for the name of the recursive call, partly because it reminds me that it's a self-call, and partly because I find it amusing) -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: #haskell IRC channel reaches 600 users
On Mon, 5 Jan 2009 07:27:13 +0100 Achim Schneider wrote: > Achim Schneider wrote: > > > [...] > > > Hmmm... I seem to have left out the academics definition of bogosity. > I bet that others are much more qualified to elaborate on this, but my > working assumption has been (and still is) that it does include a wide > range of working code, and excludes a lot of abstract nonsense. Well, as someone who has done research in at least 4 different subfields of computer science, I'd say it depends on which subfield you are in. Academics in Human Computer Interaction might criticise a project for having a badly-designed user interface that is hard to use; academics in formal methods might criticise code for not having a specification anywhere of what it does or how it is supposed to handle erroneous inputs; academics working on aspect-oriented software development might criticise code for "tangling" too many concerns unnecessarily in one function. Whereas, each of these academics might be oblivious (or almost oblivious) to the other two critiques. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Coroutines
In my opinion, in Haskell, you don't need coroutines because you have
lazy evaluation.
You example below is simply an example of a heterogenous list being
read. The simplest way to implement a heterogenous list in Haskell is
to use a tuple. Or you could use the HList package.
--
Robin
On Thu, 18 Dec 2008 02:26:26 -0800
"Ryan Ingram" wrote:
> On Thu, Dec 18, 2008 at 2:00 AM, Nicolas Pouillard
> wrote:
> > I don't see why one would need session types, channels... to
> > express that. I maybe need a more complicated coroutines (ruby)
> > example that would require using this system.
>
> OK, how would you type these routines in Haskell?
>
> def simple
> yield "hello"
> yield 1
> yield (lambda { |x| x + 1 })
> end
>
> def useSimple
> state = 0
> result = nil
> simple { |x|
> if (state == 0) then result = x
> else if (state == 1) then result += (x * 4).toString
> else if (state == 2) then result += x.call(10).toString
> state = state + 1
> }
> result
> end
>
> I know it's a bit contrived, but you get the idea.
>
> In Haskell using Control.Coroutine:
>
> simple :: forall rest. Session (String :!: Int :!: (Int -> Int) :!:
> rest) rest ()
> simple = do
> put "hello"
> put 1
> put (\x -> x + 1)
>
> useSimple :: forall rest. Session (String :?: Int :?: (Int -> Int) :?:
> rest) rest String
> useSimple = do
> string <- get
> int <- get
> func <- get
> return (string ++ show (int * 4) ++ show (func 10))
>
> result :: String
> result = snd $ connects simple useSimple
> -- result = "hello411"
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Garbage collection as a dual of laziness?
It occurs to me that garbage collection can be seen as some kind of dual of laziness. Laziness means deferring the creation of values until later in the future (or even never). Garbage collection means eagerly destroying data created in the past, and reclaiming the memory used by it, before some other event which would do so (in most garbage-collected languages, I think process destruction is the only other thing that frees memory, leaving aside foreign functions). If you don't have enough laziness (e.g. because of strict pattern matching on tuples) your program might do unnecesssary work (time wastage); if you don't have enough garbage collection (e.g. because a value will never be accessed again but is still referred to from something live), your program might leak memory (space wastage). Of course, space wastage can lead to time wastage, and vice-versa. Can this intuition be made any more formal? Is it merely of pedagogical use, or does anything interesting follow from it? -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] huge single file syncronization
On Mon, 3 Nov 2008 22:16:14 +0100 "Alberto G. Corona " <[EMAIL PROTECTED]> wrote: > I need to backup my ubuntu-VMWare image frequently (5 GBits) . I > need to know if exist such a utility (in haskell or not) for single > file syncronization. Why don't you just run rsync inside the virtual machine? That way, you will avoid unnecessarily synchronising old data from deleted files, or files that have been truncated. A Haskell library and/or GUI for rsync (to allow you to configure all the possible command-line options) would be a nice thing to have. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional MetaPost in 5 Steps
On Thu, 23 Oct 2008 22:13:10 -0700 "Jared Updike" <[EMAIL PROTECTED]> wrote: > I can't even get a simple example to show up in a PDF file I can't even get my simple example to show up anywhere, period. PDF, DVI, PS - anything. No matter which way I try, and I've tried lots, I always hit some kind of PostScript or TeX error. My Haskell file is attached. I asked about it on the tex-live mailing list, and I got this response, advising me to speak to the author: From: Taco Hoekwater <[EMAIL PROTECTED]> To: Robin Green <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Subject: Re: [tex-live] Missing \endcsname errors when trying to insert MetaPost graphic into PDF Date: Fri, 24 Oct 2008 10:28:20 +0200 User-Agent: Thunderbird 2.0.0.12 (X11/20080305) Hi Robin, Robin Green wrote: > > No, it was generated by MetaPost. Here are the sequence of commands I > used: FuncMP.mp is the culprit here. It alters MetaPost's output via explicit special command so that it is no longer acceptable to the mptopdf converter. >> I suggest you rename the file to figure1.eps (and run >> epstopdf on it before inclusion in your latex document) > > "epstopdf figure1.eps" outputs this error: > > Error: /undefined in cmmi10 If the document was was 'plain' metapost input, it would actually have been possible to fix this in texlive 2008 by adding prologues:=3; at the top of the figure1.mp file. However, FuncMP.mp has redefined (via specials) the PostScript commands like /fshow etc,. so this won't work. Also, it seems to be altering the label typesetting so that it uses metafont bitmap (pk) fonts instead of type1. My advice is to look into the functional metapost documentation or ask its author for help and guidelines on how to use the result images in pdftex (as opposed to dvips/xdvi). Best wishes, Tacoimport FMP (circle, generate, math, text) import FMP.Tree (edge, enode, node) fig1 = node (circle $ math "\\lambda") [ enode (circle $ text "::") [ enode (circle $ text "x") [] , enode (circle $ text "Int") [] ] , enode (circle $ text "+") [ enode (circle $ text "x") [] , enode (circle $ text "1") [] ] ] main = generate "figure" 1 fig1___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Total Functional Programming in Haskell
On Tue, 30 Sep 2008 03:27:09 -0600 "Luke Palmer" <[EMAIL PROTECTED]> wrote: > But I *want* to do something like that with Coq (I prefer it to Agda > for little more than personal taste). In particular, I'd like to see > a reasoning framework for partial functions, so you could state and > prove a property like: > > length [1..] = _|_ Bear in mind, in Coq, the equivalent of [1..] is a stream, whereas the equivalent of [1,2,3] is a list. You'd have to have list functions in Coq which worked generically over both lists and streams to be able to say what you want, and I don't know of any existing attempt to do that. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FRP (was: Semantic Domain, Function, and denotational model)
On Wed, 17 Sep 2008 15:28:35 +0100 "John Lato" <[EMAIL PROTECTED]> wrote: > I just noticed that the "Simply Efficient Functional Reactivity" paper > has been updated since I last looked; I'll have to read it again now. > > Is the library/code mentioned in the paper released or available > anywhere at this time? Conal has left tantalizing hints scattered in > various places... To get the latest code, which might not correspond to the code in the paper: darcs get http://code.haskell.org/reactive/ -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Weekly News: Issue 85 - September 13, 2008
On Mon, 15 Sep 2008 13:05:11 -0300 "Rafael C. de Almeida" <[EMAIL PROTECTED]> wrote: > I do not know. I'm not experienced on the field and I was under the > impression you'd write your code then get a pen and a paper and try to > prove some property of it. In fairness, that's how it's often done in universities (where correctness doesn't really matter to most people - no offense intended). But once you start using software to write formal proofs, it is quite easy in principle to get a computer to check your proof for you. Many academics do not use formal proof tools because (a) they are not aware of them, or (b) they see them as too hard to learn, or (c) they see them as too time-consuming to use, or (d) they don't see the point. Hopefully this situation will gradually change. > Someone mentioned coq, I read a bit about it, but it looked really > foreign to me. The idea is to somehow prove somethings based only on > the specification and, after that, you write your code, based on your > proof? No. There are 3 main ways of using Coq: 1. Code extraction. You write your code in Coq itself, prove that it meets your specification, and then use the Extraction commands to convert the Coq code into Haskell (throwing away all the proof bits, which aren't relevant at runtime). 2. Verification condition generation (VCGen) - you write your code in some "ordinary" language, say Haskell, and annotate it with specifications. Then you run a VCGen tool over it and it tries to prove the trivial things, and spits out the rest as "verification conditions" in the language of Coq, ready to be proved in Coq. 3. A combination of both of the above approaches - you write your code in Coq, ignoring the proof at first, and then verification conditions (called "obligations" in Coq) are generated. This is experimental. The commands that begin with "Program" in Coq are used for this. None of these involve writing the same code twice in different languages. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell Weekly News: Issue 85 - September 13, 2008
On Mon, 15 Sep 2008 10:32:44 -0400 Stefan Monnier <[EMAIL PROTECTED]> wrote: > > A more difficult question is: how do I know that the formal > > specification I've written for my program is the right one? Tools > > can fairly easily check that your programs conform to a given > > specification, but they cannot (to my knowledge) check that your > > specification says exactly what you want it to say. > > The key is *redundancy*: as long as your property is sufficiently > different (in structure, in authorship, etc...) you can hope that if > the spec has a bug, the code will not have a corresponding bug and > vice versa. It's only a hope, tho. There are other meta-level properties one might desire in a specification, too, such as: * Simplicity - if a specification is too long-winded, you might not spot a bug in it because it's too hard to read. * Definite description - if a specification is a definite description, it is satisfied by one and only one value (up to functional equivalence). For example, if I say that a list sorting function must preserve the length of its input, that's not a definite description, because it is satisfied by the identity function, as well as a correct sorting function. However, if I say (in a suitably formal way) that a sorting function must output a list where every element in the input occurs the same number of times in the output as it occurs in the input, and vice-versa, and the output is ordered according to the specified order - then that *is* a definite description, because any two functions that follow that specification must be equivalent. * Reusable (and perhaps reused!) - As in ordinary programming, reuse of specifications can help avoid errors. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting feature
On Mon, 07 Jul 2008 12:30:34 +0200 (CEST) Henning Thielemann <[EMAIL PROTECTED]> wrote: > Actually the type system of Haskell is also logic programming. I > have implemented a simple kind of logic programming using lazy peano > numbers: http://darcs.haskell.org/unique-logic/ There is also Curry which is basically Haskell extended with features from logic programming. There you get to use ordinary values instead of having to use types. However, it seems that Curry's solution finding mechanism is built-in to the language and cannot be modified (e.g. for performance reasons) without modifying the language implementation. (I think the same would be true for logic programming with Haskell types.) -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: The Disciplined Disciple Compiler - alpha 1.1
Is there any work on combining effect typing with extended static checking or full-blown formal verification (e.g. proof-carrying code)? My hunch would be that an impure functional language like this (OCaml is another example) makes optimisation easier, compared to Haskell - but at the expense of making formal reasoning about the code potentially as complicated and hard as formal reasoning about, say, Java code. Of course, the way in which programmers choose to use the language would impact how easy their code is to reason about. But from the standpoint of ease of reasoning, I'm leaning towards sticking with pure languages for the time being, in my research. -- Robin On Thu, 3 Jul 2008 22:12:30 +1000 Ben Lippmeier <[EMAIL PROTECTED]> wrote: > > Hi All, > I'm pleased to announce version 1.1 > of the Disciplined Disciple Compiler (DDC) > > Disciple is an explicitly lazy dialect of Haskell which supports: > - first class destructive update of arbitrary data. > - computational effects without the need for state monads. > - type directed field projections. > - allied functional goodness. > > All this and more through the magic of effect typing. > > New in this version: > - support for x86_64 under linux and darwin, thanks to Jared Putnam. > - the -make flag now does a full dependency driven build/rebuild. > - constructor classes. > - irrefutable patterns. > - partial support for monadic do notation. > - an unboxed Bool# type with true# and false# literals. > - field projection punning. > - lots more example code. > > Project page with full release notes and download at: >http://www.haskell.org/haskellwiki/DDC > > DDC: more than lambdas. > > Ben. > > ___ > 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] I/O without monads, using an event loop
On Fri, 30 May 2008 15:23:46 +0100 Andrew Butterfield <[EMAIL PROTECTED]> wrote: > Robin Green wrote: > > I have been thinking about to what extent you could cleanly do I/O > > without explicit use of the I/O monad, and without uniqueness types > > (which are the main alternative to monads in pure functional > > programming, and are used in the Concurrent Clean programming > > language). > > > > Suppose you have a main event handler function, like this: > > > > eventMain :: (Event, SystemState AppState) -> (Command, SystemState > > AppState) > > > > This function could be called over and over in an event loop, until > > an EndProgram command was received, and the event loop would itself > > do all the actual I/O (the SystemStates are only in-memory > > representations of some part of the system state, plus the > > application's own state). Things like disk I/O could be done with > > commands which generate events when complete. Interprocess > > communication could be done in the same way. > > > > Then eventMain, and everything called by it, would be > > referentially-transparent, and yet non-monadic. You could of course > > build higher-level stuff on top of that. > > > Given the above, without uniqueness typing, and because there is > clearly no monad, > I could write > > breakMain > :: (Event,Event,SystemState AppState) > -> ((Command,SystemState AppState),(Command,SystemState AppState)) > breakMain (e1,e2,sys) = ( eventMain (e1,sys) , eventMain (e2,sys) ) > > Now what happens? Do we get two copies of SystemState ? > > Simpler still, I can write (sys,eventMain e sys) -- what happens > here? I have references to both before- and after- state. Yes, you do - but they're only in-memory representations. Sorry, I didn't fully explain what I meant. Two points: 1. The SystemState record only contains in-memory representations of *some* parts of the system state - e.g. on an embedded system they could be the on/off status of the LEDs, motor speeds, the state of the toggle switches, which buttons are currently being pressed, etc. It would be infeasible to record the entire state of, say, an attached 120GB hard drive - and even less feasible to record the state of the external environment - so only some parts of the system would be covered by this data structure. 2. It's the event loop's job to do any necessary I/O to update the *actual* system state to match the SystemState returned by eventMain (ignoring any changes which are impossible, e.g. if the program tries to say a toggle switch is on when it isn't). As I said, only in the event loop is any I/O actually performed. So when you evaluate breakMain or whatever, nothing happens - it's just manipulating representations. You can only return one SystemState from eventMain, and that is used to update the real system state - so there's no paradox. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] I/O without monads, using an event loop
I have been thinking about to what extent you could cleanly do I/O without explicit use of the I/O monad, and without uniqueness types (which are the main alternative to monads in pure functional programming, and are used in the Concurrent Clean programming language). Suppose you have a main event handler function, like this: eventMain :: (Event, SystemState AppState) -> (Command, SystemState AppState) This function could be called over and over in an event loop, until an EndProgram command was received, and the event loop would itself do all the actual I/O (the SystemStates are only in-memory representations of some part of the system state, plus the application's own state). Things like disk I/O could be done with commands which generate events when complete. Interprocess communication could be done in the same way. Then eventMain, and everything called by it, would be referentially-transparent, and yet non-monadic. You could of course build higher-level stuff on top of that. On the other hand, it's quite stateful, because anything you need to remember between events need to be recorded, either in the SystemState or externally (e.g. in a file). I suppose this is the most important disadvantage? Is there any published work or code using this approach, or something like it, in a pure functional language? I'm primarily interested in embedded system and desktop UIs, rather than say web-based systems, although both would be interesting. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poor libraries documentation
On Wed, 30 Jan 2008 13:15:41 + Jules Bean <[EMAIL PROTECTED]> wrote: > Neil Mitchell wrote: > > For a start, its probably a good idea to mention that cos is an > > abbreviation of cosine (most people will know, but its handy to > > state it). Secondly, and much more importantly, it should state > > whether these measurements are in degrees or radians. It should > > also state things like acos is the inverse of cos - its been a > > while since I last used trig and I had to look it up!!! > > I imagine the laziness here was because these all match their names > in the traditional libc, accessable via manpages. Neil is on Windows. Windows doesn't have man pages (or libc). -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why functional programming matters
On Thu, 24 Jan 2008 10:29:23 -0600 Derek Elkins <[EMAIL PROTECTED]> wrote: > Doing it in the IDE would a) require much more from most IDEs and b) > be almost entirely useless. Most IDEs don't even get as far as > parsing the code, even the the best rarely know much about the actual > semantics of the language. This would require a rather deep analysis > and ultimately it is undecidable. Practically speaking, having such > a feature in the IDE would be useless unless the programming style of > most "imperative" programmers changed dramatically. The only > functions such an analysis would say were pure are those that were > rather trivial. Either way, having such a feature in the IDE doesn't > really help. A purity checker in the IDE isn't going to help when > the function/method is unknown, e.g. when I write a function/method > that takes a function or an object. A "purity annotation" would have > to be at the language level, short of doing a whole-program analysis > which would be infeasible. Indeed - JML (Java Modelling Language) takes exactly this approach. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A "commutative diagram" conjecture about applicative functors
I am proving various statements relating to applicative functors, using the Coq proof assistant (I am considering only Coq terms, which always terminate so you don't have to worry about _|_). However, I'm not sure how to go about proving a certain conjecture, which, translated back into Haskell and made more specific to make it easier to think about, looks like this (assuming Control.Applicative and Control.Arrow are imported): "For all applicative functors: \f x -> fmap second f <*> fmap ((,) (0::Int)) x is equivalent to \f x -> fmap ((,) (0::Int)) (f <*> x)" McBride and Patterson give four laws for applicative functors in their paper "Functional Pearl: Applicative programming with effects". Can these laws be used to prove this conjecture for all applicative functors satisfying those laws? -- Robin P.S. I realise this might not look like a "commutative diagram conjecture", but as I said, I've made it more specific - my actual conjecture is more general, but hopefully if I can understand how to prove the specific one, I'll be able to prove my real one in short order. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is StateT what I need?
On Mon, 17 Dec 2007 16:04:24 -0500 "Brandon S. Allbery KF8NH" <[EMAIL PROTECTED]> wrote: > > On Dec 17, 2007, at 15:41 , Brent Yorgey wrote: > > > Yes, and in fact, you don't even need foldM. The only thing that > > actually uses IO is the readFile, so ideally > > Actually, a quick check indicates that the regex functions used in > getProcInfo are in IO as well (?!). That's because they're implemented in C, and anything implemented in C is potentially impure. Although, I'd have thought that they'd *actually* be pure. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] #haskell works
On Sat, 15 Dec 2007 21:46:43 +0300 Bulat Ziganshin <[EMAIL PROTECTED]> wrote: > you may believe in what you want. i prefer to say about real > situation. if it will be possible to quickly write good Haskell > compiler, it was be written many years ago No-one is writing a commercial Haskell compiler yet (although there is at least one commercial Haskell-like language). What I mean is, the amount of "commercial-oriented" funding spent on GHC (as opposed to the "research-oriented" funding spent by Microsoft Research and various research bodies) is, as far as I know, zero. Incentives matter. If there were a commercial Haskell compiler, maybe we would see faster progress. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Modelling a mutable variable store
On Sat, 01 Dec 2007 21:22:53 -0600 Derek Elkins <[EMAIL PROTECTED]> wrote: > > There's also the issue of finding a more elegant way of threading > > the Store through my evaluator, but I'm not concerned too much > > about that at this point. I can probably define a state-carrying > > monad like Parsec. My real concerns are the first two issues. > > Use ST. First-class state isn't too great unless you specifically > want that. Or use IO - that way you can use a Hashtable for looking up identifiers. Although, better still is to convert variable references into Ints, instead of using a Hashtable. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] let vs. where
On Tue, 13 Nov 2007 13:51:13 -0800 "Dan Piponi" <[EMAIL PROTECTED]> wrote: > Up until yesterday I had presumed that guards only applied to > functions. But I was poking about in the Random module and discovered > that you can write things like > > a | x > 1 = 1 > | x < -1 = -1 > | otherwise = x > > where 'a' clearly isn't a function. Isn't it a function taking zero arguments? -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange Type Inference
On Mon, 5 Nov 2007 21:37:16 + (GMT) "C.M.Brown" <[EMAIL PROTECTED]> wrote: > Is there a way to give lookup0 and lookup1 explicit type signatures > without passing in m0 and m1 as parameters? (So their definitions are > the same as in the first example) If ghc can infer the type, surely > it must be possible? http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#scoped-type-variables -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compile-time evaluation
On Fri, 2 Nov 2007 05:11:53 -0500
"Nicholas Messenger" <[EMAIL PROTECTED]> wrote:
> -- Many people ask if GHC will evaluate toplevel constants at compile
> -- time, you know, since Haskell is pure it'd be great if those
> -- computations could be done once and not use up cycles during
> -- runtime. Not an entirely bad idea, I think.
I implemented the same idea. First a note about nomenclature: since
there is a Template Haskell class for the concept of "translating actual
values into TH representations of those values" called Lift, I call that
"lifting"; I also call evaluating and storing top-level constants at
compile time "baking them into the executable".
>From glancing at your code, my approach has two main differences
(apart from the fact that I didn't implement support for all of the
types that you did):
1. A generic lifter using Data.Generics does not work for certain
types, like IntSet. So I implemented the Template Haskell class Lift
for each of my own data types that I wanted to use in lifting, and
where it would work, called my generic lifter function, otherwise
lifted it more manually (as shown below).
2. I used synthesise instead of gmapQ, and did not use an intermediate
Tree data structure.
Here is the module which does most of the work. (You will not be able to
compile this as-is, obviously, because I have not published the rest of
my code yet.)
{-# OPTIONS_GHC -fglasgow-exts -fallow-overlapping-instances
-fallow-undecidable-instances -XTemplateHaskell #-}
module Language.Coq.Syntax.AbstractionBaking where
import Data.Generics.Basics (ConstrRep(..), constrRep, Data, toConstr,
Typeable)
import Data.Generics.Schemes (synthesize)
import Data.List (foldl')
import Data.IntSet (IntSet)
import qualified Data.IntSet as IntSet (fromList, toList)
import Data.Set (Set)
import qualified Data.Set as Set (fromList, toList)
import Language.Haskell.TH.Lib (appE, charL, conE, ExpQ, infixE,
integerL, litE)
import Language.Haskell.TH.Syntax (Lift(..), mkName)
import System.FilePath (())
import Data.DList (DList)
import Data.ListLike (fromList, ListLike, toList)
import Language.Coq.Parser (CoqParserState(..))
import Language.Coq.Syntax.Abstract (CoqState(..), Sentence, Term)
import Language.Coq.Syntax.Concrete (NotationRec(..))
import Language.Coq.Syntax.ParseSpec
lifter :: Data d => d -> ExpQ
lifter = head . synthesize [] (++) combiner
where
combiner x args = [case rep of
IntConstr i -> litE $ integerL i
AlgConstr _ -> algebraic (show constr) args
StringConstr (h:_) -> litE $ charL h
_ -> fail $ "Unimplemented constrRep: " ++
show rep]
where constr = toConstr x
rep = constrRep constr
algebraic "(:)" = cons
algebraic name = foldl' appE $ conE $ mkName name
cons [] = [e| (:) |]
cons [left] = infixE (Just left) (cons []) Nothing
cons [left, right] = infixE (Just left) (cons []) $
Just right
instance Lift NotationRec where
lift (NotationRec w x y z)
= appE (appE (appE (appE [| NotationRec |] $ lift w) $ lift x)
$ lift y) $ lift z
instance Lift ParseSpecTok where
lift = lifter
instance Lift Associativity where
lift = lifter
instance Lift Sentence where
lift = lifter
instance Lift Term where
lift = lifter
instance Lift CoqState where
lift (CoqState x y) = appE (appE [| CoqState |] $ lift x) $ lift y
instance Lift CoqParserState where
lift (CoqParserState x y z) = appE (appE (appE [| CoqParserState |]
$ lift x) $ lift y) $ lift z
instance (Lift a, ListLike full a) => Lift full where
lift = appE [| fromList |] . lift . toList
instance Lift IntSet where
lift = appE [| IntSet.fromList |] . lift . IntSet.toList
instance Lift a => Lift (Set a) where
lift = appE [| Set.fromList |] . lift . Set.toList
--
Robin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why can't Haskell be faster?
On Wed, 31 Oct 2007 14:17:13 + Jules Bean <[EMAIL PROTECTED]> wrote: > Specifically, clean's uniqueness types allow for a certain kind of > zero-copy mutation optimisation which is much harder for a haskell > compiler to automatically infer. It's not clear to me that it's > actually worth it, but I think that's the point at issue. I can > *imagine* algorithms in which copying is actually faster than > mutation, if copying gives you better locality. If you want in-place update in Haskell, you can use the ST monad, or IORefs. Yes, you have to refactor code, but anecdotally, uniqueness types aren't without problems either - you can make one small change and your code no longer satisfies the uniqueness condition. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parse error on input "|"
You neglected a ) - remember to count your parentheses in future when you get an error directly after a parenthesised expression. -- Robin On Thu, 31 May 2007 08:09:23 -0700 (PDT) Akijmo <[EMAIL PROTECTED]> wrote: > > Hi everyone. > I am new to this Forum, Haskell and i am german, so i am sorry for > "noob" failures or spelling mistakes. > > I am currently learning for an informatic exam (11th class) and i > tried to code a function to sum a polynom with a pair of polynoms... > (I actually want to to code a polynomdivision in which i need this) > > But I get the parse error mentioned in the headline. It is referring > to the first line of the case differentiation. > Hopefully you can help me, here's the code: > > polyplusd :: Polynom -> (Polynom, Polynom) -> Polynom > polyplusd [] p = p > polyplusd p [] = p > polyplusd p@((g1,e1):p1) (n, (q@((g2,e2):p2)) > | g1>g2 = (g1,e1):(polyplusd p1 (n,q)) > | g2>g1 = (g2,e2):(polyplusd p (n,p2)) > | g1==g2 && e1+e2 /=0 =(g1, > e1+e2):(polyplusd p1 (n,p2)) | otherwise = polyplusd p1 (n,p2) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Frisby grammars that have context
On Tue, 29 May 2007 19:28:02 -0400 Isaac Dupree <[EMAIL PROTECTED]> wrote: > Luckily, Haskell's laziness means that doing an extra "postprocessing > pass" doesn't necessarily yield two traversals requiring the whole > file to be stored in memory, nor worse hacks. (For grammars that > aren't too wild / sequential) But the suggested code fragment on the frisby homepage: -- parse complete file, returning 'Nothing' if parse fails fmap Just (myParser <<- eof) // unit Nothing does require one traversal of the file all by itself. Obviously, in order to know whether the file was fully parsed without error, you need to read in the whole file, before you can write out anything. Hence you end up with *some* representation of the whole file in memory. So, yes, it doesn't necessarily yield two traversals, but you need to be careful if you want to avoid two traversals. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] instance Monad AppF - Faster than the list monad?
The following Haskell 98 module implements a generalisation of
Prelude.ShowS for any type. Should be pretty easy to incorporate this
into code which currently uses the list monad non-trivially, and get
better performance - but can this be right? Surely someone would have
published this before if that was true? I haven't actually done any
performance tests. Anyway, with this module you end up using function
composition instead of list concatenation - except when converting from
a list.
module Data.List.AppF where
import Control.Monad (MonadPlus (mplus, mzero), msum)
-- Generalisation of ShowS
newtype AppF a = AppF { unAppF :: [a] -> [a] }
instance Monad AppF where
(>>=) = (msum .) . flip map . appFToList
return = AppF . (:)
instance MonadPlus AppF where
mzero = AppF id
mplus x y = AppF $ unAppF x . unAppF y
-- Use this to convert Maybe a into AppF a, or indeed any other
-- MonadPlus instance.
maybeToMonadPlus :: MonadPlus m => Maybe a -> m a
maybeToMonadPlus = maybe mzero return
listToAppF :: [a] -> AppF a
listToAppF = AppF . (++)
appFToList :: AppF a -> [a]
appFToList = ($ []) . unAppF
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New book: Real-World Haskell!
On Fri, 25 May 2007 19:39:19 +0100 "Neil Mitchell" <[EMAIL PROTECTED]> wrote: > http://darcs.haskell.org/darcsweb/darcsweb.cgi?r=yhc;a=summary - most > things on haskell.org have a darcsweb, thats the one for Yhc. > > Plus I suspect that darcs will be discussed in the book, for building > a library, in which case its only sensible to dogfood your own stuff. > Not that darcs is dogfood, more like a chocolate cake :) *puts on flameproof suit* Not really, due to the whole "bug #1" thing (broken merging). -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell wiki indexing
On Tue, 22 May 2007 15:05:48 +0100 Duncan Coutts <[EMAIL PROTECTED]> wrote: > On Tue, 2007-05-22 at 14:40 +0100, Claus Reinke wrote: > > > so the situation for mailing lists and online docs seems to have > > improved, but there is still the wiki indexing/rogue bot issue, > > and lots of fine tuning (together with watching the logs to spot > > any issues arising out of relaxing those restrictions). perhaps > > someone on this list would be willing to volunteer to look into > > those robots/indexing issues on haskell.org?-) > > The main problem, and the reason for the original (temporary!) measure > was bots indexing all possible diffs between old versions of wiki > pages. URLs like: > > http://haskell.org/haskellwiki/?title=Quicksort&diff=9608&oldid=9607 > > For pages with long histories this O(n^2) number of requests starts to > get quite large and the wiki engine does not seem well optimised for > getting arbitrary diffs. So we ended up with bots holding open many > http server connections. They were not actually causing much server > cpu load or generating much traffic but once the number of nearly hung > connections got up to the http child process limit then we are > effectively in a DOS situation. > > So if we can ban bots from the page histories or turn them off for the > bot user agents or something then we might have a cure. Perhaps we > just need to upgrade our media wiki software or find out how other > sites using this software deal with the same issue of bots reading > page histories. http://en.wikipedia.org/robots.txt Wikipedia uses URLs starting with /w/ for "dynamic" pages (well, all pages are dynamic in a sense, but you know what I mean I hope.) And then puts /w/ in robots.txt. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] global variables
On Thu, 17 May 2007 14:41:33 +0100 Eric <[EMAIL PROTECTED]> wrote: > H|i, > > Does anyone know of a simple and straightforward way to use global > variables in Haskell? > > E. Another alternative, for "write-once variables", is implicit parameters. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] "Recent content is available under a simple permissive license"
The Haskell wiki[1] says "Recent content is available under a simple permissive license". But this is unilluminating - recent? how recent, exactly? - and will become increasingly understated as time goes by. Wouldn't it be slightly more helpful to say "Content added after " ... /MM/DD ... " is available under a simple permissive license"? -- Robin [1] http://www.haskell.org/haskellwiki ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad definition question
On Fri, 04 May 2007 14:42:53 +0300 Ilya Tsindlekht <[EMAIL PROTECTED]> wrote: > Does the definition of monad silently assume that if f and f' are > equal in the sense that they return the same value for any argument o > correct type then m >>= f = m >>= f' How could it be otherwise? How are you going to distinguish between f and f' if they are indistinguishable functions, in Haskell? > More specifically, the definition says x >>= return = x. How does one > justify from this that x >>= (return . id) = x? > > Are values of type a -> b in general assumed to be maps from the set > of values of type a into the set ov values of type b? Yes - if _|_ is considered to be a value. > (What bothers > me is that the problem whether two lambda-expressions define the same > map is clearly undecidable.) Yes. But this is a fundamental mathematical issue which isn't at all specific to Haskell, of course. It suggests using some sort of intensional type theory, so that you have to explicitly prove lambda expressions to be equal. > More generally, is some kind of logic without equality more > appropriate for formalisation of Haskell then the usual kind(s) of > logic with equality? I suggest you look into Observational Type Theory. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] run-time type testing in haskell?
On Sat, 28 Apr 2007 14:06:21 +0100 Eric <[EMAIL PROTECTED]> wrote: > In imperative languages one can test the type of a variable and > downcast if necessary. Here's an example in Pseudojava: > > T v := ... ; > if (v instanceof T') T' v' := (T')v In object-oriented languages you can achieve the same effect by defining a method on each type which has different behaviour depending on the type. In Haskell you can achieve much the same effect by defining methods in typeclasses and then defining instances for types. It's quite analogous. This is the recommended way of doing it in Haskell. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question: template-haskell and profiling
As a workaround, you could try to use zeroTH to preprocess the template
haskell. (I have a patched version of zeroTH that works better but it
currently requires a patched version of GHC - ask me if you want it.)
ZeroTH darcs repo: http://darcs.haskell.org/~lemmih/zerothHead/
Original announcement by Lemmih:
http://permalink.gmane.org/gmane.comp.lang.haskell.template/219
--
Robin
On Fri, 27 Apr 2007 20:26:21 +0700
"ET" <[EMAIL PROTECTED]> wrote:
> Hi, folks
>
> Trying to profile the modules, those contain a template-haskell
> splices, I have ran into problem - GHC6.4 (win2K) returns an error
> message and then stops. Without the "-prof" option all works fine.
>
> Is there a way to bypass this inconsistency?
>
>
> Example below illustrates the problem:
>
>
>
> {-# OPTIONS_GHC -fth #-}
> module Main where
>
> import MainTH
>
> main :: IO ()
> main = putStrLn . show . fact $ 100
>
> fact :: Integer -> Integer
> fact n = $(thFact "n")
>
>
>
> module MainTH where
>
> import Language.Haskell.TH
>
> thFact :: String -> ExpQ
> thFact s = appE (dyn "product")
> (arithSeqE (fromToR (litE . integerL $ 1) (dyn s)))
>
> preview :: IO ()
> preview = runQ (thFact "x") >>= putStrLn . pprint
>
>
>
> >ghc --make -prof Main.hs
> Chasing modules from: Main.hs
> Compiling MainTH ( ./MainTH.hs, ./MainTH.o )
> Compiling Main ( Main.hs, Main.o )
> Loading package base-1.0 ... linking ... done.
> Loading package haskell98-1.0 ... linking ... done.
> Loading package template-haskell-1.0 ... linking ... done.
> ghc:
> ./MainTH.o: unknown symbol `_era'
>
> With function "MainTH.preview" excluded from export list, final
> phrase were ghc:
> ./MainTH.o: unknown symbol `_entering_PAP'
>
>
>
>
>
> ___
> 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] Poor first impression
On Fri, 27 Apr 2007 07:00:26 -0300
"Fernando Cassia" <[EMAIL PROTECTED]> wrote:
> But just think about it... is it easier to DOCUMENT the problem or
> just include a workaround in the make install code?
It's easier to document the problem.
> IF {library not available} then
> echo "you need to get asdfzxcv lib. before the compiler will work.
> please use yum or apt-get"
Virtually no other open source project does this, in my experience.
It's better just to use yum in the first place, and only if that
doesn't work, try the tarballs.
--
Robin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Obscure instances for Obscure types
On Fri, 27 Apr 2007 00:40:33 +0100 "Neil Mitchell" <[EMAIL PROTECTED]> wrote: > > If it's too annoying to wait for that inevitability, try commenting > > the hell out of it until it has a respectable number of lines. > > Comments are for people who can't sense what their code does from the > indentation :-) A bit of an exaggeration. I've written points-free code that *needs* comments in order for *me* to understand it six months later. ;) > That and Haddock doesn't let you comment instances in > any way that shows up, so all my beautiful comments would be lost. Yes, but you can still comment the module that contains them, which does show up, and manually list the instances. Since the number of instances is so small, this isn't hard. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is Template Haskell a suitable macro language?
On Tue, 24 Apr 2007 14:23:47 +0100
Joel Reymont <[EMAIL PROTECTED]> wrote:
> I'm finding myself dealing with several large abstract syntax trees
> that are very similar in nature. The constructor names would be the
> same or one type may be a small extension of another.
>
> This is something that I wouldn't worry about with Lisp, for
> example, as I would create a bunch of macros for creating syntax
> trees and reuse them all over. I cannot do this in Haskell, though,
> as my "macros" are functions and so I must repeat them for every AST
> since they return different types.
>
> I'm wondering if Template Haskell is a suitable replacement for Lisp
> macros.
>
> What is the consensus?
I saw your earlier post on abstract syntax trees, and I have indeed
been using Template Haskell for processing syntax trees. (Sorry I
didn't reply earlier.) It works quite well, yes.
Here's my success story. Basically I have two modules, Abstract and
Concrete, which define data types for abstract and concrete syntax
respectively. The Abstract module also contains code to convert
concrete syntax (i.e. what comes out of the parser) into abstract
syntax, and the code that just does copying (i.e. the boilerplate code)
is generated by Template Haskell code.
What I do looks like this:
$(let
preprocess :: [Dec] -> Q [Dec]
-- definition omitted
in preprocess =<<
[d|type Param = (Ident, Term)
data FixBody = FixBody Ident [Param] (Maybe Annotation)
(Maybe Term) Term deriving (Typeable, Data, Eq)
data MatchItem = MatchItem Term (Maybe Ident) (Maybe Term)
deriving (Typeable, Data, Eq)
data IdentWithParams = IdentWithParams Ident [Param] (Maybe
Term) deriving (Typeable, Data, Eq)
class Abstraction c a {- | c -> a -} where { abstractL ::
Monad m => c -> StateT [(Ident,Term)] m a }
#include "common2.inc"
|])
Let me explain what's going on here, starting from the bottom. The
order of these parts is very important! The #include "common2.inc"
includes the type definitions which are common to both modules. (I
actually maintain a file "common.inc" and then that is preprocessed to
replace newlines with semicolons, in order to avoid the problem that
would otherwise occur that the file would be included at the wrong
identation level. Although the file is still included at the wrong
indentation level, apparently the use of semicolons mollifies ghc!) The
reason why I don't just put the stuff in common2.inc into another
module is because it refers to types that are defined *differently* in
each syntax! So I really am using cpp [actually, cpphs] for an
appropriate purpose here.
The class Abstraction defines a method abstractL. It is defined for
every concrete syntax data type and specifies how to translate that
type into abstract syntax (except the top-level which is handled
differently). The fundep is commented out because (a) ghc rejected it
and (b) I didn't need it anyway.
The preprocess function then takes all of the decls between [d| and |]
as input, passes through the declarations before the class declaration
(i.e. the ones that are not the same) without looking at them any
further, and then generates instances of the class for each data
declaration given below the class (i.e. all the types which are in
common, where only automatic copying code needs to be generated). It
also passes through all of the declarations given as input.
Why not simply put the initial declarations at the top of the file?
Well, ghc rejects that, if I remember correctly, because they refer to
other types which have yet to be generated (well, passed through) by
Template Haskell. Template Haskell seems to break the general principle
in Haskell that one can refer to a declaration in the same module,
textually before that declaration.
--
Robin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Safe lists with GADT's
On Mon, 26 Feb 2007 17:28:59 -0800 (PST) [EMAIL PROTECTED] wrote: > The problem with GADTs and other run-time based evidence is just > that: _run-time_ based evidence and pattern-matching. In a non-strict > system, checking that the evidence is really present is the problem on > and of itself. That's a problem in any system that does not have both termination checking and exhaustive coverage checking. In this presence of both those checks, laziness is not a problem. > BTW, Omega, Dependent ML and a few other systems with > GADTs are strict. Omega does not yet have termination checking AFAIK, and Dependent ML has a more limited type language. Coq does have termination checking, and Neil Mitchell is working on a case-and-termination checker for Haskell. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's wrong with "cgi-undecidable"?
On Sat, 10 Feb 2007 23:37:04 +0100 Bjorn Bringert <[EMAIL PROTECTED]> wrote: > I've also recently changed the version number scheme on most of the > packages I maintain (which includes most of the packages required by > Hope) from a date-based one to a major.minor scheme. This has the > unfortunate side-effect of making newer versions have smaller > version numbers than older ones, but it felt silly to start with a > major version number of 2008. That might have been a bad decision. The rPath Linux package management tool, conary, has a nice solution to the problem that software version numbers have inconsistent lexical ordering conventions between projects and sometimes within the same project. It does not compare version numbers at all, and (as far as I can tell) asks the package repository for the most recent package, unless you specify a particular version. Perhaps Cabal could do something similar? Of course, this way you can't express "I want version >= 1.2" which is kind of a bummer. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GADTs are expressive
On Mon, 8 Jan 2007 08:51:40 -0500 "Jim Apple" <[EMAIL PROTECTED]> wrote: > The Terminating datatype takes three parameters: > 1. A term in the untyped lambda calculus > 2. A sequence of beta reductions > 3. A proof that the result of the beta reductions is normalized. > > Number 2 is the hard part. For a term that calculated the factorial of > 5, the list in part 2 would be at least 120 items long, and each one > is kind of a pain. > > GHC's type checker ends up doing exactly what it was doing before: > checking proofs. Well, not really - or not the proof you thought you were getting. As I am constantly at pains to point out, in a language with the possibility of well-typed, non-terminating terms, like Haskell, what you actually get is a "partial proof" - that *if* the expression you are demanding terminates, you will get a value of the correct type. If it doesn't, you won't get what you wanted. (Unlike in say Coq, where all functions must be proved to terminate - modulo a recently-discovered bug.) What this means is that you can supply e.g. "undefined" in place of (2) or (3) and fool the typechecker into thinking that (1) terminates, when it doesn't. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Features of Haskell
On Sun, 4 Jun 2006 11:21:23 +0200 Niels Van Och <[EMAIL PROTECTED]> wrote: > However, I'd love to know what you think. Furthermore, do you think > I should include an example on the usage of Haskell, and if so, which? I have an idea. Find some real code in another language which uses lots of state - so much state, in fact, that it's a pain to unit test or debug the code because you have to set up lots of state. Then, sketch an outline of how this code could be rewritten into Haskell, so that state updates are contained within monads or eliminated altogether, and perhaps separating the different tasks the code does into different functions. Then illustrate how this can make testing and debugging easier. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Pragmatic concurrency Re: [Haskell-cafe] multiple computations, same input
On Wed, 29 Mar 2006 12:50:02 +0100
Jon Fairbairn <[EMAIL PROTECTED]> wrote:
> There are some observations I'd like to make, and a
> proposal. Since the proposal relates (in a small way) to
> concurrency and is, I think worthwhile, I've cc'd this
> message to haskell-prime.
>
> 1) choosing the optimal reduction strategy is undecidable
>
> 2) we shouldn't (in general) attempt to do undecidable
>things automatically
>
> 3) Separation of concerns: Pragmatic decisions about
>evaluation order should be kept separate from the
>denotational aspect of the code. By this token, seq
>shouldn't be a function (because it isn't one), but a
>pragma. The fact that it's shorter to write seq a b than
>{-# SEQ a #-} b is a matter of syntax, so shouldn't rate
>highly in language design decisions. Perhaps we want a
>different syntax for this kind of pragma, but that's a
>side issue.
I don't like pragmas because (at least in C) they are defined to be
optional and can be ignored by the compiler. We need optimisation
methods that work across all Haskell implementations (of a given
Haskell standard).
I suggest that a Haskell program should be treated as an executable
specification. In some cases the compiler can't optimise the program
well enough, so we (by which I mean, ordinary programmers, not compiler
geeks) should be able to explicitly provide our own optimisations, as
rewrite rules (generalised ones, or specialised ones for individual
functions). Democratise the means of automated optimisation! Then we
should be able to prove formally that our rewrite rules preserve
functional correctness. This is the approach I am pursuing in the
programming language I am working on, which is a derivative of Haskell.
(In principle you could write rewrite rules in Template Haskell, but I
don't know if anyone has tried that.)
This way of looking at it is nice, because then we don't have to shut
off whole avenues of fruitful thought, on the grounds of "Oh no, the
compiler is far too stupid to do that", or "Oh no, that's far too much
of a special case for this particular example, and it would bloat the
compiler too much to include little things like this".
The way I would optimise the wc example in my language is as follows:
First translate it into a monadic pipeline in the State monad:
wc = evalState $ do
w <- passthru (length . words)
l <- passthru (length . lines)
c <- passthru length
return (w,l,c)
where
passthru = gets
Then convert that monadic action into a semi-lazy imperative pipeline on
lists (semi-lazy because the pipeline is evaluated lazily, but the
side-effects of the pipeline are evaluated strictly - or something
like that - I have difficulty explaining it). This is too involved to go
into here (and I haven't worked out the details of the rewrite rules
yet), but the basic idea looks like this pseudo-shell-script:
words -output w | lines -output l | length -output c >/dev/null
echo "(`cat w`, `cat l`, `cat c`)"
rm -f w l c
Each command in the first line of this pseudo-shell-script copies its
list from standard input to standard output, and stores its result in a
temporary file named by the -output option. (Obviously, in the real
code, temporary files wouldn't be used, and nor would operating system
pipes be used - I just found them convenient in order to analogise my
solution as a shell script.)
Despite the apparent waste of copying a list three times, this is
actually more efficient than the original code because it doesn't need
to store any lists in memory.
There might be better ways to do it, but that's just an idea off the top
of my head.
--
Robin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] First Question
> > Cheers everyone - if i have blatantly > > missused this mailing list just email me some abuse. Perhaps you should be asking your teacher this question? I'm sure s/he'd be very happy with you using the list to get other people to do parts of your homework for you. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Decidable type systems? (WAS: Associated TypeSynonyms question)
Miles Sabin <[EMAIL PROTECTED]> wrote: > Can someone explain to me why decidability is of any practical > interest at all? procedure which might never terminate and one which might > take > 1,000,000 years to terminate? Actually, why push it out to 1,000,000 > years: in the context of a compiler for a practical programming > language, a decision procedure which might take an hour to terminate > might as well be undecidable But are there any decidable type checking algorithms that have been seriously proposed or used which would take far too long to terminate for real code? If not, then decidability is the only thing that matters. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re[2]: strict Haskell dialect
On Fri, 3 Feb 2006 19:33:12 -
"Brian Hulley" <[EMAIL PROTECTED]> wrote:
> I've been thinking along these lines too, because it has always
> seemed to me that laziness is just a real nuisance because it hides a
> lot of inefficiency under the carpet as well as making the time/space
> behaviour of programs difficult to understand...
>
> One question is how to get some kind of "do" notation that would work
> well in a strict setting.
> The existing "do" notation makes use of lazyness in so far as the
> second arg of >> is only evaluated when needed. Perhaps a new
> keyword such as "go" could be used to use >>= instead ie:
>
> go {e1;e2;e3} === e1 >>= (\_-> (e2 >>= (\_->e3)))
That's not necessary. >> has something in common with if', where
if' True x _ = x
if' False _ y = y
- in both cases, it makes sense to evaluate the arguments lazily.
So simply make strictness the default and have laziness annotations
(for arguments), instead of making laziness the default and having
strictness annotations.
> A related question is: could monadic programming ever be as efficient
> as side-effect programming?
Monads can be viewed as code generators. So, with partial
evaluation, my guess is yes, at least in many important cases.
--
Robin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] formal methods & functional programming
Lennart Augustsson wrote: Robin Green wrote: 2. Dependent types: By programming in a dependently-typed functional programming language such as the research language Epigram, it is possible to write functional programs whose types force them to be correct. See for example "Why Dependent Types Matter" by Thorsten Altenkirch, Conor McBride, and James McKinna. However, in my opinion this is only useful for simple "sized types" such as "a list of length 6". For more complicated properties, I believe this approach is unnecessarily difficult, and does not match how mathematicians or programmers actually work. My approach (see above) clearly separates the programming, the theorems and the proofs, and (in principle) allows all three to be written in a fairly "natural" style. As opposed to dependent types which, in Epigram at least, seem to require threading proofs through programs (for some non-trivial proofs). I would just like to point out that there is nothing that forces you to "thread" the proofs through the programs. With dependent types you have this option, but you can also write standard "Haskell" code and have your proofs be separate. But wouldn't that alternate way break the principle, recommended by Cardelli, that all code should be well-typed and the types of all terms should be, shall we say, "plainly" deducible from the code alone (i.e. not requiring any "difficult" reasoning on the part of the human reader)? If not, could you give an example to illustrate your point? It's up to you to choose which way you do things. (If you do separate proofs you can even add some construct to the logic that makes it classical if you like.) Furthermore, I don't see such a clear separation between your points 1 and 2. With dependent types you are making proofs and then using them as programs. How much extraction you do is a matter of optimization, I'd say. And how efficient the extracted program is depends on which proof you choose to do. Well I thought someone might say something like that - which is why I called them "angles" on the question. :) But while statements about types and statements about values might be inter-convertable, I think they look different and one can be more convenient than the other for various purposes. I've only used dependent types trivially so I could be wrong. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] formal methods & functional programming
Abigail wrote: Hi, I have been searching papers about tha raltionship between formal methods in software engineering and functinal programmming, but i haven't found enough information. Functional programming in pure functional languages like Haskell can help to make programs easier to reason about - but it doesn't _remove_ the need for formal methods. For example, there are laws about certain classes such as Monad and Monoid which all instances of those classes must follow in order to be considered "proper" Monads or Monoids. However, in order to reason about functions defined over all Monads (say), we need to know that those laws hold for _all_ possible Monads (without laws, we don't really know anything about the methods of Monad - in a non-strict language, the methods might not even be well-defined for certain inputs). But Haskell doesn't even have a way to _state_ these laws formally, much less _prove_ them! I am working on a functional programming and specification language in my spare time which does have such formal methods features built-in, but it is not even implemented yet. (I can email you if I ever write a paper on it, but it may be some years before that happens.) However, there are various other angles which you can research: 1. Proofs as programs: _Constructive_ proofs of theorems can be automatically converted into programs in a functional programming language - although these programs are not always efficient. Indeed it is possible that a generated program will be far too inefficient to be useful. See for example "Proofs, Programs and Executable Specifications in Higher Order Logic", a Phd thesis by S Berghofer at http://www4.in.tum.de/~berghofe/papers/phd.pdf 1a. Models as functional programs: The very first sentence in Chapter 1 of the thesis I just cited, says: "Interactive theorem provers are tools which allow [one] to build abstract system models, often in some kind of functional programming language involving datatypes and recursive functions." 2. Dependent types: By programming in a dependently-typed functional programming language such as the research language Epigram, it is possible to write functional programs whose types force them to be correct. See for example "Why Dependent Types Matter" by Thorsten Altenkirch, Conor McBride, and James McKinna. However, in my opinion this is only useful for simple "sized types" such as "a list of length 6". For more complicated properties, I believe this approach is unnecessarily difficult, and does not match how mathematicians or programmers actually work. My approach (see above) clearly separates the programming, the theorems and the proofs, and (in principle) allows all three to be written in a fairly "natural" style. As opposed to dependent types which, in Epigram at least, seem to require threading proofs through programs (for some non-trivial proofs). 3. Separate formal methods tools for Haskell: My approach is to integrate formal methods directly into the essential core of a language, but this is quite unusual to say the least - a more normal thing to do (whether for functional or imperative languages) is prepare a separate formal methods tool for an existing programming language. This has been done for Haskell - see "Verifying haskell programs using constructive type theory" by Abel et. al. at http://portal.acm.org/citation.cfm?id=1088348.1088355 I have not considered testing in this email because another email already mentioned QuickCheck. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Expanding do notation
David F. Place wrote: Hi All, Is there a program for expanding 'do' notation? I am trying to understand why the following code (from the Fannkuch entry) doesn't hold onto the list 'p' causing a space leak. You can desugar (i.e. expand) the do notation relatively easily, but that won't tell you what optimisations are being performed (e.g. code rearrangements) if any. Of course the compiler can't perform IO actions in the wrong order - but it can in principle generate code which generates a value from p early on, and then p can be garbage collected. I have no idea whether that's what's happening here, though. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
