Re: [Haskell-cafe] Re: howto tuple fold to do n-ary cross product?
On Mon, Nov 24, 2008 at 7:40 AM, Andrea Vezzosi <[EMAIL PROTECTED]> wrote: > It's more natural to consider the cross product of no sets to be [[]] so > your crossr becomes: > > crossr [] = [[]] > crossr (x:xs) = concat (map (\h ->map (\t -> h:t) (crossr tail)) hd Ops, hd and tail should be x and xs here. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: howto tuple fold to do n-ary cross product?
It's more natural to consider the cross product of no sets to be [[]] so
your crossr becomes:
crossr [] = [[]]
crossr (x:xs) = concat (map (\h ->map (\t -> h:t) (crossr tail)) hd)
which we can rewrite with list comprehensions for conciseness:
crossr [] = [[]]
crossr (x:xs) = [ a:as | a <- x, as <- crossr xs ]
then look at the definition of foldr:
foldr f z [] = z
foldr f z (x:xs) = f x (foldr f z xs)
and, considering (foldr f z) == crossr, you should derive the definition of
f and z.
On Mon, Nov 24, 2008 at 5:43 AM, Larry Evans <[EMAIL PROTECTED]>wrote:
> On 11/23/08 13:52, Luke Palmer wrote:
>
>> 2008/11/23 Larry Evans <[EMAIL PROTECTED]>:
>>
>>> http://www.muitovar.com/monad/moncow.xhtml#list
>>>
>>> contains a cross function which calculates the cross product
>>> of two lists. That attached does the same but then
>>> used cross on 3 lists. Naturally, I thought use of
>>> fold could generalize that to n lists; however,
>>> I'm getting error:
>>>
>>
>> You should try writing this yourself, it would be a good exercise. To
>> begin with, you can mimic the structure of cross in that tutorial, but
>> make it recursive. After you have a recursive version, you might try
>> switching to fold or foldM.
>>
>
> Thanks. The recursive method worked with:
> -{--cross.hs--
> crossr::[[a]] -> [[a]]
>
> crossr lls = case lls of
> { [] -> []
> ; [hd]-> map return hd
> ; hd:tail -> concat (map (\h ->map (\t -> h:t) (crossr tail)) hd)
> }
> -}--cross.hs--
>
> However, I'm not sure fold will work because fold (or rather foldr1)
> from:
> http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#12
>
> has signature:
>
> (a->a->a)->[a]->a
>
> and in the cross product case, a is [a1]; so, the signature would be
>
> ([a1]->[a1]->[a1]->[[a1]]->[a1]
>
> but what's needed as the final result is [[a1]].
>
> Am I missing something?
>
> -Larry
>
>
>
> ___
> 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: howto tuple fold to do n-ary cross product?
On 11/23/08 13:52, Luke Palmer wrote:
2008/11/23 Larry Evans <[EMAIL PROTECTED]>:
http://www.muitovar.com/monad/moncow.xhtml#list
contains a cross function which calculates the cross product
of two lists. That attached does the same but then
used cross on 3 lists. Naturally, I thought use of
fold could generalize that to n lists; however,
I'm getting error:
You should try writing this yourself, it would be a good exercise. To
begin with, you can mimic the structure of cross in that tutorial, but
make it recursive. After you have a recursive version, you might try
switching to fold or foldM.
Thanks. The recursive method worked with:
-{--cross.hs--
crossr::[[a]] -> [[a]]
crossr lls = case lls of
{ [] -> []
; [hd]-> map return hd
; hd:tail -> concat (map (\h ->map (\t -> h:t) (crossr tail)) hd)
}
-}--cross.hs--
However, I'm not sure fold will work because fold (or rather foldr1)
from:
http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#12
has signature:
(a->a->a)->[a]->a
and in the cross product case, a is [a1]; so, the signature would be
([a1]->[a1]->[a1]->[[a1]]->[a1]
but what's needed as the final result is [[a1]].
Am I missing something?
-Larry
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Arch Haskell News: Nov 23 2008
News about Haskell on Arch Linux * Arch now has 734 Haskell packages now * That’s an increase of 29 new packages in the last 8 days! * 3.6 new Haskell releases are occuring each day. Noteworthy, * haskell-hledger-0.2: “A ledger-compatible text-based accounting tool.” * gitit-0.3.1: “Wiki using HAppS, git, and pandoc.” * lhc-20081121: “Lhc Haskell Compiler” * haskell-hosc-0.6: “Haskell Open Sound Control” * haskell-flickr-0.3.2: “Haskell binding to the Flickr API” * haskell-delicious-0.3.2: “Accessing the del.icio.us APIs from Haskell (v2)” * haskell-mediawiki 0.2.3: “Interfacing with the MediaWiki API” * darcs-2.1.2.2: “a distributed, interactive, smart revision control system” Full update list, http://archhaskell.wordpress.com/2008/11/24/arch-haskell-news-nov-23-2008/ -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Ambiguous type variable woes
I was trying to create a typeclass for an abstract Stack class, and ran
into some problems. The following 'works' fine:
{-# OPTIONS_GHC -XEmptyDataDecls -XFlexibleContexts
-fno-monomorphism-restriction #-}
module Stack where
data Void
class Stack s where
push_ :: s a r -> b -> s b (s a r)
empty :: s () Void
top :: s a (s b r) -> (a, s b r)
first :: s a r -> a
instance Stack (,) where
push_ s a = (a,s)
empty = ((),undefined::Void)
top = id
first = fst
p = flip push_
test0 = top . p 2 . p 3 $ empty
-- But the following doesn't - I get an "Ambiguous type variable `s' in
the contraint `Stack s' arising from the use of `first':
test1 = first . p 2 . p 3 $ empty
-- sure, that makes sense, it somehow needs to know what flavour of
Stack to use even though (or perhaps because) the answer is independent
of it.
-- So I listen to the "probable fix" and add a type signature:
test1 :: Stack (,) => Integer
-- This does not however help at all! The only way I have found of
'fixing' this requires annotating the code itself, which I most
definitely do not want to do because I specifically want the code to be
polymorphic in that way. But GHC 6.8.2 does not want to let me do this.
What are my options?
Jacques
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use Unicode strings?
Alexey Khudyakov wrote: But this bring question what "the right thing" is? If locale is UTF8 or system support unicode some other way - no problem, just encode string properly. Problem is how to deal with untanslatable characters. Skip? Replace with question marks? Anything other? Probably we need to look how this is solved in other languages. (Or not solved) Regarding untranslatable characters, I think the only correct thing to do is consider it exceptional behavior and have the conversion function accept a handler function which takes the character as input and produces a string for it. That way programs can define their own behavior, since this is something that doesn't have a "right" way to recover in all cases. Canonical handlers which skip, replace with question marks (or other arbitrary character), throw actual exceptions, etc could be provided for convenience. For stream-based "strings" a al ByteString, dealing with this sort of a handler in an efficient manner is fairly straightforward (though some CPS tricks may be needed to get rid of the Maybe in the result of the basic converter). For [Char] strings efficiency is harder, but the implementation should still be easy (given the basic converter). Most extant languages I've seen tend to pick a single solution for all cases, but I don't think we should follow along that path. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Garbage collection as a dual of laziness?
On 23/11/2008, at 9:18 PM, Robin Green wrote: It occurs to me that garbage collection can be seen as some kind of dual of laziness. Laziness means deferring the creation of values until later in the future (or even never). A program optimisation might also have the same effect (of avoiding a computation/work). Also note: if you want to take an extreme position, then most (all?) programming languages can be seen to be somewhat "lazy", since computations are goal directed, and therefore functions (or procedures) are only evaluated on points in their domain which are "needed" by the rest of the computation (consider a function defined on an infinite domain). However, that is not the traditional definition of lazy. Garbage collection means eagerly destroying data created in the past, and reclaiming the memory used by it, before some other event which would do so (in most garbage-collected languages, I think process destruction is the only other thing that frees memory, leaving aside foreign functions). Don't forget the stack. Besides, I'm not sure how "eager" most GCs are. If you don't have enough laziness (e.g. because of strict pattern matching on tuples) your program might do unnecesssary work (time wastage); if you don't have enough garbage collection (e.g. because a value will never be accessed again but is still referred to from something live), your program might leak memory (space wastage). Of course, space wastage can lead to time wastage, and vice-versa. Can this intuition be made any more formal? Is it merely of pedagogical use, or does anything interesting follow from it? If you are looking for interesting (and perhaps unconventional) musings on GC, then you might enjoy this paper: "Thermodynamics and Garbage Collection", Henry G Baker. http://home.pipeline.com/~hbaker1/ThermoGC.html Maybe that will spark some new ideas. Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: hledger 0.2 released
hledger is a minimal haskell clone of John Wiegley's "ledger" text-based accounting tool (http://newartisans.com/software/ledger.html). hledger generates ledger-compatible register & balance reports from a plain text ledger file, and demonstrates a functional implementation of ledger. For more information, see the hledger home page: http://joyful.com/hledger INSTALLATION If you have cabal-install, do:: cabal install hledger otherwise, unpack http://hackage.haskell.org/packages/archive/hledger/0.2/hledger-0.2.tar.gz and do:: runhaskell Setup.hs configure runhaskell Setup.hs build sudo runhaskell Setup.hs install (or for the latest code, darcs get http://joyful.com/repos/hledger) NEWS * fixes * fix balance report totals when filtering by account * fix balance report selection of accounts when filtering by account * fix a bug with account name eliding in balance report * if we happen to be showing a not-yet-auto-balanced entry, hide the AUTO marker * fix print command filtering by account * omit transactions with zero amount from register report * Fix bug in parsing of timelogs * rename --showsubs to --subtotal, like ledger * drop --usage flag * don't require quickcheck * features * priced amounts (eg "10h @ $50") and --basis/--cost/-B flag to show them with cost basis * easy --depth option, equivalent to c++ ledger's -d 'l<=N' * smarter y/m/d date parsing for -b and -e (any number of digits, month and day default to 1, separator can be / - or .) * -n flag for balance command * --empty/-E flag * build a library, as well as the exe * new home page url (http://joyful.com/hledger) * publish html and pdf versions of README * detect display preferences for each commodity like c++ ledger * support amounts with multiple currencies/commodities * support --real/-R flag * support -C/--cleared flag to filter by entry status (not transaction status) * support virtual and balanced virtual transactions * parse comment lines beginning with a space, as from M-; in emacs ledger-mode * allow any non-whitespace in account names, perhaps avoiding misleading missing amounts errors * clearer error message when we can't balance an entry * when we fail because of more than one missing amount in an entry, show the full entry * document the built-in test runner in --help * add a --verbose/-v flag, use it to show more test-running detail * includes 43 tests Contributors: * Simon Michael * Tim Docker ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fixity parsing, Template Haskell
> No, I believe it wouldn't. The left-biased tree cannot distinguish > where parentheses have been used from where HSE inserted its own left > fixities. For instance, if we have the expressions > > xs ++ ys ++ zs > (xs ++ ys) ++ zs > > Then HSE will return something like (I'm using strings for the > subexpression parses, for simplicity) > InfixE (InfixE "xs" "++" "ys") "++" "zs" > for both the first and second parses. However, if I then use the > knowledge that ++ is right infix, I will want to convert the first, > but not the second parses into right infix. I can't do this, because > they are both parsed the same way. No, this is not correct, they are parsed differently. HSE will return (the equivalent of) InfixApp (Paren (InfixApp "xs" "++" "ys")) "++" "zs" for the second case, i.e. with explicit parenthesizing of the subexpression. So they can be and are distinguished, and there would be no problem with the fixity fixing. However... > I would also like to point out that a list representation as I > suggested can in fact encode the correct fixities if they are known to > HSE. This is true simply because the list constructor is isomorphic to > the current constructor in the special case where the list of > operators has length 1. For instance, in the first example above, if > HSE somehow knew that ++ is right infix, it should return a parse > result of > InfixE ["xs", InfixE ["ys", "zs"] ["++"]] ["++"] > rather than just > InfixE ["xs", "ys", "zs"] ["++", "++"] Indeed, I did not realize that. So that means that this representation carries strictly *more* knowledge than that binary constructor, which is of course nice. That certainly makes me somewhat less antagonistic towards a change along these lines. Hmm... Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fixity parsing, Template Haskell
On Mon, Nov 24, 2008 at 12:39 AM, Niklas Broberg <[EMAIL PROTECTED]> wrote: >> I want this information to be used somehow when creating the Template >> Haskell AST, so that the operators used have the correct fixities. If >> I use HSE for parsing Haskell expressions, then I want it to tell me >> where it unsure of the fixities, so that I can insert the correct ones >> there. For this use case, I would want HSE to use an AST like I >> suggested, because it allows the parser to say, "I'm not sure what the >> correct fixity is". > > As noted above, I really don't like that change. If you use HSE for > parsing expressions, it would *never* know the correct fixities, and > you would always get a completely left-biased tree. Why would that be > harder to work with? I understand the argument about least surprise, > and that this feature must be strongly documented (which it currently > isn't), but for practical purposes I don't see why the current state > would be problematic. It should even be trivial to convert the > left-biased tree into an intermediate structure exactly like the one > you suggest, no? No, I believe it wouldn't. The left-biased tree cannot distinguish where parentheses have been used from where HSE inserted its own left fixities. For instance, if we have the expressions xs ++ ys ++ zs (xs ++ ys) ++ zs Then HSE will return something like (I'm using strings for the subexpression parses, for simplicity) InfixE (InfixE "xs" "++" "ys") "++" "zs" for both the first and second parses. However, if I then use the knowledge that ++ is right infix, I will want to convert the first, but not the second parses into right infix. I can't do this, because they are both parsed the same way. I would also like to point out that a list representation as I suggested can in fact encode the correct fixities if they are known to HSE. This is true simply because the list constructor is isomorphic to the current constructor in the special case where the list of operators has length 1. For instance, in the first example above, if HSE somehow knew that ++ is right infix, it should return a parse result of InfixE ["xs", InfixE ["ys", "zs"] ["++"]] ["++"] rather than just InfixE ["xs", "ys", "zs"] ["++", "++"] Cheers, Reiner > > Cheers, > > /Niklas > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Garbage collection as a dual of laziness?
> "Robin" == Robin Green <[EMAIL PROTECTED]> writes: Robin> It occurs to me that garbage collection can be seen as some Robin> kind of dual of laziness. Laziness means deferring the Robin> creation of values until later in the future (or even Robin> never). Garbage collection means eagerly destroying data Robin> created in the past, and reclaiming the memory used by it, Robin> before some other event which would do so I think of garbage collection in the opposite way - that the programmer doesn't free the memory as soon it is known to be safe to do so, but leaves the job to a garbage collector, which may not get round to it for quite some time (perhaps not until program termination, even). -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Garbage collection as a dual of laziness?
It occurs to me that garbage collection can be seen as some kind of dual of laziness. Laziness means deferring the creation of values until later in the future (or even never). Garbage collection means eagerly destroying data created in the past, and reclaiming the memory used by it, before some other event which would do so (in most garbage-collected languages, I think process destruction is the only other thing that frees memory, leaving aside foreign functions). If you don't have enough laziness (e.g. because of strict pattern matching on tuples) your program might do unnecesssary work (time wastage); if you don't have enough garbage collection (e.g. because a value will never be accessed again but is still referred to from something live), your program might leak memory (space wastage). Of course, space wastage can lead to time wastage, and vice-versa. Can this intuition be made any more formal? Is it merely of pedagogical use, or does anything interesting follow from it? -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] howto tuple fold to do n-ary cross product?
2008/11/23 Larry Evans <[EMAIL PROTECTED]>: > http://www.muitovar.com/monad/moncow.xhtml#list > > contains a cross function which calculates the cross product > of two lists. That attached does the same but then > used cross on 3 lists. Naturally, I thought use of > fold could generalize that to n lists; however, > I'm getting error: You should try writing this yourself, it would be a good exercise. To begin with, you can mimic the structure of cross in that tutorial, but make it recursive. After you have a recursive version, you might try switching to fold or foldM. The type of the function will not involve tuples, since they can be arbitrary length (dynamic-length tuples are not supported in Haskell; we use lists for that). cross :: [[a]] -> [[a]] ... Good luck, Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] howto tuple fold to do n-ary cross product?
http://www.muitovar.com/monad/moncow.xhtml#list
contains a cross function which calculates the cross product
of two lists. That attached does the same but then
used cross on 3 lists. Naturally, I thought use of
fold could generalize that to n lists; however,
I'm getting error:
{-- cut here
Compilation started at Sun Nov 23 13:15:24
make
runghc -XMultiParamTypeClasses -XFunctionalDependencies
-XFlexibleInstances cross.hs
cross.hs:23:30:
Occurs check: cannot construct the infinite type: a = (a, a)
Expected type: [a] -> [a] -> [a]
Inferred type: [a] -> [a] -> [(a, a)]
In the first argument of `Data.Foldable.foldl1', namely `cross'
In the first argument of `print', namely
`(Data.Foldable.foldl1 cross (list2, list3, list1))'
make: *** [run] Error 1
}-- cut here
How do I apply fold to cross and n lists, for n>=0?
TIA.
-regards,
Larry
{-
Purpose:
Demonstrate http://www.muitovar.com/monad/moncow.xhtml#list
-}
import Data.Foldable
cross::[a]->[b]->[(a,b)]
cross ls1 ls2 = do
{ x<- ls1
; y<- ls2
; return (x,y)
}
list1=[1,2]
list2=[10,20]
list3=[100,200]
main = do
putStrLn "cross list2 list3="
print (cross list2 list3)
putStrLn "cross list1 (cross list2 list3)="
print (cross list1 (cross list2 list3))
print (list2,list3,list1)
print (Data.Foldable.foldl1 cross (list2,list3,list1))
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extensible Exceptions
BTW, the documentation of catch is bad: the example
catch (openFile f ReadMode)
(\e -> hPutStr stderr ("Couldn't open "++f++": " ++ show e))
does not type check. Is this a known "bug" or shall I report it anywhere?
Regards,
Martin.
Ross Mellgren schrieb:
I think catch is now basically what catchJust was -- you can just do
> thing_to_try `catch` (\ (ErrorCall s) -> putStrLn s)
and it will only catch ErrorCall exceptions.
-Ross
David F. Place wrote:
Hi, All.
I am trying to understand the new exceptions package in base-4
Control.Exceptions. The documentation for catchJust is the same as in
Control.OldException including this example:
result <- catchJust errorCalls thing_to_try handler
Control.OldException provides the predicate errorCalls, but the new one
does not. I don't see how to write it.
Thanks for reading.
Cheers,
David
___
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] Re: [Haskell] GHC 6.10 and OpenGL
On Sun, 2008-11-23 at 16:41 +0100, Manlio Perillo wrote: > Claus Reinke ha scritto: > > [...] > >>> 2. It still wouldn't work for the OpenGL package on Windows, because > >>> the configure scripts require a Unix-style built environment > >>> (MinGW/MinSys or Cygwin). > >> > > [...] > > - they need to install MinGW/MSys > > - then they can do cabal install OpenGL > > > > > Does cabal support precompiled packages? You can construct a pre-compiled packages from a Cabal package (using an external tool like cabal2rpm). The cabal command line tool has no support for installing such things. Normally one makes native pre-compiled packages like .deb, .rpm, .msi etc and then uses the native system for actually installing them. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL
Claus Reinke ha scritto: [...] 2. It still wouldn't work for the OpenGL package on Windows, because the configure scripts require a Unix-style built environment (MinGW/MinSys or Cygwin). [...] - they need to install MinGW/MSys - then they can do cabal install OpenGL Does cabal support precompiled packages? Regards Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL
On Sun, 2008-11-23 at 09:24 -0500, Jeff Heard wrote: > Duncan, what kind of help do you need on the Haskell Platform install? > I have access to VMs running windows XP and Vista. The haskell-platform meta-package is here: darcs get http://code.haskell.org/haskell-platform/ This specifies the list of packages and their exact versions. We need to make sure this builds ok on all platforms. So that's the first step. We plan to use the same windows installer builder that ghc uses, but to install a few more packages. The inno setup script is in the ghc tree in distrib/ghc.iss So the second step if you want to help with that is getting the existing ghc installer building ok. We'll start from a binary install image of ghc, then build the non-core libs and add them to the install image. Finally we build the installer. As much as possible we want to automate this and keep the scripts in the haskell-platform repo. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: why 'try' not work in parsec
thannks very much!! -- Thanks & Regards Changying Li ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL
Duncan, what kind of help do you need on the Haskell Platform install? I have access to VMs running windows XP and Vista. On Sun, Nov 23, 2008 at 8:12 AM, Duncan Coutts <[EMAIL PROTECTED]> wrote: > On Sun, 2008-11-23 at 08:00 -0500, Paul L wrote: >> On 11/23/08, Duncan Coutts <[EMAIL PROTECTED]> wrote: >> >> 2. It still wouldn't work for the OpenGL package on Windows, because >> >> the configure scripts require a Unix-style built environment >> >> (MinGW/MinSys or Cygwin). >> > >> > Yes, building it requires mingw/msys, but with it cabal install opengl >> > really does work (I've tried it). >> >> Sure, I don't doubt it. The real trouble is the extra dependency to >> MinGW/MinSys. >> I'm reluctant to tell my users to go installing them just for the sake >> of compiling HOpenGL. > > Sure, we're currently in an intermediate situation where the ghc release > is smaller but we've not had the first platform release yet. > > We're only suggesting cabal install opengl on windows for developers, > not for your users. > >> On a side note, since GHC installation for Windows contains a version >> of gcc, I wonder how hard it would be to replace the autoconf >> compilation of HOPenGL with just cabal. Then we'll get rid of the >> MinGW/MinSys depedency all together. Isn't it the purpose of cabal to >> replace non-portable build systems (for Haskell at least)? > > That may well be possible and wherever it is possible we should do it. > The MinGW dependency is certainly a pain. Consider this an invitation > for anyone to go take a look at the configure scripts for these packages > and see how easy they'd be to replace with pure Haskell in the Setup.hs. > > Duncan > > ___ > 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] Fixity parsing, Template Haskell
> On Sun, Nov 23, 2008 at 8:23 AM, John A. De Goes <[EMAIL PROTECTED]> wrote: >> Though many see it as "losing" information, I agree wholeheartedly with your >> proposal to change the AST. >> >> It's better to have an AST that conveys less information, but truthfully, >> than to have an AST that purports to convey more information, when in fact >> that information is false. >> >> In most languages, some things just can't be known at parse time. They need >> to be resolved later. While I agree with you in principle, that the rule of least surprise should be adhered to, I don't agree in this instance. You are assuming that the AST is only used by the parser, and if that was true I would agree with you. But HSE is just as much a library for *building* an AST using combinators. If I changed the AST to one carrying less information, it would be impossible to *ever* get the fixities right in the AST, even for those use cases where the information is known and possible to use. > I want this information to be used somehow when creating the Template > Haskell AST, so that the operators used have the correct fixities. If > I use HSE for parsing Haskell expressions, then I want it to tell me > where it unsure of the fixities, so that I can insert the correct ones > there. For this use case, I would want HSE to use an AST like I > suggested, because it allows the parser to say, "I'm not sure what the > correct fixity is". As noted above, I really don't like that change. If you use HSE for parsing expressions, it would *never* know the correct fixities, and you would always get a completely left-biased tree. Why would that be harder to work with? I understand the argument about least surprise, and that this feature must be strongly documented (which it currently isn't), but for practical purposes I don't see why the current state would be problematic. It should even be trivial to convert the left-biased tree into an intermediate structure exactly like the one you suggest, no? Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL
On Sun, 2008-11-23 at 08:00 -0500, Paul L wrote: > On 11/23/08, Duncan Coutts <[EMAIL PROTECTED]> wrote: > >> 2. It still wouldn't work for the OpenGL package on Windows, because > >> the configure scripts require a Unix-style built environment > >> (MinGW/MinSys or Cygwin). > > > > Yes, building it requires mingw/msys, but with it cabal install opengl > > really does work (I've tried it). > > Sure, I don't doubt it. The real trouble is the extra dependency to > MinGW/MinSys. > I'm reluctant to tell my users to go installing them just for the sake > of compiling HOpenGL. Sure, we're currently in an intermediate situation where the ghc release is smaller but we've not had the first platform release yet. We're only suggesting cabal install opengl on windows for developers, not for your users. > On a side note, since GHC installation for Windows contains a version > of gcc, I wonder how hard it would be to replace the autoconf > compilation of HOPenGL with just cabal. Then we'll get rid of the > MinGW/MinSys depedency all together. Isn't it the purpose of cabal to > replace non-portable build systems (for Haskell at least)? That may well be possible and wherever it is possible we should do it. The MinGW dependency is certainly a pain. Consider this an invitation for anyone to go take a look at the configure scripts for these packages and see how easy they'd be to replace with pure Haskell in the Setup.hs. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fixity parsing, Template Haskell
It turns out that there is at least a (partial) solution to my quasiquote problem. Template Haskell's "reify" function can be used to find an operator's fixity, although it seems not for all cases. However, for the purposes of this discussion, suppose I can write a function userFixity :: String -> Q Fixity which takes a operator used in user code and returns its fixity, in the Q monad (Template Haskell's monad). I want this information to be used somehow when creating the Template Haskell AST, so that the operators used have the correct fixities. If I use HSE for parsing Haskell expressions, then I want it to tell me where it unsure of the fixities, so that I can insert the correct ones there. For this use case, I would want HSE to use an AST like I suggested, because it allows the parser to say, "I'm not sure what the correct fixity is". Cheers, Reiner On Sun, Nov 23, 2008 at 8:23 AM, John A. De Goes <[EMAIL PROTECTED]> wrote: > > Though many see it as "losing" information, I agree wholeheartedly with your > proposal to change the AST. > > It's better to have an AST that conveys less information, but truthfully, > than to have an AST that purports to convey more information, when in fact > that information is false. > > In most languages, some things just can't be known at parse time. They need > to be resolved later. > > In this case, the most important thing is following the principle of least > surprise: A Haskell expression inside a quasiquote should work the same as a > Haskell expression outside a quasiquote. > > Violating the "principle of least surprise" is one of the most grievous > mistakes language (and interface) designers make. > > Regards, > > John A. De Goes > N-BRAIN, Inc. > http://www.n-brain.net > [n minds are better than n-1] > > On Nov 22, 2008, at 9:02 AM, Reiner Pope wrote: > >> It seems to me that fixity information behaves more like semantics >> than like syntax. For instance, fixities may be imported, and obey >> namespacing rules. Knowing and correctly handling these rules seems >> beyond the scope of a mere parser: I would hope that a single Haskell >> file could be parsed without reference to any files, and fixity >> declarations seem to be just about the only thing which prevent this >> -- hence my suggestion to change the AST in order to regain this >> property. >> >> The use I envision of it is as I described: writing a quasiquoter >> using HSE to parse the user's Haskell expressions. The problem is >> that, for such a case, HSE (or any other parser) is forced to parse >> infix expressions for which it cannot possibly know the correct >> fixities. Any result with more information than the list form I gave >> would be a lie. >> >> I realise that I don't know how fixities are implemented in Haskell >> compilers, so perhaps I'm misunderstanding how they are treated. >> >> Cheers, >> >> Reiner >> >> On Sat, Nov 22, 2008 at 11:54 PM, Niklas Broberg >> <[EMAIL PROTECTED]> wrote: Of course, this would require a change to Template Haskell, so a second-best solution would be to forbid unparenthesised expressions in my quasiquoter. Then, parsing can proceed correctly without knowing the fixities. This would be easiest to do if haskell-src-exts changed its AST in a similar way to described above for Template Haskell. >>> >>> I'm not sure I follow you here. In what way would it be simpler if HSE >>> changes its AST to a less-information constructor? I won't do that, >>> for the same reason you point out with TH and disadvantages when using >>> it as a library, though I'm still curious what uses you envision and >>> how it would be made easier. I'm still in the process of designing the >>> fixity support for HSE, and all input is valuable. :-) >>> >>> Cheers, >>> >>> /Niklas >>> >> ___ >> 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] Re: [Haskell] GHC 6.10 and OpenGL
On Sun, 2008-11-23 at 12:30 +, Claus Reinke wrote: > >> >> It's sad to see the OpenGL binding being dropped from GHC binary > >> >> installers starting from 6.10. Though this issue has been brought up > >> >> and discussed before, I'm sure a lot of people who based their work on > >> >> OpenGL would share the same sympathy. > >> > > >> > $ cabal install OpenGL > >> > >> Nice except that: > >> > >> 1. The command cabal requires cabal-install package to be installed, is it > >> already bundled with all GHC 6.10.1 distributions? > > > > It will be bundled in the Haskell platform installer (as will OpenGL). > > When is that going to be available? It would be nice to know that > this unfortunate gap period will end within a few weeks or so, especially > since interest in Haskell OpenGL has been picking up again lately. The plan is for the next few weeks. But it'll be done sooner if we can get help, especially from people with access to Windows machines. > > In the mean time here's a binary: > > > > http://haskell.org/~duncan/cabal/cabal.exe > > The last time I tried bootstrapping from that, I didn't get very far, > nor have there been any suggestions on what to do about it: > > http://www.haskell.org/pipermail/cabal-devel/2008-November/004168.html Sorry I missed that email, let me reply now: > The first thing I noticed is that cabal.exe is somewhat stingy about providing > information: there doesn't seem to be a "query" or "info" command and, > usually, > the only way to get information is to look at the "-v" output of doing > something > (where is the config file? cabal --help should point to it; what are the > dependencies > for a given package? we can only ask what cabal --install --dry-run -v is > going > to do with the dependencies; where do packages get unpacked temporarily, for > building?..). Querying should be supported, not just doing. Am I missing > something? The cabal list command produces things like: $ cabal list opengl * OpenGL Latest version available: 2.2.1.1 Latest version installed: 2.2.1.1 Homepage: http://www.haskell.org/HOpenGL/ Category: Graphics Synopsis: A binding for the OpenGL graphics system License: BSD3 It does not list dependencies. The config file is in $HOME/.cabal/config on unix and under the per-user applications and settings directroy on Windows. This is the path returned by getAppUserDataDirectory "cabal". It's true it doesn't mention this location very often, just the first time you run cabal, when it tells you that it's making a default config file at the given location. Packages get unpacked in a subdirectory of the temp directory. What extra querying would you like? Please file feature requests with the details. > Having found the config file by looking at the -v output of cabal update.., I > tried > to enable documentation and to change every path so that cabal would use D: > instead of C: (often crowded). That seemed to work, only that I missed that > installs seem to be global by default, not user (also, build logs still end > up on C:)? Yes. People complained when I set the default on windows to be per-user installs. If the windows users can argue it out and come up with a consensus then we can change the defaults again. The location of the build logs should be configurable but currently is not. > (btw, I get lots of warnings about deprecated -ffi) This is very tricky to solve without breaking backwards compatibility for ghc-6.4. > Then I tried cabal install cabal-install (ghc-6.11.20081004, cygwin), and > failed. > > 1. cabal.exe prefers network-2.2.0.0 (installed) over network-2.2.0.1, and > building that fails with a Data.Generics issue (wasn't that why the > version > number was bumped in the first place? and why is it built when it is > installed?) I believe this is now fixed. The ghc-6.10.0.x pre-releases came with a version of network marked as 2.2.0.0 that had different dependencies from the network-2.2.0.0 on hackage. This is what caused cabal-install to think it needed to re-install network. Of course the old version on hackage had not been updated for ghc-6.10 so it failed. > 2. trying cabal install network explicitly does install network.2.2.0.1.. Yes. And I as I understand it, ghc-6.10.1 comes with that version. If not it's a packaging bug. > 3. cabal install cabal-install still fails, see below >From the build log you pasted it looks like something is wrong with your network package. > > Yes, building it requires mingw/msys, but with it cabal install opengl > > really does work (I've tried it). > > The problem is that this places an additional barrier on distribution: > Haskell OpenGL authors cannot simply distribute their Haskell code, > because many other Haskellers will not be able to get it to work: > > if they are on Windows: For the rest of the issues I think the proper solution is the platform installer which would include cabal.exe and a pre-buil
Re: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL
On 11/23/08, Duncan Coutts <[EMAIL PROTECTED]> wrote: >> 2. It still wouldn't work for the OpenGL package on Windows, because >> the configure scripts require a Unix-style built environment >> (MinGW/MinSys or Cygwin). > > Yes, building it requires mingw/msys, but with it cabal install opengl > really does work (I've tried it). Sure, I don't doubt it. The real trouble is the extra dependency to MinGW/MinSys. I'm reluctant to tell my users to go installing them just for the sake of compiling HOpenGL. Really, OpenGL is the only true cross-platform Graphics solution because it comes as default installation on all platforms. Nothing else comes close to my mind. On a side note, since GHC installation for Windows contains a version of gcc, I wonder how hard it would be to replace the autoconf compilation of HOPenGL with just cabal. Then we'll get rid of the MinGW/MinSys depedency all together. Isn't it the purpose of cabal to replace non-portable build systems (for Haskell at least)? -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL
>> It's sad to see the OpenGL binding being dropped from GHC binary >> installers starting from 6.10. Though this issue has been brought up >> and discussed before, I'm sure a lot of people who based their work on >> OpenGL would share the same sympathy. > > $ cabal install OpenGL Nice except that: 1. The command cabal requires cabal-install package to be installed, is it already bundled with all GHC 6.10.1 distributions? It will be bundled in the Haskell platform installer (as will OpenGL). When is that going to be available? It would be nice to know that this unfortunate gap period will end within a few weeks or so, especially since interest in Haskell OpenGL has been picking up again lately. In the mean time here's a binary: http://haskell.org/~duncan/cabal/cabal.exe The last time I tried bootstrapping from that, I didn't get very far, nor have there been any suggestions on what to do about it: http://www.haskell.org/pipermail/cabal-devel/2008-November/004168.html 2. It still wouldn't work for the OpenGL package on Windows, because the configure scripts require a Unix-style built environment (MinGW/MinSys or Cygwin). Yes, building it requires mingw/msys, but with it cabal install opengl really does work (I've tried it). The problem is that this places an additional barrier on distribution: Haskell OpenGL authors cannot simply distribute their Haskell code, because many other Haskellers will not be able to get it to work: if they are on Windows: - they need to install cabal-install (before the cabal.exe, which doesn't seem to be advertized, that involved further dependency recursion http://ghcmutterings.wordpress.com/2008/11/10/bootstrapping-cabal-install/ ) - they need to install MinGW/MSys - then they can do cabal install OpenGL - there still seem to be additional issues with Glut (I haven't got around to trying it since it these things were dropped from extralibs, but the install instructions sound too complicated; patches to support freeglut should go into the glut package, manual copying around shouldn't be needed; but none of that seems to be a cabal issue) A working cabal.exe, easily found from the cabal home page, would be a good start, but several packages suffer from the "needs MinGW/MSys before cabal-install will work" issue. Since there are known-to-work versions of the MinGW/MSys installers, perhaps a cabal package wrapper for these installers could be constructed? - this would make the build dependency explicit, and would allow to record known-to-work versions via cabal dependencies - cabal could check for presence of MinGW/MSys and record the result in its package database - whenever other packages depend on MinGW/MSys, and these cannot be found, cabal could either download and run the installers from the commandline (assuming that is supported), or produce output *with precise instructions, urls, and version numbers* for manual installation (perhaps the preferred option) Then we could simply say "here is the Haskell package, use cabal (url) to build", and windows users would follow the url to download cabal.exe, and cabal.exe would tell them what they need to do to get MinGW/MSys, just as it takes care of other dependencies, and then things would "just work". Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] why 'try' not work in parsec
On Sat, Nov 22, 2008 at 9:46 AM, Changying Li <[EMAIL PROTECTED]> wrote:
> Hi.
> I read 'write yourself a scheme in 48 hours' and try to modify its code.
> now part of code is :
>
> parseList :: Parser LispVal
> parseList = liftM List $ sepEndBy parseExpr spaces
><|> do char '('
> skipMany space
> x <- (try parseList) <|> parseDottedList
> char ')'
> return x
parseList is succeeding and returning (1); then "char ')'" is failing
(because the next character in the input is the '.'
-- ryan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL
On Sat, 2008-11-22 at 23:34 -0500, Paul L wrote: > On 11/22/08, Don Stewart <[EMAIL PROTECTED]> wrote: > > ninegua: > >> Hi everyone, > >> > >> It's sad to see the OpenGL binding being dropped from GHC binary > >> installers starting from 6.10. Though this issue has been brought up > >> and discussed before, I'm sure a lot of people who based their work on > >> OpenGL would share the same sympathy. > > > > $ cabal install OpenGL > > Nice except that: > > 1. The command cabal requires cabal-install package to be installed, is it > already bundled with all GHC 6.10.1 distributions? It will be bundled in the Haskell platform installer (as will OpenGL). In the mean time here's a binary: http://haskell.org/~duncan/cabal/cabal.exe > 2. It still wouldn't work for the OpenGL package on Windows, because > the configure scripts require a Unix-style built environment > (MinGW/MinSys or Cygwin). Yes, building it requires mingw/msys, but with it cabal install opengl really does work (I've tried it). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] How to use Unicode strings?
Hello Alexey, Sunday, November 23, 2008, 10:20:47 AM, you wrote: > And this problem related not only to IO. It raises whenever strings cross > border between haskell world and outside world. Opening files with unicode > names, execing, etc. this completely depends on libraries, and ghc-bundled i/o libs doesn't support unicode filenames. freearc project contains its own simple i/o library that doesn't have this problem (and also support files >4gb on windows). unfortunately, this library doesn't include any buffering -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
