Re: [Haskell-cafe] Haddock Markup
Am Mittwoch, 11. Februar 2009 22:38 schrieben Sie: On 12 Feb 2009, at 1:40 am, Wolfgang Jeltsch wrote: Am Mittwoch, 11. Februar 2009 00:46 schrieben Sie: I suppose I should point out what seems obvious to me, which is that one could embed a substantial chunk of MathML (possibly all of it) in TeX. I mean, give it a TeX-parseable syntax. You can convert MathML into TeX but not the other way round. How would you translate $a \odot b \otimes c$? It depends on the precedence of the operators. And the point of that is? What I suggested is the way around that works. And the point of my suggestion was that one could have something that could be embedded directly in a (La)TeX document *or* processed by Haddock: no changes when copying from one document to another means fewer new mistakes. I don’t understand this. The way which works is conversion from MathML to TeX. So your suggestion would be to use MathML as the source language. But this is obviously not what you suggest. I’m confused. If you want to use a subset of TeX in Haddock comments, how would you render them on a webpage? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
Am Mittwoch, 11. Februar 2009 20:45 schrieb Gwern Branwen: Here are the projects I favor (in no particular order): […] * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); this could possibly be based on TortoiseDarcs http://tortoisedarcs.sourceforge.net/. Perhaps the specific project could be making TortoiseDarcs not Windows specific? I plan to start writing a GUI interface to darcs together with some of our students. (However, we don’t want to base it on TortoiseDarcs.) So if you have ideas of what features such an interface should have, please write me quickly. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Changing version numbering schemes for HackageDB packages?
Am Mittwoch, 11. Februar 2009 23:02 schrieb Corey O'Connor: The way I read changes in version numbers for a scheme using the format X.Y.Z is: * A change in Z indicates bug fixes only * A change in Y indicates the interface has changed but not in an incompatible way. For instance, maybe a new method was added. * A change in X indicates the interface has changed in a way that could be incompatible with software that depended on a previous version of the library. Note that Haskell’s package versioning policy [1] assigns your meaning of Z to the 4th component of the version, your meaning of Y to the 3rd and your meaning of X to the pair of the 1st and the 2nd component. Best wishes, Wolfgang [1] http://haskell.org/haskellwiki/Package_versioning_policy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org GSoC
Am Mittwoch, 11. Februar 2009 18:51 schrieb Don Stewart: For example, if all the haddocks on hackage.org were a wiki, and interlinked, every single package author would benefit, as would all users. You mean, everyone should be able to mess about with my documentation? This would be similar to give everyone commit rights to my repositories or allow everyone to edit the code of my published libraries. What is the good thing about that? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell.org GSoC
Am Donnerstag, 12. Februar 2009 09:20 schrieb Achim Schneider: Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Mittwoch, 11. Februar 2009 18:51 schrieb Don Stewart: For example, if all the haddocks on hackage.org were a wiki, and interlinked, every single package author would benefit, as would all users. You mean, everyone should be able to mess about with my documentation? This would be similar to give everyone commit rights to my repositories or allow everyone to edit the code of my published libraries. What is the good thing about that? The fact that you can mark a revision to be the official one and, in case you e.g. have a wiki yourself, disable the hackage wiki? What do you mean by “disabling the Hackage wiki”? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org GSoC
Am Donnerstag, 12. Februar 2009 09:15 schrieben Sie: g9ks157k: Am Mittwoch, 11. Februar 2009 18:51 schrieb Don Stewart: For example, if all the haddocks on hackage.org were a wiki, and interlinked, every single package author would benefit, as would all users. You mean, everyone should be able to mess about with my documentation? This would be similar to give everyone commit rights to my repositories or allow everyone to edit the code of my published libraries. What is the good thing about that? No one said anything about unrestricted commit rights ... we're not crazy ... what if it were more like, say, RWH's wiki .. where comments go to editors to encorporate ... “Wiki” sounds like you could edit the documentation of the package. This wouldn’t necessarily mean that these modifications are written back to the repository. However, it would men that Hackage is not longer showing the real documentation of the repository but what others made of it by wiki editing. I would dislike this. However, a commenting system like that of RWH is a very different thing. People would not edit the actual documentation (so the documentation is not a wiki). People would just add comments. This might be a good idea. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell.org GSoC
Am Donnerstag, 12. Februar 2009 10:49 schrieb Luke Palmer: Something like AnnoCPAN would be a good middle-ground here; i.e. differentiate between official package documentation and user annotations, but make them both visible. And give visitors of the Hackage website the choice to not see the comments at all. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph library, was: Haskell.org GSoC
Am Donnerstag, 12. Februar 2009 15:34 schrieb Thomas DuBuisson: Daniel Kraft asked: That sounds interesting... What do you mean by no canonical library? Are there already ones but just no standard one? But in this case, I don't think adding yet another one will help :D Or isn't there a real general graph library? My impression is that there is now standard one, but then again I've only used Haskell + a graph library once. BTW, is there some sort of project hosting specifically for such Haskell projects? Or should I go with sourceforge (for instance) for developing this, if I gave it a try? Get a community.haskell.org account once you are ready to start a repo, it can not only host your repo (ex: http://community.haskell.org/~tommd/pureMD5) but also allows you to upload packages to hackage.haskell.org. I already have a Hackage account. Can this be readily used as a community.haskell.org account? If not, what if I get a community account. Do I have two accounts for Hackage access then? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: first Grapefruit release
Dear friends of Haskell and Functional Reactive Programming, its my pleasure to announce the first official release of Grapefruit, a library for Functional Reactive Programming (FRP) with a focus on user interfaces. With Grapefruit, you can implement reactive and interactive systems in a declarative style. User interfaces are described as networks of communicating widgets and windows. Communication is done via different kinds of signals which describe temporal behavior. Grapefruit consists of five packages with several interesting features: grapefruit-frp: Functional Reactive Programming core * The FRP implementation uses a hybrid push/pull-based approach. * Signals can be memoized by binding them to variables – like ordinary data structures. * Merging of event streams combines simultaneous events properly. * Signals cannot behave differently by starting them at different times. The type system is used to enforce proper aging of signals. grapefruit-records: A record system for Functional Reactive Programming * Input records can specify fields as being required or optional. * Uninteresting output fields can be ignored. The set of interesting fields is specified by pattern matching. grapefruit-ui: Declarative user interface programming * The interface for UI programming is platform-independent and can be implemented on top of different UI toolkits. * A concrete implementation can be selected at compile time or runtime. grapefruit-ui-gtk: GTK+-based implementation of the general UI interface * Gtk2Hs is used internally. grapefruit-examples: examples demonstrating features of Grapefruit * Circular communication and switching are demonstrated. Support for the following is planned for the future: * signals with incremental updates * user interfaces with changing structure * more kinds of UI components * graphical animations Further information about Grapefruit is available on its wiki page at http://haskell.org/haskellwiki/Grapefruit. If you have questions, applause or criticism, please get in touch with me. Wolfgang Jeltsch Principal Grapefruit developer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock Markup
Am Freitag, 13. Februar 2009 01:30 schrieben Sie: On 12 Feb 2009, at 8:48 pm, Wolfgang Jeltsch wrote: I don’t understand this. The way which works is conversion from MathML to TeX. So your suggestion would be to use MathML as the source language. But this is obviously not what you suggest. I’m confused. It's explicit enough in the original message: Use a substantial chunk of MathML in a TeX-parseable syntax. If you want to use a subset of TeX in Haddock comments, how would you render them on a webpage? I didn't say a subset of TeX but a subset of MathML. [explaination follows] So you mean a language which * directly corresponds to a subset of MathML (and is therefore easily convertible into sensible MathML) * is at the same time valid TeX source which can be processed by TeX based on a few macro definitions (like \mrow) This sounds interesting, indeed. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph library, was: Haskell.org GSoC
Am Samstag, 14. Februar 2009 16:59 schrieb Brent Yorgey: On Thu, Feb 12, 2009 at 04:10:21PM +0100, Wolfgang Jeltsch wrote: Am Donnerstag, 12. Februar 2009 15:34 schrieb Thomas DuBuisson: Get a community.haskell.org account once you are ready to start a repo, it can not only host your repo (ex: http://community.haskell.org/~tommd/pureMD5) but also allows you to upload packages to hackage.haskell.org. I already have a Hackage account. Can this be readily used as a community.haskell.org account? If not, what if I get a community account. Do I have two accounts for Hackage access then? No, they are two separate things. A Hackage account just lets you upload things to Hackage. A community.haskell.org account lets you log into code.haskell.org (a completely different server than Hackage), host projects there, and so on. But Thomas DuBuisson wrote that you can upload packages to HackageDB with your community.haskell.org account (see above). Is this wrong? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Possible bug?
Am Freitag, 13. Februar 2009 17:16 schrieb Peter Verswyvelen: Can all functional dependencies be completely replaced with associated types when using GHC 6.10.1? It might be possible as long as you don’t use overlapping instances. With overlapping instances, it’s typically not possible since there are no overlapping type family instances. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Amazing
Am Sonntag, 15. Februar 2009 23:00 schrieb Peter Verswyvelen:
But if I understand it correctly, dependent types are a bit like that,
values and types can inter-operate somehow?
With dependent types, parameters of types can be values. So you can define a
data type List which is parameterized by the length of the list (and the
element type):
data List :: Nat - * - * where -- The kind of List contains a type.
Nil :: List 0 el
Cons :: el - List len el - List (succ len) el
And you have functions where the result type can depend on the actual
argument:
replicate :: {len :: Nat} - el - List len el
-- We have to name the argument so that we can refer to it.
So the type of replicate 0 'X' will be List 0 Char and the type of
replicate 5 'X' will be List 5 Char.
Dependent typing is very good for things like finding index-out-of-bounds
errors and breach of data structure invariants (e.g., search tree balancing)
at compile time. But you can even encode complete behavioral specifications
into the types. For example, there is the type of all sorting functions.
Properly implemented Quicksort and Mergesort functions would be values of
this type but the reverse function wouldn’t. Personally, I have also thought
a bit about dependently typed FRP where types encode temporal specifications.
Dependent types are really interesting. But note that you can simulate them to
a large degree in Haskell, although especially dependent functions like
replicate above need nasty workarounds. You may want to have a look at
Haskell packages like type-level.
Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
Am Sonntag, 15. Februar 2009 17:50 schrieb Peter Verswyvelen: I'm having trouble understanding the explanation of the meaning of the signature of runST Were you just reading the documentation of Grapefruit’s era parameters or why are you studying ST? ;-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
[redirecting to haskell-cafe] Am Samstag, 14. Februar 2009 23:13 schrieben Sie: Great, does it run well on Windows and Mac platforms in addition to Linux platform which should run fine? Actually, I have no idea. ;-) Well, Grapefruit is a pure Haskell library without any own binding to C libraries or whatever. For GUI stuff, Grapefruit relies completely on Gtk2Hs. So if Gtk2Hs works, Grapefruit should work too. I just haven’t tested it so far. Earlier Grapefruit code was successfully executed on the Windows box of my co-developer. On the other hand, Grapefruit is designed to be implemented on top of different toolkits, although currently there is only the Gtk2Hs backend. So if you want to write a backend based on the Win32 API or Cocoa, this would be very welcome. :-) I am planning to create video phone software and I was looking for good GUI toolkit that supports FRP so it looks like it is right time to use Grapefruit :) This would be really great. Writing applications with Grapefruit gives me useful feedback and pressure for improvement. Note that currently the set of supported widgets is very low but this is likely to change during the next weeks and it should often be very easy to port Gtk2Hs widgets to Grapefruit. Thanks Jamie Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
[redirecting to haskell-cafe] Am Sonntag, 15. Februar 2009 00:25 schrieben Sie: Hi Wolfgang, I was wondering if I can use FLTK as GUI backend for Grapefruit? This should be possible in principal. It just could be that my assumptions about how widgets are created and composed were too tight so that Grapefruit’s general interface doesn’t fit FLTK. In this case, please just tell me and I will try to make the interface more general. I believe for this to make it happen, I would have to output FLTK's C++ into C then create bindings for Haskell (via FFI). Is that doable or an quite tall order? Recently, a student of mine has written a program which generates a Haskell Qt binding fully automatically from Qt header files. The generated binding consists of three layers. The first layer is C++ code which reexports Qt’s functionality as a pure C interface. The C interface is ugly for humans and not type safe (because C doesn’t know classes). The second layer consists of a couple of FFI declarations. The third layer is Haskell code which provides a nice interface similar to the original C++ interface. I still have to get the source code of the binding generator from that student but I hope this will happen soon. I want to publish it then on the web. It hope that it is possible to reuse this binding generator for other C++ libraries. Jamie Clark Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
[redirecting to haskell-cafe] Am Sonntag, 15. Februar 2009 00:26 schrieben Sie: One more thing, would Grapefruit work with files created by Glade (UI builder)? No, it won’t, I’m afraid. There is, for example, the principal problem that Glade is GTK+-specific (as far as I know) while Grapefruit shall have a toolkit-independent library interface. However, I don’t think it is such a good idea to support traditional GUI builders. These builders typically let you design a static interface but you have to code event handlers or similar stuff completely by hand and you have practically no support for dynamic user interfaces (user interfaces that change their structure). On the other hand, Grapefruit uses arrow notation for composing user interfaces so that the source code already reflects the visual appearence of the GUI to a certain degree. For example, you just list the widgets of a box and say what their input and output signals are. That said, I still think it might be a good idea to use a GUI builder together with Grapefruit. But such a builder should be specifically designed for Grapefruit, in my opinion. I already have some rough ideas in my mind about how such a builder could work. I’d want it to cover also the communication between the UI components (using signals) and maybe even dynamic user interfaces. If you are interested in my ideas, please ask. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: first Grapefruit release
Am Sonntag, 15. Februar 2009 16:27 schrieben Sie: Hi Wolfgang, Thank you for the excellent introduction Oh, I thought that you didn’t send you original question to the list and therefore answered you only privately. So the others don’t know yet the introduction you refer to (but see below). (this would be good material to put on your Wiki). Done. :-) http://haskell.org/haskellwiki/Grapefruit/Comparison_to_other_FRP_libraries Conal, are you listening? If yes, could you please look over this page to make sure that I described your work correctly? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: first Grapefruit release
Am Samstag, 14. Februar 2009 23:37 schrieb Roman Cheplyaka: * Wolfgang Jeltsch g9ks1...@acme.softbase.org [2009-02-14 17:19:09+0100] Dear friends of Haskell and Functional Reactive Programming, its my pleasure to announce the first official release of Grapefruit, a library for Functional Reactive Programming (FRP) with a focus on user interfaces. With Grapefruit, you can implement reactive and interactive systems in a declarative style. User interfaces are described as networks of communicating widgets and windows. Communication is done via different kinds of signals which describe temporal behavior. Greetings! Does this version not support Codebreaker and CircuitingObjects examples shown on the wiki page? Or there's another reason why they are not included in the grapefruit-examples? Sadly, both are not supported at the moment. The reasons are described under http://haskell.org/haskellwiki/Grapefruit#Versions: Grapefruit underwent fundamental interface and implementation changes before this release. A version from before these changes is available as the “classic” version. In contrast to the released version, the classic version contains support for animated graphics, incrementally updating list signals and a restricted form of dynamic user interfaces (user interfaces whose widget structure may change). These features are expected to come back in future releases. CircuitingObjects needs the graphics support (obviously) and Codebreaker needs at least incrementally updating list signals. I want to start hacking on these kind of signals today, so I hope that Codebreaker can soon run again. Maybe there is someone interested in helping me with the graphics support? There is already quite some stuff implemented (thanks to Matthias Reisner), it’s just that this is based on the classic interface of Grapefruit. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looping after compiling with cabal
Am Montag, 16. Februar 2009 13:07 schrieb Neil Mitchell: Hi Henk-Jan, I believe cabal adds a -O on the command line, perhaps try ghc --make -O (after deleting all object files) If it’s the -O option what causes the loop then it is problably because of this: http://hackage.haskell.org/trac/ghc/ticket/2722 Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
Am Montag, 16. Februar 2009 14:21 schrieben Sie: Aha! Wolfgang is a man who knows his own code :) Yes, I've seen this a couple of times but when I saw it again in Grapefruit, I wanted to know how this usage of existentials worked, since I'm sooo curious to find out how you managed to use the type system for solving some of the typical FRP problems. Note that in Grapefruit I not only use rank-2 polymorphism (corresponding to existentials) but also impredicative polymorphism, namely in FRP.Grapefruit.Signal.switch. However, the idea behind using impredicativity here is the same as the reason for using rank-2 in Control.Monad.ST.runST, FRP.Grapefruit.Circuit.create and Graphics.UI.Grapefruit.Circuit.run. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 15:13 schrieben Sie: So I have an application that I am developing. The UI module includes the following: import Graphics.UI.Gtk import Graphics.Rendering.Cairo import Graphics.Rendering.Cairo.SVG import Graphics.UI.Gtk.Gdk.EventM Can you tell from that list if i am likely to be able to rewrite it to use Grapefruit? No, this won’t work at the moment. As I already said, Grapefruit’s widget support is very restricted at the moment. (And if I say “very” I really mean it.) So Grapefruit is worlds apart from what the catch-all Graphics.UI.Gtk import provides. And there is no graphics support at the moment, so there is nothing equivalent to the Cairo interface. Coming up with a sensible purely-functional, toolkit-independent, reactive graphics interface will also need some design work. Until now, I concentrated on getting Grapefruit’s core well. This includes a scalable FRP implementation, a record system (since you don’t want to provide an input signal for every attribute of every single widget in practice) and support for writing/extending Grapefruit UI backends without writing lots of boilerplate code. Providing a wide variety of ready-to-use widgets, graphics primitives, etc. is future work which, hopefully, I can delegate largely to interested third parties. ;-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 16:43 schrieb Peter Verswyvelen: 2009/2/16 Gour g...@mail.inet.hr Do you anticipate that Grapefruit will be capable for writing real-world GUI apps quit soon? LOL. Funny typo. If the apps quit soon we're in trouble! :-) I’m sure that current Grapefruit applications will be quitted soon by their users. :-D Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 16:27 schrieb Gour: Do you anticipate that Grapefruit will be capable for writing real-world GUI apps quit soon? I have no concrete anticipation. It depends very much on the community. If there is notable interest and this interest makes people hacking on Grapefruit then it might not take so long until you can write real-world apps in Grapefruit. I’m really interested in developing Grapefruit further. However, I also have to do a PhD, etc. and so I need others which help. But I will try to help the helpers as much as possible and also hack myself. Various immediate reactions to my release announcement make me hopeful that there might be indeed notable Grapefruit development from other people than me. Best wishes, Wolfgang P.S.: The “hack myself” might not be a typo but it’s maybe a funny blooper. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 17:46 schrieb Wolfgang Jeltsch: Am Montag, 16. Februar 2009 16:27 schrieb Gour: Do you anticipate that Grapefruit will be capable for writing real-world GUI apps quit soon? I have no concrete anticipation. It depends very much on the community. If there is notable interest and this interest makes people hacking on Grapefruit then it might not take so long until you can write real-world apps in Grapefruit. By the way, are there people out there who would like to hack on Grapefruit during the Utrecht Hackathon [1]? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 18:05 schrieb Fraser Wilson: I'd love to hack on Grapefruit. That’s great! I'll do some study (and take a break from my own world-changing functional GUI :-) I tried to check out your repository at http://thewhitelion.org/darcs/barrie/ but darcs get failed with some complaint about cached patches or so. :-( I use darcs 2.2.1. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 19:08 schrieben Sie: Yeah, I lack some darcs fu unfortunately. I understood it was just a matter of copying a repository. I'll have a look, and by have a look I mean bother #haskell :-) If you don’t use this lazy fetch feature (or whatever it is called) then you can just copy your repository. Personally, I have very uncomfortable feelings about this lazy patch fetching since I fear it might be all too easy to loose data somewhere. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
Am Montag, 16. Februar 2009 19:04 schrieb Kim-Ee Yeoh: Despite its rank-2 type, runST really doesn't have anything to do with existential quantification. First, I thought so too but I changed my mind. To my knowledge a type (forall a. T[a]) - T' is equivalent to the type exists a. (T[a] - T'). It’s the same as in predicate logic – Curry-Howard in action. However, if we talk about existential types in Haskell, we usually mean these special algebraic data types whose declarations have a forall part before a data constructor. So it’s better to talk about rank-2 (or rank-n) polymorphism when talking about runST. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
Am Montag, 16. Februar 2009 19:22 schrieb Wolfgang Jeltsch: Am Montag, 16. Februar 2009 19:04 schrieb Kim-Ee Yeoh: Despite its rank-2 type, runST really doesn't have anything to do with existential quantification. First, I thought so too but I changed my mind. To my knowledge a type (forall a. T[a]) - T' is equivalent to the type exists a. (T[a] - T'). It’s the same as in predicate logic – Curry-Howard in action. Oops, this is probably not true. The statement holds for classical predicate logic with only non-empty domains. But in constructivist logic only the first of the above statements follows from the second, not the other way round. So arguing with the Curry-Howard isomorphism fails and indeed, the two types are not equivalent. There is just a function from the second to the first (it’s the function application function ($) actually). Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 19:27 schrieben Sie: Ah. Copy, don't darcs get. If you copy a repository which was itself fetched from somewhere using this lazy patch fetching feature, you’ll probably experience problems too. If it’s the repository you work in and you never fetched any patches into it, you might be successful. This is how I understand it. We see that this lazy patch fetching thing is dangerous. ;-) If you want to take a look, I'd love to hear your thought. demos/BarrieCalc has some commentary, and the other applications in demos are all very simple. I just executed the demos. At the moment, I have no time to look at the code but I think I will have a look in the future. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org GSoC
Am Dienstag, 17. Februar 2009 01:13 schrieb Martijn van Steenbergen: Daniel Kraft wrote: Do you think something would be especially nice to have and is currently missing? Have type class aliases been implemented yet? This proposal (or parts or it) seems like a very useful compiler extension to have, and might be an interesting GSoC project. http://repetae.net/recent/out/classalias.html Kind regards, Martijn. It would be great to have something like class aliases implemented. However, the proposal(s) should be reviewed and discussed before someone starts implementing them. Once something is implemented, it is difficult to change it. It’s similar to libraries. Several libraries were implemented as part of research and their developers didn’t seem to think very deeply about choosing identifiers and such things. Later, these libraries were in wider use and changing the identifiers got problematic. I think of such things like the DPH identifiers. In my opinion, it’s bad practice to include single letters in identifiers to denote namespace. Parallel.filter would be much better than filterP. That said, I want to reinforce that class aliases are far too long not implemented. My dream is that we thoroughly improve library interfaces and class aliases could be important for doing so without breaking compatibility very much. So we should probably also think about what kinds of library interface changes would be desirable in order to know what features some class alias extension should provide. Some things that come to my mind immediately: * making Applicative a superclass of Monad * getting rid of MonadPlus (use (Alternative m, Monad m) instead of (MonadPlus m) or, with another extension, even something like (forall a. Monoid (m a), Monad m)) * getting rid of ugly Monoid method names (empty, append, concat or something totally different instead of mempty, mappend, mconcat) * redesigning numeric classes Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: The Typeclassopedia, and request for feedback
Am Dienstag, 17. Februar 2009 00:32 schrieb George Pollard: On Mon, 2009-02-16 at 15:30 +0100, Fraser Wilson wrote: Super! Also, best definition of bottom I've yet seen -- ignoring _| _, which is a party pooper. Like good code, it's short, to the point, and obviously correct. This brings up something I've thought about: On page 8, it is said that Pointed doesn't need to be checked because the theorem comes for free, but the free theorems paper was based upon total functions only; does having _|_ affect the free theorem for Pointed? This was my question to Janis Voigtländer after his HaL 3 talk. He said that the free theorem stuff also holds in the presence of _|_, it’s just a bit more complicated to prove it. At least, this is how I understood it. :-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANN: The Typeclassopedia, and request for feedback
Am Dienstag, 17. Februar 2009 03:42 schrieb Isaac Dupree: I'm really confused that when I replied (not reply-to-all, not reply-to-list, just reply) to that message, it went to the lists and not to you Brent! (KMail 1.10.3) -- so I totally edited the To lines, to send this message... Isn’t this just because of the Reply-To: header line which is inserted by mailman? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looping after compiling with cabal
Am Montag, 16. Februar 2009 21:33 schrieb Henk-Jan van Tuyl: On Mon, 16 Feb 2009 14:56:01 +0100, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Montag, 16. Februar 2009 13:07 schrieb Neil Mitchell: Hi Henk-Jan, I believe cabal adds a -O on the command line, perhaps try ghc --make -O (after deleting all object files) If it’s the -O option what causes the loop then it is problably because of this: http://hackage.haskell.org/trac/ghc/ticket/2722 Best wishes, Wolfgang It is the -O option. How do I get/install the patch mentioned in this ticket? My workaround is to change the source which is compiled. Instead of the method implementation id = arr id, I use the implementation id = arr Prelude.id. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 22:04 schrieben Sie: As for how I want Hieroglyph to work interactively, I think the easiest way is to react to the input data considered as a coherent whole. The semantic model for visualization is that a Visualization is a function from Data to Visual. Hmm, doesn’t this approach result in scalability problems? You always have to analyse the complete input data if a small part of it changes and you always have to update the complete picture. This is similar to the problems I see with Yampa-based UI approaches. However, you might be interested in things like incremental list signals which I’m (re-)implementing at the moment. To a large degree, the library user sees a time-varying list but internally the library takes care of not updating the whole list all the time but only the parts which actually change. The main problem I have, which is what I want FRP for, is that to consider the data as a coherent whole, the data have to be composable. I don’t really understand this. Could you explain this, please? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 22:43 schrieben Sie: * Wolfgang Jeltsch g9ks1...@acme.softbase.org [2009-02-16 14:51:18+0100] Maybe there is someone interested in helping me with the graphics support? There is already quite some stuff implemented (thanks to Matthias Reisner), it’s just that this is based on the classic interface of Grapefruit. Yep, I'd like to help with graphics support. Thanks a lot. Currently I'm still learning about all these things (FRP, arrows, Grapefruit particularly), but if there are things which does not require deep understanding of these concepts (or even help to gain one), please tell me. I think, you need to understand what discrete and segmented signals are. Which is not very difficult, in my opinion. You only have to know what they mean not how they are implemented. So you don’t need a deep understanding of all kinds of FRP things in order to hack on Grapfruit graphics support. Did you have a look at my e-mail conversation with Jeff Heard (in the same haskell-cafe thread)? He thinks about adapting the Hieroglyph 2D graphics library to Grapefruit. There is also the graphics implementation of classic Grapefruit which is for 3D graphics and OpenGL-based. These may be things, you want to have a look at. Also, I'm yet not sure about Utrecht, but if Grapefruit hacking is planned, it's worth coming for me :) This sounds very good. It’s not yet sure whether I will go to Utrecht for supervising Grapefruit hacking but it’s very likely that I will. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] first class tuples?
Am Dienstag, 17. Februar 2009 14:42 schrieb Peter Verswyvelen: Tuples in Haskell always have annoyed me a bit since each tuple of different dimension is hardcoded You are not alone with this. Several people have complained about this in the past. (I guess compilers enforce a maximum dimension on tuples?) GHC has an internal module which uses a syntactically extended form of data declarations to declare different tuple types: data (,) a b = (,) a b data (,,) a b c = (,,) a b c etc. These declarations can even be found in some Haddock documentation. So at least GHC has an upper bound on tuple size although the Haskell Report states that there isn’t one. I remember that in an earlier version of this tuple module there was a comment in the source code, saying that there can be no tuples with more than 37 or so elements since GHC crashes on tuple declarations of bigger size. :-D Since a tuple represents a fixed size data structure with different types at each coordinate, it feels as it should be possible to have a couple of type and data constructors to build a tuple, and to use recursion at the type level to have functions operate on tuples of any dimension. Definitely! Make , an infix operator. Then even the syntax (,) works without further ado. Make , right-associative, for example. Then you can write (a1,...,an) which means (a1,(a2,(...,an))). You just need one data declaration: data (a,b) = (a,b) However, this has the problem that it leads to more partially-defined values than with today’s tuples. For example, you could have a *triple* (a,_|_). So maybe we should treat tuple syntax completely as special syntax (as it is today) and define our tuple types so that tuples don’t end with the last element (as above) but with an explicit empty tuple (like lists end in a nil). This would also give use 1-tuples. We would need the unit type () for empty tuples. Then we define a cons type which has a strictness annotation: data head :# tail = head :# !tail The strictness annotation ensures that a tuple which is not _|_ has at least its complete skeleton defined, i.e., the only undefined (_|_) parts may be tuple elements or parts of tuple elements. E.g. one could then have a tmap function that takes a tuple of functions and a tuple of values and applies the function at coordinate N to the value at coordinate N. Is something like this possible today in Haskell, e.g. using new features like type families, GADTs, template haskell, etc? Or do we need dependent types for it? No dependent types, no template Haskell. Only multiparameter classes and functional dependencies (or, alternatively, type synonym families): class App fun arg result | fun - arg result, arg result - fun where app :: fun - arg - result instance App (val - val') val val' where app = ($) instance App () () () where app () () = () instance (App fun1 arg1 result1, App fun2 arg2 result2) = App (fun1 :# fun2) (arg1 :# arg2) (result1 :# result2) where app (fun1 :# fun2) (arg1 :# arg2) = (app fun1 arg1 :# app fun2 arg2) (All code untested.) In C++x0 I believe it is now possible to do so, since they even allow a variable number of template arguments, using recursion at compile time (see e.g. http://publib.boulder.ibm.com/infocenter/comphelp/v9v111/index.jsp?topic=/com.ibm.xlcpp9.aix.doc/standlib/header_tuple.htm) Doesn’t even C++ allow recursion at compile time in some way? The C++ template system is Turing-complete. Grapefruit has something like first class records, so I guess it should be possible (and simpler) to do this for tuples? By the way, I have taken several ideas from HList for implementing grapefruit-records. However, I didn’t use HList itself since it didn’t do exactly what I wanted. For example, it is better to write : for a cons-like operator instead of `HCons`. (This is the point I made in a recent e-mail about people caring too little about identifiers.) Of course, you could define an alias for HCons but since this wouldn’t be a constructor, you wouldn’t be able to use it in pattern matching (see below). In addition, I’m not sure whether HList allows you to specify a reordering and a selection of record fields by pattern matching. Grapefruit does so which I consider very important for arrow-based programming. In a line output - arrow - input, output can be a record pattern and input a record expression so that the output looks similar to the input. This makes arrow statements almost symmetric also in the presence of records. The alternative would be to make output a single variable and access the record elements via some field selection operator. This makes arrow statements less symmetric. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] package for algebraic structures
Hello, for Grapefruit’s incremental list signal support, I needed a type class of semigroups. A semigroup is similar to a monoid. The difference is that a semigroup doesn’t need to have a neutral element. So a semigroup type class would make a perfect superclass of Monoid, by the way. Since a semigroup class could be of more general interest, I decided to not include it in Grapefruit. Since I couldn’t quickly find an implementation of semigroups in Haskell, I put my own into a new package. Now, a package only for one class with one method seems like overkill. However, it could serve as a start for a package of all kinds of algebraic structures. So I called the package “algebra” and put it on Hackage. So if someone wants to implement rings, ideals, fields or whatever, I’d be happy to receive patches. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Dienstag, 17. Februar 2009 17:18 schrieben Sie: I'm glad that FRP isn't still alive and kicking. You are glad that FRP is *not* alive? Okay, this was a typo, wasn’t it? ;-) I hope you will support wxHAskell in the near future. I tried wxFruit and I liked it, but it isn't complete and it is not in development. I tried GTK2HS, but it was too buggy (probably because of the Windows version of GTK+, Cairo was quite buggy to), so I switched to wxHaskell. Well, I have no plans myself to create a wxHaskell UI backend, basically for one reason: wxWidgets tries to implement the same API using different native UI libs for getting native look and feel. However, when I last checked, it didn’t seem to do this very well. So I decided to implement the multi-toolkit feature directly in Grapefruit. If you have problems with Gtk2Hs on Windows, it might be better to write a Win32-based backend for Grapefruit instead of a wxWidgets-based one. What do you think about that? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Dienstag, 17. Februar 2009 19:36 schrieben Sie: If you have problems with Gtk2Hs on Windows, it might be better to write a Win32-based backend for Grapefruit instead of a wxWidgets-based one. What do you think about that? Win32-based backend would make more sense as it is one less layer to deal with. But how? Same thing with Mac. A student of mine wrote a fully automatic binding generator for C++ libraries which also supports Qt extensions (signals and slots). (However, this guy still has to give me the code. :-/ ) One could do a similar thing for generating Win32 and Cocoa bindings. Then one could write Grapefruit UI backends based on these bindings. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org GSoC
Am Dienstag, 17. Februar 2009 21:01 schrieben Sie: Wolfgang Jeltsch wrote: * making Applicative a superclass of Monad * getting rid of MonadPlus (use (Alternative m, Monad m) instead of (MonadPlus m) or, with another extension, even something like (forall a. Monoid (m a), Monad m)) * getting rid of ugly Monoid method names (empty, append, concat or something totally different instead of mempty, mappend, mconcat) * redesigning numeric classes Let's make these ideas more concrete and add them to the Other Prelude, if they haven't been already! http://www.haskell.org/haskellwiki/The_Other_Prelude Is this really good? First, I’m not only talking about prelude stuff but also stuff from other libraries. Second, the page “The Other Prelude” states right at the beginning that this project is (just) a fun project. However, I mean my comment very seriously. My agenda is not “This would be nice but won’t be realized anyway.” but “I really want to see this implemented.”. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-users] darcs and Google Summer of Code
Am Mittwoch, 18. Februar 2009 10:54 schrieb Eric Kow: The first is to work towards a sort of graphical interface for darcs (as has been suggested on this list). I suspect that we what we will likely do with this idea is to refine it into something that may either be part of a GUI (like a patch dependency viewer), or which will make it much easier for third parties to write a GUI in the future. What do you mean with “something which will make it much easier for third parties to write a GUI in the future”? I'll note that last year, we had a few interested students for this year and a potential mentor (Shelarcy from wxHaskell). Hopefully we can call on them again this year? There is also some work by Wolgang Jeltsch Wol*f*gang, please. :-) and students that we could talk about extending into a GSoC project. I would really like if patch viewer and GUI GSoC plans would be coordinated with me. There will probably some students that will start working on a darcs GUI next week. In addition there might be other students working on a patch viewer in spring or summer. We are also keeping a summary of this discussion here with our active ideas: http://wiki.darcs.net/index.html/GoogleSummerOfCode How can I get write access for this page? I’ve put myself as a potential mentor on the old Haskell SoC ticket (http://hackage.haskell.org/trac/summer-of-code/ticket/17). However, one or two years ago I was told that mentoring is a very time-consuming thing (and to my knowledge, you don’t get any payments for that, at least for Haskell projects). So if some other person wants to mentor a Grapefruit-based GUI or patch viewer project, I’d be very happy and would support this person the best I can. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Mittwoch, 18. Februar 2009 15:42 schrieben Sie: When he gives you the code, could you let me know? I would really love to bind Open Scene Graph, but it's entirely C++ and that makes for a lot more difficult coding to say the least. Yes, I will let you know. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org GSoC
Am Donnerstag, 19. Februar 2009 02:22 schrieb sylvain: Haskell is a nice, mature and efficient programming language. By its very nature it could also become a nice executable formal specification language, provided there is tool support. Wouldn’t it be better to achieve the goals you describe with a dependently typed programming language? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] package for algebraic structures
Am Donnerstag, 19. Februar 2009 00:17 schrieben Sie: On Tue, 17 Feb 2009, Wolfgang Jeltsch wrote: Now, a package only for one class with one method seems like overkill. However, it could serve as a start for a package of all kinds of algebraic structures. So I called the package “algebra” and put it on Hackage. So if someone wants to implement rings, ideals, fields or whatever, I’d be happy to receive patches. Do you mean this one: http://haskell.org/haskellwiki/Numeric_Prelude? There is currently no code for this, is there? In addition, I wouldn’t include algebraic structures in a *numerical* prelude since the cool thing about them is that they are so abstract that they are not only about numbers. However, then you might say that this package is overkill for Grapefruit since you only need the Semigroup class. What is the alternative to using a “numerical prelude” or the algebra package? Declaring the semigroup class inside Grapefruit? Then almost no library writer would define instances of this class. What’s the problem with Grapefruit having an additional dependency? If the package that is depended upon is open-source and automatically installable via cabal-install then the problems are little. On the other hand, you have the big advantage of modularization and thereby reuse of effort and consistency between different libraries (all use the same semigroup class). Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [darcs-users] darcs and Google Summer of Code
Am Donnerstag, 19. Februar 2009 05:10 schrieben Sie: Wolfgang Jeltsch wrote: I’ve put myself as a potential mentor on the old Haskell SoC ticket (http://hackage.haskell.org/trac/summer-of-code/ticket/17). However, one or two years ago I was told that mentoring is a very time-consuming thing (and to my knowledge, you don’t get any payments for that, at least for Haskell projects). So if some other person wants to mentor a Grapefruit-based GUI or patch viewer project, I’d be very happy and would support this person the best I can. Unless Google's changed things, the organization gets 500$ for each project. What the Darcs organization does with that, who knows. Yes, who knows. The “Haskell orgainization” didn’t give a cent to the mentors, as far as I know. Am I wrong here? It'd be a piddling amount as a stipend for the mentor, but... …it would be much better than nothing. :-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org GSoC
Am Donnerstag, 19. Februar 2009 11:35 schrieb Alberto G. Corona: 2009/2/19 Wolfgang Jeltsch g9ks1...@acme.softbase.org Am Donnerstag, 19. Februar 2009 02:22 schrieb sylvain: Haskell is a nice, mature and efficient programming language. By its very nature it could also become a nice executable formal specification language, provided there is tool support. Wouldn't it be better to achieve the goals you describe with a dependently typed programming language? But I wonder how a dependent typed language can express certain properties, for example, the distributive property between the operation + and * in a ring or simply the fact that show(read x)==x. As far as I understand, a dependent type system can restrict the set of values for wich a function apply, but it can not express complex relationships between operations. Each type system corresponds to some constructive logic and can enforce properties which are expressible in that logic. Dependent type systems correspond to higher order predicate logics or so and therefore can express almost everything you want. An Agda or Epigram type can cover a complete behavioral specification like “This function turns a list into its sorted equivalent.” Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [darcs-users] darcs and Google Summer of Code
Am Donnerstag, 19. Februar 2009 12:37 schrieb Malcolm Wallace: Unless Google's changed things, the organization gets 500$ for each project. What the Darcs organization does with that, who knows. Yes, who knows. The Haskell organization didn't give a cent to the mentors, as far as I know. Am I wrong here? That is correct. The haskell.org mentors decided to spend the money on hosting the haskell.org and community.haskell.org web sites and services, to benefit the whole community rather than just themselves. Hmm, mentoring a project also benefits the whole community and not just the mentors. So even if mentors take the money, the community wins. Resources are limited. The more limited a resource is, the more painful it is to abandon parts of it. This is also true for my time. If keeping valuable time is better for me than getting a software project done then I chose to keep the time. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org GSoC
Am Donnerstag, 19. Februar 2009 14:50 schrieb John A. De Goes: Unfortunately the proofs in dependently typed languages are extremely long and tedious to write. Some kind of compiler proofing tool could ease the pain, but I do not think it has low enough complexity for a GSoC project. I was not saying that I want such a thing done as a GSoC project. I just wanted to say that if one wants a programming language with an integrated proof language, it might be better to put work into Agda or Epigram instead of extending Haskell. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] package for algebraic structures
Am Freitag, 20. Februar 2009 00:38 schrieben Sie: Wolfgang Jeltsch schrieb: Am Donnerstag, 19. Februar 2009 00:17 schrieben Sie: Do you mean this one: http://haskell.org/haskellwiki/Numeric_Prelude? There is currently no code for this, is there? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/numeric-prelude http://darcs.haskell.org/numericprelude/ Is this linked from the wiki page? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: AW: [Haskell-cafe] Haskell.org GSoC
Am Freitag, 20. Februar 2009 09:42 schrieben Sie: Hello, but to specify that “this function turns a list into its sorted equivalent” would probably require to specify e.g. sort in terms of the type system and to write code that actually does the sorting. The first task is much like specifying what a sorted list is in first-order-logic (much like a Prolog program) and the second task is a regular functional program. If this is correct, dependent types would become more useful if the first task could be done by the compiler - which is probably impossible in general. I might not really understand you. Do you mean the compiler should be able to infer the specification from the implementation? In a dependently-typed programming language this would just mean type inference since specifications are types. However, type inference isn’t possible for dependent type systems. Personally, I think, it makes more sense to start with a specification (type) and then provide implementations. Systems like Agda and Epigram can actually use the reach information from the types to assist you in writing your implementation. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-users] darcs and Google Summer of Code
Am Samstag, 21. Februar 2009 16:18 schrieb Eric Kow: Hi Wolgang, Hmm, wrong again. ;-) On Wed, Feb 18, 2009 at 12:53:23 +0100, Wolfgang Jeltsch wrote: What do you mean with “something which will make it much easier for third parties to write a GUI in the future”? Kari's example of GUI-friendly optimisations might be one thought. More generally, I was thinking of some kind of darcs library design work: now that we have exposed all our modules in a sort of darcs library, how we can grow this into a proper library that people can safely use (safe in the sense that the library makes it very clear what kinds of operations are read-only, or to what extent operations are atomic, preferably with atomic repository-manipulating functions only being exposed and not their underlying substeps). The library could also tackle issues like darcs sending messages back to the user (right now, we just putStrLn, but what if we want them to go a special Window?) Tomorrow, I will discuss with the first half of my student project students (3 students) about what exact topic they will pursue. My idea is to let them start a Grapefruit-based darcs GUI. They should not use the currenct darcs interface directly where it doesn’t fit GUI frontends well. Instead they should write a wrapper around the “ugly” parts which exposes a “nice” interface. Later, one could merge this wrapper into the darcs codebase so that darcs exports the “nice” interface then. The GUI code wouldn’t have to change much then. In April, the second half of the students will start with their project. If there is some graphics support in Grapefruit at that time then they might work on a patch viewer. What do you think about that? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hac5 projects page
Hello, on http://www.haskell.org/haskellwiki/Hac5/Projects, you can list a project under “Project descriptions” and under “Experiences”. What’s the difference? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: package for algebraic structures
Am Dienstag, 24. Februar 2009 09:30 schrieb Aaron Denney: On 2009-02-19, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: In addition, I wouldn’t include algebraic structures in a *numerical* prelude since the cool thing about them is that they are so abstract that they are not only about numbers. But the thing is that to have the numerical classes support the proper abstractions we want them to support, we need to define the algebraic structures as well. So the rework goes together... Of course! It’s just that having algebraic structures in a separate algebra package is in my opinion a better idea than having them in a numeric prelude. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] base-4 + gtk2hs-0.10.0 licensing
Am Mittwoch, 25. Februar 2009 14:33 schrieb Duncan Coutts: Note that some people will tell you that by a strict interpretation of the LGPL that statically linked Haskell libs under that license are a pain in the backside. When we decided on that license for gtk2hs that was not our intention. In other words nobody is going to sue you if you statically link gtk2hs libs. Of course if you need a cast iron legal guarantee then that's not good enough and you'd have to ship .a and .o files to let users relink if they wanted to. I’m not sure whether this would be enough. .a and .o files are not compatible among GHC versions, as far as I know. Relinking against newer Gtk2Hs versions might not work. And a program using Gtk2Hs contains code from the .hi files of Gtk2Hs through inlining. So it’s not pure linking. However, the LGPL only allows linking, as far as I understand. I want to repeat what I’ve said earlier on this list: For Haskell, there is no real difference between LGPL and GPL, as far as I understand it. If you don’t want to force the users of your library to use an open source license for their work then use BSD3 or a similar license for your library. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] subscription problems for projects.haskell.org mailing list
Hello, I created a mailing list for Grapefruit on the Haskell Community Server (grapefr...@projects.haskell.org). If I try to subscribe to it, I receive a confirmation e-mail but my answers to this e-mail seem to get ignored. Does anyone have an idea what’s wrong here? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] subscription problems for projects.haskell.org mailing list
Am Mittwoch, 25. Februar 2009 17:05 schrieb Wolfgang Jeltsch: Hello, I created a mailing list for Grapefruit on the Haskell Community Server (grapefr...@projects.haskell.org). If I try to subscribe to it, I receive a confirmation e-mail but my answers to this e-mail seem to get ignored. Does anyone have an idea what’s wrong here? Confirmation via the weblink inside the confirmation e-mail works, by the way. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] subscription problems for projects.haskell.org mailing list
Am Mittwoch, 25. Februar 2009 17:15 schrieb Wolfgang Jeltsch: Am Mittwoch, 25. Februar 2009 17:05 schrieb Wolfgang Jeltsch: Hello, I created a mailing list for Grapefruit on the Haskell Community Server (grapefr...@projects.haskell.org). If I try to subscribe to it, I receive a confirmation e-mail but my answers to this e-mail seem to get ignored. Does anyone have an idea what’s wrong here? Confirmation via the weblink inside the confirmation e-mail works, by the way. Meanwhile, I received automatic answers to my two unsuccesful confirmation e-mails. They both claim that the confirmation string is invalid. However, the confirmation string worked when confirming via the website. The only problem I can imagine at the moment is that the URLs with the confirmation string were broken into two lines in my confirmation e-mails. However, Mailman should take the string from the subject line, shouldn’t it? The error notifications told me that for each of my confirmation e-mails, the last paragraph was “ignored” while everything before it was “unprocessed”. What does that mean? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Grapefruit infrastructure
Hello, I just want to mention that the Grapefruit FRP library now has a mailing list and a Trac instance which contains a bug tracker. See: http://www.haskell.org/haskellwiki/Grapefruit#Community Please also note that the Grapefruit repositories have moved to code.haskell.org. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing
Am Mittwoch, 25. Februar 2009 23:38 schrieb Peter Hercek: So my opinion (IAMNAL): 1) source code under very limiting commercial license (just to allow recompile with a newer LGPL lib and nothing else) is OK 2) it is probable that only the *.o, *.hi files and a linking script are OK too I think, it’s technically not possible to let your Haskell application use another library version when you just have the .o and .hi files of the new library version. The .hi files typically contain code which is inlined by the application, so you have to be able to recompile the application. Or am I misunderstanding you? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing
Am Donnerstag, 26. Februar 2009 09:17 schrieb Ketil Malde: Peter Hercek pher...@gmail.com writes: Relinking against newer Gtk2Hs versions might not work. You have the option of recompiling the new Gtk2Hs with the old GHC and relinking, don't you? Relinking is technically not possible because of inlining. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing
Am Donnerstag, 26. Februar 2009 21:39 schrieb Peter Hercek: The acceptable size of inlined fuctions for a C code is about 10 lines. I did not read any info how it would be for Haskell. At least, GHC inlines very massively, to my knowledge. And I think you need this massive inlining for reasonable performance because of Haskell’s high level nature, lazy evaluation, etc. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing
Am Donnerstag, 26. Februar 2009 20:20 schrieb Achim Schneider: Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Donnerstag, 26. Februar 2009 09:17 schrieb Ketil Malde: Peter Hercek pher...@gmail.com writes: Relinking against newer Gtk2Hs versions might not work. You have the option of recompiling the new Gtk2Hs with the old GHC and relinking, don't you? Relinking is technically not possible because of inlining. I don't think the situation is any different from providing C headers that contain macros or inline functions. But as Peter Hercek said, the LGPL limits the amount of macro expansion for C libraries. And the amount of GHC’s inlining would probably exceed all limits. ;-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A foray into type-level programming, and getting stuck
Am Sonntag, 1. März 2009 22:10 schrieb Brian Bloniarz: Hi George, Since none of the type metaprogramming specialists have answered you on-list, I took a crack at this -- I think you can work around the issue by avoiding overlapping instances entirely. I learned about this technique from the HList paper this message: http://okmij.org/ftp/Haskell/keyword-arguments.lhs (see the rest of the implementation). Note that HList still needs overlapping instances for implementing type equality. If we will have closed type families at some future time, this will change. See: http://www.mail-archive.com/glasgow-haskell-users%40haskell.org/msg12792.html Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [reactive] FRP + physics / status of hpysics
Am Freitag, 6. März 2009 14:34 schrieb Daniel Bünzli: without using recursive signal functions, If this is because there's this limitation in the frp system you use It is. then better fix the system. The system is Grapefruit, by the way. And I’m its developer, by the way. :-) I have to say that it’s hard, if not impossible, to combine recursive signal definitions with other features, I want to have. The point of recursive definitions is that you want to turn recursive equations from your problem domain directly into Haskell definitions. This is nice from a user’s point of view but hard from a programmers point of view. Standard Haskell already shows that. While it is possible to define an infinite list of ones by ones = 1 : ones, it is not possible to do the same for sequences of type Seq. The above definition of ones relies very much on the structure of lists. Analogously, the ability to define signals recursively restricts the set of possible signal implementations seriously. Haskell’s recursive definitions are very general. They have to find fixpoints of arbitrary functions over arbitrary type. Therefore, their semantics are rather weak. They give you the least defined fixpoint. The consequence is that you get bottom if you use something like x = 0 * x although x = 0 might be what you prefered. What I want to say is that coming up with a signal implementation that allows Haskell recursion and has other advantages at the same time is a big challenge. There are three features, you might want from a signal implementation: 1. support for recursive signal definitions using Haskell equations 2. memoization (for avoiding time leaks, for example) 3. signals which may depend on external sources I tried hard to support 2 and 3 well in Grapefruit. Fran has 1 but has problems with 2 and 3. I don’t know whether Reactive has a solution for 2 in the context of recursive definitions, i.e., whether the space and time leak problems of Fran were solved. I think, it has at least problems with 3. For me, 2 and 3 are more important than 1. One reason is that 1 has other problems than being in conflict with 2 and 3. The result of a recursively defined signal depends on when sampling occurs. Since a recursive definition tends to result in accumulation of values, errors introduced by sampling may accumulate too. So you have to use clever approximation algorithms in addition. My new idea is to view the problem in a different way. Let’s take the problem where the position of a ball is the integral of the difference between the mouse position and the ball position. As far as I can see, the transformation of the mouse position signal into the ball position signal forms a linear system. So the ball position signal is the mouse position signal convoluted with another signal. If we would have a function that performes convolution, we could probably implement many problems using this function. Using convolution would let us get rid of the problems with accumulating errors. I suppose that most of the recursive definitions you would use in FRP are differential or integral equations. Let’s look at the equation for the ball-following-the-mouse example: ballPos = integral (mousePos - ballPos) ballPos can be represented in terms of mousePos as follows: ballPos = (exp . negate) * mousePos where * means convolution. We could provide a library which supports common stuff like distance-dependent acceleration, friction etc. Of course, you could say that now the programmer isn’t able anymore to enter his equations directly which isn’t nice. However, this situation is not different to other areas. For example, you cannot write x = 5 - x / 2 and expect x to be 10 / 3. Instead, you have to transform the equation first. Soon or later it you'll want it elsewhere. A recursive reactive signal just means that some of what your reactive program computed will be usefull/necessary for the next step. You can do this with convolution, I think. By the way, continuous signals don’t have steps. These are just introduced by sampling. You'll see that happen very quickly (e.g. any simple reactive state machine). “State machine” sounds like a discrete problem. You can use accumulation over event sequences here (as, for example, provided by the scan function in FRP.Grapefruit.Signal.Discrete). By the way, the adress of the Grapefruit mailing list is grapefr...@projects.haskell.org, not grapefr...@haskell.org. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [reactive] FRP + physics / status of hpysics
Am Freitag, 6. März 2009 17:51 schrieb Wolfgang Jeltsch: By the way, the adress of the Grapefruit mailing list is grapefr...@projects.haskell.org, not grapefr...@haskell.org. Oh, this is really strange: I addressed my e-mail to grapefr...@projects.haskell.org but the version arriving at the Reactive mailing list has grapefr...@haskell.org in its To: header. However, my e-mail also reached the Grapefruit mailing list (but Daniel Bünzli’s didn’t) and the version there has the correct address in its To: headers. Does anyone know who is responsible for the Haskell mail server? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [grapefruit] [reactive] FRP + physics / status of hpysics
Am Freitag, 6. März 2009 17:57 schrieb Wolfgang Jeltsch: Am Freitag, 6. März 2009 17:51 schrieb Wolfgang Jeltsch: By the way, the adress of the Grapefruit mailing list is grapefr...@projects.haskell.org, not grapefr...@haskell.org. Oh, this is really strange: I addressed my e-mail to grapefr...@projects.haskell.org but the version arriving at the Reactive mailing list has grapefr...@haskell.org in its To: header. However, my e-mail also reached the Grapefruit mailing list (but Daniel Bünzli’s didn’t) and the version there has the correct address in its To: headers. Does anyone know who is responsible for the Haskell mail server? Best wishes, Wolfgang It was a misconfiguration of the mailserver which is believed to be fixed now. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FRP + physics / status of hpysics
Am Samstag, 7. März 2009 18:49 schrieb Roman Cheplyaka: Great! I'll have more free time after March 15, and we can arrange an IRC meeting to discuss this. I’d be happy if you would also invite me to this IRC meeting when it will finally happen. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Sugestion for a Haskell mascot
Am Dienstag, 10. März 2009 00:59 schrieb Joe Fredette: Hehe, I love it. Sloth is a synonym for Lazyness in English too, and they're so freaking cute... :) Same in German: The german “Faultier” means “lazy animal”. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to insert character key self in sourceView?
Maybe you should direct your question to the Gtk2Hs users mailing list gtk...@lists.sourceforge.net. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Sugestion for a Haskell mascot
Am Donnerstag, 12. März 2009 22:00 schrieb Martijn van Steenbergen: Deniz Dogan wrote: Then of course, there's the downside that there's no connection to the language itself in any way. I usually go for names that don't have to do anything with the application itself: GroteTrap (translates to GreatBustard), Yogurt, Custard... saves me from having to think of appropriate names. :-P This is basically how I chose the name “Grapefruit” for “my” FRP library. Okay, it refers to Fruit (a FRP GUI library) but the only further meaning of “Grapefruit” is that I find Grapefruits to be tasty. :-) Often people choose meaningful names and convert them to acronyms, noone can pronounce. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Against cuteness
Am Freitag, 13. März 2009 04:29 schrieb Benjamin L.Russell: Consider the following logo: Silver red monad.png http://commons.wikimedia.org/wiki/File:Silver_red_monad.png Can’t we choose something which is not connected to certain worldviews? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State monad is missing Applicative instance
Am Freitag, 13. März 2009 05:09 schrieb Denis Bueno: This works because every monad induces an Applicative instance in a way I've ingested just enough wine to forget. =] pure = return (*) = ap Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Natural Numbers: Best implementation?
Am Freitag, 13. März 2009 04:01 schrieb Alexander Dunlap: 2. Use the type data Natural = Zero | Succ !Natural […] In terms of speed, I think that [3] would be reasonably fast (unless you do a ton of subtraction with bounds-checking) and [2] would probably be quite slow, because you don't get the speed-boost from doing computations right on the processor. Not only that but also because operations like addition now take at least linear time. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Natural Numbers: Best implementation?
Am Freitag, 13. März 2009 04:53 schrieb Brandon S. Allbery KF8NH: On 2009 Mar 12, at 22:54, Mark Spezzano wrote: I was wondering what the best way to implement Natural number would be. Is there a package which already does this? type-level on Hackage. I think, the original poster wanted value-level naturals, not type-level naturals. 2. Use the type data Natural = Zero | Succ !Natural One of the reasons people use type-level naturals is to get laziness; you've made this strict. Is there a reason? Do you really mean type-level naturals? The following is a definition of value-level naturals: data Natural = Zero | Succ Natural Type-level naturals would be defined like this: data Zero data Succ nat Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Natural Numbers: Best implementation?
Am Freitag, 13. März 2009 09:21 schrieb Roman Cheplyaka: * Alexander Dunlap alexander.dun...@gmail.com [2009-03-12 20:01:57-0700] Also, a lot of functions just take Integers so it would be more of a pain to use. AFAIK there are very few fuctions that take Integers. Many functions take instances of Integral, but it's not a problem to make your own type such an instance. I’d say that it is a problem. Class instances should satisfy certain laws. (Although these laws are often not stated explicitely, they are assumed to hold by users of the class and they should hold to make the instance sensible.) In the case of Num, I would expect num + negate num to equal num. This wouldn’t hold for a Natural instance of Num. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Microsoft PhD Scholarship at Strathclyde
Am Samstag, 14. März 2009 08:19 schrieb Peter Verswyvelen: Well, in C++ one can already use the numerical values with templates for achieving a lot of compile time computations. So I would be very happy to have this feature in Haskell. It might also be good research towards full dependent types no? I doubt that it will be a good thing to include full dependent types into a language with partial functions like Haskell. Conor, is Epigram currently under development? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Microsoft PhD Scholarship at Strathclyde
Am Samstag, 14. März 2009 14:51 schrieb Conor McBride: Conor, is Epigram currently under development? We've even stopped working on the engine and started working on the chassis. I'm in an intensive teaching block until the end of April, but from May it becomes Priority. The Reusability and Dependent Types project studentship will hopefully bring an extra pair of hands, come October. This sounds good! I don't see any conflict -- indeed I see considerable synergy -- in working simultaneously on the experimental frontier of dependent type systems and on the pragmatic delivery of their basic benefits via a much more established language like Haskell. Indeed, I think we'll learn more readily about the engineering realities of developing applications with dependent types by doing plenty of the latter. This makes sense indeed. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Natural Numbers: Best implementation?
Am Samstag, 14. März 2009 23:33 schrieben Sie: On Fri, 13 Mar 2009, Wolfgang Jeltsch wrote: Class instances should satisfy certain laws. (Although these laws are often not stated explicitely, they are assumed to hold by users of the class and they should hold to make the instance sensible.) In the case of Num, I would expect num + negate num to equal num. equal zero ? Exactly. Best wishes, Wolfgang ___ 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
Am Dienstag, 17. März 2009 05:09 schrieb wren ng thornton: a...@spamcop.net wrote: Or to put it another way, category theory is the pattern language of mathematics. Indeed. Though, IMO, there's a distinction between fairly banal things (e.g. monoids), Monoids aren’t a concept of category theory. There are a generalization of groups. So they more belong to group theory. By the way, the documentation of Control.Category says that a category is a monoid (as far as I remember). This is wrong. Category laws correspond to monoid laws but monoid composition is total while category composition has the restriction that the domain of the first argument must match the codomain of the second. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
categories and monoids (was: Re: [Haskell-cafe] Design Patterns by Gamma or equivalent)
Am Dienstag, 17. März 2009 10:54 schrieben Sie: Wolfgang Jeltsch g9ks1...@acme.softbase.org writes: By the way, the documentation of Control.Category says that a category is a monoid (as far as I remember). This is wrong. Category laws correspond to monoid laws but monoid composition is total while category composition has the restriction that the domain of the first argument must match the codomain of the second. I'm reading the Barr/Wells slides at the moment, and they say the following: Thus a category can be regarded as a generalized monoid, What is a “generalized monoid”? According to the grammatical construction (adjective plus noun), it should be a special kind of monoid, like a commutative monoid is a special kind of monoid. But then, monoids would be the more general concept and categories the special case, quite the opposite of how it really is. A category is not a “generalized monoid” but categories (as a concept) are a generalization of monoids. Each category is a monoid, but not the other way round. A monoid is clearly defined as a pair of a set M and a (total) binary operation over M that is associative and has a neutral element. So, for example, the category of sets and functions is not a monoid. First, function composition is not total if you allow arbitrary functions as its arguments. Second, the collection of all sets is not itself a set (but a true class) which conflicts with the above definition which says that M has to be a set. or a 'monoid with many objects' What is a monoid with many objects? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type equality proof
Am Dienstag, 17. März 2009 11:49 schrieb Yandex: data (a :=: a') where Refl :: a :=: a Comm :: (a :=: a') - (a' :=: a) Trans :: (a :=: a') - (a' :=: a'') - (a :=: a'') I don’t think, Comm and Trans should go into the data type. They are not axioms but can be proven. Refl says that each type equals itself. Since GADTs are closed, Martijn’s definition also says that two types can *only* be equal if they are actually the same. Here are the original definition and the proofs of comm and trans. Compiles fine with GHC 6.10.1. data (a :=: a') where Refl :: a :=: a comm :: (a :=: a') - (a' :=: a) comm Refl = Refl trans :: (a :=: a') - (a' :=: a'') - (a :=: a'') trans Refl Refl = Refl Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: categories and monoids
Am Dienstag, 17. März 2009 16:32 schrieben Sie: On Tue, 2009-03-17 at 13:06 +0100, Wolfgang Jeltsch wrote: A category is not a “generalized monoid” but categories (as a concept) are a generalization of monoids. Each category is a monoid, but not the other way round. You mean ``each monoid is a category, but not the other way round''. Exactly. :-) What is a monoid with many objects? A categorical definition of a monoid (that is, a plain old boring monoid in Set) is that it is a category with a single object. A category is thus a monoid with the restriction to a single object lifted :) Okay. Well, a monoid with many objects isn’t a monoid anymore since a monoid has only one object. It’s the same as with: “A ring is a field whose multiplication has no inverse.” One usually knows what is meant with this but it’s actually wrong. Wrong for two reasons: First, because the multiplication of a field has an inverse. Second, because the multiplication of a ring is not forced to have no inverse but may have one. It reminds me of a definition of “constant” in programming languages which occured in some literature: “A constant is a variable whose value cannot be changed.” :-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: categories and monoids
Am Dienstag, 17. März 2009 18:43 schrieben Sie: On Tue, Mar 17, 2009 at 5:06 AM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: What is a “generalized monoid”? According to the grammatical construction (adjective plus noun), it should be a special kind of monoid There's no such implication in English. The standard example used by linguists is fake gun. Okay, but this is a corner case isn’t it? And the phrase “generalized monoid” has another problem. It’s not a single monoid that is generalized but the “monoid concept”. The class of monoids is extended to become the class of categories. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: categories and monoids
Am Mittwoch, 18. März 2009 05:36 schrieb wren ng thornton: Wolfgang Jeltsch wrote: Am Dienstag, 17. März 2009 10:54 schrieben Sie: I'm reading the Barr/Wells slides at the moment, and they say the following: Thus a category can be regarded as a generalized monoid, What is a “generalized monoid”? According to the grammatical construction (adjective plus noun), it should be a special kind of monoid, like a commutative monoid is a special kind of monoid. But then, monoids would be the more general concept and categories the special case, quite the opposite of how it really is. Usually in math texts a Y is a generalized X means exactly Ys are a generalization of Xs, and thus Y is the larger class of objects got by relaxing some law in X. It's a description, not a name. E.g. Hilbert space is a generalized Euclidean space, Heyting algebras are generalized Boolean algebras, modules are generalized vector spaces, etc. I know these phrases but I always considered them as something, mathematicians use when they talk to each other informally, not what they would write in a book. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type equality proof
Am Dienstag, 17. März 2009 21:51 schrieben Sie: On Tue, Mar 17, 2009 at 6:14 AM, Wolfgang Jeltsch wrote: Am Dienstag, 17. März 2009 11:49 schrieb Yandex: data (a :=: a') where Refl :: a :=: a Comm :: (a :=: a') - (a' :=: a) Trans :: (a :=: a') - (a' :=: a'') - (a :=: a'') I don’t think, Comm and Trans should go into the data type. They are not axioms but can be proven. Refl says that each type equals itself. Since GADTs are closed, Martijn’s definition also says that two types can *only* be equal if they are actually the same. Here are the original definition and the proofs of comm and trans. Compiles fine with GHC 6.10.1. data (a :=: a') where Refl :: a :=: a comm :: (a :=: a') - (a' :=: a) comm Refl = Refl trans :: (a :=: a') - (a' :=: a'') - (a :=: a'') trans Refl Refl = Refl These two theorems should be in the package. But they should not be data constructors. Best wishes, Wolfgang ___ 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!
Am Dienstag, 17. März 2009 16:55 schrieb Eelco Lempsink: We'll see. Worst case: nobody votes (with 123 votes at this moment, I don't think that will be the problem). Second worst case: most people don't have/take the time to order a bit, so it turns into a majority vote. Or there are many people like me who won’t vote at all because the process is so difficult and time-consuming. :-( That said, you're absolutely right the visual feedback of the voting system is suboptimal. I'd be very interested in seeing a good UI for this sort of task. I imagine it'd be pretty close to printing everything on small pieces of paper and ordering them by hand ;) A good UI is what we need here. Maybe someone can write a simple app that does the following: * download the logos from the Haskell web server * present the user pairs of logos and let him decide which one of the two presented logos he likes better * shows a progress bar during voting * presents the voting result for easy entering into the webpage Best wishes, Wolfgang ___ 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!
Am Mittwoch, 18. März 2009 10:03 schrieb Benjamin L.Russell: Just go through the list, choose your top favorite, and assign rank 1 to it; Is rank 1 the best or the worst? I thought it would be the worst so I would probably have voted exactly the opposite way than I wanted to. :-( Best wishes, Wolfgang ___ 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!
Am Dienstag, 17. März 2009 21:08 schrieb Robin Green: 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. If you announce it on the mailing list, I might use it. By the way, when will the voting period be over? Best wishes, Wolfgang ___ 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!
Am Mittwoch, 18. März 2009 03:22 schrieb Robin Green: I'm afraid it is entirely terminal-based (i.e. text only), so it doesn't show the pictures. Hmm, this doesn’t help me since I’ve already written a terminal-based app. See attachement. However, no guarantees that this app works as intended. The preferences shown by the app are currently meant to stand for better logos if they are lower. So 1 is the winner, not 113. Well, the terminal-based app is still not enough for me since it’s way too time-consuming to always lookup the pictures. You should have a GUI showing the pictures and allowing you to select the better one of a pair by a single click. Best wishes, Wolfgang module Main ( main ) where import List hiding (sort) main :: IO () main = do putStr Number of items: itemCount - fmap read getLine sorted - sort (\val1 val2 - do putStr $ Is++ show val1 ++ better than ++ show val2 ++ ? initAnswer - getLine getDecision initAnswer) [1..itemCount] putStr $ unlines [show val ++ has preference ++ show rank | (val,rank) - sortBy (\(val1,rank1) (val2,rank2) - compare val1 val2) $ zip sorted [1..itemCount]] getDecision :: String - IO Bool getDecision n = return False getDecision y = return True getDecision _ = do putStr Illegal answer. Try again. answer - getLine getDecision answer sort :: (Monad monad) = (val - val - monad Bool) - [val] - monad [val] sort compare []= return [] sort compare [val] = return [val] sort compare vals = let (part1,part2) = dissociate vals in do sorted1 - sort compare part1 sorted2 - sort compare part2 merge compare sorted1 sorted2 dissociate :: [val] - ([val],[val]) dissociate [] = ([],[]) dissociate [val]= ([val],[]) dissociate (val1 : val2 : vals) = let (subpart1,subpart2) = dissociate vals in (val1 : subpart1,val2 : subpart2) merge :: (Monad monad) = (val - val - monad Bool) - [val] - [val] - monad [val] merge compare [] [] = return [] merge compare vals1 [] = return vals1 merge compare [] vals2 = return vals2 merge compare (val1 : vals1) (val2 : vals2) = do before - compare val1 val2 if before then do subresult - merge compare vals1 (val2 : vals2) return (val1 : subresult) else do subresult - merge compare (val1 : vals1) vals2 return (val2 : subresult) ___ 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!
Am Mittwoch, 18. März 2009 13:31 schrieben Sie: On Wed, Mar 18, 2009 at 04:36, Wolfgang Jeltsch wrote: Am Mittwoch, 18. März 2009 10:03 schrieb Benjamin L.Russell: Just go through the list, choose your top favorite, and assign rank 1 to it; Is rank 1 the best or the worst? The condorcet info page makes it clear that higher is better. http://www.cs.cornell.edu/w8/~andru/civs/rp.html So assigning rank 1 to my favorite, as Benjamin suggested, might not be the best idea. :-( I hope, everyone who voted did it the right way. Best wishes, Wolfgang ___ 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!
Am Donnerstag, 19. März 2009 03:53 schrieb Benjamin L.Russell: Therefore, rank 1 is the best. This is quite the opposite of what Denis Bueno said. :-( Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: categories and monoids
Am Mittwoch, 18. März 2009 15:17 schrieben Sie: Wolfgang Jeltsch schrieb: Okay. Well, a monoid with many objects isn’t a monoid anymore since a monoid has only one object. It’s the same as with: “A ring is a field whose multiplication has no inverse.” One usually knows what is meant with this but it’s actually wrong. Wrong for two reasons: First, because the multiplication of a field has an inverse. Second, because the multiplication of a ring is not forced to have no inverse but may have one. “A ring is like a field, but without a multiplicative inverse” is, in my eyes, an acceptable formulation. We just have to agree that “without” here refers to the definition, rather than to the definitum. Note that you said: “A ring is *like* a field.”, not “A ring is a field.” which was the formulation, I criticized above. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: categories and monoids
Am Donnerstag, 19. März 2009 13:58 schrieben Sie: An easier idea to think about would be to categorize most adjectives applied to mathematical constructs into traits and cotraits. A trait refines a notion and a cotrait broadens the definition. When talking about a commutative ring, commutativity is a trait, it narrows the definition of the ring, adding a requirement of commutativity to the multiplication operation. When talking about semi rings, semi is a cotrait. It broadens the definition of a ring, removing the requirement that addition form a group, weakening it to merely require a monoid. Is “semi” and adjective at all? In German, we say “halb” instead of “semi” and the semi ring becomes a Halbring. Note that “halb” and “ring” are written toghether which means that “Halbring” is a compound noun. (We always write compound nouns as a single word, e.g., “Apfelsaft” for “apple juice”). So at least in German (which shares common roots with English), the “halb” is not considered an adjectiv. “halb” means “half”, so a “Halbring” is just half of a ring – not a special ring but less than a ring. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Elerea, another FRP library
Am Freitag, 10. April 2009 18:41 schrieb Patai Gergely: is based on some unsafePerformIO dark magic (that might easily break depending on many factors) I wonder if this breaks referential transparency. Say, you define a signal s and use s twice in some expression. s may be evaluated once and it maybe evaluated twice. Does this make a difference? In the Haddock docs, you say that repeated evaluation of the same value is prevented by caching. However, caching probably only works if the signal in question is only evaluated once. If it’s evaluated twice, the second “instance” probably cannot reuse cached values of the first “instance”. Is it possible that thereby the second “instance” has different values than the first one? A well known FRP problem is that the values of a signal with internal state (an accumulating signal) depend on the time when the signal is started, i.e., when accumulation starts. When are your signals started? At evaluation time? If yes, doesn’t this mean that the meaning of a signal depends on evaluation time so that evaluating the same signal expression twice actually results in two different signals? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Elerea, another FRP library
Am Dienstag, 14. April 2009 11:33 schrieb Patai Gergely: and then the integration of a Grapefruit-like and a Reactive-like system could be the ultimate solution in the long run. What do you think, Grapefruit is lacking, compared to Reactive? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Elerea, another FRP library
Am Samstag, 11. April 2009 16:57 schrieb Patai Gergely: Any idea how Elerea compares to Grapefruit? It's great to see a lot of competition in the FRP arena, but I hope in the end this results in a really usable and scalable FRP system for Haskell :-) I think Wolfgang can judge this better, because I don't really know the innards of Grapefruit, I didn’t have a deep look at Elerea so far but looked at the Haddock docs. If I understand correctly, Elerea’s signals construct mutable variables for caching their current values when they are evaluated. This happens using unsafePerformIO. Grapefruit’s DSignals and SSignals use a purely functional data structure to represent several possible future values of whom only the ones which are actually occuring are evaluated. This data structure is created using unsafeInterleaveIO. So Elerea seems to have to take special care to not break referential transparency. Grapefruit has to take care only with CSignals since only these are using unsafePerformIO internally. Since Grapefruit uses ordinary expression evaluation for evaluating signal values, it can probably make use of certain compiler optimizations. Elerea’s evaluation seems to be driven by hand-coded IO actions so that use of such compiler optimizations is certainly not possible. Both Grapefruit and Elerea probably need a way to fix a signal to a specific starting time. Grapefruit does this using era type parameters. Elerea doesn’t seem to do anything about this at the moment. Patai, could you please correct me where I’m wrong and clarify the points which are still unclear to me? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: Elerea, another FRP library
Am Mittwoch, 15. April 2009 09:03 schrieb Achim Schneider: I don't think using dirty tricks to implement FRP deserves flak, at all, from my POV, it sounds like complaining that the IO monad is implemented using C... meaning that if you're that close to bare thunks, you have every right to use any means necessary to make them behave properly. It depends. Using unsafe stuff internally, might be acceptable and sometimes necessary. I also use unsafePerformIO in Grapefruit for implementing CSignals although I’m not very comfortable with this. On the other hand, breaking referential transparency in the external interface is a very bad idea, in my opinion. Actually, this means that the library user would have to turn certain compiler optimizations off to get the intended behavior. Just have a look at the Haddock docs of unsafePerformIO. In my earlier years of Haskell programming, I thought that unsafePerformIO is not too bad but I had to discover that it can quickly lead to a catastrophe. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-atomic atoms for type-level programming
Am Dienstag, 14. April 2009 20:01 schrieb Tillmann Rendel: How is the need for a common import for 'data TTrue; data TFalse' different then the need for a common import for 'data Bool = True | False'? Why not say data True data False, instead of data TTrue data TFalse? I don’t see the reason why we should insert the “T”. Data constructors are in a different namespace than type constructors. By the way, the grapefruit-records package imports type-level, only to not define its own type-level booleans but to reuse “common” types whereas I considered type-level as the standard type level programming library. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] package cache being out of date
Hi, I have a freshly installed Haskell Platform 2010.2.0.0 on Windows 7. When I run ghc-pkg list, I get the following message (besides the expected package info): WARNING: cache is out of date: C:/Program Files (x86)/Haskell Platform/2010.2.0.0\lib\package.conf.d\package.cache use 'ghc-pkg recache' to fix. What does this mean? Is this harmful? (In principal, I could just run ghc-pkg recache, but the installation is replicated on about 20 machines, and I don’t have admin rights on these.) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
