[Haskell-cafe] Re: dynamic loading of code on windows
This is a known problem and there appears to be a fix: http://www.mail-archive.com/haskell-cafe@haskell.org/msg55899.html I can't access that link for some reason but Google has it cached here: http://www.google.com/url?sa=tsource=webcd=3ved=0CCQQFjACurl=http%3A%2F%2Fwww.mail-archive.com%2Fhaskell-cafe%40haskell.org%2Fmsg55899.htmlrct=jq=Missing%20header%20file%3A%20Linker.hei=k0riTOjZDc_pOd3K5GAusg=AFQjCNHa8H8tDTcD65dqhTlZO448bEIOCQsig2=fxbBCuMUpU-8yHTlYhaoxQcad=rja Kevin On Nov 16, 6:46 am, Arnaud Bailly arnaud.oq...@gmail.com wrote: OK, here is a short summary: - installed MinGW + GCC 4.5 toolchain - downloaded latest code from darcs - Run ./Setup.lhs configure - got another failure Setup.lhs:2:2: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: Use simpleUserHooks or autoconfUserHooks, unless you need Cabal compatibility in which case you must stick with defaultUserHooks Warning: plugins.cabal: The field hs-source-dir is deprecated, please use hs-source-dirs Warning: defaultUserHooks in Setup script is deprecated. Configuring plugins-1.0... Warning: No 'build-type' specified. If you do not need a custom Setup.hs or ./configure script then use 'build-type: Simple'. checking build system type... i686-pc-mingw32 checking for ghc... ghc checking for value of __GLASGOW_HASKELL__... 612 checking for ghc library directory... D:\Program Files\Haskell Platform\2010.2.0.0\lib checking for tex... tex checking for tex2page... no configure: WARNING: tex2page is needed to build some of the documentation http://www.ccs.neu.edu/home/dorai/tex2page/tex2page-doc.html checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for arc4random... no checking for a BSD-compatible install... /usr/bin/install -c configure: creating ./config.status config.status: creating config.mk config.status: creating testsuite/makewith/io/TestIO.conf config.status: creating testsuite/makewith/unsafeio/Unsafe.conf config.status: creating config.h config.status: config.h is unchanged Setup.lhs: Missing dependency on a foreign library: * Missing header file: Linker.h This problem can usually be solved by installing the system package that provides this library (you may need the -dev version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. So it seems really I will have to 1) fix this myself or 2) gave up. I would really like to go for 1) but my knowledge of GHC's internals is rather limited, so I must stick with 2). I will try to adapt hint. I have one question regarding hint: does it handle reloading of modules? Thanks a lot for the various answers so far, Best regards, Arnaud On Mon, Nov 15, 2010 at 11:45 PM, Mathias Weber mat_we...@t-online.de wrote: Hello Arnaud, I also faced this problem with the plugins package. This particular error comes from the backslashes in the ghc library directory not being escaped. But even after patching this, I had trouble with missing imports and some other stuff. It seams that this package is not much used/tested under Windows. At the end I gave up using it and switched to hint (like Alberto pointed out before). Mathias Am 13.11.2010 19:41, schrieb Arnaud Bailly: Hello again, So I followed Kevin's suggestion and installed MinGW along with gcc and autoconf tools needed by hs-plugins. Then it failed with the following error: $ cabal install --enable-documentation plugins Resolving dependencies... Configuring plugins-1.5.1.4... checking build system type... i686-pc-mingw32 checking for ghc... ghc checking for value of __GLASGOW_HASKELL__... 612 checking for ghc library directory... D:\Program Files\Haskell Platform\2010.2.0 .0\lib checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for arc4random... no checking for a BSD-compatible install... /usr/bin/install -c configure: creating ./config.status config.status: creating config.mk config.status: creating testsuite/makewith/io/TestIO.conf config.status: creating
[Haskell-cafe] Catching up on Time and Directory
I'm probably terribly out of date with this, so I wonder if anyone can save me the bother of working out what the /preferred/ libraries are for (a) determining the last-modified-time of a file or directory and (b) manipulating the resulting time datum. I can find System.Directory.getModificationTime and Data.Time.formatTime, but using them together seems unduly awkward. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2010-09-14) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] intent-typing
Hi, Marcus Sundman wrote: Hi, how would one go about implementing (or using if it's supported out-of-the-box) intent-typing* for haskell? A basic technique is to use newtype declarations to declare separate types for separate intents. module StringSafety ( SafeString () , UnsafeString () , quote , considerUnsafe ) where newtype SafeString = SafeString String newtype UnsafeString = UnsafeString String considerUnsafe :: String - UnsafeString considerUnsafe s = UnsafeString s quote :: UnsafeString - SafeString quote (UnsafeString s) = SafeString s' where s' = ... s ... This module does not export the SafeString and UnsafeString constructors, so we can be sure that no other code in the program can invent SafeStrings which are not really safe. Every string can be safely treated as unsafe, however, so we export a function considerUnsafe which does so. Now, if we type our interface to the outside world as getInput :: ... - UnsafeString sendOutput:: SafeString - ... we can be sure that a return value from getInput needs to pass through quote on its way to sendOutput, because quote is the only way to produce a SafeString. This guarantuees safety. It has, however, a practical problem: We can't use the usual String functions on UnsafeString or SafeString values. For instance, we can't concatenate two UnsafeStrings using (++). A naive solution would be to provide separate (++) functions for unsafe and safe strings: append_safe :: SafeString - SafeString - SafeString append_safe (SafeString x) (SafeString y) = SafeString (x ++ y) append_unsafe :: SafeString - SafeString - SafeString append_unsafe (UnsafeString x) (UnsafeString y) = UnsafeString (x ++ y) Note that at least append_safe needs to be implemented in and exported from the StringSafety module. That is a good thing, because this function needs to be carefully checked for safety. The programmer needs to prove (or unit-test, or at least think about) the following theorem: If a and b are safe strings, so is a ++ b. After this fact has been established, other modules are free to use append_safe however they like without possibly compromising safety. Now, the above approach should work, but is still rather impractical: We need to copy the definitions of all String functions for unsafe and safe strings. However, since the bodies of all these copies are actually identical, so we can use parametric polymorphism to abstract over the difference between UnsafeString and SafeString. One way to achieve this is to use phantom types. With phantom types, we declare only a single newtype for both safe and unsafe strings, but we annotate that type with an additional flag to distinguish safe from unsafe uses. module StringSafety ( AnnotatedString () , Safe () , Unsafe () , quote , considerUnsafe , append ) where data Safe = Safe data Unsafe = Unsafe newtype AnnotatedString safety = AnnotatedString String considerUnsafe :: String - AnnotatedString Unsafe considerUnsafe s = AnnotatedString s quote :: AnnotatedString Unsafe - AnnotatedString Safe quote (AnnotatedString s) = AnnotatedString s' where s' = ... s ... append :: AnnotatedString a - AnnotatedString a - AnnotatedString a append (AnnotatedString x) (AnnotatedString y) = AnnotatedString (x ++ y) Note that AnnotatedString does not really use its type parameter safety: That's why it is called a phantom type. The data constructor AnnotatedString can be freely used to convert between safe and unsafe strings, so we better not export it from the module. Inside the module, uses of the data constructor gives rise to proof obligations as above. So the programmer needs to reason that the following is true to justify the implementation and export of append: If x and y have the same safety level, then (x ++ y) has again that same safety level. So now, we still have to write a wrapper around each string operation, but at least we need to write only one such wrapper for all intents, not a separate wrapper for each intent. There is an inconvenience left: We can't concatenate safe and unsafe strings, because both arguments to append need to have exactly the same type. To fix this, we first have to figure out what the result of sucha concatenation would be: It would be an unsafe string, because at least one of the inputs is unsafe. We need to teach this kind of reasoning to the compiler, for instance, using type families: type family Join a b type instance Join Safe Safe = Safe type instance Join Safe Unsafe = Unsafe type instance Join Unsafe Safe = Unsafe type instance Join Unsafe Unsafe = Unsafe The idea is that (Join a b) is the safety level of the result of an operation which
[Haskell-cafe] Annual dutch functional programming day, january 7 2011
The annual Dutch functional programming day will take place soon: Date: Friday, January 7th, 2011 Location: University of Twente, Enschede During the day there will be several presentation related to FP-oriented research results, the use of FP concepts in industry, and the use of FP in education. Of course there is also plenty of opportunity to talk, exchange information, give demo's, and to meet old friends. Most participants are 'advanced' functional programmers; but those who recently developed an interest in all that is FP are of course more than welcome to join. Tradition dictates that at the end of the day we will enjoy a dinner together with those who wish join (at your own costs). You can register for the event by sending an email to me, Christiaan Baaij (c.p.r.ba...@utwente.nl). More information can be found at the website: http://caes.ewi.utwente.nl/External/NLFP Please indicate if you want to give presentation, and if you like to attend the dinner afterwards. Please also register if you only want to participate, as we have to know for how many people we should order lunch. There is of course NO participation fee. See you the 7th of January! Christiaan Baaij ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Making monadic code more concise
Ling Yang wrote I think a good question as a starting point is whether it's possible to do this 'monadic instance transformation' for any typeclass, and whether or not we were lucky to have been able to instance Num so easily (as Num, Fractional can just be seen as algebras over some base type plus a coercion function, making them unusually easy to lift if most typeclasses actually don't fit this description). In general, what this seems to be is a transformation on functions that also depends explicitly on type signatures. For example in Num: Things start to break down when we get to the higher order. In the first order, it is indeed easy to see that the monadification of the term Int - Int - Int should/could be m Int - m Int - m Int Indeed, liftM2 realizes this transformation. But what about (Int - Int) - Int ? Should it be (m Int - m Int) - m Int ? A moment of thought shows that there is no total function of the type Monad m = ((Int - Int) - Int) - ((m Int - m Int) - m Int) because there is no way, in general, to get from (m Int - m Int) to the pure function Int-Int. That is, we can't write Monad m = (m Int - m Int) - m (Int-Int) One may try tabulation (for finite domains) tf f = do vt - f (return True) vf - f (return False) return $ \x - if x then vt else vf but that doesn't quite work: what if the resulting function is never invoked on the True argument. We have needlessly computed that value, vt. Worse, we have incurred the effect of computing vt; that effect could be failure. We have needlessly failed. One can say: we need runnable class (Monad m) = Runnable m where exit : m a - a are there many monads that are members of that typeclass? For example, Maybe cannot be Runnable; otherwise, what is (exit Nothing)? Any Error or MonadPlus monad can't be Runnable. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Catching up on Time and Directory
2010/11/16 Jon Fairbairn jon.fairba...@cl.cam.ac.uk: I'm probably terribly out of date with this, so I wonder if anyone can save me the bother of working out what the /preferred/ libraries are for (a) determining the last-modified-time of a file or directory and (b) manipulating the resulting time datum. I can find System.Directory.getModificationTime and Data.Time.formatTime, but using them together seems unduly awkward. I'm interested too. There's so many times and dates types it's confusing. I had a problem last week, got it to compile but I'm not sure I'm doint it right. ( asked but got no replies on the list ) David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Catching up on Time and Directory
On Tue, Nov 16, 2010 at 12:30 PM, Jon Fairbairn jon.fairba...@cl.cam.ac.uk wrote: I'm probably terribly out of date with this, so I wonder if anyone can save me the bother of working out what the /preferred/ libraries are for (a) determining the last-modified-time of a file or directory and (b) manipulating the resulting time datum. I can find System.Directory.getModificationTime and Data.Time.formatTime, but using them together seems unduly awkward. Well, if it makes you feel any better: yes, it seems that you're doing it the right way, and yes the right way is awkward. Perhaps it's time to deprecate old-time and get directory to use the time datatypes directly? While we're at it, maybe we could deprecate old-locale as well. It's always awkward starting a new project and importing an old-* library immediately... Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Catching up on Time and Directory
Jon Fairbairn wrote: I'm probably terribly out of date with this, so I wonder if anyone can save me the bother of working out what the /preferred/ libraries are for (a) determining the last-modified-time of a file or directory and (b) manipulating the resulting time datum. I can find System.Directory.getModificationTime and Data.Time.formatTime, but using them together seems unduly awkward. It's not you who is out of date - it is the base library, which *still* uses the long deprecated old-time library for these kinds of functions. Is there an existing trac ticket about this? Going via a string representation is obviously not the most robust or efficient method, but converting to a CalendarTime and manually building a UTCTime from it may not be worth the effort. One alternative is to use the convertible package. Then you can just say: utc - fmap convert (getModificationTime myFile) :: IO UTCTime Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Catching up on Time and Directory
On Tue, Nov 16, 2010 at 6:42 AM, Michael Snoyman mich...@snoyman.com wrote: On Tue, Nov 16, 2010 at 12:30 PM, Jon Fairbairn jon.fairba...@cl.cam.ac.uk wrote: I'm probably terribly out of date with this, so I wonder if anyone can save me the bother of working out what the /preferred/ libraries are for (a) determining the last-modified-time of a file or directory and (b) manipulating the resulting time datum. I can find System.Directory.getModificationTime and Data.Time.formatTime, but using them together seems unduly awkward. Well, if it makes you feel any better: yes, it seems that you're doing it the right way, and yes the right way is awkward. Perhaps it's time to deprecate old-time and get directory to use the time datatypes directly? While we're at it, maybe we could deprecate old-locale as well. It's always awkward starting a new project and importing an old-* library immediately... What is the replacement for old-locale? I've used it and not known I should have been using something better. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Catching up on Time and Directory
On Tue, Nov 16, 2010 at 3:00 PM, Antoine Latter aslat...@gmail.com wrote: On Tue, Nov 16, 2010 at 6:42 AM, Michael Snoyman mich...@snoyman.com wrote: On Tue, Nov 16, 2010 at 12:30 PM, Jon Fairbairn jon.fairba...@cl.cam.ac.uk wrote: I'm probably terribly out of date with this, so I wonder if anyone can save me the bother of working out what the /preferred/ libraries are for (a) determining the last-modified-time of a file or directory and (b) manipulating the resulting time datum. I can find System.Directory.getModificationTime and Data.Time.formatTime, but using them together seems unduly awkward. Well, if it makes you feel any better: yes, it seems that you're doing it the right way, and yes the right way is awkward. Perhaps it's time to deprecate old-time and get directory to use the time datatypes directly? While we're at it, maybe we could deprecate old-locale as well. It's always awkward starting a new project and importing an old-* library immediately... What is the replacement for old-locale? I've used it and not known I should have been using something better. Sorry, I didn't mean that there *is* a replacement for it, I meant that we should replace it with something that isn't old-*. It seems that the original purpose of old-locale was to support many different locale issues, not just time (I'm just going based on the docs). However, since it currently does only support time, I would recommend we just pack it up and throw it into the time package. In fact, as a complete strawman, here's a proposal: * Move System.Locale into the time package, bumping version number to 1.3. * Bump old-locale to 1.1 and have it simply re-export System.Locale from time. (Maybe we don't actually need to make that bump, 1.0.1 may be sufficient.) * Bump old-time to 2.0 (make it clear this is a *very* different version) and have it re-export modules from time. (This is the part of the proposal people should *really* beat up on.) * Find every single package depending on old-time[1] and get it to use time instead. The last part especially will be difficult, but we can at least start with the packages in the HP. Michael [1] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Catching up on Time and Directory
Michael Snoyman wrote: * Move System.Locale into the time package, bumping version number to 1.3. * Bump old-locale to 1.1 and have it simply re-export System.Locale from time. (Maybe we don't actually need to make that bump, 1.0.1 may be sufficient.) * Bump old-time to 2.0 (make it clear this is a *very* different version) and have it re-export modules from time. (This is the part of the proposal people should *really* beat up on.) I disagree with all of these items, and only support the last item: * Find every single package depending on old-time and get it to use time instead. Most importantly, base. These old- packages have been deprecated for long enough. Dump them. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Catching up on Time and Directory
On Tue, Nov 16, 2010 at 3:23 PM, Yitzchak Gale g...@sefer.org wrote: Michael Snoyman wrote: * Move System.Locale into the time package, bumping version number to 1.3. * Bump old-locale to 1.1 and have it simply re-export System.Locale from time. (Maybe we don't actually need to make that bump, 1.0.1 may be sufficient.) * Bump old-time to 2.0 (make it clear this is a *very* different version) and have it re-export modules from time. (This is the part of the proposal people should *really* beat up on.) I disagree with all of these items, and only support the last item: * Find every single package depending on old-time and get it to use time instead. Most importantly, base. These old- packages have been deprecated for long enough. Dump them. Well, time still depends on old-locale, so if you want to dump them you'll need to do *something* about it. I frankly don't care too much about keeping old-locale or old-time on further life support, I just don't want to start having conflicting implementations of System.Locale; it gives me too many not-fond-memories of the mtl/transformers split. Michael PS: I'm still a little bit in shock that we actually got past the mtl/transformers issue. Well done to everyone involved, especially Ross. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Updating Haskell Packages through Archlinux becoming A Pain
Hi Mathew, [My GHC installation breaks] when pacman updates a package using an AUR package, which cabal refuses to install because it can break other packages (yet the package still gets installed according to pacman). this bug has been fixed about two weeks ago; it should no longer occur with the current PKGBUILD files. An easy way to get your system back in shape is to un-install all Haskell packages by running pacman -R --cascade ghc ..., then clean up the package database with rm -rf /usr/lib/ghc-6.12.3 ..., and finally re-install those packages that you'd like to have. The procedure is a little awkward, I'm afraid, but you won't ever have to do it again, just this one time. ;-) Take care, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bracket around every IO computation monad
Hi! On Tue, Nov 16, 2010 at 1:40 AM, Alexander Solla a...@2piix.com wrote: Check out: http://apfelmus.nfshost.com/articles/operational-monad.html It's the paper that inspired the operational module. I read that yesterday. A nice read. Now I have to think how to make my own monad based on all this knowledge. (As an exercise.) Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bracket around every IO computation monad
Hi! On Tue, Nov 16, 2010 at 2:05 AM, Bas van Dijk v.dijk@gmail.com wrote: The assumption being that Mitar's Nerves are scarce resources (like files for example). Meaning: Yes. My nerves are really a scarce resource. ;-) And I haven't yet heard anybody comparing them to files. I heard that they are short and sometimes people step on some of them. But not that they are like files. ;-) I have to tell this to my fellow neuroscientists. This is a whole new paradigm. ;-) But yes, Nerves were modeled by looking at file handles. And were also made so that they fit nicely into the bracket function. They are mostly a wrapper around scarce resource (like display, complex computation (CPU), sensors and similar). This is why there has to be some preparation and cleanup. In fact your approach opens a whole new idea for me. Because currently my whole main program was: attach everything together, if error while attaching cleanup and exit wait until everything lives/works or until an error cleanup everything and wait until everything is really cleaned up exit The whole main program just prepares my generic data-flow computation framework I am developing. So that attaching is how all flows (called Nerves) are interconnected and then you let it live and process. So your approach is interesting because I could do cleanup at one place, and it wouldn't matter if I am doing this in the attach phase (which this thread is about) or any other phase. someOperation :: LiveNeuron n - IO () (I'm not sure Mitar actually has this...) No. In fact Neurons are defined with an operation they do. You just feed them with data and they output data. In main program you do not do operations over them. You just grow/prepare them and attache/interconnect them. 4) It's important not to leave handles open (or in this case leave nerves attached) when they don't need to be. In the case of files when you leave a file open when you're not using it anymore, other processes may not be able to use the file. (I'm not sure this is a requirement for Nerves...) It is. Because they encapsulate also complex resources like sensors, cameras, displays, keyboard and similar things. (But they can also be quite low-level too.) (Again, I'm not sure a similar requirement exists for LiveNeurons) It does. Once things are cleaned up there should be no other use of them. Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Add haskell-src as an official machine-readable component of the Haskell standard
(Moving to Café) (Examples of controversies possible in haskell-src: we have the Hs prefix on constructors everywhere, we can't provide fixity information (and the haskell-src-exts implementation of this is unsatisfactory in several important ways) ... What ways? http://trac.haskell.org/haskell-src-exts/ :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Add haskell-src as an official machine-readable component of the Haskell standard
On 16 November 2010 16:24, Niklas Broberg niklas.brob...@gmail.com wrote: (Moving to Café) (Examples of controversies possible in haskell-src: we have the Hs prefix on constructors everywhere, we can't provide fixity information (and the haskell-src-exts implementation of this is unsatisfactory in several important ways) ... What ways? http://trac.haskell.org/haskell-src-exts/ :-) For what it's worth, I'm writing an sexpr haskell - vanilla haskell converter, so I built an AST with haskell-src-exts and use the pretty printer to output haskell. I can rewrite (* 1 2 3) to 1 * 2 * 3, or (- a b c d) to a - b - c - d, and thus associativity is preserved. Pretty nice. Anyway, thanks for your awesome library. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Catching up on Time and Directory
On 16 November 2010 11:30, Jon Fairbairn jon.fairba...@cl.cam.ac.uk wrote: I'm probably terribly out of date with this, so I wonder if anyone can save me the bother of working out what the /preferred/ libraries are for (a) determining the last-modified-time of a file or directory and (b) manipulating the resulting time datum. I can find System.Directory.getModificationTime and Data.Time.formatTime, but using them together seems unduly awkward. Yep, it's still awkward. The annoying thing is these base libraries still use the old time libraries. Here's me having to use both because of getModificationTime: https://github.com/chrisdone/amelie/blob/master/src/Amelie/Import.hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] intent-typing
- Original Message From: aditya siram aditya.si...@gmail.com To: Haskell Café haskell-cafe@haskell.org Cc: hask...@haskell.org; Marcus Sundman sund...@iki.fi Sent: Tue, November 16, 2010 8:18:33 AM Subject: Re: [Haskell-cafe] Re: [Haskell] intent-typing That was a great explanation of phantom types and type-families. I'm just getting started on understand type families and I was wondering why you didn't use data families in the truth table structure: type family Join a b type instance Join Safe Safe = Safe type instance Join Safe Unsafe = Unsafe type instance Join Unsafe Safe = Unsafe type instance Join Unsafe Unsafe = Unsafe My understanding is that since 'type' just produces a type synonym and the last three type instances are Unsafe, they are equivalent. Wouldn't it be better to have data instance Join Safe Unsafe ... so that the compiler can distinguish between Join Unsafe Safe, Join Safe Unsafe and Join Unsafe Unsafe ? The goal is to have ++ produce an AnnotatedString Safe or an AnnotatedString Unsafe, reflecting the safety level. A data family would maintain the distinction, but then AnnotatedString (Join Unsafe Unsafe) would not be equivalent to AnnotatedString Unsafe - and what if you want to concatenate three pieces? Brandon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Making monadic code more concise
Thanks Oleg for the feedback. If I understand right, there is a hard (as in computability) limit for automatic instancing due to the general requirement of deriving functions off of the behavior of another. At this point, I wonder: How good are we at doing this? There's languages that reside in the more expressive corners of the lambda cube, such as Epigram. Some of the concepts have been translated to Haskell, such as Djinn. Are only 'trivial' results possible, or that the incomputability problems are just moved into type space? In any case, it's a good reason to limit the scope of autolifting. On Tue, Nov 16, 2010 at 2:49 AM, o...@okmij.org wrote: Ling Yang wrote I think a good question as a starting point is whether it's possible to do this 'monadic instance transformation' for any typeclass, and whether or not we were lucky to have been able to instance Num so easily (as Num, Fractional can just be seen as algebras over some base type plus a coercion function, making them unusually easy to lift if most typeclasses actually don't fit this description). In general, what this seems to be is a transformation on functions that also depends explicitly on type signatures. For example in Num: Things start to break down when we get to the higher order. In the first order, it is indeed easy to see that the monadification of the term Int - Int - Int should/could be m Int - m Int - m Int Indeed, liftM2 realizes this transformation. But what about (Int - Int) - Int ? Should it be (m Int - m Int) - m Int ? A moment of thought shows that there is no total function of the type Monad m = ((Int - Int) - Int) - ((m Int - m Int) - m Int) because there is no way, in general, to get from (m Int - m Int) to the pure function Int-Int. That is, we can't write Monad m = (m Int - m Int) - m (Int-Int) One may try tabulation (for finite domains) tf f = do vt - f (return True) vf - f (return False) return $ \x - if x then vt else vf but that doesn't quite work: what if the resulting function is never invoked on the True argument. We have needlessly computed that value, vt. Worse, we have incurred the effect of computing vt; that effect could be failure. We have needlessly failed. One can say: we need runnable class (Monad m) = Runnable m where exit : m a - a are there many monads that are members of that typeclass? For example, Maybe cannot be Runnable; otherwise, what is (exit Nothing)? Any Error or MonadPlus monad can't be Runnable. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Making monadic code more concise
On Nov 16, 2010, at 12:36 PM, Ling Yang wrote: Are only 'trivial' results possible, or that the incomputability problems are just moved into type space? That's typically the case, under Rice's theorem. A construct is derivable if it works for all cases (i.e., it's a free theorem), or if it works for none. If it works for some, you need to encode the differences between the cases yourself. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: typeclass namespace rational?
On Tue, 2010-11-16 at 00:55 -0500, Daniel Peebles wrote: If I were to guess, I'd say it's because there are two major spaces in Haskell, the type level and the value level. They never interact directly (their terms are never juxtaposed) so there's not much chance for confusion. Typeclass constructors and type constructors do however live in the same space. The fact that you propose instance String String might be odd to some. It's still unambiguous, but isn't necessarily the most clear: (with higher-sorted kind polymorphism, MPTCs, type families, and GADTs) instance String String String String String where data String String String String String where String :: String String String String String :-) data Buffalo = Buffalo class Buffalo b where type familly Buffalo b instance Buffalo Buffalo where type familly Buffalo Buffalo = Buffalo instance Buffalo b = Buffalo (Buffalo b) where type familly Buffalo (Buffalo b) = b But: data Buffalo b = Buffalo b class Buffalo b where type familly Buffalo b -- Is it about Buffalo (type) b being buffalo or result of -- Buffalo (type function) being Buffalo? instance Buffalo b = Buffalo (Buffalo b) where type familly Buffalo (Buffalo b) = b Regards 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
[Haskell-cafe] borked windows environment, want to start over
I think I may have borked things good using cygwin. I want to remove it and do a clean install of haskell platform w/out cygwin. What do I need to do to make sure all configuration files have been removed? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE zeno 0.1.0
On 11/13/10 8:15 AM, Will Sonnex wrote: Infinite values (lazy-evaluation in general) also give Zeno a problem, since you can no longer use structure as a well-defined ordering for induction. A property such as reverse (reverse xs) === xs does not work for infinite lists, since you can successfully case-analyse values from xs but case-analysing reverse (reverse xs) will give an infinite loop. You could say the values are equal in some sense (maybe given infinite computation time) but they do not behave in the same way. Generally speaking the solution for handling possibly infinite structures is to use coinduction rather than induction. The reason reverse (reverse xs) === xs doesn't work for (possibly)infinite lists is that we can't prove that reverse.reverse makes any progress (since reverse of an infinite list is bottom). But there are plenty of other things you could still prove for infinite structures, map f (map g xs) === map (f.g) xs for example. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
