Re: [GHC] #3554: ASSERT failed! file TcMType.lhs line 349
#3554: ASSERT failed! file TcMType.lhs line 349 +--- Reporter: simonmar |Owner: chak Type: bug | Status: new Priority: normal |Milestone: 6.12.2 Component: Compiler (Type checker) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T2627b | Os: Unknown/Multiple Architecture: Unknown/Multiple | +--- Comment (by chak): This is one of the remaining cases, where a type variable is instantiated twice, due to the current imperfect interaction between the equality solver and the rest of TcSimplify. This will probably only get fixed once we have the new implementation of implications constraints. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3554#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #3555: Vectorisation error with negative Double const
#3555: Vectorisation error with negative Double const -+-- Reporter: ams | Owner: Type: bug | Status: new Priority: normal| Component: Data Parallel Haskell Version: 6.10.4| Severity: normal Keywords:| Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -+-- Negative Double constants cause an error in parallel comprehensions. This function negs xs = [: -1.0 | x - xs :] doesn't make it through the compiler; this negs xs = [: (0.0 - 1.0) | x - xs :] does. The error text is *** Vectorisation error *** Tycon not vectorised: GHC.Num.T:Num -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3555 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3555: Vectorisation error with negative Double const
#3555: Vectorisation error with negative Double const ---+ Reporter: ams| Owner: Type: bug| Status: new Priority: normal | Milestone: Component: Data Parallel Haskell |Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ---+ Changes (by ams): * os: Unknown/Multiple = Linux * architecture: Unknown/Multiple = x86_64 (amd64) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3555#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3555: Vectorisation error with negative Double const
#3555: Vectorisation error with negative Double const ---+ Reporter: ams| Owner: Type: bug| Status: new Priority: normal | Milestone: Component: Data Parallel Haskell |Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ---+ Changes (by ams): * version: 6.10.4 = 6.11 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3555#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3555: Vectorisation error with negative Double const
#3555: Vectorisation error with negative Double const ---+ Reporter: ams| Owner: Type: bug| Status: new Priority: normal | Milestone: Component: Data Parallel Haskell |Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ---+ Comment (by ams): Version is actually 6.13.20090929. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3555#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2965: GHC on OS X does not compile 64-bit
#2965: GHC on OS X does not compile 64-bit +--- Reporter: Axman6 |Owner: thoughtpolice Type: feature request | Status: new Priority: normal |Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit| Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | +--- Changes (by skrap): * cc: skrap+hask...@spflrc.org (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2965#comment:35 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3550: Dynamic libraries don't work on Mac OS/X
#3550: Dynamic libraries don't work on Mac OS/X +--- Reporter: StephenBlackheath|Owner: StephenBlackheath Type: bug | Status: new Priority: normal |Milestone: Component: Compiler | Version: 6.11 Severity: major| Resolution: Keywords: dynamic mac osx | Difficulty: Unknown Testcase: http://upcycle.it/~blackh/ghc/test-case.tar.bz2 | Os: MacOS X Architecture: Unknown/Multiple | +--- Comment (by StephenBlackheath): Version 5 changes the name of the new option to -dylib-install-name and adds documentation for it to the Users Guide. The corresponding Cabal patch (also needed) it #591 at http://hackage.haskell.org/trac/hackage/ticket/591 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3550#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2965: GHC on OS X does not compile 64-bit
#2965: GHC on OS X does not compile 64-bit +--- Reporter: Axman6 |Owner: thoughtpolice Type: feature request | Status: new Priority: normal |Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit| Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | +--- Changes (by mokus): * cc: mo...@deepbondi.net (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2965#comment:36 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Fwd: GHC Bug report
[I just found out that there is a dedicated bugs email address so forwarding
the original message there.]
Hello,
I've created a small example of the program I have at this URL with the
output of -ddump-simpl:
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=10109#a10109
Notice that on line 139, I would like it if the Word8 could be passed
without boxing.
The full program text is here also in case the link above disappears:
\begin{code}
{-# LANGUAGE BangPatterns, MagicHash #-}
module Main where
import GHC.Word ( Word8(W8#) )
import GHC.Exts ( Int#, Int(I#), Ptr(..), Word#, Word(W#) )
import GHC.Prim ( indexWord8OffAddr#, (==#), (=#), (+#), word2Int#, Addr# )
isSpaceWord8 :: Word8 - Bool
isSpaceWord8 !w =
w == 0x20 ||-- ' '
w == 0x09 ||-- '\t'
w == 0x0A ||-- '\n'
w == 0x0D -- '\r'
{-# INLINE isSpaceWord8 #-}
firstnonspace :: Ptr Word8 - Int - Int - Int
firstnonspace (Ptr p) (I# n) (I# m) = I# (first p n m)
where
first :: Addr# - Int# - Int# - Int#
first addr n' m'
| n' =# m' = n'
| otherwise = if (not (isSpaceWord8 ch))
then n'
else first addr (n' +# 1#) m'
where
ch = W8# (indexWord8OffAddr# addr n')
{-# INLINE firstnonspace #-}
main = return ()
\end{code}
The output from ghc -O2 -ddump-simpl is:
\begin{core}
Tidy Core
Main.a :: GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
[GlobalId]
[Arity 1
NoCafRefs
Str: DmdType L]
Main.a =
\ (s_aHK :: GHC.Prim.State# GHC.Prim.RealWorld) -
(# s_aHK, GHC.Unit.() #)
Main.a1 :: GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
[GlobalId]
[Arity 1
Str: DmdType L]
Main.a1 =
GHC.TopHandler.a5
@ ()
(Main.a
`cast` (sym ((GHC.IOBase.:CoIO) ())
:: GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
~
GHC.IOBase.IO ()))
Main.main :: GHC.IOBase.IO ()
[GlobalId]
[Arity 1
NoCafRefs
Str: DmdType L]
Main.main =
Main.a
`cast` (sym ((GHC.IOBase.:CoIO) ())
:: GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
~
GHC.IOBase.IO ())
Main.lit :: GHC.Word.Word8
[GlobalId]
[NoCafRefs
Str: DmdType m]
Main.lit = GHC.Word.W8# __word 13
Main.lit1 :: GHC.Word.Word8
[GlobalId]
[NoCafRefs
Str: DmdType m]
Main.lit1 = GHC.Word.W8# __word 10
Main.lit2 :: GHC.Word.Word8
[GlobalId]
[NoCafRefs
Str: DmdType m]
Main.lit2 = GHC.Word.W8# __word 9
Main.lit3 :: GHC.Word.Word8
[GlobalId]
[NoCafRefs
Str: DmdType m]
Main.lit3 = GHC.Word.W8# __word 32
Main.isSpaceWord8 :: GHC.Word.Word8 - GHC.Bool.Bool
[GlobalId]
[Arity 1
NoCafRefs
Str: DmdType U(L)]
Main.isSpaceWord8 =
__inline_me (\ (w_ap1 :: GHC.Word.Word8) -
GHC.Classes.||
(GHC.Word.==2 w_ap1 Main.lit3)
(GHC.Classes.||
(GHC.Word.==2 w_ap1 Main.lit2)
(GHC.Classes.||
(GHC.Word.==2 w_ap1 Main.lit1) (GHC.Word.==2 w_ap1
Main.lit
Main.firstnonspace :: GHC.Ptr.Ptr GHC.Word.Word8
- GHC.Types.Int
- GHC.Types.Int
- GHC.Types.Int
[GlobalId]
[Arity 3
NoCafRefs
Str: DmdType U(L)U(L)U(L)m]
Main.firstnonspace =
__inline_me (\ (ds_dGa :: GHC.Ptr.Ptr GHC.Word.Word8)
(ds1_dGb :: GHC.Types.Int)
(ds2_dGc :: GHC.Types.Int) -
case ds_dGa of wild_B1 { GHC.Ptr.Ptr p_ap6 -
case ds1_dGb of wild1_XB { GHC.Types.I# n_ap8 -
case ds2_dGc of wild2_XG { GHC.Types.I# m_apa -
letrec {
first_sH5 :: GHC.Prim.Addr#
- GHC.Prim.Int#
- GHC.Prim.Int#
- GHC.Prim.Int#
[Arity 3
Str: DmdType LLL]
first_sH5 =
\ (addr_ape :: GHC.Prim.Addr#)
(n'_apg :: GHC.Prim.Int#)
(m'_api :: GHC.Prim.Int#) -
case GHC.Prim.=# n'_apg m'_api of wild3_XS {
GHC.Bool.False -
case GHC.Classes.not
(Main.isSpaceWord8
(GHC.Word.W8#
(GHC.Prim.indexWord8OffAddr# addr_ape n'_apg)))
of wild4_XU {
GHC.Bool.False - first_sH5 addr_ape
(GHC.Prim.+# n'_apg 1) m'_api;
GHC.Bool.True - n'_apg
};
GHC.Bool.True - n'_apg
}; } in
case first_sH5 p_ap6 n_ap8 m_apa of wild3_XN { __DEFAULT -
GHC.Types.I# wild3_XN
}
Re: [GHC] #3390: Upgrade the Windows build to use gcc 4.4.0
#3390: Upgrade the Windows build to use gcc 4.4.0 -+-- Reporter: simonmar |Owner: Type: task | Status: new Priority: normal|Milestone: 6.14.1 Component: Build System | Version: 6.10.4 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Windows Architecture: x86 | -+-- Changes (by igloo): * priority: high = normal * owner: igloo = * summary: Make the Windows build work with mingw gcc 4.4.0 = Upgrade the Windows build to use gcc 4.4.0 * milestone: 6.12.1 = 6.14.1 Comment: We now put the mingw tarballs we use in the source tree, so we always use the same version no matter what is installed. We should upgrade to gcc 4.4.0 at some point, though. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3390#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #3556: Build the bootstrapping ghc-pkg with ghc-cabal
#3556: Build the bootstrapping ghc-pkg with ghc-cabal ---+ Reporter: igloo | Owner: Type: task | Status: new Priority: normal| Milestone: 6.14.1 Component: Build System |Version: 6.11 Severity: normal| Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---+ The current build rules for ghc-pkg are getting increasingly intricate. It should be possible to build the bootstrapping ghc-pkg with ghc-cabal instead, which should simplify things. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3556 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3555: Vectorisation error with negative Double const
#3555: Vectorisation error with negative Double const ---+ Reporter: ams| Owner: rl Type: bug| Status: new Priority: normal | Milestone: Component: Data Parallel Haskell |Version: 6.13 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---+ Changes (by chak): * owner: = rl * cc: r...@cse.unsw.edu.au (added) * version: 6.11 = 6.13 * os: Linux = Unknown/Multiple * architecture: x86_64 (amd64) = Unknown/Multiple Comment: The current version of the vectoriser can't handle type classes yet; hence, the error. BTW, in the current version of DPH, you need to use the simple mock Prelude from package dph in all code that ought to be vectorised — if you use the standard Prelude, you will get similar errors (even without using type classes). We will lift these restrictions in future versions. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3555#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[Haskell] ANNOUNCE: SourceGraph 0.5.1.0
This is an updated version of my graph-theoretic static analysis tool for Haskell, SourceGraph. This version is available from http://hackage.haskell.org/package/SourceGraph-0.5.1.0 (now with docs on the Hackage page!). This version provides the ability to pass in a single Haskell source file rather than a Cabal file for analysis purposes. Note that the Cabal version is still preferred as it is better able to determine the project name and which modules are exported: when using a single source file, that file is presumed to be the only exported module and its module name is used as the overall project name. This feature was requested by Curt Sampson. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: usb-0.1
Bas van Dijk wrote: Comments and patches are highly welcome. I tried to install on my Mac but bindings-common choked on: cabal install bindings-common Resolving dependencies... cabal: Error: some packages failed to install: bindings-common-1.1 failed while unpacking the package. The exception was: /var/folders/mR/mRFqQvztFo0URT0d6GN9wE+++TI/-Tmp-/bindings-common-1.174967/bindings-common-1.1/src/Bindings: createDirectory: does not exist (No such file or directory) Not sure if this is interesting to you, Bas, but I thought I'd share. :-) Groetjes, Martijn. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] New TMR editor
Dear all, After several years at the helm, I've decided to step down as editor of the Monad.Reader. I am happy to announce that Brent Yorgey will take over my role as editor. I'd like to take this opportunity to thank Brent for helping to keep the Monad.Reader alive. I'm sure he'll do a fantastic job. Finally, I'd like to thank all the people who have contributed to the Monad.Reader over the last few years – you guys have made this publication, and my job as an editor, so much fun. All the best, Wouter ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Testing polymorphic properties with QuickCheck
---
This message is a literate Haskell file, hence:
{-# LANGUAGE GADTs#-} -- a matter of style only
import Control.Monad.State hiding (mapM)
import Control.Applicative
import Data.Traversable
import Data.Foldable
import Data.Monoid
import Test.QuickCheck
-
Hello everyone,
This message is my answer a common question coming from
QuickCheck users: How do I use QuickCheck on polymorphic
properties?. The answer also applies to all test generators for
Haskell (SmallCheck, ...).
Consider the following polymorphic property:
prop_reverse_append :: Eq a = [a] - [a] - Bool
prop_reverse_append xs ys = reverse (xs ++ ys) == reverse xs ++ reverse ys
Running QuickCheck on that property is possible, but...
quickCheck prop_reverse_append
... 100 tests passed!
Even though the property is false, it passes QuickCheck, because GHC
has defaulted |a| to |()|, and the unit type cannot capture any difference
in the content of the lists.
The usual QuickCheck answer is to force using |Int| for |a|:
prop_reverse_append_Int :: [Int] - [Int] - Bool
prop_reverse_append_Int = prop_reverse_append
While sound, this is highly unsatisfactory:
1. Many tests will be redundant. For example, if |prop_reverse_append
[1] [2]| holds, then |prop_reverse_append [a] [b]| holds for any
choice of a and b. So if the first test passes, it is useless to test
|prop_reverse_append [1] [3]|, |prop_reverse_append [1] [4]|, etc.
Unfortunately, QuickCheck does not realize this and may perform all
these tests.
2. Some tests will be weaker than necessary. For example, testing
|prop_reverse_append| with elements that are equal to each other is a
waste: this might only hide bugs in the implementation, as when we
used the unit type.
In fact, one should test |prop_reverse_append| only once for each
length of the input lists, and the elements in the lists should all be
different from each other. Note that this observation applies not only
to |prop_reverse_append|, but to all properties of the same type.
In the remainder I will show how to generalize the argument, and give
a systematic method to compute a monomorphic property which is as
strong as a polymorphic one. This is done only by looking at the type
of the property.
The basic idea is to identify all the ways that the property can
construct elements of the polymorphic type (say |a|), and represent
this in a datatype.
For example, the type |Eq a = [a] - [a] - Bool| tells us that the
property can construct an element by picking any element from the
first or the second list. This yields the datatype:
data A where
XsElement :: Int - A
YsElement :: Int - A
deriving (Eq, Show)
Which we can substitute for the type variable. The gain comes from the
fact that we also know how to fill in the input lists, yielding the
monomorphic property:
prop_reverse_append_Mono :: [()] - [()] - Bool
prop_reverse_append_Mono xs ys
= prop_reverse_append (combine XsElement xs) (combine YsElement ys)
where |combine f| replaces the |i|:th element in the list with |f i|.
Generalization 1
It is worth noting that observations, that is, elements which do not
return any |a|, do not play any role in the monomorphisation
process. This is illustrated in the next example, about testing a
filter-like function:
prop_filter :: Eq a = (a - Bool) - [a] - Bool
prop_filter = error add your definition here
prop_filter_Mono :: (A - Bool) - [()] - Bool
prop_filter_Mono p xs = prop_filter p (combine XsElement xs)
Generalization 2
Arguments which return |a| are turned into constructors of
the monomorphic datatype, and then fixed.
prop_iterate :: Eq a = a - (a - a) - Bool
prop_iterate = error add your definition here
data B where
Initial :: B
Next:: B - B
deriving (Eq, Show)
prop_iterate_Mono = prop_iterate Initial Next
Note that the more polymorphic the function is, the more the arguments
become fixed. In the above case, all quantifiers disappear.
Notes
-
Note that the technique works only for first order polymorphic
arguments. We do not have a generalization for higher order
ones. Also, extra care must be taken in the presence of type classes
constraints: they may hide constructors.
More examples and applications, together with the theory behind all
this can be found in a paper I co-authored with Patrik Jansson and Koen
Claessen:
http://publications.lib.chalmers.se/cpl/record/index.xsql?pubid=99387
or direct link to the pdf:
http://www.cse.chalmers.se/~bernardy/PolyTest.pdf
Cheers,
Jean-Philippe Bernardy.
PS.
Definition of |combine|
---
combine :: Traversable t = (Int - a) - t () - t a
combine f t = evalState (Data.Traversable.mapM getValue t) 0
where getValue _ = do i - get
put (i+1)
return (f i)
Example:
[Haskell] Re: [Haskell-cafe] ANNOUNCE: vty-ui 0.1
Am I correct in saying that the collection of widgets contains a single widget type so far? ;-) Technically, four; vertical and horizontal boxes, a text string widget, and the List you mentioned. It only has a few types because I was just releasing early. I'm going to start using this in a project and add things as needed. The list widget looks useful, does it handle multi-line strings (i.e. strings with a \n)? It currently only handles single-line strings but I'd actually like to generalize it to take a list of Widget instances (possibly with restrictions). -- Jonathan Daugherty ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] ANNOUNCE: vty-ui 0.1
# Nice. This sure beats how I've been doing it in the past. Out of # curiousity, can you talk about what you're doing with it? Yeah, I'd like to use this to write an administration tool for my dbmigrations package. I started doing it in hscurses and decided I needed to be able to live with the code (and the process of writing it), so now I'm off in the weeds working on a UI library. :) On the way to work this morning I started working on a Scrollable class to generalize the List's scrolling capabilities and support scrolling of any widget rendered in constrained space. We'll see how that goes.. -- Jonathan Daugherty ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] New TMR editor
Ah-- so _that's_ why you stopped doing HWN. Moving on to Greener Pastures... :) Congrats Brent! On Oct 1, 2009, at 3:44 PM, Brent Yorgey wrote: On Thu, Oct 01, 2009 at 04:33:43PM +0200, Wouter Swierstra wrote: Dear all, After several years at the helm, I've decided to step down as editor of the Monad.Reader. I am happy to announce that Brent Yorgey will take over my role as editor. I'd like to take this opportunity to thank Brent for helping to keep the Monad.Reader alive. I'm sure he'll do a fantastic job. Finally, I'd like to thank all the people who have contributed to the Monad.Reader over the last few years – you guys have made this publication, and my job as an editor, so much fun. And let me be the first to thank Wouter for the outstanding job he's done as editor! I think he deserves much thanks for consistently putting together such a high-quality publication. I look forward to continuing the tradition of excellence -- and I hope YOU, the author of an upcoming Monad.Reader article, do too! I'll be sending out a call for copy for the next issue soon. -Brent ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] New TMR editor
On Thu, Oct 1, 2009 at 3:48 PM, Joe Fredette jfred...@gmail.com wrote: Ah-- so _that's_ why you stopped doing HWN. Moving on to Greener Pastures... At least, less-frequently-released pastures! -- gwern ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
On 2009-10-01 08:53 +0100 (Thu), Andrew Coppin wrote: Sure. But what is a computer program? It's a *list of instructions* that tells a computer *how to do something*. Some are. Some aren't, as proven by the Haskell definition of sum, which is certainly a program. I like to think of a program as a specification. A list of instructions can certainly qualify, but so can other things, depending on what's interpreting and executing that specification. On 2009-10-01 08:59 +0100 (Thu), Andrew Coppin wrote: Although, to all the people who ask why is Ruby so popular?, I might suggest because it's easy to learn... Actually, Ruby isn't terribly easy to learn. If you have previous experience in another imperative or OO language, you'll pick up the parts of Ruby that are similar to that fairly quickly, but you're not really learning anything so much as just doing a simple translation of a few concepts you already know. You're still going to run into problems with a number of standard Ruby constructions, probably not be writing clean or idiomatic code, and you'll be a long way from writing DSLs. In particular, you're likely to be writing highly repetitive code which could easily be refactored into something much smaller and nicer. (I'm constantly seeing people who have programmed in Ruby for years come up with six- to ten-line chunks of code that are could be replaced with a single line if they, e.g., only know that there was such as thing as a modulo function.) From reading a lot of the code out there (particularly disasters such as Rails), I suspect a lot of Ruby programmers don't get much past this level. cjs -- Curt Sampson c...@starling-software.com+81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: SourceGraph 0.5.1.0
This is an updated version of my graph-theoretic static analysis tool for Haskell, SourceGraph. This version is available from http://hackage.haskell.org/package/SourceGraph-0.5.1.0 (now with docs on the Hackage page!). This version provides the ability to pass in a single Haskell source file rather than a Cabal file for analysis purposes. Note that the Cabal version is still preferred as it is better able to determine the project name and which modules are exported: when using a single source file, that file is presumed to be the only exported module and its module name is used as the overall project name. This feature was requested by Curt Sampson. -- 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: Re[2]: [Haskell-cafe] Any generic serializer to String? was: Any working example of using genericserialize?
Hi Dimitry, On Thu, Oct 1, 2009 at 05:23, Dimitry Golubovsky golubov...@gmail.comwrote: OK, I got it to work with gread/gshow. However I have noticed this: *Main (gread $ gshow $ FuncExpr 0 [] (EmptyStmt 0)) :: [(Expression Int, String)] [(FuncExpr 0 [] (EmptyStmt 0),)] vs. *Main (gread $ gshow $ FuncExpr () [] (EmptyStmt ())) :: [(Expression (), String)] [] Or even narrower: *Main (gread $ gshow 1)::[(Int, String)] [(1,)] vs. *Main (gread $ gshow ())::[((), String)] [] that is, the unit type does not work well with gread/gshow, likely because inner parentheses are not parsed as a constructor. *Main gshow () (()) Is this a known bug? I don't think this was noticed before. I wrote it down on the SYB tracker [1]. It should be fixed for the next release. Thanks, Pedro [1] http://code.google.com/p/scrapyourboilerplate/issues/detail?id=9 Thanks. On Wed, Sep 30, 2009 at 10:19 AM, Dimitry Golubovsky golubov...@gmail.com wrote: Bulat, OK, gread/gshow seem to be like the basis primitives. If they work properly, then it is what is needed. Thanks. On 9/30/09, Bulat Ziganshin bulat.zigans...@gmail.com wrote: Hello Max, Wednesday, September 30, 2009, 5:53:37 PM, you wrote: afaik, SYB just provides gshow/gread functions what serialize any Data instance to String -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
2009/10/1 Curt Sampson c...@starling-software.com On 2009-10-01 08:53 +0100 (Thu), Andrew Coppin wrote: Sure. But what is a computer program? It's a *list of instructions* that tells a computer *how to do something*. Some are. Some aren't, as proven by the Haskell definition of sum, which is certainly a program. I like to think of a program as a specification. A list of instructions can certainly qualify, but so can other things, depending on what's interpreting and executing that specification. Lets say that how to do a sum is pure abstract knowledge, and this translates nicely to a declarative haskell sentence. But to perform a sum of two concrete numbers is procedural, because either the program or the compiler or yourself have to extract from the available knowledge a sequence of steps in order to obtain a new knowledge, that is , the result. In imperative languages the sequentiation is more explicit. in functional languages this is more implicit, because the compiler+ runtime do the sequentiation. In fact, a C compiler also perform an automatic sequentiation for this simple operation and generates a sequence of assembler code for either a sum or any mathematical expression, but the haskell compiler is way more powerful for extracting sequences of steps from declarative statements. moreover, haskell promote a declarative style because laziness avoid to express abstract knowledge as sequences. Referential transparency avoid also dependencies of expressions from other expressions, and thus avoids artificial sequencing. however every time the program has to interact with the external world, even for printing the result,, sequencing is necessary. That´s why the compilers and interpreters exist!!!. If the program has to interact many times with the external world in a given sequence, the compiler can not guess such sequence if you don't write it explicitly. The perfect declarative haskell program has no main, no IO monad and no executable. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: Uniplate + strict fields = fail. Why?
2009/10/1 Dmitry Astapov dasta...@gmail.com: Hi, I've been playing with generics in general (pardon the pun) and Uniplate in particular, and found out that strict data fields somehow derail Uniplate. I think this is related to Neil's bug report about Ratio: http://hackage.haskell.org/trac/ghc/ticket/2782 The issue is that the Data instance for your types is stricter than he is expecting. I don't know enough about Uniplate to work out why he can't tunnel the undefined's he's trying to send through Data by hiding then within a box. Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Exceptions during exception unwinding
1254389201.7656.3.ca...@localhost Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 On Thu=2C 2009-10-01 at 03:29 +=2C Brian Bloniarz wrote: I.e. why does an exception raised during exception handling get propagated past the exception that triggered the handler? Because it's the obvious and sensible thing to do and it what every other mainstream language with exceptions does. Good to know ... C++ (the mainstream language I'm most familiar with) treats throwing from a destructor during unwinding as a fatal error. bracket openSomeHandle closeSomeHandle doAction Then catch and ignore the exception from closeSomeHandle (though not all exceptions or you'd block ^C etc). That said=2C how will you know that closeSomeHandle ever works if you always ignore any exceptions it raises? I was suggesting having bracket ignore exceptions from closeSomeHandle when doAction threw=2C not that it'd ignore any exceptions from closeSomeHandle. It's only the case where bracket has 2 exceptions to choose from that's ambiguous=2C and I'm saying that there's a fair amount of code out there that'd prefer to see the first one. Your point about ^C gets us i= nto an even grayer area -- maybe code would prefer to propagate whichever of the 2 exceptions is asynchronous=2C or define a criterion to choose which exception is more serious=2C who knows. All these behaviors are easy to implement using the building blocks that Control.Exception exports right now=2C you're right. So I'm free to build my own bracket variants with different behavior and that's what I'll do. I was just wondering if the default behavior that bracket/onException provide (which are themselves built from catch/block/unblock) is the one that most people want. Thanks=2C -Brian =0A= _=0A= Microsoft brings you a new way to search the web. Try Bing=99 now=0A= http://www.bing.com?form=3DMFEHPGpubl=3DWLHMTAGcrea=3DTEXT_MFEHPG_Core_ta= gline_try bing_1x1= ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exceptions during exception unwinding
Sorry for the garbled post, this should hopefully be plain text: On Thu, 2009-10-01 at 03:29 +, Brian Bloniarz wrote: I.e. why does an exception raised during exception handling get propagated past the exception that triggered the handler? Because it's the obvious and sensible thing to do and it what every other mainstream language with exceptions does. The behaviour you want, to automatically discard any exceptions raised in the handler and to always re-raise the original exception can be implemented using the current semantics, but the reverse is not true. Good to know ... C++ (the mainstream language I'm most familiar with) treats throwing from a destructor during unwinding as a fatal error. I was suggesting having bracket ignore exceptions from closeSomeHandle when doAction threw, not that it'd ignore any exceptions from closeSomeHandle. It's only the case where bracket has 2 exceptions to choose from that's ambiguous, and I'm saying that there's a fair amount of code out there that'd prefer to see the first one. Your point about ^C gets us into an even grayer area -- maybe code would prefer to propagate whichever of the 2 exceptions is asynchronous, or define a criterion to choose which exception is more serious, who knows. All these behaviors are easy to implement using the building blocks that Control.Exception exports right now, you're right. So I'm free to build my own bracket variants with different behavior and that's what I'll do. I was just wondering if the default behavior that bracket/onException provide (which are themselves built from catch/block/unblock) is the one that most people want. Thanks, -Brian _ Microsoft brings you a new way to search the web. Try Bing™ now http://www.bing.com?form=MFEHPGpubl=WLHMTAGcrea=TEXT_MFEHPG_Core_tagline_try bing_1x1___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: usb-0.1
Hello, I would like to announce the release of usb-0.1, a Haskell library for communicating with USB devices from userspace. usb is implemented as a high-level wrapper around Maurício C. Antunes' bindings-libusb which is a binding to the C library: libusb-1.* ( http://libusb.org ). All functionality from libusb is provided except for asynchronous IO. I'm still thinking about if and how I should add that. As usual, install usb using cabal: cabal install usb Or download and install it manually from hackage: http://hackage.haskell.org/package/usb-0.1 Or get the development source using darcs: darcs get http://code.haskell.org/~basvandijk/code/usb Comments and patches are highly welcome. Note that this is the first release, so expect API changes in the future. Note that my brother uploaded 'usb-id-database' to hackage. A small library for associating usb identifiers like vendor, product, class, subclass or prototcol identifiers with their respective names and vice versa: http://hackage.haskell.org/package/usb-id-database This can be helpful when trying to find the right device to operate. In a short while, the package 'ls-usb' will be released. This is a simple program for showing all the usb devices currently attached to your system. It's a nice demonstration on how to use the library. regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1
Bas van Dijk wrote: Comments and patches are highly welcome. I tried to install on my Mac but bindings-common choked on: cabal install bindings-common Resolving dependencies... cabal: Error: some packages failed to install: bindings-common-1.1 failed while unpacking the package. The exception was: /var/folders/mR/mRFqQvztFo0URT0d6GN9wE+++TI/-Tmp-/bindings-common-1.174967/bindings-common-1.1/src/Bindings: createDirectory: does not exist (No such file or directory) Not sure if this is interesting to you, Bas, but I thought I'd share. :-) Groetjes, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1
Yes, that happens. I don't now the cause but the work-around is easy. Simply download the package manually from hackage, unpack and install using cabal. At least the following packages suffer from this problem: bindings-common bindings-libusb bindings-posix Perhaps Maurício can shed some light on this. Groetjes, Roel On Thu, Oct 1, 2009 at 4:02 PM, Martijn van Steenbergen mart...@van.steenbergen.nl wrote: Bas van Dijk wrote: Comments and patches are highly welcome. I tried to install on my Mac but bindings-common choked on: cabal install bindings-common Resolving dependencies... cabal: Error: some packages failed to install: bindings-common-1.1 failed while unpacking the package. The exception was: /var/folders/mR/mRFqQvztFo0URT0d6GN9wE+++TI/-Tmp-/bindings-common-1.174967/bindings-common-1.1/src/Bindings: createDirectory: does not exist (No such file or directory) Not sure if this is interesting to you, Bas, but I thought I'd share. :-) Groetjes, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
On Thu, Oct 1, 2009 at 9:53 AM, Andrew Coppin andrewcop...@btinternet.comwrote: Sure. But what is a computer program? It's a *list of instructions* that tells a computer *how to do something*. And yet, the Haskell definition of sum looks more like a definition of what a sum is rather than an actual, usable procedure for *computing* that sum. (Of course, we know that it /is/ in fact executable... it just doesn't look it at first sight.) Is it? The list of instruction is just an abstraction layer built on top of purely physical process of electrons and transistors; I'm not sure how much imperativeness remains at this level? Not to mention the quantum mechanical processes that take place... And that are also just mathematical models... I mean, it really depends from which angle and at which detail you look at it, no? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] c2hs, size_t, and CSize -- argh!
Hello List, I'm running into a problem with c2hs and how it parses the C typedef 'size_t'. On 32bit systems, this ends up being parsed as a CUInt. On 64bit systems, this ends up as a CULong. This gets especially sticky with function pointers. In order to make bindings with c2hs that work across the different word sizes, I have to write an indirection layer in C that defines wrappers for functions or re-defines typedef's for function pointers to include 'unsigned long' instead of 'size_t'. I see there is a ticket open for this: http://hackage.haskell.org/trac/c2hs/ticket/20 Has any one else run into this issue? Is there a good workaround that doesn't involve writing a C function/typedef for each collision? /jve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1
Roel van Dijk wrote: Yes, that happens. I don't now the cause but the work-around is easy. Simply download the package manually from hackage, unpack and install using cabal. At least the following packages suffer from this problem: bindings-common bindings-libusb bindings-posix Perhaps Maurício can shed some light on this. That's odd, even cabal unpack fails. Smells like a cabal bug. :-) I'll see if I can find if it's been reported before. Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1
That's odd, even cabal unpack fails. Smells like a cabal bug. :-) I'll see if I can find if it's been reported before. I meant a manual unpack: tar xvf bindings-common-1.1.tar.gz But it is indeed odd. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] New TMR editor
Dear all, After several years at the helm, I've decided to step down as editor of the Monad.Reader. I am happy to announce that Brent Yorgey will take over my role as editor. I'd like to take this opportunity to thank Brent for helping to keep the Monad.Reader alive. I'm sure he'll do a fantastic job. Finally, I'd like to thank all the people who have contributed to the Monad.Reader over the last few years – you guys have made this publication, and my job as an editor, so much fun. All the best, Wouter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New OpenGL package: efficient way to convert datatypes?
Ah, but it takes care of my performance problems, so many thanks from the lurker :-) -- Jeff On Wed, Sep 30, 2009 at 11:37 PM, wren ng thornton w...@freegeek.org wrote: wren ng thornton wrote: I guess one could make rules for that, but this tickets makes me wander if that really works: http://hackage.haskell.org/trac/ghc/ticket/1434 The RealToFrac class solves Henning's performance complaint as well. Er, I misread his performance problems. The logfloat package doesn't offer any particular support for rounding to integral types. -- Live well, ~wren ___ 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] river crossing puzzle
Or you could look at my blog posts describing the implementation of the Cannibals and Missionaries variant step by step. First a naive approach and secondly using a state monad solution. http://adoseoflogic.blogspot.com/2009/07/cannibals-missionaries-and-state-monad.html Cheers, Bas 2009/9/28 pat browne patrick.bro...@comp.dit.ie Hi, Does anyone know where there are any Haskell implementations of the the River Crossing puzzle (AKA Farmer/Fox/Goose/Grain). There are several variations but the general ideas are explained at: http://en.wikipedia.org/wiki/River_crossing_puzzle http://en.wikipedia.org/wiki/Fox,_goose_and_bag_of_beans_puzzle I have found one at: http://www.shido.info/hs/haskell9.html Thanks, Pat ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- http://adoseoflogic.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
;) Off topic: Maybe the entire space time, the universe and his history, is isomorphic to a mathematical structure. http://space.mit.edu/home/tegmark/toe_frames.html http://space.mit.edu/home/tegmark/toe_frames.html 2009/10/1 Peter Verswyvelen bugf...@gmail.com On Thu, Oct 1, 2009 at 9:53 AM, Andrew Coppin andrewcop...@btinternet.com wrote: Sure. But what is a computer program? It's a *list of instructions* that tells a computer *how to do something*. And yet, the Haskell definition of sum looks more like a definition of what a sum is rather than an actual, usable procedure for *computing* that sum. (Of course, we know that it /is/ in fact executable... it just doesn't look it at first sight.) Is it? The list of instruction is just an abstraction layer built on top of purely physical process of electrons and transistors; I'm not sure how much imperativeness remains at this level? Not to mention the quantum mechanical processes that take place... And that are also just mathematical models... I mean, it really depends from which angle and at which detail you look at it, no? ___ 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: vty-ui 0.1
On Wed, Sep 30, 2009 at 5:35 AM, Jonathan Daugherty drcyg...@gmail.com wrote: vty-ui is: An extensible library of user interface widgets for composing and laying out Vty user interfaces. This library provides a collection of widgets and a type class for rendering widgets to Vty Images. Am I correct in saying that the collection of widgets contains a single widget type so far? ;-) What are the plans for adding widgets in the future? The list widget looks useful, does it handle multi-line strings (i.e. strings with a \n)? /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] ANNOUNCE: vty-ui 0.1
Am I correct in saying that the collection of widgets contains a single widget type so far? ;-) Technically, four; vertical and horizontal boxes, a text string widget, and the List you mentioned. It only has a few types because I was just releasing early. I'm going to start using this in a project and add things as needed. The list widget looks useful, does it handle multi-line strings (i.e. strings with a \n)? It currently only handles single-line strings but I'd actually like to generalize it to take a list of Widget instances (possibly with restrictions). -- Jonathan Daugherty ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: vty-ui 0.1
On Thu, Oct 1, 2009 at 4:23 PM, Jonathan Daugherty drcyg...@gmail.com wrote: Am I correct in saying that the collection of widgets contains a single widget type so far? ;-) Technically, four; vertical and horizontal boxes, a text string widget, and the List you mentioned. It only has a few types because I was just releasing early. I'm going to start using this in a project and add things as needed. Nice. This sure beats how I've been doing it in the past. Out of curiousity, can you talk about what you're doing with it? The list widget looks useful, does it handle multi-line strings (i.e. strings with a \n)? It currently only handles single-line strings but I'd actually like to generalize it to take a list of Widget instances (possibly with restrictions). Very nice. /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] Splitting data and function declarations over multiple files
Along the projection/co-algebra lines (I actually didn't know that's what
they were called until today :) yay for learning new things!)
How about something like this:
-- Define prototypes for your class of actions here
data Actor = Actor {pos::Vector2 Float, move::Vector2 Float - Actor}
-- simple class that selects your actions based on type
class ActorClass a where
mkActor :: a - Actor
-- object types
data Ball = Ball ... -- stuff
data Paddle = Paddle ... -- stuff
data Wall = Wall ... -- suff
-- Functions for working with objects
getBallPosition (Ball ...) = ...
getPaddlePosition (Paddle ...) = ...
moveBall (Ball ...) = ...
movePaddle (Ball ...) = ...
-- selection actions for Ball
instance Actor Ball where
mkActor this = let
pos' = getBallPosition this
move' v = moveBall this
in Actor pos' move'
-- selection actions for Paddle
instance Actor Paddle where
mkActor this = let
pos' = getPaddlePosition this
move' v = movePaddle this
in Actor pos' move'
Base off a technique I ran across here:
http://www.mail-archive.com/hask...@haskell.org/msg04513.html
Also, a useful wikipage for doing OO things in haskell:
http://www.haskell.org/haskellwiki/OOP_vs_type_classes
- Job
On Thu, Oct 1, 2009 at 4:45 AM, Peter Verswyvelen bugf...@gmail.com wrote:
I'm not sure if I understand what you mean with this co-algebraic approach,
but I guess you mean that functions - like move - don't work directly on any
datatype; you need to provide other functions that give access to the data.
But that's basically what type classes do no? And that's also related to my
earlier post of strong duck typing in Haskell.
At least also in C#, that's the way I usually write code that works on any
type, just make an interface or pass in a delegate. I also know that my OO
background keeps pushing me in the wrong direction when it comes to Haskell
;-)
The collision handling approach is always interesting :) In OO this is
usually solved using multi-methods or visitors:
http://en.wikipedia.org/wiki/Multiple_dispatch. What I usually did in old
games of mine to handle collisions is not look at the type, but at the
collision specific features of a type (which are again functions that
extract information from the object), and that is most likely again the
co-algebraic approach?
On Wed, Sep 30, 2009 at 9:15 PM, Luke Palmer lrpal...@gmail.com wrote:
On Wed, Sep 30, 2009 at 9:54 AM, Peter Verswyvelen bugf...@gmail.com
wrote:
I guess this is related to the expression problem.
Suppose I have a datatype
data Actor = Ball ... | Paddle ... | Wall ...
and a function
move (Ball ...) =
move (Paddle ...) =
move (Wall ...) =
in Haskell one must put Actor and move into a single file.
This is rather cumbersome if you work with multiple people or want to
keep
the files small and readable.
Surely it is possible to use type classes, existentials, etc to split
the
data type into multiple ones, but that's already advanced stuff in a
sense.
You can do it without type classes and existentials. The
functionality you want is already supported by Haskell, you just have
to let go of your syntactical expectations. The trick is that you
should rewrite your data type not as an algebra (a set of
constructors), but as a coalgebra (a set of projections).
Let's say your two open functions are:
move :: Actor - Actor
isAlive :: Actor - Bool
This gives rise to the definition of an Actor type:
data Actor = Actor { move :: Actor, isAlive :: Bool }
And then the alternatives of your open data type are just values of type
Actor:
ball :: Vector - Vector - Actor
ball pos vel = Actor {
move = ball (pos + vel) vel,
isAlive = True
}
etc.
This trick works well until you get to the encoding of functions that
pattern match on multiple Actors at the same time. As far as I can
tell, that cannot be encoded in this style in any reasonable way.
Such functions must be rephrased in a coalgebraic style; i.e. instead
of asking about constructors, using projection functions it knows are
available.
So for example instead of implementing collide by asking about
pairs, add functions which report a shape function and a normal, or
whatever your collide algorithm needs from shapes.
You would probably end up having to do this anyway even with your
proposed extension, because watch:
partial data Actor = Ball ...
collide (Ball ...) (Ball ...) = ...
collide (Ball ...) x = ...
We don't know about any other constructors, so the second line has to
contain a pattern-free x. So you would have to use projection
functions to get any information about it, exactly as you would when
you're writing in the coalgebraic style.
So, Yes! Haskell can do that!
Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Re: [Haskell-cafe] Market Place for Haskell development teams?
On 2009-09-29 13:18 +0200 (Tue), Alberto G. Corona wrote: What is the vehicle that haskell can use to enter the mainstream?. Actually, I have one more thought on that: wait. I'd had the impression that Haskell was becoming fairly well known (if not yet heavily used, in comparison to languages like Java), but I just ran across some hard evidence for this. In the 32 languages ranked on http://www.langpop.com/ , Haskell consistently comes down near the bottom in the various rankings of use. (But hey, we're not so weird we're not in there!) But if you look down near the bottom, at the chart labeled Normalized Discussion Site Results, you'll notice that Haskell comes out sixth. Even trying to be more fair to the mainstream, and changing the weighting to drop Lambda the Ultimate completely (after all, they're just a bunch of academic wankers, right?) and bring IRC down to a contribution of 0.5 instead of 1 (apparently those academic wankers have lots of time to chat online), Haskell still comes out tenth, with a score over a third that of the leader, Java, and close to half that of PHP and C (2nd and 3rd place, respectively). We've also got at least one undeniably good, production-quality compiler (which is more than PHP or Ruby can say), and have sold many tens of thousands, perhaps even hundreds of thousands, of books. At this point, I don't think many people (John A. De Goes excepted) are looking at people writing major applications in Haskell as if they're aliens living on another planet. Haskell is in the mainstream already as far as being taken seriously; most of the complaints I'm seeing seem to be grasping at the same kinds of straws that the anti-Java guys were back in the late '90s. (It's hopeless if it uses garbage collection.) We've even got our own over-hyped, under-utilized supposed benefit (it's good for multicore). The main whinging seems to be about libraries, of which we have only 1585 on hackage. Compare with RubyForge, which has 2059 projects in beta or better status, or 2961 if we include alpha as well. The Ruby Application Archive has 1768 projects; I have no idea how much overlap there is, or how many of these are real. I think we just need to sit tight for a couple of years. cjs -- Curt Sampson c...@starling-software.com+81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1
The file bindings-common.tar.gz looks a bit odd: when I unpack it with 7Zip, I get the path: bindings-common-1.1.tar.gz\\home\mauricio\bindings-common-1.1.tar.gz\bindings-common-1.1\ (first part deleted) Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- On Thu, 01 Oct 2009 16:12:21 +0200, Roel van Dijk vandijk.r...@gmail.com wrote: Yes, that happens. I don't now the cause but the work-around is easy. Simply download the package manually from hackage, unpack and install using cabal. At least the following packages suffer from this problem: bindings-common bindings-libusb bindings-posix Perhaps Maurício can shed some light on this. Groetjes, Roel On Thu, Oct 1, 2009 at 4:02 PM, Martijn van Steenbergen mart...@van.steenbergen.nl wrote: Bas van Dijk wrote: Comments and patches are highly welcome. I tried to install on my Mac but bindings-common choked on: cabal install bindings-common Resolving dependencies... cabal: Error: some packages failed to install: bindings-common-1.1 failed while unpacking the package. The exception was: /var/folders/mR/mRFqQvztFo0URT0d6GN9wE+++TI/-Tmp-/bindings-common-1.174967/bindings-common-1.1/src/Bindings: createDirectory: does not exist (No such file or directory) Not sure if this is interesting to you, Bas, but I thought I'd share. :-) Groetjes, Martijn. ___ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1
On Thu, 2009-10-01 at 16:22 +0200, Martijn van Steenbergen wrote: Roel van Dijk wrote: Yes, that happens. I don't now the cause but the work-around is easy. Simply download the package manually from hackage, unpack and install using cabal. At least the following packages suffer from this problem: bindings-common bindings-libusb bindings-posix Perhaps Maurício can shed some light on this. That's odd, even cabal unpack fails. Smells like a cabal bug. :-) I'll see if I can find if it's been reported before. I suspect it is a bug in the tar code (a copy of which is used in cabal-install). Most .tar files contain entries for the directories that precede the entries for the files. This is only by convention however. It looks like this tar file has an entry for src/Bindings/SomeFile.hs without any preceding entries for src/AnotherFile or for the directory itself src/Bindings/. The bug is that while the tar code would create the src/ directory for a file entry src/AnotherFile, it would not create the src/ directory for src/Bindings/SomeFile.hs, just try to create the src/Bindings directroy, which then fails since src/ does not yet exist. I was trying to avoid making all parent directories in a fully recursive way. In particular I don't want it to make the target root directory if it did not already exist. I guess it should at least make the directories between the target root and the directory containing the file to be unpacked. If someone wants to make a patch for this then please do it against the tar package code: darcs get http://code.haskell.org/tar/ Note that tar files constructed using cabal sdist should not have this particular problem due to the order of entries within the archive. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
Tom Tobin wrote: On Thu, Oct 1, 2009 at 3:26 AM, Andrew Coppin andrewcop...@btinternet.com wrote: It might be a better argument to say that human thinking is fundamentally sequential; parallel computers have been around for a little while now... Perhaps *conscious* human thinking is sequential — yet our brains are massively parallel processors, and have been around for quite a long time. ;-) This is very true. And it's just as well; I read somewhere that the maximum firing rate of a neuron gives the human brain an effective clock frequency of about 100 MHz - which isn't terribly fast. But it's massively parallel, as you say. Actually, I just had a flash of inspiration: Maybe the reason programmers tend to think sequentially is because programmers tend to be *men*. Maybe the way to hardness the multicores is to get more women into programming? :-D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] c2hs, size_t, and CSize -- argh!
On Thu, 2009-10-01 at 10:20 -0400, John Van Enk wrote:
Hello List,
I'm running into a problem with c2hs and how it parses the C typedef
'size_t'. On 32bit systems, this ends up being parsed as a CUInt. On
64bit systems, this ends up as a CULong. This gets especially sticky
with function pointers.
Right. Of course that's because on those different platforms size_t
really is a typedef for unsigned int or unsigned long.
I see there is a ticket open for this:
http://hackage.haskell.org/trac/c2hs/ticket/20
Has any one else run into this issue? Is there a good workaround that
doesn't involve writing a C function/typedef for each collision?
So what you would want, presumably, is to map the size_t typedef to
the Haskell type Foreign.C.Types.CSize, rather than what c2hs discovers
as the actual raw type of size_t. Then you're making the promise that
unsigned long, or unsigned int really really does match
Foreign.C.Types.CSize.
Currently c2hs has no support for remapping basic types like that.
As for a workaround, just use fromIntegral to convert to CSize. You know
this is always possible because you know CSize matches CUInt or CULong
on the appropriate platforms.
$ cat foo.h
#include stddef.h
size_t foo(void);
$ cat foo.c
#include foo.h
size_t foo(void) { return 42; }
$ cat foo.chs
import Foreign.C.Types
foo :: IO CSize
foo = fmap fromIntegral {# call foo as bar #}
$ gcc -c foo.c
$ c2hs foo.h foo.chs
$ ghci foo.hs -fffi foo.o
Main foo
42
Duncan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
May be because consciousness is relatively new and thus, not optimized. Sequentiallity is somehow related with lack of information and lack or resources. There is nothing more sequential than a Turing machine. The Von Newman architecture is designed to make as much as possible with a few more resources. The older parts of the brain are fast and parallel because they have a long history of optimizations by natural selection., The new cortex still struggles, step by step, to deduce new information from the available internal and external information at the pace they arrive. 2009/10/1 Tom Tobin korp...@korpios.com On Thu, Oct 1, 2009 at 3:26 AM, Andrew Coppin andrewcop...@btinternet.com wrote: It might be a better argument to say that human thinking is fundamentally sequential; parallel computers have been around for a little while now... Perhaps *conscious* human thinking is sequential — yet our brains are massively parallel processors, and have been around for quite a long time. ;-) ___ 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: vty-ui 0.1
# Nice. This sure beats how I've been doing it in the past. Out of # curiousity, can you talk about what you're doing with it? Yeah, I'd like to use this to write an administration tool for my dbmigrations package. I started doing it in hscurses and decided I needed to be able to live with the code (and the process of writing it), so now I'm off in the weeds working on a UI library. :) On the way to work this morning I started working on a Scrollable class to generalize the List's scrolling capabilities and support scrolling of any widget rendered in constrained space. We'll see how that goes.. -- Jonathan Daugherty ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting data and function declarations over multiple files
Opps, errors, it should be more like:
moveBall (Vector2 x y) (Ball ...) = ...
movePaddle (Vector2 x y) (Paddle ...) = ...
-- selection actions for Ball
instance Actor Ball where
mkActor this = let
pos' = getBallPosition this
move' v = mkActor $ moveBall v this
in Actor pos' move'
-- selection actions for Paddle
instance Actor Paddle where
mkActor this = let
pos' = getPaddlePosition this
move' v = mkActor $ movePaddle v this
in Actor pos' move'
Hmm, I bet some generics, or template haskell could clean up the extra
boilerplate associated with this technique.
- Job
On Thu, Oct 1, 2009 at 11:35 AM, Job Vranish jvran...@gmail.com wrote:
Along the projection/co-algebra lines (I actually didn't know that's what
they were called until today :) yay for learning new things!)
How about something like this:
-- Define prototypes for your class of actions here
data Actor = Actor {pos::Vector2 Float, move::Vector2 Float - Actor}
-- simple class that selects your actions based on type
class ActorClass a where
mkActor :: a - Actor
-- object types
data Ball = Ball ... -- stuff
data Paddle = Paddle ... -- stuff
data Wall = Wall ... -- suff
-- Functions for working with objects
getBallPosition (Ball ...) = ...
getPaddlePosition (Paddle ...) = ...
moveBall (Ball ...) = ...
movePaddle (Ball ...) = ...
-- selection actions for Ball
instance Actor Ball where
mkActor this = let
pos' = getBallPosition this
move' v = moveBall this
in Actor pos' move'
-- selection actions for Paddle
instance Actor Paddle where
mkActor this = let
pos' = getPaddlePosition this
move' v = movePaddle this
in Actor pos' move'
Base off a technique I ran across here:
http://www.mail-archive.com/hask...@haskell.org/msg04513.html
Also, a useful wikipage for doing OO things in haskell:
http://www.haskell.org/haskellwiki/OOP_vs_type_classes
- Job
On Thu, Oct 1, 2009 at 4:45 AM, Peter Verswyvelen bugf...@gmail.comwrote:
I'm not sure if I understand what you mean with this co-algebraic
approach, but I guess you mean that functions - like move - don't work
directly on any datatype; you need to provide other functions that give
access to the data. But that's basically what type classes do no? And that's
also related to my earlier post of strong duck typing in Haskell.
At least also in C#, that's the way I usually write code that works on any
type, just make an interface or pass in a delegate. I also know that my OO
background keeps pushing me in the wrong direction when it comes to Haskell
;-)
The collision handling approach is always interesting :) In OO this is
usually solved using multi-methods or visitors:
http://en.wikipedia.org/wiki/Multiple_dispatch. What I usually did in old
games of mine to handle collisions is not look at the type, but at the
collision specific features of a type (which are again functions that
extract information from the object), and that is most likely again the
co-algebraic approach?
On Wed, Sep 30, 2009 at 9:15 PM, Luke Palmer lrpal...@gmail.com wrote:
On Wed, Sep 30, 2009 at 9:54 AM, Peter Verswyvelen bugf...@gmail.com
wrote:
I guess this is related to the expression problem.
Suppose I have a datatype
data Actor = Ball ... | Paddle ... | Wall ...
and a function
move (Ball ...) =
move (Paddle ...) =
move (Wall ...) =
in Haskell one must put Actor and move into a single file.
This is rather cumbersome if you work with multiple people or want to
keep
the files small and readable.
Surely it is possible to use type classes, existentials, etc to split
the
data type into multiple ones, but that's already advanced stuff in a
sense.
You can do it without type classes and existentials. The
functionality you want is already supported by Haskell, you just have
to let go of your syntactical expectations. The trick is that you
should rewrite your data type not as an algebra (a set of
constructors), but as a coalgebra (a set of projections).
Let's say your two open functions are:
move :: Actor - Actor
isAlive :: Actor - Bool
This gives rise to the definition of an Actor type:
data Actor = Actor { move :: Actor, isAlive :: Bool }
And then the alternatives of your open data type are just values of type
Actor:
ball :: Vector - Vector - Actor
ball pos vel = Actor {
move = ball (pos + vel) vel,
isAlive = True
}
etc.
This trick works well until you get to the encoding of functions that
pattern match on multiple Actors at the same time. As far as I can
tell, that cannot be encoded in this style in any reasonable way.
Such functions must be rephrased in a coalgebraic style; i.e. instead
of asking about constructors, using projection functions it knows are
available.
So for example instead of implementing collide by asking about
pairs, add functions which report a shape function and a normal, or
whatever your collide algorithm needs from
Re: [Haskell-cafe] c2hs, size_t, and CSize -- argh!
Hi Duncan,
Yes, I forgot to leave out that I'd like to see 'size_t' mapped to CSize.
As a (dirty) workaround, one can use 'castPtr' as the marshaler when dealing
with pointers to 'size_t'. I'm a little more concerned about FunPtr's
(though 'castPtr' still makes the issue go away).
Here's my specific case dealing with function pointers:
In 64bit world, it looks like this:
type ReadableCallback = Ptr () - Ptr CUChar - *Ptr CULong* - IO CUInt
{#fun gcry_ac_io_init_readable_callback {
id `ACIO',
id `FunPtr ReadableCallback',
id `Ptr ()'
} - `()'#}
In 32bit world, it looks like this:
type ReadableCallback = Ptr () - Ptr CUChar - *Ptr CUInt* - IO CUInt
{#fun gcry_ac_io_init_readable_callback {
id `ACIO',
id `FunPtr ReadableCallback',
id `Ptr ()'
} - `()'#}
I'd really like it if I could use 'Ptr CSize' (which corresponds to the
'size_t * ptr' in the C code).
My current workaround (which doesn't use a cast in Haskell) is to redefine
the function pointer type in a C header file to use 'unsigned long' instead
of 'size_t', but this gets cludgy in a hurry. If c2hs could translate to
CSize directly, I could pass a pointer to CSize.
Is it really such a problem to make the conversion? My assumption is that
CSize would match 'size_t' for the specific architecture.
Thanks for your comment.
/jve
On Thu, Oct 1, 2009 at 12:37 PM, Duncan Coutts duncan.cou...@googlemail.com
wrote:
On Thu, 2009-10-01 at 10:20 -0400, John Van Enk wrote:
Hello List,
I'm running into a problem with c2hs and how it parses the C typedef
'size_t'. On 32bit systems, this ends up being parsed as a CUInt. On
64bit systems, this ends up as a CULong. This gets especially sticky
with function pointers.
Right. Of course that's because on those different platforms size_t
really is a typedef for unsigned int or unsigned long.
I see there is a ticket open for this:
http://hackage.haskell.org/trac/c2hs/ticket/20
Has any one else run into this issue? Is there a good workaround that
doesn't involve writing a C function/typedef for each collision?
So what you would want, presumably, is to map the size_t typedef to
the Haskell type Foreign.C.Types.CSize, rather than what c2hs discovers
as the actual raw type of size_t. Then you're making the promise that
unsigned long, or unsigned int really really does match
Foreign.C.Types.CSize.
Currently c2hs has no support for remapping basic types like that.
As for a workaround, just use fromIntegral to convert to CSize. You know
this is always possible because you know CSize matches CUInt or CULong
on the appropriate platforms.
$ cat foo.h
#include stddef.h
size_t foo(void);
$ cat foo.c
#include foo.h
size_t foo(void) { return 42; }
$ cat foo.chs
import Foreign.C.Types
foo :: IO CSize
foo = fmap fromIntegral {# call foo as bar #}
$ gcc -c foo.c
$ c2hs foo.h foo.chs
$ ghci foo.hs -fffi foo.o
Main foo
42
Duncan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1
At least the following packages suffer from this problem: bindings-common bindings-libusb bindings-posix Most .tar files contain entries for the directories that precede the entries for the files. This is only by convention however. It looks like this tar file has an entry for src/Bindings/SomeFile.hs without any preceding entries for src/AnotherFile or for the directory itself src/Bindings/. Thanks for the tip. I used Mercurial archive to create those tars: hg archive -t tgz -p 'bindings-common-1.1' ~/bindings-common-1.1.tar.gz I'll check if this is known in Mercurial, specially the weird output got from 7zip. Meanwhile, I'll be uploading as soon as possible new versions of those packages with runhaskell Setup.hs sdist Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for Physicists
I can't help with the title, but you might show how Haskell can help avoid the subtle bugs that create erroneous results. Start with the dimensional library (http://hackage.haskell.org/package/dimensional). Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1
2009/10/1 Maurício CA mauricio.antu...@gmail.com: Meanwhile, I'll be uploading as soon as possible new versions... Thanks Mauricio, I've uploaded usb-0.1.0.1 that now depends on the fixed bindings-libusb-1.2. http://hackage.haskell.org/package/usb-0.1.0.1 regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] c2hs, size_t, and CSize -- argh!
On Thu, 2009-10-01 at 13:00 -0400, John Van Enk wrote:
Hi Duncan,
Yes, I forgot to leave out that I'd like to see 'size_t' mapped to
CSize.
As a (dirty) workaround, one can use 'castPtr' as the marshaler when
dealing with pointers to 'size_t'. I'm a little more concerned about
FunPtr's (though 'castPtr' still makes the issue go away).
Here's my specific case dealing with function pointers:
Ohhh, if you're dealing with pointers to CSize then it's easy, c2hs
supports that directly. See the c2hs user guide section on the pointer
hook.
{# pointer *size_t as CSizePtr - CSize #}
This tells c2hs that when it sees a *size_t type in a function argument
or result that it should be imported as Ptr CSize.
It generates a type alias and uses that when it imports functions eg:
{# pointer *size_t as CSizePtr - CSize #}
foo :: Ptr CSize - IO ()
foo = {# call foo as raw_foo #}
generates:
type CSizePtr = Ptr (CSize)
foo :: Ptr CSize - IO ()
foo = raw_foo
foreign import ccall safe foo.chs.h foo
raw_foo :: CSizePtr - IO ()
Duncan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] c2hs, size_t, and CSize -- argh!
Ohhh, if you're dealing with pointers to CSize then it's easy, c2hs
supports that directly. See the c2hs user guide section on the pointer
hook.
{# pointer *size_t as CSizePtr - CSize #}
I seriously should have thought of that. I have #pointer's everywhere, but I
didn't think to do it with that. Thanks.
/jve
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New TMR editor
On Thu, Oct 01, 2009 at 04:33:43PM +0200, Wouter Swierstra wrote: Dear all, After several years at the helm, I've decided to step down as editor of the Monad.Reader. I am happy to announce that Brent Yorgey will take over my role as editor. I'd like to take this opportunity to thank Brent for helping to keep the Monad.Reader alive. I'm sure he'll do a fantastic job. Finally, I'd like to thank all the people who have contributed to the Monad.Reader over the last few years – you guys have made this publication, and my job as an editor, so much fun. And let me be the first to thank Wouter for the outstanding job he's done as editor! I think he deserves much thanks for consistently putting together such a high-quality publication. I look forward to continuing the tradition of excellence -- and I hope YOU, the author of an upcoming Monad.Reader article, do too! I'll be sending out a call for copy for the next issue soon. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New TMR editor
Ah-- so _that's_ why you stopped doing HWN. Moving on to Greener Pastures... :) Congrats Brent! On Oct 1, 2009, at 3:44 PM, Brent Yorgey wrote: On Thu, Oct 01, 2009 at 04:33:43PM +0200, Wouter Swierstra wrote: Dear all, After several years at the helm, I've decided to step down as editor of the Monad.Reader. I am happy to announce that Brent Yorgey will take over my role as editor. I'd like to take this opportunity to thank Brent for helping to keep the Monad.Reader alive. I'm sure he'll do a fantastic job. Finally, I'd like to thank all the people who have contributed to the Monad.Reader over the last few years – you guys have made this publication, and my job as an editor, so much fun. And let me be the first to thank Wouter for the outstanding job he's done as editor! I think he deserves much thanks for consistently putting together such a high-quality publication. I look forward to continuing the tradition of excellence -- and I hope YOU, the author of an upcoming Monad.Reader article, do too! I'll be sending out a call for copy for the next issue soon. -Brent ___ 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] New TMR editor
On Thu, Oct 1, 2009 at 3:48 PM, Joe Fredette jfred...@gmail.com wrote: Ah-- so _that's_ why you stopped doing HWN. Moving on to Greener Pastures... At least, less-frequently-released pastures! -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: a boring parser
so whats pretty cool is that I can traverse arbitrary data structures as well: data Tree a = Tree (Tree a) a (Tree a) | Bottom deriving Show left a = do make $ \ st - do case(st) of (Bottom) - eos (Tree left val right) - case (a val) of True - return $ (val, left) False - noMatch right a = do make $ \ st - do case(st) of (Bottom) - eos (Tree left val right) - case (a val) of True - return $ (val, right) False - noMatch eqT a = do make $ \ st - do case(st) of (Bottom) - eos (Tree _ val _) - case (a == val) of True - return $ (val, st) False - noMatch search a = manyTill (left a | right a) (eqT a) run (search 5) $ Tree (Tree Bottom 1 Bottom) 3 (Tree Bottom 5 Bottom) Right (([3],5),Tree Bottom 5 Bottom) On Wed, Sep 30, 2009 at 8:04 PM, Anatoly Yakovenko aeyakove...@gmail.com wrote: i got annoyed with Parsec and wrote a much more boring parser which allows me to parse anything with any kind of matching i want. Its basically a combination of State and Error monads. So i can use a grep like parser that matches via a regular expression over a list of lines grep re = do vv::B.ByteString - any let (_,_,_,rv) = (vv =~ re)::(B.ByteString,B.ByteString,B.ByteString,[B.ByteString]) case (rv) of [] - throwError no match _ - return $ rv run (grep $ C.pack (hello)) $ [C.pack hello world] Right ([hello],[]) or use the same library to scan over a string by combining regular expressions regex re = do make $ \ st - do case (B.null st) of True - throwError eos _ - do let (_,_,after,rv) = (st =~ re)::(B.ByteString,B.ByteString,B.ByteString,[B.ByteString]) case (rv) of [] - throwError no match _ - return $ (rv,after) run (do aa - regex $ C.pack (hello); bb - regex $ C.pack (world); return (aa,bb) ) $ C.pack hello world Right (([hello],[world]),) or simply match integers in a list, or anything that is of type Eq run (many1 $ eq 1) [1,1,1,2,3,4] Right ([1,1,1],[2,3,4]) i can define lt lt cc = do vv - any case (vv cc) of True - return $ vv _ - throwError no match and do run (many1 $ lt 5 | eq 5) [1..10] Right ([1,2,3,4,5],[6,7,8,9,10]) here is the implementation module Parser( ParserM --type alias for the parser ParserM a b is over stream a and returns b , make --makes a parser from a matching function of type :: stream - m (match_data,stream) --for example any is implemented via: --any :: ParserM [a] a --any = make $ \ ll - -- case (ll) of -- (hh:tt) - return $ (hh,tt) -- _ - throwError eos --matches and returns an element from a list, which makes any of type :: ParserM [a] a , any --matches any element from [a] type stream , eq --matches an equal element from [Eq] stream, trivialy implemented in terms of any --eq :: Eq a = a - ParserM [a] a --eq cc = do -- vv - any -- case (vv == cc) of -- True - return $ vv -- _ - throwError no match , (|) --or operator, tries the left one then the right one , manyTill --collects the results of parser 1 until parser 2 succeeds , many1 --collects the results of the parser, must succeed at least once , many --collects the results of a parser , run --runs the parser ) where import Control.Monad.State.Lazy import Control.Monad.Error import Test.QuickCheck import Control.Monad.Identity import Prelude hiding (any) type ParserM a c = StateT a (ErrorT [Char] Identity) c make pp = do st - get (rv,nst) - pp $ st put $ nst return $ rv aa | bb = aa `catchError` \ _ - bb manyTill :: ParserM a c - ParserM a d - ParserM a ([c],d) manyTill pp ee = do do dd - ee return $ ([],dd) `catchError` \ _ - do cc - pp (ccs,dd) - manyTill pp ee return $ (cc:ccs,dd) many1 pp = do rv - pp rest - many1 pp `catchError` \ _ - return $ [] return $ rv : rest many pp = do many1 pp | return [] any :: ParserM [a] a any = make $ \ ll - case (ll) of (hh:tt) - return $ (hh,tt) _ - throwError eos eq :: Eq a = a - ParserM [a] a eq cc = do vv - any case (vv == cc) of True - return $ vv _ - throwError no match lt cc = do vv - any case (vv cc) of True -
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1
In a short while, the package 'ls-usb' will be released. I've just uploaded usb-id-database-0.4 and ls-usb-0.1: http://hackage.haskell.org/package/usb-id-database-0.4 http://hackage.haskell.org/package/ls-usb-0.1 The utility ls-usb uses the usb package to detect all USB devices connected to you system. It then displays them in a nice list. It behaves very much like the existing utility lsusb and is meant more as an example of using the usb package then as an actual program. Be sure to run with elevated privileges if you want detailed information. Regards, Roel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] parsing error
Hi there, I am trying to write some code for parsing string in p==q or pq or p|||r, something like this.But I have trouble in reading operator like==|||... how can I fix it? I attached my code file with the email.Can some one give me some hints to fix the error and run the code?Thank you in advance!!! _ 上Windows Live 中国首页，下载最新版Messenger！ http://www.windowslive.cn assi3.lhs Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] Can this be done?
You can do it almost transparently with the Workflow package:: http://hackage.haskell.org/package/Workflow 2009/2/11 Cristiano Paris cristiano.pa...@gmail.com On Wed, Feb 11, 2009 at 2:30 PM, Peter Verswyvelen bugf...@gmail.com wrote: I haven't looked at the details, but I think this is what a library like Reactive from Conal Elliott could do, but as far as I understand it, it is still work in progress. I'm interested in the possibility of stopping/pickling/unpickling/resuming a computation. Cristiano ___ 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 this be done?
I was poking around once trying to find something like that and stumbled across this: http://wiki.cs.pdx.edu/forge/riviera.html Cheers, Tim On Wed, Feb 11, 2009 at 8:22 AM, Cristiano Paris cristiano.pa...@gmail.comwrote: I wonder whether this can be done in Haskell (see muleherd's comment): http://www.reddit.com/r/programming/comments/7wi7s/how_continuationbased_web_frameworks_work/ Cristiano ___ 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] DSL and GUI Toolkits
Hi, I managed to abstract parts of the business logic of my application by employing a very naive DSL and it actually worked quite well. I'll probably replace that with a Finally Tagless version, just for the sake of it. But now I'd really try to abstract the hard part, the GUI logic. I had been switching back and forth between wxHaskell and Gtk and eventually settled for wxHaskell. And my gui code is a huge mess, it works, for now, but it'd be hell if I even had to change the tiniest bit. So I'm wondering if I could go the same way as with (parts) of the business logic, using a DSL here too. Now I could do with some input on the merits of this approach. Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
On Oct 1, 2009, at 8:53 PM, Andrew Coppin wrote: Sure. But what is a computer program? It depends on the computer. Classical machines do one thing, data flow machines do another, reduction machines another. I once saw a tiny machine at a UK university where the hardware was a combinator reduction gadget. It wasn't combinators on top of conventional instructions, the hardware did nothing _but_ combinators. A computer program, in short, is *whatever we want it to be*. (Within reasonable limits.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
On Oct 1, 2009, at 9:26 PM, Andrew Coppin wrote: It might be a better argument to say that human thinking is fundamentally sequential; parallel computers have been around for a little while now... You've never been talking on the phone while stirring a pot with one hand and wiping down a child with the other? You've never read (part of) a book while watching a TV program and been able to summarize both afterwards? You've never played the piano while talking about something else? Human *verbalisation* is fundamental, human *thinking* is not. (It's not unboundedly parallel either.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
On Oct 2, 2009, at 11:14 AM, Richard O'Keefe wrote: Human *verbalisation* is fundamental, human *thinking* is not. Sigh. Accidentally lean on the wrong key and half your text disappears. Human *verbalisation* is fundamentally sequential. Human *thinking* is not. I don't know any sign language myself, but I am aware that since people have faces and two hands, there is a limited amount of concurrency in some sign languages. (E.g., you can give place and manner at the same time.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
Andrew Coppin said: Sure. But what is a computer program? then Richard O'Keefe said: A computer program, in short, is *whatever we want it to be*. (Within reasonable limits.) I agree with Richard's conclusion. From where I sit, the critical point is that, unless you're breadboarding, programming is working in the abstract, and we choose our abstractions. There's a strong tradition of sequential imperative programming, but that's as far as it goes. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Introspection on types.
Is there a way to tell, let's say, how many constructors there are for a type? Or do I need one of the haskell extensions I've read about? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Introspection on types.
On Thu, Oct 1, 2009 at 6:22 PM, Gregory Propf gregorypr...@yahoo.com wrote: Is there a way to tell, let's say, how many constructors there are for a type? Or do I need one of the haskell extensions I've read about? Use Data.Data and derive Data for the types you are interested in or instance it for pre-existing types that aren't already instances. Introspection is tedious but trivial. http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Data.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Introspection on types.
On Oct 1, 2009, at 19:22 , Gregory Propf wrote: Is there a way to tell, let's say, how many constructors there are for a type? Or do I need one of the haskell extensions I've read about? If the constructors are nullary (that is: data MyData = Foo | Bar | Baz) you could derive Enum and Bounded, then (maxBound :: MyData) is one less than the number of constructors. Anything more complicated requires deriving Data or Typeable (I've done it with the latter but don't recall details off the top of my head). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig 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] Re: a boring parser
Cool, I like how this parser can model the Look, an Eagle scenario. For reference: http://www.youtube.com/watch?v=pjh3e198pUQ The parser can change focus (that is, change traversal strategy) in response to a successful parse. In the Look, an Eagle scenario, the bear is able to interpret and respond to its input serially and interactively, but when the bear's input stream is replaced by a new one, the man is able to capture the prize. -Greg On Thu, Oct 1, 2009 at 1:02 PM, Anatoly Yakovenko aeyakove...@gmail.comwrote: so whats pretty cool is that I can traverse arbitrary data structures as well: data Tree a = Tree (Tree a) a (Tree a) | Bottom deriving Show left a = do make $ \ st - do case(st) of (Bottom) - eos (Tree left val right) - case (a val) of True - return $ (val, left) False - noMatch right a = do make $ \ st - do case(st) of (Bottom) - eos (Tree left val right) - case (a val) of True - return $ (val, right) False - noMatch eqT a = do make $ \ st - do case(st) of (Bottom) - eos (Tree _ val _) - case (a == val) of True - return $ (val, st) False - noMatch search a = manyTill (left a | right a) (eqT a) run (search 5) $ Tree (Tree Bottom 1 Bottom) 3 (Tree Bottom 5 Bottom) Right (([3],5),Tree Bottom 5 Bottom) On Wed, Sep 30, 2009 at 8:04 PM, Anatoly Yakovenko aeyakove...@gmail.com wrote: i got annoyed with Parsec and wrote a much more boring parser which allows me to parse anything with any kind of matching i want. Its basically a combination of State and Error monads. So i can use a grep like parser that matches via a regular expression over a list of lines grep re = do vv::B.ByteString - any let (_,_,_,rv) = (vv =~ re)::(B.ByteString,B.ByteString,B.ByteString,[B.ByteString]) case (rv) of [] - throwError no match _ - return $ rv run (grep $ C.pack (hello)) $ [C.pack hello world] Right ([hello],[]) or use the same library to scan over a string by combining regular expressions regex re = do make $ \ st - do case (B.null st) of True - throwError eos _ - do let (_,_,after,rv) = (st =~ re)::(B.ByteString,B.ByteString,B.ByteString,[B.ByteString]) case (rv) of [] - throwError no match _ - return $ (rv,after) run (do aa - regex $ C.pack (hello); bb - regex $ C.pack (world); return (aa,bb) ) $ C.pack hello world Right (([hello],[world]),) or simply match integers in a list, or anything that is of type Eq run (many1 $ eq 1) [1,1,1,2,3,4] Right ([1,1,1],[2,3,4]) i can define lt lt cc = do vv - any case (vv cc) of True - return $ vv _ - throwError no match and do run (many1 $ lt 5 | eq 5) [1..10] Right ([1,2,3,4,5],[6,7,8,9,10]) here is the implementation module Parser( ParserM --type alias for the parser ParserM a b is over stream a and returns b , make--makes a parser from a matching function of type :: stream - m (match_data,stream) --for example any is implemented via: --any :: ParserM [a] a --any = make $ \ ll - -- case (ll) of -- (hh:tt) - return $ (hh,tt) -- _ - throwError eos --matches and returns an element from a list, which makes any of type :: ParserM [a] a , any --matches any element from [a] type stream , eq --matches an equal element from [Eq] stream, trivialy implemented in terms of any --eq :: Eq a = a - ParserM [a] a --eq cc = do -- vv - any -- case (vv == cc) of -- True - return $ vv -- _ - throwError no match , (|) --or operator, tries the left one then the right one , manyTill--collects the results of parser 1 until parser 2 succeeds , many1 --collects the results of the parser, must succeed at least once , many--collects the results of a parser , run --runs the parser ) where import Control.Monad.State.Lazy import Control.Monad.Error import Test.QuickCheck import Control.Monad.Identity import Prelude hiding (any) type ParserM a c = StateT a (ErrorT [Char] Identity) c make pp = do st - get (rv,nst) - pp $ st put $ nst return $ rv aa | bb = aa `catchError` \ _ - bb manyTill :: ParserM a c -
[Haskell-cafe] FP Market Place (was Market Place for Haskell development teams?)
Haskell, and FP languages more broadly, are finding a pretty solid niche in small scale, but technically demanding and lucrative projects. Financial modeling and analytics are the first thing that comes to mind. The work of Galois, Atom, etc also sort of fit this mold. While the people on this list are clearly leaning towards Haskell, this is a niche that Haskell shares with OCaml, Erlang, and even Scala and Clojure. Perhaps, combining efforts with those communities (call it lambdajobs or something) would help get closer to a critical mass and aid cross-pollination between communities. Considering the salaries and value-add with skilled FP programmers, and the difficulty in finding them, this could even be a profitable venture in the long run if employers are charged for successful placements or for ads once we get going. Just my 2¢ Max On Oct 1, 2009, at 11:56 AM, Curt Sampson wrote: On 2009-09-29 13:18 +0200 (Tue), Alberto G. Corona wrote: What is the vehicle that haskell can use to enter the mainstream?. Actually, I have one more thought on that: wait. I'd had the impression that Haskell was becoming fairly well known (if not yet heavily used, in comparison to languages like Java), but I just ran across some hard evidence for this. In the 32 languages ranked on http://www.langpop.com/ , Haskell consistently comes down near the bottom in the various rankings of use. (But hey, we're not so weird we're not in there!) But if you look down near the bottom, at the chart labeled Normalized Discussion Site Results, you'll notice that Haskell comes out sixth. Even trying to be more fair to the mainstream, and changing the weighting to drop Lambda the Ultimate completely (after all, they're just a bunch of academic wankers, right?) and bring IRC down to a contribution of 0.5 instead of 1 (apparently those academic wankers have lots of time to chat online), Haskell still comes out tenth, with a score over a third that of the leader, Java, and close to half that of PHP and C (2nd and 3rd place, respectively). We've also got at least one undeniably good, production-quality compiler (which is more than PHP or Ruby can say), and have sold many tens of thousands, perhaps even hundreds of thousands, of books. At this point, I don't think many people (John A. De Goes excepted) are looking at people writing major applications in Haskell as if they're aliens living on another planet. Haskell is in the mainstream already as far as being taken seriously; most of the complaints I'm seeing seem to be grasping at the same kinds of straws that the anti-Java guys were back in the late '90s. (It's hopeless if it uses garbage collection.) We've even got our own over-hyped, under-utilized supposed benefit (it's good for multicore). The main whinging seems to be about libraries, of which we have only 1585 on hackage. Compare with RubyForge, which has 2059 projects in beta or better status, or 2961 if we include alpha as well. The Ruby Application Archive has 1768 projects; I have no idea how much overlap there is, or how many of these are real. I think we just need to sit tight for a couple of years. cjs -- Curt Sampson c...@starling-software.com+81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.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] ANN: json-b-0.0.4
This version fixes defective handling of empty objects and arrays. http://hackage.haskell.org/package/json-b-0.0.4 Thanks to Dmitry Astapov for this fix. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell for Physicists
ed...@ymonad.com 쓴 글: Hi, I will give a seminar to physicists at USP (Universidade de São Paulo, Brazil) university and they asked me for a good title, something that can attract physicists. Anyone has some suggestions? (Will be a seminar about the use of Haskell to substitute C or Fortran in a lot of tasks, and how it can be used in some problems instead of Matlab, Mathematica, etc.) Thanks, Edgar You should also see the well known Haskell story in this area: http://bayern.stanford.edu/~brant/lightning/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] Market Place for Haskell development teams?
On 2009-09-30 21:27 +0200 (Wed), Alberto G. Corona wrote: Do you really want, in 2020, to look back at the 2010 revision of the Haskell standard and think, we entrenched things that for a decade everybody agreed was dumb? I see no problem in haskell having both. experimental and fixed versions. Haskell 2020 for you and me and haskell 2010 for my commercial code. Both woukd ve maintained and enriched by far more people. If so, why hasn't this happened with Haskell98? Become more stupid may mean give exactly what the people want that transaltes to be more stable, give libraries, platforms etc. Not entering the mainstream seems a small price to pay to avoid this fate. Haskell has pretty nice niche right now that it's filling very well; emptying this nich to move into competition for other niches that already have languages filling them seems to me bad for everybody all around. I suspect that main hope a lot of Haskell promoters have (certainly this is mine) is not that more people do what they do now but in Haskell, but people do things in the better ways that Haskell allows. In other words, we don't want to move into the mainstream, we want the mainstream to come over here. And as far as something like dealing with a changing language and libraries, the mainstream already has well-established and popular techniques for doing just: agile development. If anything, the FP community could be learning from them on this score. So in some of your marketing ideas, you're actually marketing to a problem that has better solutions already in the mainstream. cjs -- Curt Sampson c...@starling-software.com+81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cal, Clojure, Groovy, Haskell, OCaml, etc.
namekuseijin namekusei...@gmail.com writes: Point is: = . $ : ! `` and meaningful whitespace are all nice shortcuts, but also hairy confusing... As somebody pointed out, these are rather idiomatic, and only confusing to beginners. (I'm not sure what you refer to with whitespace, some think layout makes code difficult to write, but I don't think it hurts legibility? If you refer to extension that makes 'x?y' and 'x ? y' mean different things, then I agree: that way lies madness.) I agree it's usually better to use real names, but one problem with many operators (and Haskell functions in general) is their extreme generality. For instance, the = cominator is usually pronounced 'bind'. Does this really help? exp1 = exp2 vs exp1 `bind` exp2 or even bind exp1 exp2 In some cases where names are used, it just increases confusion, e.g. the Monoid function 'mappend' is nice for concatenating two lists, but a rather odd name for mulitplying two integers. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
Andrew Coppin andrewcop...@btinternet.com writes: Peter Verswyvelen wrote: I really doubt people tend to think in either way. It's not even sure our thinking can be modeled with computing no? Well, try this: Go ask a random person how you add up a list of numbers. Although the question of how we naturally think often comes up, I'm not sure it's a very important one. In my experience, the natural thing for humans appear rather to be the absence of thinking, and instead slouching in front of the TV eating unhealthy food. After all, we give people who program computers several years of education to learn about unnatural things like counters and temporary variables, or recursion and folds. The question shouldn't be what comes more natural for average Joe, but rather what skills can we teach a reasonably bright student in three to five years that will make her the most effective programmer. (That's what the question should be, of course what the question really *is* is what curriculum can we present that looks entertaining, fashionable, and trivial enough that enough high-school kids will apply for the department not to be starved of funds... ) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
John Dorsey wrote: Well, try this: Go ask a random person how you add up a list of numbers. Most of them will say something about adding the first two together, adding the third to that total, and so forth. In other words, the step by step instructions. You word the (hypothetical) question with a bias toward imperative thinking. You're asking How do you do this action? Why isn't the question What is the sum of a list of numbers?, which is biased toward the declarative? Sure. But what is a computer program? It's a *list of instructions* that tells a computer *how to do something*. And yet, the Haskell definition of sum looks more like a definition of what a sum is rather than an actual, usable procedure for *computing* that sum. (Of course, we know that it /is/ in fact executable... it just doesn't look it at first sight.) Whatever; I'm leaning more and more towards the concept that FP is only hard for people who already learned some other way... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
Ketil Malde wrote: Although the question of how we naturally think often comes up, I'm not sure it's a very important one. In my experience, the natural thing for humans appear rather to be the absence of thinking, and instead slouching in front of the TV eating unhealthy food. After all, we give people who program computers several years of education to learn about unnatural things like counters and temporary variables, or recursion and folds. The question shouldn't be what comes more natural for average Joe, but rather what skills can we teach a reasonably bright student in three to five years that will make her the most effective programmer. I'll go along with that. Although, to all the people who ask why is Ruby so popular?, I might suggest because it's easy to learn... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
2009/10/1 Andrew Coppin andrewcop...@btinternet.com: John Dorsey wrote: Well, try this: Go ask a random person how you add up a list of numbers. Most of them will say something about adding the first two together, adding the third to that total, and so forth. In other words, the step by step instructions. You word the (hypothetical) question with a bias toward imperative thinking. You're asking How do you do this action? Why isn't the question What is the sum of a list of numbers?, which is biased toward the declarative? Sure. But what is a computer program? It's a *list of instructions* that tells a computer *how to do something*. And yet, the Haskell definition of sum looks more like a definition of what a sum is rather than an actual, usable procedure for *computing* that sum. (Of course, we know that it /is/ in fact executable... it just doesn't look it at first sight.) Well, we are not writing computer programs directly, even in C, that's what compilers are for. That's why I find arguments about the sequential essence of computer programs to be weak. Whatever; I'm leaning more and more towards the concept that FP is only hard for people who already learned some other way... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] error on --++ bla bla bla
Hong Yang hyang...@gmail.com writes: But in my program, I did not define --++. And that's what the error tells you, no? Defining operators (or not) doesn't change the syntax. Since the lexeme --++ is syntactially a valid operator, it will be parsed as such, regardless of whether it is defined or not. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Splitting data and function declarations over multiple files
Peter Verswyvelen wrote: I guess this is related to the expression problem. Suppose I have a datatype *data Actor = Ball ... | Paddle ... | Wall ...* and a function *move (Ball ...) = * *move (Paddle ...) = * *move (Wall ...) = * in Haskell one must put *Actor* and *move* into a single file. Just a nitpick: you don't have to put Actor and move into the same module. module A where data Actor = Ball | Paddle | Wall module B where import A (Actor) move Ball = ... move Paddle = ... move Wall = ... But that's probably not what you meant. Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
Eugene Kirpichov wrote: 2009/10/1 Andrew Coppin andrewcop...@btinternet.com: Sure. But what is a computer program? It's a *list of instructions* that tells a computer *how to do something*. And yet, the Haskell definition of sum looks more like a definition of what a sum is rather than an actual, usable procedure for *computing* that sum. (Of course, we know that it /is/ in fact executable... it just doesn't look it at first sight.) Well, we are not writing computer programs directly, even in C, that's what compilers are for. That's why I find arguments about the sequential essence of computer programs to be weak. It might be a better argument to say that human thinking is fundamentally sequential; parallel computers have been around for a little while now... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
2009/10/1 Andrew Coppin andrewcop...@btinternet.com: Eugene Kirpichov wrote: 2009/10/1 Andrew Coppin andrewcop...@btinternet.com: Sure. But what is a computer program? It's a *list of instructions* that tells a computer *how to do something*. And yet, the Haskell definition of sum looks more like a definition of what a sum is rather than an actual, usable procedure for *computing* that sum. (Of course, we know that it /is/ in fact executable... it just doesn't look it at first sight.) Well, we are not writing computer programs directly, even in C, that's what compilers are for. That's why I find arguments about the sequential essence of computer programs to be weak. It might be a better argument to say that human thinking is fundamentally sequential; parallel computers have been around for a little while now... I don't buy this argument, either; human thinking is far too broad a concept to say that it is simply sequential. If it were sequential, it could barely express non-sequential concepts, and natural languages would have rather few of them, which we all know is false. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting data and function declarations over multiple files
I'm not sure if I understand what you mean with this co-algebraic approach,
but I guess you mean that functions - like move - don't work directly on any
datatype; you need to provide other functions that give access to the data.
But that's basically what type classes do no? And that's also related to my
earlier post of strong duck typing in Haskell.
At least also in C#, that's the way I usually write code that works on any
type, just make an interface or pass in a delegate. I also know that my OO
background keeps pushing me in the wrong direction when it comes to Haskell
;-)
The collision handling approach is always interesting :) In OO this is
usually solved using multi-methods or visitors:
http://en.wikipedia.org/wiki/Multiple_dispatch. What I usually did in old
games of mine to handle collisions is not look at the type, but at the
collision specific features of a type (which are again functions that
extract information from the object), and that is most likely again the
co-algebraic approach?
On Wed, Sep 30, 2009 at 9:15 PM, Luke Palmer lrpal...@gmail.com wrote:
On Wed, Sep 30, 2009 at 9:54 AM, Peter Verswyvelen bugf...@gmail.com
wrote:
I guess this is related to the expression problem.
Suppose I have a datatype
data Actor = Ball ... | Paddle ... | Wall ...
and a function
move (Ball ...) =
move (Paddle ...) =
move (Wall ...) =
in Haskell one must put Actor and move into a single file.
This is rather cumbersome if you work with multiple people or want to
keep
the files small and readable.
Surely it is possible to use type classes, existentials, etc to split the
data type into multiple ones, but that's already advanced stuff in a
sense.
You can do it without type classes and existentials. The
functionality you want is already supported by Haskell, you just have
to let go of your syntactical expectations. The trick is that you
should rewrite your data type not as an algebra (a set of
constructors), but as a coalgebra (a set of projections).
Let's say your two open functions are:
move :: Actor - Actor
isAlive :: Actor - Bool
This gives rise to the definition of an Actor type:
data Actor = Actor { move :: Actor, isAlive :: Bool }
And then the alternatives of your open data type are just values of type
Actor:
ball :: Vector - Vector - Actor
ball pos vel = Actor {
move = ball (pos + vel) vel,
isAlive = True
}
etc.
This trick works well until you get to the encoding of functions that
pattern match on multiple Actors at the same time. As far as I can
tell, that cannot be encoded in this style in any reasonable way.
Such functions must be rephrased in a coalgebraic style; i.e. instead
of asking about constructors, using projection functions it knows are
available.
So for example instead of implementing collide by asking about
pairs, add functions which report a shape function and a normal, or
whatever your collide algorithm needs from shapes.
You would probably end up having to do this anyway even with your
proposed extension, because watch:
partial data Actor = Ball ...
collide (Ball ...) (Ball ...) = ...
collide (Ball ...) x = ...
We don't know about any other constructors, so the second line has to
contain a pattern-free x. So you would have to use projection
functions to get any information about it, exactly as you would when
you're writing in the coalgebraic style.
So, Yes! Haskell can do that!
Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exceptions during exception unwinding
Exception handling code should generally be assumed to work, so if something goes wrong there you would normally like to know about it. Also, there is nothing preventing you from wrapping the rescue code in further exception handling, however, if the initial error were raised upon encountering a second error, you would not be able to choose to handle the second error. This is how I see it anyway. On Thu, Oct 1, 2009 at 11:29 AM, Brian Bloniarz phun...@hotmail.com wrote: I had a question about onException friends: what's the rationale for having: (error foo) `onException` (error bar) give bar and not foo? I.e. why does an exception raised during exception handling get propagated past the exception that triggered the handler? Most examples I can think for exception unwinding code would prefer the original exception be propagated -- for example, HDBC has a function which rolls back a DB transaction on exception; it implements it like so: withTransaction conn func = do r - onException (func conn) doRollback commit conn return r where doRollback = -- Discard any exception from (rollback conn) so original -- exception can be re-raised Control.Exception.catch (rollback conn) doRollbackHandler doRollbackHandler :: SomeException - IO () doRollbackHandler _ = return () IMHO, it'd be easier to just write: withTransaction conn func = do r - onException (func conn) (rollback conn) commit conn return r This same argument applies to bracket, bracket_, bracketOnError finally; even the common: bracket openSomeHandle closeSomeHandle doAction If some error arises during doAction, there's a chance closeSomeHandle might fail (even a good chance, given that exception unwinding paths are usually poorly tested), and probably doAction has more accurate information about what went wrong than closeSomeHandle. This is just a thought; I hadn't seen this discussed somewhere. I know for example that Java has the same approach as the current Control.Exception, so there must be good arguments for that too. One that I can think of: using onException to rethrow an exception as a different type, though that's what mapException is for, correct? Thanks, -Brian _ Microsoft brings you a new way to search the web. Try Bing™ now http://www.bing.com?form=MFEHPGpubl=WLHMTAGcrea=TEXT_MFEHPG_Core_tagline_try bing_1x1___ 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] Exceptions during exception unwinding
On Thu, 2009-10-01 at 03:29 +, Brian Bloniarz wrote: I had a question about onException friends: what's the rationale for having: (error foo) `onException` (error bar) give bar and not foo? I.e. why does an exception raised during exception handling get propagated past the exception that triggered the handler? Because it's the obvious and sensible thing to do and it what every other mainstream language with exceptions does. The behaviour you want, to automatically discard any exceptions raised in the handler and to always re-raise the original exception can be implemented using the current semantics, but the reverse is not true. Most examples I can think for exception unwinding code would prefer the original exception be propagated Then do not rethrow a different exception. This same argument applies to bracket, bracket_, bracketOnError finally; even the common: bracket openSomeHandle closeSomeHandle doAction If some error arises during doAction, there's a chance closeSomeHandle might fail (even a good chance, given that exception unwinding paths are usually poorly tested), and probably doAction has more accurate information about what went wrong than closeSomeHandle. Then catch and ignore the exception from closeSomeHandle (though not all exceptions or you'd block ^C etc). That said, how will you know that closeSomeHandle ever works if you always ignore any exceptions it raises? For example in the case of your database transaction, having the transaction fail and roll back is something your application may be set up to handle. But transation failing during the rollback may be much more catastrophic and may want to be treated differently. If it fails in the rollback it might be leaking resources and at the very least you may want to log it differently from just a transaction that was successfully rolled back. This is just a thought; I hadn't seen this discussed somewhere. I know for example that Java has the same approach as the current Control.Exception, so there must be good arguments for that too. One that I can think of: using onException to rethrow an exception as a different type, though that's what mapException is for, correct? mapException is for the case of exceptions raised by pure code. As you say, being able to rethrow a different kind of exception, or simply handle the exception there and then are useful. I think using onException is the best one for your use case. If you really really want to ignore an exception raised by rollback then you have the tools available to do so. As I mentioned earlier do not just catch and discard all exceptions, see: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html#4 Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Journals on Haskell and FP?
Hi. I was going to add a reference to the recently born Russian journal Practice of functional programming (http://fprog.ru/ ; had its 1st issue in July and 2nd was Sep.28) to haskellwiki into a section devoted specifically to journals, but it turned out there is no such section and, consequently, no information on journals: just books, tutorials and research papers. I think this is very valuable information and it's a shame that it's not listed on haskellwiki. So, I added such a subsection to http://haskell.org/haskellwiki/Books_and_tutorials#Journals and added a reference to Monad.Reader (the only other openly available journal on FP that I am aware of) , and I encourage the community to mention some more journals there. I also encourage the Russian readers who have not yet seen the aforementioned journal to give it a look :) -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cal, Clojure, Groovy, Haskell, OCaml, etc.
On Tue, Sep 29, 2009 at 9:36 PM, Andrew Coppin andrewcop...@btinternet.com wrote: Similarly, Parsec has some lovely external documentation (unfortunately as a single giant HTML page), but the Haddock stuff is bare. The last version (3.x) improves things. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
