[Haskell-cafe] Re: Type Families: deleting from HList
Serguey Zefirov wrote:
Is it possible to delete an element from heterogenous list using type
families alone?
I can do it using multiparameter type classes:
class Del a list result
instance Del a (a,list) list
instance Del a list list' = Del a (a',list) list'
instance Del a () ()
I'm afraid you'll find that class quite difficult to use: lots of type
annotations will be required. For example, if we define
del :: Del a li lo = a - li - lo
del = undefined
and write
test1 = del True ('a',(True,()))
the compiler will complain because it doesn't know which instance to
choose.
BTW, since GHC checks for overlapping lazily, the fact that GHC
accepts a set of instance declarations does not tell that the
instances `work'. The problems may lurk, becoming apparent when we
define values that attempt to use the instances.
In order for something like Del to be useful, functional dependencies
are needed. It is easy to see that Del uses overlapping
instances. That answers the question: since type families do not
support overlapping instances, one cannot re-write Del using type
families alone.
One may ask is it possible to define some sort of type inequality
using type families. And the answer is yes, recently discussed at
http://www.haskell.org/pipermail/haskell-cafe/2010-July/080473.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hsb2hs preprocessor looking for a maintainer
Hi, out of a discussion in haskell-devscripts, John MacFarlane wrote a very nice tool, called hsb2hs, that allows you to include any binary (or text) file as a constant in your program. This can be useful in various instances, e.g. when creating programs that should not depend on data files installed in the right location, or larger, multi-line strings that you’d like to edit on their own, not as a long string constant in the Haskell file (I once wished I had this when including some CSS in a CGI script written in Haskell). The current code is on http://github.com/jgm/hsb2hs and you can read more about it in the subthread starting at http://lists.debian.org/debian-haskell/2010/08/msg00013.html Unfortunately, John says that he does not have time to develop it further, and I probably don’t either. Is there anyone here interested in picking up the projects? Possible TODOs involve the optimization I suggested in http://lists.debian.org/debian-haskell/2010/08/msg00015.html and making Cabal support .hsb files directly (just as with .y etc. files). Greetings, Joachim -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer
On 4 August 2010 07:42, Joachim Breitner m...@joachim-breitner.de wrote:
out of a discussion in haskell-devscripts, John MacFarlane wrote a very
nice tool, called hsb2hs, that allows you to include any binary (or
text) file as a constant in your program.
When I've needed to do this in the past, I've used a simple bit of
Template Haskell:
module Embed where
import Language.Haskell.TH
embedFile :: String - ExpQ
embedFile fp = runIO (readFile fp) = stringE
Here is how you use it to implement a (cheaty sort of) quine:
{-# LANGUAGE TemplateHaskell #-}
import Embed
foo = $(embedFile UseEmbed.hs)
main = putStrLn foo
Cheers,
Max
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer
Hi, Am Mittwoch, den 04.08.2010, 08:05 +0100 schrieb Max Bolingbroke: On 4 August 2010 07:42, Joachim Breitner m...@joachim-breitner.de wrote: out of a discussion in haskell-devscripts, John MacFarlane wrote a very nice tool, called hsb2hs, that allows you to include any binary (or text) file as a constant in your program. When I've needed to do this in the past, I've used a simple bit of Template Haskell: the problem is that Template Haskell does not work on all architectures, so the Debian people prefer solutions that avoid TH if it is not needed. Yet another solution would be to create an ELF file contiangin the binary blob as described in http://burtonini.com/blog/computers/ld-blobs-2007-07-13-15-50 and link to it using FFI. But I’m not sure if there are any gains. Maybe for very large files where even _parsing_ the string literal by ghc takes too long. Greetings, Joachim -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can Haskell do everyting as we want?
Hi Qi, have a look at brainfuck language. Its turing complete as Python, Haskell, etc are. Then you'll learn that the quesntion Can I do everything possible is not at all important. You have to ask instead: Can I complete my task in reasonable time and with reasonable runtime performance etc. For most use cases Haskell is a good choice - the only real things I'm missing are - nice stack traces - completion support - because I find it relaxing not having to looking all names. This could be fixed to some extend though.. If you want to target JavaScript in browsers I'm not sure whether Haskell is the best fit either. If I were you I'd learn some Haskell - I don't think you'll regret it. By reading the mailinglists, joining the chat room ocassionally you'll learn a lot. But if you have a real task to solve - have a look whether existing solutions exist - thus Use the best tool for the given problem. Because recoding can sometimes take longer. And eg the Java community has been much bigger in the past - thus there are more libraries available. Eg Haskell has no htmlunit yet which interpretes JavaScript and simulates a headless browser etc. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
Thanks. In fact, the server lookup is needed only to make initial contact to another node, or better - as the distributed architecture is transparent to the app programmer - to make initial contact to another TVar. This initial TVar would then be able to distribute more TVars. It could be typed something like: data initTVar a = TVar [TVar a] Also, once you have made contact (i.e. lookup from name server) to a TVar, you can access it as if it were locally defined. It does not matter if the name server then fails or not. Obviously, a failed name server would not allow to make new contacts. Then your distributed program would need to create redundant name servers and make sure their IP address stays the same or is known to every node. Frank Am 03.08.2010 um 21:59 schrieb Alberto G. Corona: That is really nice. The architecture seems to be around a single server that bring lookup services, so there is a single point of failure. I´m thinking on cloud computing. Can be extended to have backup servers somehow ? Alberto. 2010/8/3 Christopher Done chrisd...@googlemail.com This is very cool, thanks for writing it. I will try it when I get home tonight. On 3 August 2010 10:35, Frank Kupke f...@informatik.uni-kiel.de wrote: Hi, DSTM is an implementation of a robust distributed Software Transactional Memory (STM) library for Haskell. Many real-life applications are distributed by nature. Concurrent applications may profit from robustness added by re-implementation as distributed applications. DSTM extends the STM abstraction to distributed systems and presents an implementation efficient enough to be used in soft real-time applications. Further, the implemented library is robust in itself, offering the application developer a high abstraction level to realize robustness, hence, significantly simplifying this, in general, complex task. The DSTM package consists of the DSTM library, a name server application, and three sample distributed programs using the library. Provided are a simple Dining Philosophers, a Chat, and a soft real-time Bomberman game application. Distributed communication is transparent to the application programmer. The application designer uses a very simple name server mechanism to set up the system. The DSTM library includes the management of unavailable process nodes and provides the application with abstract error information thus facilitating the implementation of robust distributed application programs. For usage please look into the documentation file: DSTMManual.pdf. The package including the documentation can be found on: http://hackage.haskell.org/package/DSTM-0.1.1 Best regards, Frank Kupke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
data InitTVar a = TVar [TVar a] sorry Am 04.08.2010 um 10:04 schrieb Frank Kupke: Thanks. In fact, the server lookup is needed only to make initial contact to another node, or better - as the distributed architecture is transparent to the app programmer - to make initial contact to another TVar. This initial TVar would then be able to distribute more TVars. It could be typed something like: data initTVar a = TVar [TVar a] Also, once you have made contact (i.e. lookup from name server) to a TVar, you can access it as if it were locally defined. It does not matter if the name server then fails or not. Obviously, a failed name server would not allow to make new contacts. Then your distributed program would need to create redundant name servers and make sure their IP address stays the same or is known to every node. Frank Am 03.08.2010 um 21:59 schrieb Alberto G. Corona: That is really nice. The architecture seems to be around a single server that bring lookup services, so there is a single point of failure. I´m thinking on cloud computing. Can be extended to have backup servers somehow ? Alberto. 2010/8/3 Christopher Done chrisd...@googlemail.com This is very cool, thanks for writing it. I will try it when I get home tonight. On 3 August 2010 10:35, Frank Kupke f...@informatik.uni-kiel.de wrote: Hi, DSTM is an implementation of a robust distributed Software Transactional Memory (STM) library for Haskell. Many real-life applications are distributed by nature. Concurrent applications may profit from robustness added by re-implementation as distributed applications. DSTM extends the STM abstraction to distributed systems and presents an implementation efficient enough to be used in soft real-time applications. Further, the implemented library is robust in itself, offering the application developer a high abstraction level to realize robustness, hence, significantly simplifying this, in general, complex task. The DSTM package consists of the DSTM library, a name server application, and three sample distributed programs using the library. Provided are a simple Dining Philosophers, a Chat, and a soft real-time Bomberman game application. Distributed communication is transparent to the application programmer. The application designer uses a very simple name server mechanism to set up the system. The DSTM library includes the management of unavailable process nodes and provides the application with abstract error information thus facilitating the implementation of robust distributed application programs. For usage please look into the documentation file: DSTMManual.pdf. The package including the documentation can be found on: http://hackage.haskell.org/package/DSTM-0.1.1 Best regards, Frank Kupke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can Haskell do everyting as we want?
Before entering haskell, please read our disclaimer: http://www.haskell.org/pipermail/haskell-cafe/2010-June/079044.html You've been warned * * 2010/8/4 Zura_ x...@gol.ge As already noted here, Haskell is a general purpose language, but you should take it with a grain of salt. For instance, you can nail with a laptop (provided that you hit the place where a HDD is located), but you prefer a hammer :) One thing is if you do it only for enjoyment, in this case you can even develop 3D shooter game in Haskell, but when it comes to production/real world use, I think it is better to maintain right tool for the right job attitude. Regards, Zura Qi Qi-2 wrote: Is there anyone happen to come into any tasks that haskell is not able to achieve? -- View this message in context: http://old.nabble.com/can-Haskell-do-everyting-as-we-want--tp29341176p29342871.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
This looks very cool! It would be nice to put the pdf online somewhere, and add a link from the package documentation. Also, the chat client seems to have some problems with output buffering on my system (OS X, GHC 6.12). -chris On 3 aug 2010, at 10:35, Frank Kupke wrote: Hi, DSTM is an implementation of a robust distributed Software Transactional Memory (STM) library for Haskell. Many real-life applications are distributed by nature. Concurrent applications may profit from robustness added by re-implementation as distributed applications. DSTM extends the STM abstraction to distributed systems and presents an implementation efficient enough to be used in soft real-time applications. Further, the implemented library is robust in itself, offering the application developer a high abstraction level to realize robustness, hence, significantly simplifying this, in general, complex task. The DSTM package consists of the DSTM library, a name server application, and three sample distributed programs using the library. Provided are a simple Dining Philosophers, a Chat, and a soft real-time Bomberman game application. Distributed communication is transparent to the application programmer. The application designer uses a very simple name server mechanism to set up the system. The DSTM library includes the management of unavailable process nodes and provides the application with abstract error information thus facilitating the implementation of robust distributed application programs. For usage please look into the documentation file: DSTMManual.pdf. The package including the documentation can be found on: http://hackage.haskell.org/package/DSTM-0.1.1 Best regards, Frank Kupke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
Frank Kupke wrote: For usage please look into the documentation file: DSTMManual.pdf. 1. Any danger of puting this somewhere I can read it without having to download and manually unpack the Hackage tarball? 2. Since DSTM depends on the Unix package, I presume this won't work on Windows. (?) OOC, what does it use Unix for? 3. It is unclear to me what happens in the event of a communications failure. The documentation says an exception is thrown, but does the running transaction rollback or just retry or...? (The documentation seems to suggest that it might actually *commit* in spite of a communications failure, which sounds wrong.) Also, when is failure detected? Is it only when a transaction tries to access the variable? 4. What network transport does this thing use? TCP? UDP? What port numbers? 5. How does it work? Does it spawn a Haskell thread for each machine connection or something? 6. The past tense of join is joined, not joint. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
On Wed, Aug 4, 2010 at 06:00, Mark Lentczner ma...@glyphic.com wrote: The Haddock team has spent the last few months revamping the look of the generated output. We're pretty close to done, but we'd like to get the community's input before we put it in the main release. Please take a look, and then give us your feedback through a short survey Sample pages: http://www.ozonehouse.com/mark/snap-xhtml/index.html I really like it, especially the synopsis tab on the right. Brilliant! The TOC is nice too! The over-all impression is that it doesn't look as auto-generated as the old style. Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html Also very good looking. Does the current stable version of Haddock really create a frame version? I've never seen one before... /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
2010/8/4 Mark Lentczner ma...@glyphic.com: The Haddock team has spent the last few months revamping the look of the generated output. We're pretty close to done, but we'd like to get the community's input before we put it in the main release. Please take a look, and then give us your feedback through a short survey Sample pages: http://www.ozonehouse.com/mark/snap-xhtml/index.html Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html Survey: http://spreadsheets.google.com/viewform?formkey=dHcwYzdMNkl5WER1aVBXdV9HX1l5U3c6MQ Short link to same survey: http://bit.ly/9Zvs9B I think there is a typo in the question about the looks 3) and 4) (the -alt and non-alt version). The -alt is the one with the titles and the non-alt deosn't have them. But the question states the opposite. The rendering is really great, thanks for it. Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] design question: decision tree from Programming Collective Intelligence
I have added the permutation parsers from uulib to uu-parsinglib: http://hackage.haskell.org/packages/archive/uu-parsinglib/2.5.1.1/doc/html/Text-ParserCombinators-UU-Perms.html, where you find reference to the paper Doaitse On 22 jun 2010, at 09:24, Stephen Tetley wrote: Hello Maybe permutation trees are a viable starting point? See the paper Parsing Permutation Phrases which appears to be on CiteSeer. Some slides are also here - the data type definitions and Functor instance for permutation trees are on page 18 (pdf index page 19): http://www.comlab.ox.ac.uk/jeremy.gibbons/wg21/meeting56/loeh-slides.pdf An alternative implementation for applicative functors is here: http://hackage.haskell.org/package/action-permutations Note the use of existentials here is pretty cunning, I didn't get very far the time I attempted to use the technique for my own purposes. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can Haskell do everyting as we want?
Just to clarify, I mean: Haskell may be seriously addictive. Sounds like a joke, but it is not. I do not recommend it for coding something quick and dirty. 2010/8/4 Alberto G. Corona agocor...@gmail.com Before entering haskell, please read our disclaimer: http://www.haskell.org/pipermail/haskell-cafe/2010-June/079044.html You've been warned * * 2010/8/4 Zura_ x...@gol.ge As already noted here, Haskell is a general purpose language, but you should take it with a grain of salt. For instance, you can nail with a laptop (provided that you hit the place where a HDD is located), but you prefer a hammer :) One thing is if you do it only for enjoyment, in this case you can even develop 3D shooter game in Haskell, but when it comes to production/real world use, I think it is better to maintain right tool for the right job attitude. Regards, Zura Qi Qi-2 wrote: Is there anyone happen to come into any tasks that haskell is not able to achieve? -- View this message in context: http://old.nabble.com/can-Haskell-do-everyting-as-we-want--tp29341176p29342871.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
Magnus Therning mag...@therning.org writes: On Wed, Aug 4, 2010 at 06:00, Mark Lentczner ma...@glyphic.com wrote: The Haddock team has spent the last few months revamping the look of the generated output. We're pretty close to done, but we'd like to get the community's input before we put it in the main release. Please take a look, and then give us your feedback through a short survey Sample pages: http://www.ozonehouse.com/mark/snap-xhtml/index.html I really like it, especially the synopsis tab on the right. Brilliant! The TOC is nice too! The over-all impression is that it doesn't look as auto-generated as the old style. Agreed; I'm also glad that the usage of a middle column isn't a fixed width but resizes as the text resizes (the lack of this is something that annoys me to no end on some websites). Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html Also very good looking. Does the current stable version of Haddock really create a frame version? I've never seen one before... There is, but I for one don't use it (and there was an email sent out in May asking if anyone did: http://www.mail-archive.com/haskell-cafe@haskell.org/msg75269.html ). I quite like this new approach, however, but with one caveat: the empty frame on the bottom left at default. Especially with my weird firefox setup (which has almost grown organically over the years and should really be wiped), it doesn't display too well; is it possible to have _something_ there by default just to make it look more interesting (Haskell logo, a message saying stuff will appear here when you click on something above, etc.) ? However, I would still be highly tempted to use the framed version by default with that new layout. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why do unsafe foreign calls block other threads?
On Wed, Aug 4, 2010 at 1:50 AM, Donn Cave d...@avvanta.com wrote: Quoth John Meacham j...@repetae.net, It is more an accident of ghc's design than anything, the same mechanism that allowed threads to call back into the runtime also allowed them to be non blocking so the previously used 'safe' and 'unsafe' terms got re-used. personally, I really don't like those terms, they are non-descriptive in terms of what they actually mean and presuppose a RTS similar to ghcs current design. 'reentrant' and 'blocking' which could be specified independently would be better and would be more future-proof against changes in the RTS or between compilers. Is the concurrency issue documented somewhere? What does `non blocking' mean, and why would it not just always be that way? In my situation, thread creation and dispatch happens in foreign library code, and execution in the Haskell runtime happens _only_ via callbacks. I don't need those callbacks to compute in parallel, generally, but it would be disappointing to hear that a callback strictly blocks execution of any others for its entire duration, for example even during a potentially slow I/O. (Will test for that, but not sure whether it would be conclusive since the system seems to be slightly broken at this point - need to disable RTS timer signals ( -V0 ) to survive externally generated thread dispatch events.) This is slightly out of date (GHC couldn't multiplex haskell threads onto multiple OS threads at the time, but now does), but basically spells out the situation: http://www.haskell.org/~simonmar/papers/conc-ffi.pdf As for the specific question, callbacks do happen concurrently. thanks, Donn Cave, d...@avvanta.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Work is punishment for failing to procrastinate effectively. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can Haskell do everyting as we want?
Marc Weber marco-owe...@gmx.de writes: Hi Qi, have a look at brainfuck language. Its turing complete as Python, Haskell, etc are. Then you'll learn that the quesntion Can I do everything possible is not at all important. You have to ask instead: Can I complete my task in reasonable time and with reasonable runtime performance etc. And in a way that makes the code maintainable. For most use cases Haskell is a good choice - the only real things I'm missing are - nice stack traces - completion support - because I find it relaxing not having to looking all names. This could be fixed to some extend though.. If you mean whilst writing your code, this is an editor issue (I believe scion aims to help writing cross-editor utilities for things like this). ghci also has tab-completion, and ghc-mod provides such functionality in Emacs. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer
Joachim Breitner m...@joachim-breitner.de writes: Hi, Am Mittwoch, den 04.08.2010, 08:05 +0100 schrieb Max Bolingbroke: On 4 August 2010 07:42, Joachim Breitner m...@joachim-breitner.de wrote: out of a discussion in haskell-devscripts, John MacFarlane wrote a very nice tool, called hsb2hs, that allows you to include any binary (or text) file as a constant in your program. When I've needed to do this in the past, I've used a simple bit of Template Haskell: the problem is that Template Haskell does not work on all architectures, so the Debian people prefer solutions that avoid TH if it is not needed. Yeah, we've just come across this problem in Gentoo when dealing with how Haddock behaves when there's TH to be documented in some architectures :s -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
Ivan Lazar Miljenovic ivan.miljeno...@gmail.com writes: On Wed, Aug 4, 2010 at 06:00, Mark Lentczner ma...@glyphic.com wrote: Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html I quite like this new approach Dammit, I just realised as I went to do the survey that the old framed approach is almost identical to the new framed approach :s For some reason I thought it was different... :s -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer
On 4 August 2010 11:39, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Joachim Breitner m...@joachim-breitner.de writes: the problem is that Template Haskell does not work on all architectures, so the Debian people prefer solutions that avoid TH if it is not needed. Yeah, we've just come across this problem in Gentoo when dealing with how Haddock behaves when there's TH to be documented in some architectures :s I didn't know this: is there a corresponding GHC ticket? I can't find one, but I could just have chosen the wrong keywords. It seems like the right thing to do would just be to make TH work properly rather than maintain a special-purpose preprocessor. Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer
Max Bolingbroke batterseapo...@hotmail.com writes: On 4 August 2010 11:39, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Joachim Breitner m...@joachim-breitner.de writes: the problem is that Template Haskell does not work on all architectures, so the Debian people prefer solutions that avoid TH if it is not needed. Yeah, we've just come across this problem in Gentoo when dealing with how Haddock behaves when there's TH to be documented in some architectures :s I didn't know this: is there a corresponding GHC ticket? I can't find one, but I could just have chosen the wrong keywords. It seems like the right thing to do would just be to make TH work properly rather than maintain a special-purpose preprocessor. Not that I know of; all I know is that Sergei (aka slyfox) disabled building documentation (for libraries that come with GHC) on some architectures where ghci isn't available because of this. My understanding is that TH uses ghci (or something like it) to evaluate the expressions, and that when Haddock started understanding TH it also needed to run ghci to build documentation containing TH. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Software architecture
Hey there, I'm searching for software designs in Haskell ; for example, I have a pretty good ideo of how I would arrange my modules/classes (in ocaml/(java/c++)) and how they would all fit together to create, say, a website aspirator. But I don't have any clue of the right way to do it with Haskell. I don't need a solution for this example, I'd just like to see how to manage non-trivial code. I haven't found any pointers on the interwebs. On an unrelated note, what is the simplest way to get the llvm bitcode? I understand I can compile myself ghc but it there an easier way? Thanks a lot! -- Cp ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can Haskell do everyting as we want?
Marc Weber marco-owe...@gmx.de writes: Excerpts from Ivan Lazar Miljenovic's message of Wed Aug 04 12:37:29 +0200 2010: functionality in Emacs. I know - I patched the py backend for scion. I'm talking about: node.getParent().getParent().tabAttributes[value] Or (let's talk about a haskell example): pkgVersion $ package $ packageDescription It feels unnatural to complete this. How should this be done? I know that you can define your own .dot. operator, so that you can write it in (let's call it Java style): packageDescription .dot. package .dot. pkgVersion I don't get the point of this .dot. operator (which isn't even a valid operator). Without completion I have to get the type of packageDescription, then follow the structure until I find Version. Using tags and Vim that's fast. Still completion is a lot faster. Not really following your example here: you want something to write your code for you and read your mind to know what that code should be? My understanding of tab-completion in IDEs for Java, etc. is that it just displayed every single possible class method for a particular object value, and then did some kind of matching based upon what you typed to narrow down the list, not that it was type-based. I'm not talking about the universal put everything in scope completion thing - eg which Vim provides for some languages. I'm talking about really helpful context sensitive completion. I know its pretty hard to get this hard for Haskell - because type is determined by things you use. But the example I gave above is one which could be implemented easily. How is it easy? How would this mythical completer know which function to use? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer
On 4 August 2010 12:05, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Max Bolingbroke batterseapo...@hotmail.com writes: On 4 August 2010 11:39, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Joachim Breitner m...@joachim-breitner.de writes: the problem is that Template Haskell does not work on all architectures, so the Debian people prefer solutions that avoid TH if it is not needed. Yeah, we've just come across this problem in Gentoo when dealing with how Haddock behaves when there's TH to be documented in some architectures :s I didn't know this: is there a corresponding GHC ticket? I can't find one, but I could just have chosen the wrong keywords. It seems like the right thing to do would just be to make TH work properly rather than maintain a special-purpose preprocessor. Not that I know of; all I know is that Sergei (aka slyfox) disabled building documentation (for libraries that come with GHC) on some architectures where ghci isn't available because of this. My understanding is that TH uses ghci (or something like it) to evaluate the expressions, and that when Haddock started understanding TH it also needed to run ghci to build documentation containing TH. Correct. It also needs to be able to generate machine code from the currently compiled package and its dependencies. This is because ghci does not support some features, in particular unboxed tuples. Therefore, to be on the safe side, Haddock has to create (unoptimised) binary code as well. I believe the main reason why ghci isn't available on all platforms is the dynamic linker. I don't think it would be easy (or even feasible) to switch to something like 'ld', though. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- If it looks like a duck, and quacks like a duck, we have at least to consider the possibility that we have a small aquatic bird of the family Anatidae on our hands. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suggestions For An Intro To Monads Talk.
Hi,
aditya siram wrote:
For example in the beginning it was useful for me to think of monads
(and typeclasses really) as approximating Java interfaces.
Type classes are somewhat parallel to Java interfaces, but Monad is a
*specific* type class, so it should be somewhat parallel to a *specific*
Java interface, if at all.
Type classes are somewhat parallel to Java interfaces because a Java
interface
interface Foo {
Result method (Argument argument);
}
declares that there is a set of types so that every type T in that set
has an operation (T, Argument) - Result, with these operations all
implemented specifically to particular type T. In Haskell, the type class
class Foo t where
method : t - Argument - Result
expresses a similar concept. There are a number of differences though:
Firstly, in Java, calls to the method are late bound, while in Haskell,
they are early bound. However, a kind of late bound behavior can be
achieved using existentials.
Secondly, in Java, the receiver of the method has to be of type T, and T
may not appear at other positions in the type of the method, while in
Haskell, T may appear anywhere in the type of the method, even more then
once.
Finally, in Java, T has to be a proper type (of kind *), while in
Haskell, it may be an improper type (of a kind involving -).
Already for the type class Functor, these differences become relevant.
class Functor f where
fmap :: (a - b) - f a - f b
f has kind (* - *), and it is mentioned twice in the type of fmap.
Conclusion: While Haskell type classes have some similarities to Java
interfaces, the type class Functor (or Monad, if you like) is not that
similar to any Java interface, because it uses features specific to
Haskell type classes which are not available in Java interfaces.
Nevertheless, it may be helpful for a Java developer to understand that
Haskell type classes are more similar to Java interfaces than to Java
classes.
Tillmann
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
On Aug 4, 2010, at 5:11 AM, Magnus Therning wrote: Does the current stable version of Haddock really create a frame version? I've never seen one before... Yes it does. For example, the standaed GHC book packages doc has the frames version here: http://www.haskell.org/ghc/docs/6.12.2/html/libraries/frames.html Documentation on Hackage doesn't seems to be missing two of the generated files to enable the frames version to work for each package. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
After chatting with Chris privately it turned out that the confusion within the Chat example is partly because I did not find a good and simple solution for mixing user input and chat output asynchronously in one terminal stream. One can possibly do better, here. Also, apparently I left some debug flags active in the library which does not help to explore it. Sorry. You can turn debugging mode off by setting all debug flags to False in DebugBase.hs. I will correct that with the next update as well. As a quick fix to put the documentation online it can be downloaded from http://www-ps.informatik.uni-kiel.de/~frk/dstm.pdf, also available through my very rudimentary institute's web presence http://www.informatik.uni-kiel.de/prog/mitarbeiter/frank-kupke/. Regards, Frank Am 04.08.2010 um 10:43 schrieb Chris Eidhof: This looks very cool! It would be nice to put the pdf online somewhere, and add a link from the package documentation. Also, the chat client seems to have some problems with output buffering on my system (OS X, GHC 6.12). -chris On 3 aug 2010, at 10:35, Frank Kupke wrote: Hi, DSTM is an implementation of a robust distributed Software Transactional Memory (STM) library for Haskell. Many real-life applications are distributed by nature. Concurrent applications may profit from robustness added by re-implementation as distributed applications. DSTM extends the STM abstraction to distributed systems and presents an implementation efficient enough to be used in soft real-time applications. Further, the implemented library is robust in itself, offering the application developer a high abstraction level to realize robustness, hence, significantly simplifying this, in general, complex task. The DSTM package consists of the DSTM library, a name server application, and three sample distributed programs using the library. Provided are a simple Dining Philosophers, a Chat, and a soft real-time Bomberman game application. Distributed communication is transparent to the application programmer. The application designer uses a very simple name server mechanism to set up the system. The DSTM library includes the management of unavailable process nodes and provides the application with abstract error information thus facilitating the implementation of robust distributed application programs. For usage please look into the documentation file: DSTMManual.pdf. The package including the documentation can be found on: http://hackage.haskell.org/package/DSTM-0.1.1 Best regards, Frank Kupke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Software architecture
I think the general process is the same. You define your components, try to decouple them as much as possible and implement them. One thing that is different from other languages: try to write as much pure code as possible. This is great for creating composable components. There are several different ways to structure your programs. The Utrecht Haskell Compiler is structured using attribute grammars, which is (similar to) aspect-oriented programming. Another architectural pattern you see a lot is that a program is provided as a library and a very small main function. A very good example of this is XMonad. You could also look at http://www.haskell.org/haskellwiki/Haskell_in_industry, which gives some pointers to commercial projects and how they are structured. -chris On 4 aug 2010, at 13:07, Charles-Pierre Astolfi wrote: Hey there, I'm searching for software designs in Haskell ; for example, I have a pretty good ideo of how I would arrange my modules/classes (in ocaml/(java/c++)) and how they would all fit together to create, say, a website aspirator. But I don't have any clue of the right way to do it with Haskell. I don't need a solution for this example, I'd just like to see how to manage non-trivial code. I haven't found any pointers on the interwebs. On an unrelated note, what is the simplest way to get the llvm bitcode? I understand I can compile myself ghc but it there an easier way? Thanks a lot! -- Cp ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: can Haskell do everyting as we want?
My understanding of tab-completion in IDEs for Java, etc. is that it just displayed every single possible class method for a particular object value, and then did some kind of matching based upon what you typed to narrow down the list, not that it was type-based. With Eclipse, try something like (within some method) String s = foo; s. (stop after the dot) and you see only methods of String (and Object). To me, that seems very much type-based. Of course this requires the integration of parser and static analyzer with the editor - and you need to be able to parse and analyze partial programs. J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: can Haskell do everyting as we want?
Johannes Waldmann waldm...@imn.htwk-leipzig.de writes: My understanding of tab-completion in IDEs for Java, etc. is that it just displayed every single possible class method for a particular object value, and then did some kind of matching based upon what you typed to narrow down the list, not that it was type-based. With Eclipse, try something like (within some method) String s = foo; s. (stop after the dot) and you see only methods of String (and Object). To me, that seems very much type-based. Well, yes, it is every single possible class method for a String object. However, if you tried to do s.equalsIgnoreCase(, does it offer to insert every single String available and every function that could result in a String? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
Great! I like it a lot, but a couple of minor suggestions regarding the tree view of modules. I think it would be more attractive (and space-efficient) to have them indent a little less and to provide some sort of visual link, in the form of even subtle branches, from parents to children. A bit like http://origin.arstechnica.com/journals/linux.media/300/dolphin_tree_view.pngor similar. On Wed, Aug 4, 2010 at 7:00 AM, Mark Lentczner ma...@glyphic.com wrote: The Haddock team has spent the last few months revamping the look of the generated output. We're pretty close to done, but we'd like to get the community's input before we put it in the main release. Please take a look, and then give us your feedback through a short survey Sample pages: http://www.ozonehouse.com/mark/snap-xhtml/index.html Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html Survey: http://spreadsheets.google.com/viewform?formkey=dHcwYzdMNkl5WER1aVBXdV9HX1l5U3c6MQ Short link to same survey: http://bit.ly/9Zvs9B Thanks! - Mark Mark Lentczner http://www.ozonehouse.com/mark/ irc: MtnViewMark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer
On 4 August 2010 12:34, Thomas Schilling nomin...@googlemail.com wrote: I believe the main reason why ghci isn't available on all platforms is the dynamic linker. I don't think it would be easy (or even feasible) to switch to something like 'ld', though. AFAIK the current linker is meant to support Mach O, ELF and COFF, which should cover almost every platform GHC is able to run on. Now, it's not ideal that GHC maintains its own dynamic linker implementation, but if someone has discovered a bugs with it (or any other bug preventing TH from working) I'm sure GHC HQ would be interested in knowing. Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can Haskell do everyting as we want?
Ivan Lazar Miljenovic wrote:: My understanding of tab-completion in IDEs for Java, etc. is that it just displayed every single possible class method for a particular object value, and then did some kind of matching based upon what you typed to narrow down the list, not that it was type-based. Good completion is type based. For example, consider the following situations in Eclipse: (1) int foo = bar.cursor here (2) String foo = bar.cursor here In both cases, completion will only propose methods of String and its super class Object, so the type of the receiver is taken into account. Furthermore, the proposed methods will be ordered differently in (1) and (2). In (1), the list of proposed methods starts with methods returning int, while in (2), the list of proposed methods starts with methods returning String, so the type of the context is taken into account. I guess that it may be easier to implement effective completion for Java because in Java, completion-relevant context information is often to the left of the completion position. On the other hand, shouldn't constraint-based type inference à la Haskell be relatively easy to extend towards type-based completion? An IDE could infer the types of the holes in half-finished source code, and then try to unify the types of identifiers in scope with the type of the hole the programmer is typing in. If the resulting constraint system is consistent, the identifier should be proposed as a completion. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can Haskell do everyting as we want?
Rogan Creswick wrote: Haskell has very limited support for high-level Natural Language Processing (tokenization, sentence splitting, Named-entity recognition, etc...). Since the role of a general purpose language is relatively new for Haskell, there are many areas where Haskell is still an emerging language. So it is interesting that you say that about NLP, where Haskell is not only quite mature, but arguably the leading language today. For example, the EU's huge Molto project http://molto-project.eu/, which aims to provide automated real-time high-quality translation of a wide class of documents between all of the EU languages, is based on Haskell's GF http://grammaticalframework.org/. Coincidentally, just yesterday a company that markets one of the top semantic NLP products contacted me. They have decided to dump their entire Java code base, using older technologies such as the ones you mentioned. One of their leading candidates for a replacement language is Haskell. They told me, You see Haskell everywhere in NLP these days. See http://www.haskell.org/haskellwiki/Applications_and_libraries/Linguistics for links about NLP work in Haskell. That is a huge wiki page and hard to maintain, so some of the links are out of date, but you get the idea. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can Haskell do everyting as we want?
Tillmann Rendel ren...@informatik.uni-marburg.de writes: Ivan Lazar Miljenovic wrote:: My understanding of tab-completion in IDEs for Java, etc. is that it just displayed every single possible class method for a particular object value, and then did some kind of matching based upon what you typed to narrow down the list, not that it was type-based. Good completion is type based. For example, consider the following situations in Eclipse: (1) int foo = bar.cursor here (2) String foo = bar.cursor here In both cases, completion will only propose methods of String and its super class Object, so the type of the receiver is taken into account. Yes, it knows which class methods are available. But can it list every possible argument that a given class method needs? IMHO, that is a closer analogy/comparison to what type-based completion for Haskell would require. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: can Haskell do everyting as we want?
However, if you tried to do s.equalsIgnoreCase(, does it offer to insert every single String available and every function that could result in a String? well, try this: String s = foo; String t = bar; int u = 42; s.equalsIgnoreCase( it suggests s, t, and null (but not u), so this is again type-based. if you try completion on s.equalsIgnoreCase(t. then you see that those methods that return a String, are at the front of the completion list. J.W. signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: can Haskell do everyting as we want?
On 4 August 2010 23:13, Johannes Waldmann waldm...@imn.htwk-leipzig.de wrote: However, if you tried to do s.equalsIgnoreCase(, does it offer to insert every single String available and every function that could result in a String? well, try this: String s = foo; String t = bar; int u = 42; s.equalsIgnoreCase( it suggests s, t, and null (but not u), so this is again type-based. Huh, last time I tried an IDE for Java (which was admittedly quite a while ago) it wouldn't do anything like that... I stand corrected then. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
On 4 August 2010 10:11, Magnus Therning mag...@therning.org wrote: On Wed, Aug 4, 2010 at 06:00, Mark Lentczner ma...@glyphic.com wrote: The Haddock team has spent the last few months revamping the look of the generated output. We're pretty close to done, but we'd like to get the community's input before we put it in the main release. Please take a look, and then give us your feedback through a short survey Sample pages: http://www.ozonehouse.com/mark/snap-xhtml/index.html I really like it, especially the synopsis tab on the right. Brilliant! The TOC is nice too! The over-all impression is that it doesn't look as auto-generated as the old style. Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html Also very good looking. Does the current stable version of Haddock really create a frame version? I've never seen one before... Yes, I added it two years ago, but we never advertised it much, because of a problem on Firefox. You had to press the back button twice, which was annoying. I've just found a fix, though, so it should work fine in the next release. It already works fine in Chrome, though. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- If it looks like a duck, and quacks like a duck, we have at least to consider the possibility that we have a small aquatic bird of the family Anatidae on our hands. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
On Tue, 03 Aug 2010 16:36:33 +0200, Janis Voigtländer j...@informatik.uni-bonn.de wrote: Nicolas Pouillard schrieb: - If there is no class instance for function types, then those problems go away, of course. But it is doubtful whether that would be a viable solution. Quite a few programs would be rejected as a consequence. (Say, you want to use the strict version of foldl. That will lead to a type class constraint on one of the type variables. Now suppose you actually want to fold in a higher-order fashion, like when expressing efficient reverse via foldr. That would not anymore be possible for the strict version of foldl, as it would require the type-class-constrained variable to be instantiated with a function type.) I think it would be a step forward. The old seq would still exists as unsafeSeq and such applications could continue to use it. In the mean time parametricity results would better apply to programs without unsafe functions. And this without adding extra complexity into the type system. Yes, I agree. Of course, you (and Lennart, and others advocating putting seq into a type class) could work toward that solution right away, could have done so for quite some time: write a package with an Eval type class and method safeSeq (and *no* class instance for function types), upload it on Hackage, encourage people to use it. Modulo the naming difference seq/safeSeq vs. unsafeSeq/seq, that's exactly the solution you want. I wonder why it is not happening. :-) Yes it would be a starting point. Actually I think we can keep the old generic seq, but cutting its full polymorphism: seq :: Typeable a = a - b - b I guess I don't know enough about Typeable to appreciate that. Basically the Typeable constraints tells that we dynamically know the identity of the type being passed in. So this may be a bit challenging to cleanly explain how this safely disable the parametricity but in the mean time this is the net result the type is dynamically known at run time. The same trick is known to work for references as well when effects are everywhere: newRef :: Typeable a = a - Ref a readRef :: Ref a - a writeRef :: Ref a - a - () In the same vein it would make unsafePerformIO less dangerous to add such a constraint. However I would like to here more comments about this seq variant, anyone? OK, I better understand now where we disagree. You want to see in the type whether or not the free theorem apply, Oh, YES. That's the point of a free theorem, isn't it: that I only need to look at the type of the function to derive some property about it. I want them to always apply when no call to unsafe function is made. Well, the question is what you mean by no call to unsafe function is made. Where? In the function under consideration, from whose type the free theorem is derived? Are you sure that this is enough? Maybe that function f does not contain a call to unsafeSeq, but it has an argument which is itself a function. Maybe in some function application, unsafeSeq is passed to f in that argument position, directly or indirectly. Maybe f does internally apply that function argument to something. Can you be sure that this will not lead to a failure of the free theorem you derived from f's type (counting on the fact that f does not call an unsafe function)? Of course, preventing the *whole program* from calling unsafeSeq is enough to guarantee validity of the free theorems thus derived. But that's equivalent to excluding seq from Haskell altogether. It depends on the unsafe function that is used. Using unsafeCoerce or unsafePerformIO (from which we can derive unsafeCoerce) badely anywhere suffice to break anything. So while seq is less invasive I find it too much invasive in its raw form. -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
Nicolas Pouillard schrieb: Actually I think we can keep the old generic seq, but cutting its full polymorphism: seq :: Typeable a = a - b - b I guess I don't know enough about Typeable to appreciate that. Basically the Typeable constraints tells that we dynamically know the identity of the type being passed in. So this may be a bit challenging to cleanly explain how this safely disable the parametricity but in the mean time this is the net result the type is dynamically known at run time. ... However I would like to here more comments about this seq variant, anyone? On reflection, isn't Typeable actually much too strong a constraint? Given that it provides runtime type inspection, probably one cannot derive any parametricity results at all for a type variable constrained by Typeable. In contrast, for a type variable constrained via a hypothetical (and tailored to seq) Eval-constraint, one still gets something which looks like a standard free theorem, just with some side conditions relating to _|_ (strictness, totality, ...). In other words, by saying seq :: Typeable a = a - b - b, you assume pessimistically that seq can do everything that is possible on members of the Typeable class. But that might be overly pessimistic, since in reality the only thing that seq can do is evaluate an arbitrary expression to weak head normal form. OK, I better understand now where we disagree. You want to see in the type whether or not the free theorem apply, Oh, YES. That's the point of a free theorem, isn't it: that I only need to look at the type of the function to derive some property about it. I want them to always apply when no call to unsafe function is made. Well, the question is what you mean by no call to unsafe function is made. Where? In the function under consideration, from whose type the free theorem is derived? Are you sure that this is enough? Maybe that function f does not contain a call to unsafeSeq, but it has an argument which is itself a function. Maybe in some function application, unsafeSeq is passed to f in that argument position, directly or indirectly. Maybe f does internally apply that function argument to something. Can you be sure that this will not lead to a failure of the free theorem you derived from f's type (counting on the fact that f does not call an unsafe function)? Of course, preventing the *whole program* from calling unsafeSeq is enough to guarantee validity of the free theorems thus derived. But that's equivalent to excluding seq from Haskell altogether. It depends on the unsafe function that is used. Using unsafeCoerce or unsafePerformIO (from which we can derive unsafeCoerce) badely anywhere suffice to break anything. So while seq is less invasive I find it too much invasive in its raw form. Hmm, from this answer I still do not see what you meant when you said you want free theorems to always apply when no call to seq is made. You say that seq is less invasive, so do you indeed assume that as soon as you are sure a function f does not itself (syntactically) contain a call to seq you are safe to use the standard free theorem derived from f's type unconstrained? Do you have any justification for that? Otherwise, we are back to banning seq completely from the whole program/language, in which case it is trivial that no seq-related side conditions will be relevant. Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
Good questions. I am about to write a paper explaining the design of the DSTM library in more detail which I will link when available. Please bear with me, here. In the meantime please find some shorter answers below. Regards, Frank Am 04.08.2010 um 10:53 schrieb Andrew Coppin: Frank Kupke wrote: For usage please look into the documentation file: DSTMManual.pdf. 1. Any danger of puting this somewhere I can read it without having to download and manually unpack the Hackage tarball? Actually not. I just had not thought about it. Here is a link to the pdf. http://www-ps.informatik.uni-kiel.de/~frk/dstm.pdf 2. Since DSTM depends on the Unix package, I presume this won't work on Windows. (?) OOC, what does it use Unix for? Good point. I use System.Posix for benchmark debug code and a sigPIPE handler. Probably both can go without doing any damage. I will look into it. As you can tell, I have not tested using Windows... 3. It is unclear to me what happens in the event of a communications failure. The documentation says an exception is thrown, but does the running transaction rollback or just retry or...? (The documentation seems to suggest that it might actually *commit* in spite of a communications failure, which sounds wrong.) Two things happen in parallel. + One is that the library throws an exception to the application saying basically: Hey, at least one of your TVars you just accessed is broken, you better check which ones and react on it in your program. This is the abstraction level outside of a transaction (atomic function). The app now knows that one or more of its services represented by TVars is down and needs attention. + The other thing is the low-level stuff within the transaction thus within the library. The behavior of the transaction depends on *when* actually the failure is detected. - If the failure comes up *before* the transaction has been validated ok, it is aborted. A normal invalidation abort would restart the transaction automatically but in this case throwing the exception terminates it. Abort is often called rollback (when referring to databases) but I prefer not to because up to now everything has been done safely within the STM monad. Nothing happened in the IO world, hence nothing need to be rolled back. (Btw. *retry* is a different kind of transaction restart. It is not done automatically but forced by the application calling the retry function.) - If the failure comes up *after* the transaction has been validated ok, it is committed. At first, this might look wrong but it is not. Here is why: If the validation is ok, all participating TVars on any node have agreed that the transaction is ready to commit. If then any one of these TVars fails, the decision to commit is still valid as nothing else has changed. Note that all TVars are locked by the library from before validating until after committing. Furthermore, some TVars might have already finished the commit. Then it would be inconsistent for the others not to commit. In both cases, commit or not, however, the library takes precautions that no deadlocks build up by broken TVars unexpectedly quitting the transaction protocol. Also, when is failure detected? Is it only when a transaction tries to access the variable? Yes. However, all such accesses are happening within the library and are fully transparent to the application. As TCP is a connection based protocol only simulating a connection, we do not know exactly when a connection actually breaks. We can peek, though. Either by sending test messages (ping), if they bounce, the connection is obviously broken; Or by just observing when a regular message bounces. Regular messages are due to reading, validating, committing, ... TVars within atomic transactions. The library detects the failure (sooner or later) and informs the application by throwing the exception right after the detection. From an application's perspective the failure is only detected when the application reads from or writes to the TVar within an atomic transaction. If a TVar is not accessed its failure might remain undetected. 4. What network transport does this thing use? TCP? UDP? What port numbers? DSTM uses TCP communication. It searches dynamically for available ports starting at port 60001, using 6 for the name server. If two nodes are running each on a separate machine with a different IP address, chances are that both use the same port 60001. If they run on the same machine, most likely one will use port 60001 and the other 60002. 5. How does it work? Does it spawn a Haskell thread for each machine connection or something? Each node spawns a Haskell thread listening to its designated port and spawning itself a thread for each accepted TCP communication, i.e. one for each foreign node talking to it. Each such thread implements a communication line between two threads. I have tried several communication line schemas
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
Mark Lentczner wrote: The Haddock team... Please take a look, and then give us your feedback Very very nice. I took the survey, but here are some comments I left out. I like the idea of the Snappy style the best, but there are two serious problems with it, at least in my browser (Safari): 1. The black on dark blue of the Snap Packages title makes it nearly unreadable for me. 2. The wide fonts stretch things out so far on my screen that the page becomes almost unusable. The other styles are fine, I would use them instead. Here is a comment I'll repeat from the survey because of its importance: Please add a collapse all button for the tree on the contents page. For me, that is perhaps the most urgent thing missing in all of Haddock. It would make that tree so much more usable. Thanks for the great work, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can Haskell do everyting as we want?
On Wed, Aug 4, 2010 at 3:16 AM, Alberto G. Corona agocor...@gmail.comwrote: Just to clarify, I mean: Haskell may be seriously addictive. Sounds like a joke, but it is not. I do not recommend it for coding something quick and dirty. I use it for quick and dirty stuff all the time, mainly because what I want is often something that can be broken down into stages of processing, and pure functions are really nice for that. If I know the input is coming from a reliable enough stream (like a unix pipe to stdin) I can use functions like interact to create filters, or parse some input, and produce some output. It's pretty nice. 2010/8/4 Alberto G. Corona agocor...@gmail.com Before entering haskell, please read our disclaimer: http://www.haskell.org/pipermail/haskell-cafe/2010-June/079044.html You've been warned * * 2010/8/4 Zura_ x...@gol.ge As already noted here, Haskell is a general purpose language, but you should take it with a grain of salt. For instance, you can nail with a laptop (provided that you hit the place where a HDD is located), but you prefer a hammer :) One thing is if you do it only for enjoyment, in this case you can even develop 3D shooter game in Haskell, but when it comes to production/real world use, I think it is better to maintain right tool for the right job attitude. Regards, Zura Qi Qi-2 wrote: Is there anyone happen to come into any tasks that haskell is not able to achieve? -- View this message in context: http://old.nabble.com/can-Haskell-do-everyting-as-we-want--tp29341176p29342871.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
A few points, * The text in Synopsis part is typically wide. (See http://www.ozonehouse.com/mark/snap-xhtml/heist/Text-Templating-Heist.htmlwith Ocean style) I think it would be more *usable *if it was at the bottom of the page (again with a similar button and open/close toggling effect) * On my browser (firefox on a mac) if I select any of the two styles other than Ocean, module pages seem like they do not apply any style. And also they still reference ocean.css. A cookie problem or something like that? * Opening the synopsis frame (either at its current position or at the bottom of the page) might be better if it was implemented as a preference. Namely, if I open the synopsis frame in a module page, I'd possibly like to see it in the next modules page as well. Carrying that information to the same extend as preferred style information sounds like a better idea to me. Thanks for the work! Best, On 4 August 2010 06:00, Mark Lentczner ma...@glyphic.com wrote: The Haddock team has spent the last few months revamping the look of the generated output. We're pretty close to done, but we'd like to get the community's input before we put it in the main release. Please take a look, and then give us your feedback through a short survey Sample pages: http://www.ozonehouse.com/mark/snap-xhtml/index.html Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html Survey: http://spreadsheets.google.com/viewform?formkey=dHcwYzdMNkl5WER1aVBXdV9HX1l5U3c6MQ Short link to same survey: http://bit.ly/9Zvs9B Thanks! - Mark Mark Lentczner http://www.ozonehouse.com/mark/ irc: MtnViewMark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
I really like the color scheme and the Javadoc looking frames. One suggestion I can make is to have the index show all the functions with type signatures without having to pick a letter. A lot of times I'll be looking for a function of a certain signature as opposed to a name. Indeed an index of type signatures would great! I remember wishing I had this when trying the understand the Parsec package. -deech On Wed, Aug 4, 2010 at 8:55 AM, Yitzchak Gale g...@sefer.org wrote: Mark Lentczner wrote: The Haddock team... Please take a look, and then give us your feedback Very very nice. I took the survey, but here are some comments I left out. I like the idea of the Snappy style the best, but there are two serious problems with it, at least in my browser (Safari): 1. The black on dark blue of the Snap Packages title makes it nearly unreadable for me. 2. The wide fonts stretch things out so far on my screen that the page becomes almost unusable. The other styles are fine, I would use them instead. Here is a comment I'll repeat from the survey because of its importance: Please add a collapse all button for the tree on the contents page. For me, that is perhaps the most urgent thing missing in all of Haddock. It would make that tree so much more usable. Thanks for the great work, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
On 4 August 2010 15:44, aditya siram aditya.si...@gmail.com wrote: I really like the color scheme and the Javadoc looking frames. One suggestion I can make is to have the index show all the functions with type signatures without having to pick a letter. A lot of times I'll be looking for a function of a certain signature as opposed to a name. Indeed an index of type signatures would great! I remember wishing I had this when trying the understand the Parsec package. -deech Wouldn't hoogle be better for this kind of use case? The index can become very large already. More direct hoogle/hayoo integration (at least on Hackage) sounds like a worthwhile goal, though. Noted. On Wed, Aug 4, 2010 at 8:55 AM, Yitzchak Gale g...@sefer.org wrote: Mark Lentczner wrote: The Haddock team... Please take a look, and then give us your feedback Very very nice. I took the survey, but here are some comments I left out. I like the idea of the Snappy style the best, but there are two serious problems with it, at least in my browser (Safari): 1. The black on dark blue of the Snap Packages title makes it nearly unreadable for me. 2. The wide fonts stretch things out so far on my screen that the page becomes almost unusable. The other styles are fine, I would use them instead. Here is a comment I'll repeat from the survey because of its importance: Please add a collapse all button for the tree on the contents page. For me, that is perhaps the most urgent thing missing in all of Haddock. It would make that tree so much more usable. Thanks for the great work, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- If it looks like a duck, and quacks like a duck, we have at least to consider the possibility that we have a small aquatic bird of the family Anatidae on our hands. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
On Wed, 04 Aug 2010 15:41:54 +0200, Janis Voigtländer j...@informatik.uni-bonn.de wrote: Nicolas Pouillard schrieb: Actually I think we can keep the old generic seq, but cutting its full polymorphism: seq :: Typeable a = a - b - b I guess I don't know enough about Typeable to appreciate that. Basically the Typeable constraints tells that we dynamically know the identity of the type being passed in. So this may be a bit challenging to cleanly explain how this safely disable the parametricity but in the mean time this is the net result the type is dynamically known at run time. ... However I would like to here more comments about this seq variant, anyone? On reflection, isn't Typeable actually much too strong a constraint? It is indeed too strong, or not precise enough we could say. However at least this simple change make it correct (i.e. restore the parametricity results). I would call this function genericSeq :: Typeable a = a - b - b Given that it provides runtime type inspection, probably one cannot derive any parametricity results at all for a type variable constrained by Typeable. Exactly. We could say that we no longer car derive wrong parametricity results about it. In contrast, for a type variable constrained via a hypothetical (and tailored to seq) Eval-constraint, one still gets something which looks like a standard free theorem, just with some side conditions relating to _|_ (strictness, totality, ...). Indeed, that's why I want both! In particular for the instance on functions which could be defined using genericSeq. OK, I better understand now where we disagree. You want to see in the type whether or not the free theorem apply, Oh, YES. That's the point of a free theorem, isn't it: that I only need to look at the type of the function to derive some property about it. I want them to always apply when no call to unsafe function is made. Well, the question is what you mean by no call to unsafe function is made. Where? In the function under consideration, from whose type the free theorem is derived? Are you sure that this is enough? Maybe that function f does not contain a call to unsafeSeq, but it has an argument which is itself a function. Maybe in some function application, unsafeSeq is passed to f in that argument position, directly or indirectly. Maybe f does internally apply that function argument to something. Can you be sure that this will not lead to a failure of the free theorem you derived from f's type (counting on the fact that f does not call an unsafe function)? Of course, preventing the *whole program* from calling unsafeSeq is enough to guarantee validity of the free theorems thus derived. But that's equivalent to excluding seq from Haskell altogether. It depends on the unsafe function that is used. Using unsafeCoerce or unsafePerformIO (from which we can derive unsafeCoerce) badely anywhere suffice to break anything. So while seq is less invasive I find it too much invasive in its raw form. Hmm, from this answer I still do not see what you meant when you said you want free theorems to always apply when no call to seq is made. You say that seq is less invasive, so do you indeed assume that as soon as you are sure a function f does not itself (syntactically) contain a call to seq you are safe to use the standard free theorem derived from f's type unconstrained? Do you have any justification for that? Otherwise, we are back to banning seq completely from the whole program/language, in which case it is trivial that no seq-related side conditions will be relevant. Actually given genericSeq, I no longer advocate the need for a polymorphic seq function. So both genericSeq and the seq from the type class would both safe. However the rule is still the same when using an unsafe function you are on your own. Clearer? Best regards, -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: can Haskell do everyting as we want?
In my experience two of the biggest issues in selecting any language are the pool of potential programmers and the learning curve for the programmers you already have. If you only need two programmers to do a project and they both know Haskell well, then I think Haskell would do almost any job very well. I also think that the pool of potential Haskell programmers is growing. But it is still much smaller than many other languages. I do think that there is a larger learning curve for Haskell than moving from one imperative language (eg. PHP) to another one (eg. Ruby). In my view Haskell programmers are likely to be more productive and produce more correct (and possibly even more efficient) code once they know the language well. Kevin On Aug 4, 4:35 pm, David Leimbach leim...@gmail.com wrote: On Wed, Aug 4, 2010 at 3:16 AM, Alberto G. Corona agocor...@gmail.comwrote: Just to clarify, I mean: Haskell may be seriously addictive. Sounds like a joke, but it is not. I do not recommend it for coding something quick and dirty. I use it for quick and dirty stuff all the time, mainly because what I want is often something that can be broken down into stages of processing, and pure functions are really nice for that. If I know the input is coming from a reliable enough stream (like a unix pipe to stdin) I can use functions like interact to create filters, or parse some input, and produce some output. It's pretty nice. 2010/8/4 Alberto G. Corona agocor...@gmail.com Before entering haskell, please read our disclaimer: http://www.haskell.org/pipermail/haskell-cafe/2010-June/079044.html You've been warned * * 2010/8/4 Zura_ x...@gol.ge As already noted here, Haskell is a general purpose language, but you should take it with a grain of salt. For instance, you can nail with a laptop (provided that you hit the place where a HDD is located), but you prefer a hammer :) One thing is if you do it only for enjoyment, in this case you can even develop 3D shooter game in Haskell, but when it comes to production/real world use, I think it is better to maintain right tool for the right job attitude. Regards, Zura Qi Qi-2 wrote: Is there anyone happen to come into any tasks that haskell is not able to achieve? -- View this message in context: http://old.nabble.com/can-Haskell-do-everyting-as-we-want--tp29341176... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Arrays and image processing
On Wed, Aug 4, 2010 at 12:49 AM, kirstin penelope rhys kirs...@speakeasy.net wrote: But now I need a fast multidimensional array which can handle a tuple of primitive types. My options, as far an I can see, are: 1) Add an instance for UArray (Int,Int) (Word16, Word16, Word16) and/or UArray (Int,Int) (Word8, Word8, Word8) 2) Add a multidimensional wrapper for Data.Vector What about something like, import qualified Data.Vector.Unboxed as V import Data.Word type Pixel = (Word8, Word8, Word8) type Image = (Int, Int, V.Vector Pixel) Since you may want interoperability with C, you could also consider using Data.Vector.Storable with flat data. Just put the multi-dimensional logic in your indexing operations. I do quite a bit of image processing with a mix of Haskell and C, and have found Unboxed and Storable Vectors effective. Anthony ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
Nicolas Pouillard schrieb: However the rule is still the same when using an unsafe function you are on your own. Clearer? Almost. What I am missing is whether or not you would then consider your genericSeq (which is applicable to functions) one of those unsafe functions or not. Ciao, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: can Haskell do everyting as we want?
I think what the OP is asking for is a killer application of Haskell - Ruby, for example, is great for web programming because of Rails. The Haskell community is somewhat unique in that it has many killer apps and that confuses people. It's great for version control (Darcs), window managers (XMonad), parsing grammers (Parsec), concurrency (would STM be considered a killer app?) etc. etc. People outside the community get flustered because they keep trying to peg the language as more suitable to one domain than another. To the OP, while Haskell is not perfect (Jeremy Shaw already mentioned the garbage-collector issue) it seems as though you could get pretty far before you hit a wall. So pick a domain and have at it! -deech On Wed, Aug 4, 2010 at 10:04 AM, Kevin Jardine kevinjard...@gmail.comwrote: In my experience two of the biggest issues in selecting any language are the pool of potential programmers and the learning curve for the programmers you already have. If you only need two programmers to do a project and they both know Haskell well, then I think Haskell would do almost any job very well. I also think that the pool of potential Haskell programmers is growing. But it is still much smaller than many other languages. I do think that there is a larger learning curve for Haskell than moving from one imperative language (eg. PHP) to another one (eg. Ruby). In my view Haskell programmers are likely to be more productive and produce more correct (and possibly even more efficient) code once they know the language well. Kevin On Aug 4, 4:35 pm, David Leimbach leim...@gmail.com wrote: On Wed, Aug 4, 2010 at 3:16 AM, Alberto G. Corona agocor...@gmail.com wrote: Just to clarify, I mean: Haskell may be seriously addictive. Sounds like a joke, but it is not. I do not recommend it for coding something quick and dirty. I use it for quick and dirty stuff all the time, mainly because what I want is often something that can be broken down into stages of processing, and pure functions are really nice for that. If I know the input is coming from a reliable enough stream (like a unix pipe to stdin) I can use functions like interact to create filters, or parse some input, and produce some output. It's pretty nice. 2010/8/4 Alberto G. Corona agocor...@gmail.com Before entering haskell, please read our disclaimer: http://www.haskell.org/pipermail/haskell-cafe/2010-June/079044.html You've been warned * * 2010/8/4 Zura_ x...@gol.ge As already noted here, Haskell is a general purpose language, but you should take it with a grain of salt. For instance, you can nail with a laptop (provided that you hit the place where a HDD is located), but you prefer a hammer :) One thing is if you do it only for enjoyment, in this case you can even develop 3D shooter game in Haskell, but when it comes to production/real world use, I think it is better to maintain right tool for the right job attitude. Regards, Zura Qi Qi-2 wrote: Is there anyone happen to come into any tasks that haskell is not able to achieve? -- View this message in context: http://old.nabble.com/can-Haskell-do-everyting-as-we-want--tp29341176... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp:// www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer j...@informatik.uni-bonn.de wrote: Nicolas Pouillard schrieb: However the rule is still the same when using an unsafe function you are on your own. Clearer? Almost. What I am missing is whether or not you would then consider your genericSeq (which is applicable to functions) one of those unsafe functions or not. I would consider it as a safe function. -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
This is something I've wanted for a long time, but I always intended to just submit a patch since it would be trivial, but maybe other people have an opinion about it too: I've always wanted a button to collapse or maybe toggle all expanded branches. Once a library gets large, it's easier to navigate when things are closed by default. I used to have to re-close giant things I didn't care about, like the open gl modules, all the time. And if I hit the back button to go back to the toc, it's forgotten which branches I had closed. Of course, since the stdlib has been broken up a lot this is less of a problem than it used to be, but as my own project gets bigger it's since become a problem there. In fact, without an easy way of closing everything, the fact that sub-packages are collapsable at all doesn't seem very useful, unless you use frame view and keep the page open for a long time. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
Nicolas Pouillard schrieb: On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer j...@informatik.uni-bonn.de wrote: Nicolas Pouillard schrieb: However the rule is still the same when using an unsafe function you are on your own. Clearer? Almost. What I am missing is whether or not you would then consider your genericSeq (which is applicable to functions) one of those unsafe functions or not. I would consider it as a safe function. Well, then I fear you have come full-circle back to a non-solution. It is not safe: Consider the example foldl''' from our paper, and replace seq therein by your genericSeq. Then the function will have the same type as the original foldl, but the standard free theorem for foldl does not hold for foldl''' (as also shown in the paper). Ciao, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
Frank Kupke wrote: Good questions. I am about to write a paper explaining the design of the DSTM library in more detail which I will link when available. Please bear with me, here. In the meantime please find some shorter answers below. Well, that was pretty comprehensive. A few questions remain... - If the failure comes up *before* the transaction has been validated ok, it is aborted. Right. So the transaction rolls back and the application gets an exception? - If the failure comes up *after* the transaction has been validated ok, it is committed. So if a TVar goes walkabout in the split second between validate and commit, the others commit anyway, and then the application gets an exception? In that case, is there a way to determine whether or not the rest of the transaction completed? Because it looks like you can the same exception either way, regardless of whether a commit happened or not. 4. What network transport does this thing use? TCP? UDP? What port numbers? DSTM uses TCP communication. It searches dynamically for available ports starting at port 60001, using 6 for the name server. If two nodes are running each on a separate machine with a different IP address, chances are that both use the same port 60001. If they run on the same machine, most likely one will use port 60001 and the other 60002. Right. So both the nameserver and any clients run on random port numbers? (Begs the question of how the clients figure out which port a remote nameserver is on...) 5. How does it work? Does it spawn a Haskell thread for each machine connection or something? Each node spawns a Haskell thread listening to its designated port and spawning itself a thread for each accepted TCP communication, i.e. one for each foreign node talking to it. Each such thread implements a communication line between two threads. I have tried several communication line schemas which I will describe in more detail in the paper yet to come... What impact (if any) does threaded vs non-threaded RTS have? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
On Wed, 04 Aug 2010 17:47:12 +0200, Janis Voigtländer j...@informatik.uni-bonn.de wrote: Nicolas Pouillard schrieb: On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer j...@informatik.uni-bonn.de wrote: Nicolas Pouillard schrieb: However the rule is still the same when using an unsafe function you are on your own. Clearer? Almost. What I am missing is whether or not you would then consider your genericSeq (which is applicable to functions) one of those unsafe functions or not. I would consider it as a safe function. Well, then I fear you have come full-circle back to a non-solution. It is not safe: I feared a bit... but no Consider the example foldl''' from our paper, and replace seq therein by your genericSeq. Then the function will have the same type as the original foldl, but the standard free theorem for foldl does not hold for foldl''' (as also shown in the paper). So foldl''' now has some Typeable constraints. I agree that the free theorem for foldl does not hold for foldl'''. However can we derive the free theorem by looking at the type? No because of the Typeable constraint. So it is safe to derive free theorems without looking at the usage of seq, just the type of the function. Taking care of not considering parametric a type constrained by Typeable. Finally the difference between your solution and this one is that fewer (valid) free theorems can be derived (because of the Typable constraints introduced by seq on functions). Still it is a solution since we no longer have to fear the usage of seq when deriving a free theorem. Best regards, -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
Nicolas Pouillard schrieb: On Wed, 04 Aug 2010 17:47:12 +0200, Janis Voigtländer j...@informatik.uni-bonn.de wrote: Nicolas Pouillard schrieb: On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer j...@informatik.uni-bonn.de wrote: Nicolas Pouillard schrieb: However the rule is still the same when using an unsafe function you are on your own. Clearer? Almost. What I am missing is whether or not you would then consider your genericSeq (which is applicable to functions) one of those unsafe functions or not. I would consider it as a safe function. Well, then I fear you have come full-circle back to a non-solution. It is not safe: I feared a bit... but no Consider the example foldl''' from our paper, and replace seq therein by your genericSeq. Then the function will have the same type as the original foldl, but the standard free theorem for foldl does not hold for foldl''' (as also shown in the paper). So foldl''' now has some Typeable constraints. No, I don't see how it has that. Or maybe you should make explicit under what conditions a type (a - b) is in Typeable. What exactly will the type of foldl''' be, and why? Ciao, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Platform OPENGL dependencies
Hi folks, I just installed the latest Haskell Platform on a fresh Ubuntu Lucid machine and I had to install the following packages to satisfy Open GL: libgmp3-dev,libgl1-mesa-dev, libglu1-mesa-dev, freeglut3-dev Just thought you might want to document that on the Haskell Platform page. -deech ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe to Either -- is there a better way?
Ivan Lazar Miljenovic schrieb: Yitzchak Gale g...@sefer.org writes: While useful, I think its ubiquity to simplicity ratio is not high enough to justify either depending on MissingH just for that, or adding it to a base library. Just like the swap :: (a,b) - (b,a) function a lot of people were discussing on librar...@? I have 'swap' in my utility-ht. In general, I agree. Problem in Haskell is, that it allows for a high degree of modularization such that most components become trivial. Does that mean that we should not define simple functions at all, which in the extreme case would mean that we inline all potential function calls? I think converting Maybe to Either is an often repeating task which justifies an individual function. Maybe I add it to utility-ht. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe to Either -- is there a better way?
On Wed, Aug 4, 2010 at 9:21 AM, Henning Thielemann schlepp...@henning-thielemann.de wrote: Ivan Lazar Miljenovic schrieb: Yitzchak Gale g...@sefer.org writes: While useful, I think its ubiquity to simplicity ratio is not high enough to justify either depending on MissingH just for that, or adding it to a base library. Just like the swap :: (a,b) - (b,a) function a lot of people were discussing on librar...@? I have 'swap' in my utility-ht. In general, I agree. Problem in Haskell is, that it allows for a high degree of modularization such that most components become trivial. Does that mean that we should not define simple functions at all, which in the extreme case would mean that we inline all potential function calls? It's also nice for people reading code if common functions are functions from common libraries. This allows readers' vocabulary of common functions to increase, so they don't have to trawl through someone's personal utility library to figure out what each utility function does. Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
Is there a Git/Darcs dev repo hiding anywhere we could submit patches to? On Tue, Aug 3, 2010 at 4:35 AM, Frank Kupke f...@informatik.uni-kiel.dewrote: Hi, DSTM is an implementation of a robust distributed Software Transactional Memory (STM) library for Haskell. Many real-life applications are distributed by nature. Concurrent applications may profit from robustness added by re-implementation as distributed applications. DSTM extends the STM abstraction to distributed systems and presents an implementation efficient enough to be used in soft real-time applications. Further, the implemented library is robust in itself, offering the application developer a high abstraction level to realize robustness, hence, significantly simplifying this, in general, complex task. The DSTM package consists of the DSTM library, a name server application, and three sample distributed programs using the library. Provided are a simple Dining Philosophers, a Chat, and a soft real-time Bomberman game application. Distributed communication is transparent to the application programmer. The application designer uses a very simple name server mechanism to set up the system. The DSTM library includes the management of unavailable process nodes and provides the application with abstract error information thus facilitating the implementation of robust distributed application programs. For usage please look into the documentation file: DSTMManual.pdf. The package including the documentation can be found on:http://hackage.haskell.org/package/DSTM-0.1.1 Best regards, Frank Kupke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe to Either -- is there a better way?
On Tue, Aug 3, 2010 at 8:33 PM, Claude Heiland-Allen
claudiusmaxi...@goto10.org wrote:
{-# LANGUAGE TemplateHaskell, ScopedTypeVariables #-}
import Language.Haskell.Djinn (djinnD)
$(djinnD maybeToEither [t|forall a b . a - Maybe b - Either a b|])
main = print . map (maybeToEither foo) $ [Nothing, Just bar]
This is very cool (as is Djinn itself), but for me the ideal syntax would be
maybeToEither :: a - Maybe b - Either a b
maybeToEither = $(derived)
Is something like this possible in TH? The splice would have to know
its declared (even inferred?) type.
--Max
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
Great work! I'm sure you're already aware of http://sphinx.pocoo.org/ which is used to generate the Python docs. A lot of good ideas there. One thing which would be great would be to integrate their javascript in-browser text search engine. Obviously not a priority but it might be nice. Best, B Message: 14 Date: Wed, 4 Aug 2010 15:56:58 +0100 From: Thomas Schilling nomin...@googlemail.com Subject: Re: [Haskell-cafe] Preview the new haddock look and take a short survey To: aditya siram aditya.si...@gmail.com Cc: haddock hadd...@projects.haskell.org, haskell-cafe@haskell.org Message-ID: aanlktincl6ousuj6hfdi+3-uao2bqmrx-p8dvrzym...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On 4 August 2010 15:44, aditya siram aditya.si...@gmail.com wrote: I really like the color scheme and the Javadoc looking frames. One suggestion I can make is to have the index show all the functions with type signatures without having to pick a letter. A lot of times I'll be looking for a function of a certain signature as opposed to a name. Indeed an index of type signatures would great! I remember wishing I had this when trying the understand the Parsec package. -deech Wouldn't hoogle be better for this kind of use case? The index can become very large already. More direct hoogle/hayoo integration (at least on Hackage) sounds like a worthwhile goal, though. Noted. On Wed, Aug 4, 2010 at 8:55 AM, Yitzchak Gale g...@sefer.org wrote: Mark Lentczner wrote: The Haddock team... Please take a look, and then give us your feedback Very very nice. I took the survey, but here are some comments I left out. I like the idea of the Snappy style the best, but there are two serious problems with it, at least in my browser (Safari): 1. The black on dark blue of the Snap Packages title makes it nearly unreadable for me. 2. The wide fonts stretch things out so far on my screen that the page becomes almost unusable. The other styles are fine, I would use them instead. Here is a comment I'll repeat from the survey because of its importance: Please add a collapse all button for the tree on the contents page. For me, that is perhaps the most urgent thing missing in all of Haddock. It would make that tree so much more usable. Thanks for the great work, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- If it looks like a duck, and quacks like a duck, we have at least to consider the possibility that we have a small aquatic bird of the family Anatidae on our hands. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
On Wed, Aug 4, 2010 at 1:00 AM, Mark Lentczner ma...@glyphic.com wrote: The Haddock team has spent the last few months revamping the look of the generated output. We're pretty close to done, but we'd like to get the community's input before we put it in the main release. Please take a look, and then give us your feedback through a short survey Sample pages: http://www.ozonehouse.com/mark/snap-xhtml/index.html Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html Survey: http://spreadsheets.google.com/viewform?formkey=dHcwYzdMNkl5WER1aVBXdV9HX1l5U3c6MQ Short link to same survey: http://bit.ly/9Zvs9B Thanks! - Mark Mark Lentczner http://www.ozonehouse.com/mark/ irc: MtnViewMark The index page is not rendered properly on Firefox 3.0.18 on 64-bit Ubuntu: http://imgur.com/Ez6Ki.jpg. Note that the package name a module comes from is not aligned with the module. The synopsis pull-out box is also not rendered properly: http://imgur.com/Ez6KicfdfMl. The `Synopsis' tab is raised an inch or so above the box, long type signatures are truncated, and the nested scroll bar is obscured. I also really dislike nested scroll bars in web pages. Best, Brad ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Software architecture
Charles-Pierre Astolfi c...@crans.org wrote: I'm searching for software designs in Haskell ; for example, I have a pretty good ideo of how I would arrange my modules/classes (in ocaml/(java/c++)) and how they would all fit together to create, say, a website aspirator. But I don't have any clue of the right way to do it with Haskell. I don't need a solution for this example, I'd just like to see how to manage non-trivial code. I haven't found any pointers on the interwebs. This really depends on the concept you use to solve your problem. In most programming languages the glue is ready-made and tells you, how to structure your program. In Haskell you make your own glue. For example, I use monads heavily and the logical parts of my program are monad transformers. The program itself is the stack of those. Using type classes the individual transformers can communicate with each other: newtype GameT m a= GT (StateT GameConfig m a) newtype TextureT m a = TT (StateT TextureConfig m a) newtype OpenGLT m a = GLT (IdentityT m a) newtype SDLT m a = SDLT (ReaderT SDLConfig m a) type MyAppT = GameT (TextureT (OpenGLT SDLT)) game :: MyAppT IO () Another important type of glue in modern software programming is concurrency. Split your program into a number of subprograms (threads). This is very well supported in Haskell: logVar - newEmptyMVar let logStr = putMVar logVar let logStrLn = putMVar logVar = const (putChar '\n') forkIO . forever $ takeMVar logVar = hPutStrLn stderr When using other concepts, usually by using a library, use the glue of that particular concept/library. For example, if you use Yampa to model a reactive system, your individual program parts could become signal transformers: fire :: SF Particle Particle snow :: SF Particle Particle If your current problem is a Parser, your split it into subparsers. For example to parse HTML you definitely want to parse tags and entities. To parse tags you want to parse attribute/value pairs. Use the composability features of monads to do this: tag :: Parser Tag attribute :: Parser (ByteString, ByteString) entity:: Parser Entity The possibilities are endless. You get the idea when writing actual applications. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Software architecture
Ertugrul Soeylemez e...@ertes.de wrote: forkIO . forever $ takeMVar logVar = hPutStrLn stderr hPutStrLn should become hPutStr, otherwise the output may look strange. =) Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
On Wed, 04 Aug 2010 18:04:13 +0200, Janis Voigtländer j...@informatik.uni-bonn.de wrote: Nicolas Pouillard schrieb: On Wed, 04 Aug 2010 17:47:12 +0200, Janis Voigtländer j...@informatik.uni-bonn.de wrote: Nicolas Pouillard schrieb: On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer j...@informatik.uni-bonn.de wrote: Nicolas Pouillard schrieb: However the rule is still the same when using an unsafe function you are on your own. Clearer? Almost. What I am missing is whether or not you would then consider your genericSeq (which is applicable to functions) one of those unsafe functions or not. I would consider it as a safe function. Well, then I fear you have come full-circle back to a non-solution. It is not safe: I feared a bit... but no Consider the example foldl''' from our paper, and replace seq therein by your genericSeq. Then the function will have the same type as the original foldl, but the standard free theorem for foldl does not hold for foldl''' (as also shown in the paper). So foldl''' now has some Typeable constraints. No, I don't see how it has that. Or maybe you should make explicit under what conditions a type (a - b) is in Typeable. What exactly will the type of foldl''' be, and why? Right let's make it more explicit, I actually just wrote a Control.Seq module and a test file: module Control.Seq where genericSeq :: Typeable a = a - b - b genericSeq = Prelude.seq class Seq a where seq :: a - b - b instance (Typeable a, Typeable b) = Seq (a - b) where seq = genericSeq ... Other seq instances ... $ cat test.hs import Prelude hiding (seq) import Data.Function (fix) import Control.Seq (Seq(seq)) import Data.Typeable foldl :: (a - b - a) - a - [b] - a foldl c = fix (\h n ys - case ys of [] - n x : xs - let n' = c n x in h n' xs) foldl' :: Seq a = (a - b - a) - a - [b] - a foldl' c = fix (\h n ys - case ys of [] - n x : xs - let n' = c n x in seq n' (h n' xs)) foldl'' :: (Typeable a, Typeable b, Seq b) = (a - b - a) - a - [b] - a foldl'' c = fix (\h n ys - seq (c n) (case ys of [] - n x : xs - seq xs (seq x (let n' = c n x in h n' xs foldl''' :: (Typeable a, Typeable b) = (a - b - a) - a - [b] - a -- GHC infer this one -- foldl''' :: Seq (a - b - a) = (a - b - a) - a - [b] - a -- however this one require FlexibleContext, and the first one is accepted. foldl''' c = seq c (fix (\h n ys - case ys of [] - n x : xs - let n' = c n x in h n' xs)) Best regards, -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Software architecture
This came up a month or so ago, Don Stewart and others overviewed this topic in detail: http://www.haskell.org/pipermail/haskell-cafe/2010-May/077154.html On 4 August 2010 13:07, Charles-Pierre Astolfi c...@crans.org wrote: Hey there, I'm searching for software designs in Haskell ; for example, I have a pretty good ideo of how I would arrange my modules/classes (in ocaml/(java/c++)) and how they would all fit together to create, say, a website aspirator. But I don't have any clue of the right way to do it with Haskell. I don't need a solution for this example, I'd just like to see how to manage non-trivial code. I haven't found any pointers on the interwebs. On an unrelated note, what is the simplest way to get the llvm bitcode? I understand I can compile myself ghc but it there an easier way? Thanks a lot! -- Cp ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
On 4 August 2010 10:43, Chris Eidhof ch...@eidhof.nl wrote: This looks very cool! It would be nice to put the pdf online somewhere, and add a link from the package documentation Regarding that, it would be nice if Hackage let you access the files in the package instead of having to extract the .tar.gz, as in this case the PDF is in the package; it makes sense to make it clickable somewhere on the package page. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
Nicolas Pouillard schrieb: Right let's make it more explicit, I actually just wrote a Control.Seq module and a test file: module Control.Seq where genericSeq :: Typeable a = a - b - b genericSeq = Prelude.seq class Seq a where seq :: a - b - b instance (Typeable a, Typeable b) = Seq (a - b) where seq = genericSeq ... Other seq instances ... $ cat test.hs import Prelude hiding (seq) import Data.Function (fix) import Control.Seq (Seq(seq)) import Data.Typeable ... foldl''' :: (Typeable a, Typeable b) = (a - b - a) - a - [b] - a -- GHC infer this one -- foldl''' :: Seq (a - b - a) = (a - b - a) - a - [b] - a -- however this one require FlexibleContext, and the first one is accepted. foldl''' c = seq c (fix (\h n ys - case ys of [] - n x : xs - let n' = c n x in h n' xs)) Well, in this example you were lucky that the function type on which you use seq involves some type variables. But consider this example: f :: (Int - Int) - a - a f h x = seq h x I think with your definitions that function will really have that type, without any type class constraints on anything. So let us derive the free theorem for that type. It is: forall t1,t2 in TYPES, g :: t1 - t2, g strict. forall p :: Int - Int. forall q :: Int - Int. (forall x :: Int. p x = q x) == (forall y :: t1. g (f p y) = f q (g y)) Now, set p :: Int - Int p = undefined q :: Int - Int q _ = undefined Clearly, forall x :: Int. p x = q x holds. So it should be the case that for every strict function g and type-appropriate input y it holds: g (f p y) = f q (g y) But clearly the left-hand side is undefined (due to strictness of g and f p y = f undefined y = seq undefined y), while the right-hand side is not necessarily so (due to f q (g y) = f (\_ - undefined) (g y) = seq (\_ - undefined) (g y) = g y). So you have claimed that by using seq via genericSeq in the above definition of f you are guaranteed that any free theorem you derive from its type is correct. But as you see above it is not! I think you have to face it: if you want a solution that both gives meaningful free theorems and still allows to write all programs involving seq that you can currently write in Haskell, then using type classes is not the answer. Ciao, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe to Either -- is there a better way?
On 4 August 2010 18:40, Alexander Dunlap alexander.dun...@gmail.com wrote: It's also nice for people reading code if common functions are functions from common libraries. This allows readers' vocabulary of common functions to increase, so they don't have to trawl through someone's personal utility library to figure out what each utility function does. Agreed. That's why I like readMay. There are many ways to write a reads wrapper: case reads str of [(x,_)] - Just x; _ - Nothing vs case reads str of [(x,)] - Just x; _ - Nothing -- stricter Etc. It seems everyone defines their one, where as Safe.readMay is common. There could be others defined in Safe that encompass most cases. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] what's the best environment for haskell work?
I use Leksah and have done since I started contributing to it. The best way to make it work for you is to use Leksah to fix what you don't like about Leksah ;-) Failing that giving good feedback about bugs and missing features is the next best thing. On 3 Aug 2010, at 18:48, David Virebayre wrote: Trying code completion in comments on string constants, for example. Code completion makes the text jump if you're editing near the bottom of the editor area. You could turn on Edit Prefs - GUI Options - Complete only on Hotkey Default hotkey is Ctrl+Space I like the tocandy feature but then it breaks alignment if you open the file in another editor. Something probably fixable by editing the candy file. Just out of interest which of the candy replacements caused problems. Some of them (such as -) already are set to include spaces to pad out differences. You can turn candy off by unchecking Configuration - To Candy Does your existing editor handle candy better? If so how? I'am a bit lost between Workspace and Package, especially when all I want is write a quick single-source haskell program. We are planning to improve this by adding a default workspace and/or adding messages to prompt users if they have not got a workspace or package open. Basically to get started on a app Workspace - New Workspace (this file contains a list of packages to open) I think most users probably only ever need one workspace file. Next if you have a .cabal file already... Panes - Workspace (to show the workspace pane) Right click in the workspace Pane and select Add Package Or if you want to create a new package... Package - New Package Select a folder whose name matches the desired project name If you just click Save down the bottom you will get a very basic executable package with a Main module (but no main function) To switch between packages in your workspace just double click on it in the Workspace pane. That's all I can think of right now, I've exagerated a bit when I said unusable. Leksah is going to be an awesome editor, it's just not ready yet for me. Thanks for the feedback, please let us know if you think of anything else. As well as the google forum we now also have #leksah on IRC. Hamish___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] what's the best environment for haskell work?
This is slightly OT, but is there a way of getting some Emacs keybindings in Leksah? -deech On Wed, Aug 4, 2010 at 1:01 PM, Hamish Mackenzie hamish.k.macken...@googlemail.com wrote: I use Leksah and have done since I started contributing to it. The best way to make it work for you is to use Leksah to fix what you don't like about Leksah ;-) Failing that giving good feedback about bugs and missing features is the next best thing. On 3 Aug 2010, at 18:48, David Virebayre wrote: Trying code completion in comments on string constants, for example. Code completion makes the text jump if you're editing near the bottom of the editor area. You could turn on Edit Prefs - GUI Options - Complete only on Hotkey Default hotkey is Ctrl+Space I like the tocandy feature but then it breaks alignment if you open the file in another editor. Something probably fixable by editing the candy file. Just out of interest which of the candy replacements caused problems. Some of them (such as -) already are set to include spaces to pad out differences. You can turn candy off by unchecking Configuration - To Candy Does your existing editor handle candy better? If so how? I'am a bit lost between Workspace and Package, especially when all I want is write a quick single-source haskell program. We are planning to improve this by adding a default workspace and/or adding messages to prompt users if they have not got a workspace or package open. Basically to get started on a app Workspace - New Workspace (this file contains a list of packages to open) I think most users probably only ever need one workspace file. Next if you have a .cabal file already... Panes - Workspace (to show the workspace pane) Right click in the workspace Pane and select Add Package Or if you want to create a new package... Package - New Package Select a folder whose name matches the desired project name If you just click Save down the bottom you will get a very basic executable package with a Main module (but no main function) To switch between packages in your workspace just double click on it in the Workspace pane. That's all I can think of right now, I've exagerated a bit when I said unusable. Leksah is going to be an awesome editor, it's just not ready yet for me. Thanks for the feedback, please let us know if you think of anything else. As well as the google forum we now also have #leksah on IRC. Hamish___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] what's the best environment for haskell work?
On 5 Aug 2010, at 06:10, aditya siram wrote: This is slightly OT, but is there a way of getting some Emacs keybindings in Leksah? You can add them to the keymap.lkshk, but you will be limited to adding things leksah has commands for. If you do make some bindings please share them. We are working on integrating Yi as our editor instead of GtkSourceView and it has emacs keybindings. This integration is still in the early stages and I would not recommend trying to use it yet (unless you happen to have time to help out). Hamish___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: hierarchical-clustering and gsc-weighting
On Tue, Aug 3, 2010 at 8:23 AM, Felipe Lessa felipe.le...@gmail.com wrote: On Tue, Aug 3, 2010 at 8:01 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Felipe Lessa felipe.le...@gmail.com writes: 'hierarchical-clustering' provides a function to create a dendrogram from a list of items and a distance function between them. The most common linkage types are available: single linkage, complete linkage and UPGMA. An item can be anything, for example a DNA sequence, so this may used to create a phylogenetic tree. What actual clustering algorithm are you using here? A naïve O(n^2) algorithm using a distance matrix. This can be improved without changing the API, however. What a blunder! I mean, an O(n^3) algorithm -- each step takes O(n^2), and you need 'n' steps to create the whole dendrogram. I'll fix the documentation on the next release. Cheers! =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why is toRational a method of Real?
Why is toRational a method of Real? I thought that real numbers need not be rational, such as the square root of two. Wouldn't it make more sense to have some sort of Rational typeclass with this method? Thanks. --Omari ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
On Aug 4, 2010, at 11:30 AM, Omari Norman wrote: Why is toRational a method of Real? I thought that real numbers need not be rational, such as the square root of two. Wouldn't it make more sense to have some sort of Rational typeclass with this method? Thanks. You can't build the real number field using a computer. So you have to turn what should be a real into something you can express on a computer. You can either choose to use the field of computable real numbers, which is slow, or you can just go with a near enough rational approximation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
On 10-08-04 01:00 AM, Mark Lentczner wrote: Sample pages: http://www.ozonehouse.com/mark/snap-xhtml/index.html On the Contents page, among the collapsable trees: when I click on a link that is also a parent, such as Snap.Http.Server and Text.Templating.Heist, it has the undesirable side effect of collapsing the subtree (or expanding the subtree). (Firefox 3.6.8 as provided by current Ubuntu 32-bit.) When I click on a link, my intention --- and I'm sure most people's intention too --- is to jump to the linked page only. No side effects unrelated to the jump. No messing with the tree state. Another thing. In Safari in iOS 4 in iPod Touch 2nd generation, when a tree is collapsed, the [+] doesn't show. (Haha I'm an impossible reviewer. iPod Touch?!) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
John, a very nice idea. I have not worked with git yet but used an svn repository on our institute server. I will look into it though and eventually set something up. In the meantime you are welcome to send patches to me for merging them into the project. Frank Am 04.08.2010 um 18:54 schrieb John Van Enk: Is there a Git/Darcs dev repo hiding anywhere we could submit patches to? On Tue, Aug 3, 2010 at 4:35 AM, Frank Kupke f...@informatik.uni-kiel.de wrote: Hi, DSTM is an implementation of a robust distributed Software Transactional Memory (STM) library for Haskell. Many real-life applications are distributed by nature. Concurrent applications may profit from robustness added by re-implementation as distributed applications. DSTM extends the STM abstraction to distributed systems and presents an implementation efficient enough to be used in soft real-time applications. Further, the implemented library is robust in itself, offering the application developer a high abstraction level to realize robustness, hence, significantly simplifying this, in general, complex task. The DSTM package consists of the DSTM library, a name server application, and three sample distributed programs using the library. Provided are a simple Dining Philosophers, a Chat, and a soft real-time Bomberman game application. Distributed communication is transparent to the application programmer. The application designer uses a very simple name server mechanism to set up the system. The DSTM library includes the management of unavailable process nodes and provides the application with abstract error information thus facilitating the implementation of robust distributed application programs. For usage please look into the documentation file: DSTMManual.pdf. The package including the documentation can be found on: http://hackage.haskell.org/package/DSTM-0.1.1 Best regards, Frank Kupke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
Both Git and GitHub are fantastic. (and very convenient for contributors) Also if you're the kind of person who's into GUI's, SmartGit is quite good as well. - Job On Wed, Aug 4, 2010 at 3:28 PM, Frank Kupke f...@informatik.uni-kiel.dewrote: John, a very nice idea. I have not worked with git yet but used an svn repository on our institute server. I will look into it though and eventually set something up. In the meantime you are welcome to send patches to me for merging them into the project. Frank Am 04.08.2010 um 18:54 schrieb John Van Enk: Is there a Git/Darcs dev repo hiding anywhere we could submit patches to? On Tue, Aug 3, 2010 at 4:35 AM, Frank Kupke f...@informatik.uni-kiel.dewrote: Hi, DSTM is an implementation of a robust distributed Software Transactional Memory (STM) library for Haskell. Many real-life applications are distributed by nature. Concurrent applications may profit from robustness added by re-implementation as distributed applications. DSTM extends the STM abstraction to distributed systems and presents an implementation efficient enough to be used in soft real-time applications. Further, the implemented library is robust in itself, offering the application developer a high abstraction level to realize robustness, hence, significantly simplifying this, in general, complex task. The DSTM package consists of the DSTM library, a name server application, and three sample distributed programs using the library. Provided are a simple Dining Philosophers, a Chat, and a soft real-time Bomberman game application. Distributed communication is transparent to the application programmer. The application designer uses a very simple name server mechanism to set up the system. The DSTM library includes the management of unavailable process nodes and provides the application with abstract error information thus facilitating the implementation of robust distributed application programs. For usage please look into the documentation file: DSTMManual.pdf. The package including the documentation can be found on:http://hackage.haskell.org/package/DSTM-0.1.1 Best regards, Frank Kupke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can Haskell do everyting as we want?
On Wed, Aug 4, 2010 at 3:37 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Marc Weber marco-owe...@gmx.de writes: Hi Qi, have a look at brainfuck language. Its turing complete as Python, Haskell, etc are. Then you'll learn that the quesntion Can I do everything possible is not at all important. You have to ask instead: Can I complete my task in reasonable time and with reasonable runtime performance etc. And in a way that makes the code maintainable. For most use cases Haskell is a good choice - the only real things I'm missing are - nice stack traces - completion support - because I find it relaxing not having to looking all names. This could be fixed to some extend though.. If you mean whilst writing your code, this is an editor issue (I believe scion aims to help writing cross-editor utilities for things like this). ghci also has tab-completion, and ghc-mod provides such functionality in Emacs. Is scion still being developed? I have the impression it's dead now. Really a shame, I think it has a good solid design and just needs work/polish. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] real-time audio processing [Was: can Haskell do everyting as we want?]
On Aug 3, 8:31 pm, Jeremy Shaw jer...@n-heptane.com wrote: The only area I have had any trouble with Haskell is doing realtime music synthesis. And only because the garbage collector is not realtime friendly. That is not unfixable though. However, I am thinking that the best way to do realtime synthesis with Haskell is to use it to create a DSL that uses LLVM to create code at runtime so that the realtime code is outside the scope of the normal RTS and garbage collector. I'm also very interested in this topic---how to apply a general- purpose functional language to real-time needs, even if it is in a domain-specific way. Indeed, it mostly comes down to memory management and the fact that functional concepts like closures and laziness require a lot of dynamic allocation and garbage collection. Certainly, one solution is to provide a real-time-friendly memory manager. However, it's interesting to notice that, as proven by FAUST [1], a huge amount of DSP algorithms can be expressed functionally in a real- time-compatible way by describing them as static diagrams of connected blocks. These can be efficiently compiled to imperative code with no dynamic memory allocation required. So yes, if such a language were available as an embedded DSL in Haskell (one effort can be found here [2]), it could be generated at run-time using LLVM and called out to. Alternatively, it would be very cool if it were possible to generate code statically at compile time, just like in FAUST. I can imagine this being very useful, especially if it could be generalized to operate on datatypes other than floating points, and had easy access to data structures provided by non-RT portions of the code. If there are mutability requirements, it could be made to run in the ST monad with a pre-allocated workspace. Of course _modifying_ such structures at run-time is always a dynamic thing by definition, although there is the possibility of dynamically generating a replacement block diagram while an one existing one runs, and using an atomic pointer swap to switch them without causing interruptions. In any case, as far as I know the only thing in the way is that it's impossible to tell GHC to compile a section of code in such as way as to guarantee avoidance of memory management. Compilers and runtime- systems always seem to be either RT- or non-RT-friendly, but never seem to support the idea of code *portions* that have differing requirements. My point is, RT code _can_ be expressed functionally, even if the RT-ness imposes certain expressivity restrictions. It would be very cool to be able to mark sections of code as following such a sub-language and be guaranteed that the compiler will generate GC-free code for a particular function, if possible, or otherwise fail. Even if such a sub-language were no more expressive than C, it would be nice to be able to write it in Haskell instead of dropping down to C, so that data can be easily shared with non-RT parts, and Haskell's type checker could be exploited. It seems strange to me that with technology like Haskell and GHC we still depend on using C to express these last remaining droplets of real-time determinism requirements--- strange, since I think of higher-level languages like Haskell to be supersets of the capabilities of C---and annoying, because it means having to deal with the complexities of language interoperability, just for a few low-level components of an application. I realize some of this has probably been discussed in conjunction with FRP. I'm aware of one paper on RT-FRP that talks about requiring an RT-friendly sub-language [3], but I don't pretend to follow it completely. I'm almost sure it also has something to do with arrows, but I have very little idea what they are, since I'm still just getting monads at this point in my personal Haskell understanding. I hope someone more knowledgeable about these things on this list might be able to comment on their relation to real-time determinism. [1] http://faust.grame.fr/ [2] http://claudiusmaximus.goto10.org/cm/2009-12-04_heist_dataflow_algebra.html [3] http://www.haskell.org/frp/rt-frp.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
Andrew, Thanks for pointing your finger at it Am 04.08.2010 um 17:48 schrieb Andrew Coppin: Frank Kupke wrote: Good questions. I am about to write a paper explaining the design of the DSTM library in more detail which I will link when available. Please bear with me, here. In the meantime please find some shorter answers below. Well, that was pretty comprehensive. A few questions remain... - If the failure comes up *before* the transaction has been validated ok, it is aborted. Right. So the transaction rolls back and the application gets an exception? Yes, the transaction aborts and the application gets an exception (see remarks below). - If the failure comes up *after* the transaction has been validated ok, it is committed. So if a TVar goes walkabout in the split second between validate and commit, the others commit anyway, and then the application gets an exception? Yes. In that case, is there a way to determine whether or not the rest of the transaction completed? Because it looks like you can the same exception either way, regardless of whether a commit happened or not. Ah, now I see. Excellent point. I was always focussing the commit case which is well designed, I am certain. But, maybe, the abort case above is not. It would probably be better to not only abort but also restart the transaction even in presence of a failure (that is what's being done when there is no failure). I am not quite clear yet about a possible implementation of such a behavior. Currently I'm thinking: Restarting a transaction containing broken TVars will definitely fail again. To avoid that, the validation vote of a broken TVar (i.e. not able to vote any more) should be taken as a valid vote and no exception should be thrown. Eventually every transaction comes to a commit and probably that's the only place where an exception should be thrown. Then the answer to your question is clear, also. Any opinions? 4. What network transport does this thing use? TCP? UDP? What port numbers? DSTM uses TCP communication. It searches dynamically for available ports starting at port 60001, using 6 for the name server. If two nodes are running each on a separate machine with a different IP address, chances are that both use the same port 60001. If they run on the same machine, most likely one will use port 60001 and the other 60002. Right. So both the nameserver and any clients run on random port numbers? (Begs the question of how the clients figure out which port a remote nameserver is on...) Well, not quite. The name server gets a fixed 6 to make it accessible statically, the others may vary. Their dynamic address is used to label the TVars which then always carry their correct address. 5. How does it work? Does it spawn a Haskell thread for each machine connection or something? Each node spawns a Haskell thread listening to its designated port and spawning itself a thread for each accepted TCP communication, i.e. one for each foreign node talking to it. Each such thread implements a communication line between two threads. I have tried several communication line schemas which I will describe in more detail in the paper yet to come... What impact (if any) does threaded vs non-threaded RTS have? I have done a few tests with threads and could not find a significant difference. But I really did not look deep and thorough enough into it to give a qualified answer. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real-time audio processing
On Wed, 4 Aug 2010, Stephen Sinclair wrote: On Aug 3, 8:31 pm, Jeremy Shaw jer...@n-heptane.com wrote: The only area I have had any trouble with Haskell is doing realtime music synthesis. And only because the garbage collector is not realtime friendly. That is not unfixable though. However, I am thinking that the best way to do realtime synthesis with Haskell is to use it to create a DSL that uses LLVM to create code at runtime so that the realtime code is outside the scope of the normal RTS and garbage collector. I'm also very interested in this topic---how to apply a general- purpose functional language to real-time needs, even if it is in a domain-specific way. If you like to see real-time audio synthesis in action ... http://code.haskell.org/hal/05-2010/unsafe-performance/MOV09560.MPG and for the background: http://arxiv.org/abs/1004.4796 http://dafx04.na.infn.it/WebProc/Proc/P_201.pdf Unfortunately the package is not yet available on Hackage, because there are some patches to the llvm interface that I could not push to the main branch so far. Regarding garbage collection: My experience is that the garbage collector is quite friendly, but you run easily into a memory leak, and this memory leak will make the garbage collector busy, because it has to check reachability of more chunks. Nonetheless you can consider the memory leaks being bugs of the garbage collector or the compiler.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
On Wed, Aug 4, 2010 at 2:11 AM, Magnus Therning mag...@therning.org wrote: On Wed, Aug 4, 2010 at 06:00, Mark Lentczner ma...@glyphic.com wrote: The Haddock team has spent the last few months revamping the look of the generated output. We're pretty close to done, but we'd like to get the community's input before we put it in the main release. Please take a look, and then give us your feedback through a short survey Sample pages: http://www.ozonehouse.com/mark/snap-xhtml/index.html I really like it, especially the synopsis tab on the right. Likewise, although I notice that the synopsis tab closes if I click on a link inside it, which seems unfortunate. Mark, thanks for the great work! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real-time audio processing [Was: can Haskell do everyting as we want?]
+ 1 This is probably the biggest obstacle to using Haskell where I work. (Aviation industry, software for flight management systems for airplanes) We often need to perform some computations with hard deadlines, say every 20ms, with very little jitter. Major GC's spoil the fun; It's quite easy to have a major GC take longer than 20ms, and currently they are not pauseable (nor is it trivial to make them so). It would be very nice to have some annotation/DSL/compiler-flag that would let me run a small block of mostly regular haskell code under hard, real-time constraints. Hmm, it looks like the HASP project is working on some of this, though I'm not sure how portable their work is back to GHC: http://hasp.cs.pdx.edu/ - Job On Wed, Aug 4, 2010 at 4:24 PM, Stephen Sinclair radars...@gmail.comwrote: On Aug 3, 8:31 pm, Jeremy Shaw jer...@n-heptane.com wrote: The only area I have had any trouble with Haskell is doing realtime music synthesis. And only because the garbage collector is not realtime friendly. That is not unfixable though. However, I am thinking that the best way to do realtime synthesis with Haskell is to use it to create a DSL that uses LLVM to create code at runtime so that the realtime code is outside the scope of the normal RTS and garbage collector. I'm also very interested in this topic---how to apply a general- purpose functional language to real-time needs, even if it is in a domain-specific way. Indeed, it mostly comes down to memory management and the fact that functional concepts like closures and laziness require a lot of dynamic allocation and garbage collection. Certainly, one solution is to provide a real-time-friendly memory manager. However, it's interesting to notice that, as proven by FAUST [1], a huge amount of DSP algorithms can be expressed functionally in a real- time-compatible way by describing them as static diagrams of connected blocks. These can be efficiently compiled to imperative code with no dynamic memory allocation required. So yes, if such a language were available as an embedded DSL in Haskell (one effort can be found here [2]), it could be generated at run-time using LLVM and called out to. Alternatively, it would be very cool if it were possible to generate code statically at compile time, just like in FAUST. I can imagine this being very useful, especially if it could be generalized to operate on datatypes other than floating points, and had easy access to data structures provided by non-RT portions of the code. If there are mutability requirements, it could be made to run in the ST monad with a pre-allocated workspace. Of course _modifying_ such structures at run-time is always a dynamic thing by definition, although there is the possibility of dynamically generating a replacement block diagram while an one existing one runs, and using an atomic pointer swap to switch them without causing interruptions. In any case, as far as I know the only thing in the way is that it's impossible to tell GHC to compile a section of code in such as way as to guarantee avoidance of memory management. Compilers and runtime- systems always seem to be either RT- or non-RT-friendly, but never seem to support the idea of code *portions* that have differing requirements. My point is, RT code _can_ be expressed functionally, even if the RT-ness imposes certain expressivity restrictions. It would be very cool to be able to mark sections of code as following such a sub-language and be guaranteed that the compiler will generate GC-free code for a particular function, if possible, or otherwise fail. Even if such a sub-language were no more expressive than C, it would be nice to be able to write it in Haskell instead of dropping down to C, so that data can be easily shared with non-RT parts, and Haskell's type checker could be exploited. It seems strange to me that with technology like Haskell and GHC we still depend on using C to express these last remaining droplets of real-time determinism requirements--- strange, since I think of higher-level languages like Haskell to be supersets of the capabilities of C---and annoying, because it means having to deal with the complexities of language interoperability, just for a few low-level components of an application. I realize some of this has probably been discussed in conjunction with FRP. I'm aware of one paper on RT-FRP that talks about requiring an RT-friendly sub-language [3], but I don't pretend to follow it completely. I'm almost sure it also has something to do with arrows, but I have very little idea what they are, since I'm still just getting monads at this point in my personal Haskell understanding. I hope someone more knowledgeable about these things on this list might be able to comment on their relation to real-time determinism. [1] http://faust.grame.fr/ [2]
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
Frank Kupke wrote: Andrew, Thanks for pointing your finger at it Am 04.08.2010 um 17:48 schrieb Andrew Coppin: In that case, is there a way to determine whether or not the rest of the transaction completed? Because it looks like you can the same exception either way, regardless of whether a commit happened or not. Ah, now I see. Excellent point. I was always focussing the commit case which is well designed, I am certain. OK, so there's design work to do here. (Or at least, things to think about.) But that's OK. It's new and exciting. :-) What impact (if any) does threaded vs non-threaded RTS have? I have done a few tests with threads and could not find a significant difference. But I really did not look deep and thorough enough into it to give a qualified answer. I have a vague recollection of there being a situation to do with calling foreign code that makes all Haskell threads block in the non-threaded RTS, but not in the threaded one. Depending on how big your send and receive buffers are and how long everything is blocked for, it might not matter. I just thought I'd ask about it... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
Christopher Done chrisd...@googlemail.com writes: On 4 August 2010 10:43, Chris Eidhof ch...@eidhof.nl wrote: This looks very cool! It would be nice to put the pdf online somewhere, and add a link from the package documentation Regarding that, it would be nice if Hackage let you access the files in the package instead of having to extract the .tar.gz, as in this case the PDF is in the package; it makes sense to make it clickable somewhere on the package page. Yeah, I'm beginning more and more to wish for a documentation section in .cabal so that you can specify such things (would also help with automated package generation for Linux distributions). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real-time audio processing [Was: can Haskell do everyting as we want?]
job.vranish: + 1 This is probably the biggest obstacle to using Haskell where I work. (Aviation industry, software for flight management systems for airplanes) We often need to perform some computations with hard deadlines, say every 20ms, with very little jitter. Major GC's spoil the fun; It's quite easy to have a major GC take longer than 20ms, and currently they are not pauseable (nor is it trivial to make them so). It would be very nice to have some annotation/DSL/compiler-flag that would let me run a small block of mostly regular haskell code under hard, real-time constraints. Hmm, it looks like the HASP project is working on some of this, though I'm not sure how portable their work is back to GHC: http://hasp.cs.pdx.edu/ Or look at EDSLs, like Atom: http://hackage.haskell.org/package/atom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real-time audio processing [Was: can Haskell doeryting as we want?]
On Wed, 4 Aug 2010, Don Stewart wrote: job.vranish: Hmm, it looks like the HASP project is working on some of this, though I'm not sure how portable their work is back to GHC: http://hasp.cs.pdx.edu/ Or look at EDSLs, like Atom: http://hackage.haskell.org/package/atom Maybe Feldspar, too ... http://hackage.haskell.org/package/feldspar-compiler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suggestions For An Intro To Monads Talk.
On 3 Aug 2010, at 23:51, aditya siram wrote: I am doing an Intro To Monads talk in September [1]. The audience consists of experienced non-Haskell developers but they will be familiar with basic functional concepts (closures, first-class functions etc.). I am looking for suggestions on how to introduce the concept and its implications. I'd also like to include a section on why monads exist and why we don't really see them outside of Haskell. Probably because one does not bother writing them out in the type system. I wrote on a C++ wrap for Guile, and they showed up when typing expressions, though C++ templates are too limited to make this efficiently. The monad has a code lifting property. If one has code which has both non-monadic and monadic components, it can be lifted up to the monadic level without having iterates (can be taken away with the monad projection). So if one has code which has both non-IO and IO components, it can be lifted to the becoming all IO. Since IO and other imperative structures are incompatible with the lazy evaluation default, the type system can be used to describe them using monads. Then one can use syntactic sugar like do and = to make the code look like ordinary imperative code. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suggestions For An Intro To Monads Talk.
For me, the following two things did the magic, so I'll suggest them: 1. Writing a recursive function that takes a binary tree and returns the same tree, but with its leaves enumerated. Each function call takes the tree and the counter and returns the resulting tree and the new counter value. The pattern that emerges is similar to the state monad. The pattern shows that the order of the recursive calls is not ambiguous, unlike in a function that just counts the leaves, for example. Changing the order of the recursive calls changes the result. (code below) 2. Putting the above pattern into a datatype and rewriting the apply-funtion for this datatype (=) allows only to apply funtions in a non-ambiguous way. Not giving a deconstructor for the IO monad forces the programmer to decide in which order calls to IO functions have to be done. I hope this is clear enough; I was able to use the IO monad at the moment I realized that Haskell uses this kind of "trick" to ensure that the order of execution of function arguments is always well-defined and never ambiguous. Of course, there is much more about monads, but this was my entry point. Best regards Daniel code (tree enumeration): data Tree a = Leaf a | Node (Tree a) (Tree a) deriving Show enumTree n (Node a b) = let (n', a') = enumTree n a in let (n'', b') = enumTree n' b in (n'', Node a' b') enumTree n (Leaf x) = (n+1, Leaf n) aditya siram schrieb: Hi all, I am doing an "Intro To Monads" talk in September [1]. The audience consists of experienced non-Haskell developers but they will be familiar with basic functional concepts (closures, first-class functions etc.). I am looking for suggestions on how to introduce the concept and its implications. I'd also like to include a section on why monads exist and why we don't really see them outside of Haskell. Has anyone here done a talk like this? And if so what parts of your presentation were successful and what would you stay away from. Thanks for the feedback. -deech [1] It's in St.Louis, Missouri at the St.Louis Perl Mongers meeting so come on by if you're around! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
You're right. It's bad to have toRational in Real. It's also bad to have Show and Eq as superclasses to Num. On Wed, Aug 4, 2010 at 8:30 PM, Omari Norman om...@smileystation.com wrote: Why is toRational a method of Real? I thought that real numbers need not be rational, such as the square root of two. Wouldn't it make more sense to have some sort of Rational typeclass with this method? Thanks. --Omari ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
On Wed, Aug 04, 2010 at 02:30:10PM -0400, Omari Norman wrote: Why is toRational a method of Real? I thought that real numbers need not be rational, such as the square root of two. Wouldn't it make more sense to have some sort of Rational typeclass with this method? Thanks. The numeric classes are sort of messed up when it comes to non integral values. (not that they are perfect for other things) for instance, realToFrac doesn't preserve NaN or Infinity, except on ghc when optimization is turned on. and the rounding functions discard information too by trying to convert a floating point value to an integral one... I was probably going to introduce a 'FloatMax' type in jhc that is guarenteed to be able to represent all values representable by native floating point types, then replace the use of Rational as an intermediate type with it.. not that that helps things right now really. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
Why is toRational a method of Real? I thought that real numbers need not be rational, such as the square root of two. Wouldn't it make more sense to have some sort of Rational typeclass with this method? I think everyone has problems with the Haskell numeric typeclasses. The answer in this case is that - toRational DOES make sense for every instance of Real in the Haskell98 Report and Libraries, because that basically means floating point numbers, and floating point numbers are rationals (if you allow 1/0, -1/0, and 0/0 you've covered infinities and NaNs) - the designers don't seem to have included any layers that weren't needed for the tasks immediately at hand, after all, Haskell was supposed to avoid success, and the language went through several revisions quite quickly. - but then the wind changed and her face WAS frozen like that... http://www.haskell.org/haskellwiki/Numeric_Prelude shows what _can_ be done in Haskell. Making it possible to work with alternatives to parts of the standard Prelude was a very far-sighted design decision. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is toRational a method of Real?
On 5 August 2010 10:15, Lennart Augustsson lenn...@augustsson.net wrote: You're right. It's bad to have toRational in Real. It's also bad to have Show and Eq as superclasses to Num. I understand why it's bad to have Show as a superclass, but why Eq? Because it stops you from using functions as numbers, etc. ? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/4/10 05:11 , Magnus Therning wrote: Also very good looking. Does the current stable version of Haddock really create a frame version? I've never seen one before... http://www.haskell.org/ghc/docs/current/html/libraries/frames.html - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxaLBUACgkQIn7hlCsL25XhhQCgs9SZ2kGZNLl76Pu4qQnGjkkw rqwAn3pVaRj5+eTwW4W3LU+n2Jnc1Meq =JfAa -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
On Wed, Aug 4, 2010 at 1:36 AM, Ben Millwood hask...@benmachine.co.uk wrote: On Sun, Jul 18, 2010 at 3:02 AM, Mark Wotton mwot...@gmail.com wrote: I've uploaded haskell-src-meta-mwotton, using the development version. It seems to work fine for my applications. It's a bit of a hack, but I can't think of a better way to do it for now. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I've just come up against one of the drawbacks of this approach - having needed haskell-src-meta for a personal project, I downloaded the source and updated it to work with GHC 6.12, fixed various bits and bobs, and only now found out that much of that work had already been done elsewhere :) Matt Morrow has been missing for a long time and I think it's reasonable to suppose he won't suddenly spring out of the darkness to fix things for us. I propose that someone just take up maintainership of the package. I am quite willing to do this with my version, or Mark if you think you'd like to keep a closer eye on your dependencies you could do it instead. I further propose that we should write up a haskellwiki page about absent maintainers and what the community thinks is reasonable in terms of attempting contact before assuming them missing, presumed gone. This kind of depends also on how big an indignity we consider it to be if someone updates a package while the maintainer is just on holiday or something. So we need to decide on: first, who will take haskell-src-meta, and second, what we think is good as a more general policy. I would think the process would go something like: 1. email maintainer, wait 2 weeks for reply 2. email cafe and maintainers of reverse dependencies with proposed changes, wait a week or so for people who know the maintainer to show up or other people to object to your changes 3. chomp package I'm happy to let you do it, I don't understand much of the actual source. Not sure who's the grand gatekeeper of Hackage, though. Might it be possible to enable multiple maintainers on packages, each of whom can upload new versions? As far as I can tell, that's not currently possible with Cabal. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/4/10 08:04 , Frank Kupke wrote: After chatting with Chris privately it turned out that the confusion within the Chat example is partly because I did not find a good and simple solution for mixing user input and chat output asynchronously in one terminal stream. One can possibly do better, here. http://hackage.haskell.org/package/hscurses is the best you're going to do without moving to a GUI. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxaL4IACgkQIn7hlCsL25WTxwCeJ3Tif9ikRtA9ns0YqTB3FGjA QfIAn2AbaZqXLBxMO6EQlSpMPgvtWjkW =r/zf -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
On 5 August 2010 13:23, Mark Wotton mwot...@gmail.com wrote: Might it be possible to enable multiple maintainers on packages, each of whom can upload new versions? As far as I can tell, that's not currently possible with Cabal. Huh? Cabal doesn't care who the maintainers are: it just has a text field where you list a maintainer[s]. See for example http://hackage.haskell.org/package/fgl-5.4.2.3 Currently, AFAIK Hackage allows anyone with an account to upload anything. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
