Re: [Haskell-cafe] Candlestick charts

[Alexander McPhail]

Hi,

The rationale behind developing the plot package is a desire to target users
as well as programmers.

The plot interface provides monadic construction of figures, very similar in
style to the way a gnuplot script or matlab script/function would be
structured (especially with the Simple interface).  I am looking forward to
being able to use GHCi instead of matlab, and the plot-gtk companion package
provides a way to incrementally update a plot on screen.  I think that this
is where the design difference occurs.

Looking at the Chart interface, I was confronted with myriad data types and
functions.  Yes, the plots look nice, but, as I have been told, the Chart
interface can be overwhelming for a mathematics user cf. haskell
programmerr.

Also, the plot package uses Pango, so unicode should work out of the box
(for greek symbols and the like).

Cheers,

Vivian


On 1 October 2010 18:24, Ivan Lazar Miljenovic wrote:

> On 1 October 2010 15:12, Vivian McPhail
>  wrote:
> > Hi
> >
> >>Message-ID:  vvbg...@mail.gmail.com>
> >>
> >>Hi -
> >>
> >>What are the libraries to use in Haskell to generate a stock
> >>candlestick chart like
> >>http://stockcharts.com/h-sc/ui?s=SPY&p=D&b=5&g=5&id=p05007254056
> >>
> >>I will use Finance-Quote-Yahoo to get the quote data from Yahoo.
> >>
> >>thanks for all your help.
> > The plot 0.1.1 package supports candle and whisker charts.
> >
> > http://hackage.haskell.org/plot
>
> That URL should of course be http://hackage.haskell.org/package/plot
>
> However, I'm curious: what is the rationale behind you developing plot
> rather than you helping Tim extend Chart?
>
>
> --
> Ivan Lazar Miljenovic
> ivan.miljeno...@gmail.com
> IvanMiljenovic.wordpress.com
>



-- 
---
yolar et elver.
---

DISCLAIMER

This transmission contains information that may be confidential. It is
intended for the named addressee only. Unless you are the named addressee
you may not copy or use it or disclose it to anyone else.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Candlestick charts

[Ivan Lazar Miljenovic]

On 1 October 2010 15:12, Vivian McPhail
 wrote:
> Hi
>
>>Message-ID: 
>>
>>Hi -
>>
>>What are the libraries to use in Haskell to generate a stock
>>candlestick chart like
>>http://stockcharts.com/h-sc/ui?s=SPY&p=D&b=5&g=5&id=p05007254056
>>
>>I will use Finance-Quote-Yahoo to get the quote data from Yahoo.
>>
>>thanks for all your help.
> The plot 0.1.1 package supports candle and whisker charts.
>
> http://hackage.haskell.org/plot

That URL should of course be http://hackage.haskell.org/package/plot

However, I'm curious: what is the rationale behind you developing plot
rather than you helping Tim extend Chart?


-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Candlestick charts

[Vivian McPhail]

 Hi

>Message-ID: 
>
>Hi -
>
>What are the libraries to use in Haskell to generate a stock
>candlestick chart like
>http://stockcharts.com/h-sc/ui?s=SPY&p=D&b=5&g=5&id=p05007254056
>
>I will use Finance-Quote-Yahoo to get the quote data from Yahoo.
>
>thanks for all your help.

The plot 0.1.1 package supports candle and whisker charts.

http://hackage.haskell.org/plot

Vivian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ANN: contstuff: CPS-based monad transformers

[Ertugrul Soeylemez]

Felipe Lessa  wrote:

> Very interesting!  And the API seems very nice, although I haven't
> used the package.
>
> Are there benchmarks for monad transformers?  How big is the
> difference between CPS and non-CPS monad libraries?

I have run some small and probably not that meaningful benchmarks.  For
StateT it doesn't seem to make a lot of difference.  ChoiceT appears to
be considerably faster than [] in all tests I've made.

As a small benchmark consider the following factoring functions, which
return a (very redundant) list of factors of the argument:

  testComp1 :: Integral a => a -> [a]
  testComp1 n = do
x <- [1..n]
y <- [x+1..n]
guard $ n - x /= y
guard $ mod (x^2 - y^2) n == 0
return $ gcd n (x-y)

  testComp2 :: Integral a => a -> ChoiceT r i m a
  testComp2 n = do
x <- choice [1..n]
y <- choice [x+1..n]
guard $ n - x /= y
guard $ mod (x^2 - y^2) n == 0
return $ gcd n (x-y)

On my machine testComp1 takes 5.6 seconds to finish, and testComp2 takes
3.9 seconds.  The programs I've used to test are:

  main1, main2 :: IO ()

  main1 = do
hSetBuffering stdout (BlockBuffering Nothing)
getArgs >>= mapM_ (print . testComp1 . read)

  main2 = do
hSetBuffering stdout (BlockBuffering Nothing)
getArgs >>= mapM_ (print . listChoice . testComp2 . read)

To take this further I modified the benchmark to print only the first
result found.  To return a factor of 1237*65537 testComp1 needs 10.2
seconds, while testComp2 needs only 5.1 seconds.  Here is the modified
code (testComp1 and testComp2 remain unchanged):

  main1, main2 :: IO ()

  main1 = getArgs >>= mapM_ (print . head . testComp1 . read)
  main2 = getArgs >>= mapM_ (print . maybeChoice . testComp2 . read)

At least ChoiceT is faster than using regular lists, and it's also a
CPS-based monad transformer, so you get all the goodies of CPS and
combining monads:

  testComp3 :: (Integral a, Monad m, LiftBase m, Base m ~ IO) =>
   a -> ChoiceT r i m a
  testComp3 n = do
x <- choice [1..n]
y <- choice [x+1..n]
guard $ n - x /= y
guard $ mod (x^2 - y^2) n == 0
let factor = gcd n (x-y)
io $ printf "Factor found: %i\n" (toInteger factor)
return factor

Note that instead of 'listA' I'm using the 'choice' function, which is
slightly faster, but even with 'listA' ChoiceT outperforms regular
lists.


Greets,
Ertugrul


-- 
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANNOUNCE: atomo 0.1, a simple, adventurous programming language

[Alex Suraci]

Over the past few months I've been designing and implementing a new language
called Atomo. The idea is to build up a very expressive language from as few
parts as possible, akin to Io or Scheme. But first, the fundamentals:
prototype-based object-orientation with multiple dispatch and pattern-matching.

Still here?

Great!

Being object-oriented and dynamic, I expect a few boos and hisses, but if you
want to dive in, it's a lot of fun. :) An immense amount of progress has been
made in a short amount of time.

It already sports a powerful documentation system (similar to Racket's
Scribble), and a package manager is in the works (it's functional, but it's
local-only). For a while I had atomo-lang.org serving up a site powered by
Atomo itself, with Snap underneath via Atomo's Haskell interface. It's down at
the moment (it was wrestling with darcsden over my VPS's resources), but the
docs are always available:

Documentation: http://atomo-lang.org/docs/ (work-in-progress)

Repository: http://darcsden.com/alex/atomo

Examples: http://darcsden.com/alex/atomo/browse/examples

I recommend the generators example if you want some mind-bending, or html.atomo
for a nice EDSL, or web.(atomo|hs) for an example of Haskell interop.

On Hackage: http://hackage.haskell.org/package/atomo

Installation: `cabal install atomo` should "just work", though I haven't worked
out the appropriate version numbers for all of its dependencies yet. Hackage
shows a build failure, but that seems to be caused by Haddock; I still haven't
figured that out.

If you want to get involved, you can find me on freenode in #atomo (and
#haskell); my nick is alexsuraci. Or, you can fork the repository on darcsden.
I'd just like to put this out there to see if anyone else is interested in
playing with this.

--
Alex
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] I still cannot seem to get a GUI working under Windows.

[Richard O'Keefe]

On 30/09/2010, at 7:08 AM, Christopher Done wrote:

> On 29 September 2010 17:01,   wrote:
>> I still cannot seem to get a GUI working under Windows.
>> 
>> For Haskell GUI's is Ubuntu easier to setup.
>> 
>> If so, we're losing people if Haskell GUI's are so hard to get working under
>> Windows.
> 
> We're losing people! Charge!
> 
> I think the problem is lack of Windows developers interested in GUIs,
> and that Windows is not so POSIXy-development-friendly as Linux or OS
> X. But mostly lack of people interested in that area, I think.

I think we should put this in perspective.
I teach a full-year 300-level software engineering paper.
This year the students were required to design a project of their
own and start to build it in Windows using C or C++.
Then we switched them to Linux -- it's an education, not a picnic!
For the final deliverable, they had to provide something I could
run on one of the department's Macs running Linux.

Welcome to DLL Hell.

Of course I made a good faith attempt to try to install the libraries
that they provided (if they did) but without superuser access there
are limits; I also made a good faith attempt to download and build
libraries they did not provide, but my patience has its limits and I
wasn't prepared to spend more than an hour per assignment doing this.
And of course there's the 64-bit -vs- 32-bit thing, where 32-bit
programs are *supposed* to run on 64-bit Linux, but some of the 32-bit
libraries required to make this actually work are missing...

Unless you are willing to work at the level of Xt or possibly Lesstif,
portability of GUI software on Linux in C or C++ does not come
automatically; you have to work at it.

Don't get me started on "everyone has the same kind of screen I do..."


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] CCC MyType

[Brent Yorgey]

On Wed, Sep 22, 2010 at 04:57:42PM +0200, Lafras Uys wrote:
> 
> > data MyType a b = MyType {f::(a -> b)}
> > data SomeType a b = SomeType {g::(a,b)}
> 
> > instance (Symmetric MyType (Product MyType),
> >   Monoidal MyType (Product MyType),
> >   PreCartesian MyType) => CCC MyType where
> 
> >   type Exp MyType = SomeType

This doesn't seem right to me.  I would expect

  type Exp MyType = MyType

and 

  type Product MyType = SomeType

since the exponential objects corresponding to functions are
precisely function types.

-Brent
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Coding conventions for Haskell?

[Evan Laforge]

Sorry, forgot to reply to all

> You also sometimes refactor part of a module to another module, and
> then you need to copy over all the necessary imports. I tend to copy
> all my imports over and then remove the ones GHCi tells me aren't
> necessary. So, one solution to make this automatic copy over all the
> imports from the current module and then prune.
>
> Perhaps I will attempt some of this on the weekend, as it's the
> biggest pain I have right now writing Haskell code. I spend a lot of
> time just maintaining my imports.

Same here, though I use exclusively qualified imports so it's not such
a hassle.  But it
adds busywork when you start a new module or want to split some code
into a new one.

The one feature I really like in eclipse is a key you hit to clean up
the imports.  It removes the unused ones, and tries to find imports
for symbols that aren't in scope.  If there are multiple
possibilities, it asks which one.  It even does this automatically
when you copy and paste code between files.  I would love something
like this for haskell.

It's easier in my case because I use exclusively qualified imports and
almost always name them as the last component after the dot, so if you
parse the source file and find 'M.a' and there's no 'import qualified
.. as M' then you just search for 'M' modules.  If I were writing this
(and I may take a shot some day), I'd write a standalone program that
filters a file, that way it works no matter what editor you use.  And
why write it in elisp when you could write it in haskell, and have
access to haskell-src?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Coding conventions for Haskell?

[Christopher Done]

On 30 September 2010 21:02, Bas van Dijk  wrote:
> Note that, although I don't use it myself, the GHC flag:
> -ddump-minimal-imports can help you with this style:
>
> http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/separate-compilation.html#hi-options

Indeed, after discovering this I thought about writing a little Emacs
Lisp to have a keybinding for updating my imports using
-ddump-minimal-imports, so that I can write without explicit import
but then make it explicit when I'm done automatically. I forgot about
it so thanks for reminding me.

Ideally I would also write some functions that make automatic import
of a symbol easier. There are 4 problems with writing Haskell and
managing imports, as I see it, right now (I'll make up some names to
encapsulate these ideas):

1. Pretty printing: The order and spacing of imports.
2. Explicitness: The explicit naming of imported symbols, or qualification.
3. Discovery: Calculating where the symbol I'm using right now should
be imported from, and then adding that import either automatically or
with-confirmation.
4. Pruning: Removing unnecessary imports, and merging imports which
are the same.

I made some functions to make it easier to jump back and forth to
imports, but now I don't really want to manually write out an import
statement again. I'd prefer to have Emacs present me with options,
i.e., these are the modules that export that type/symbol/class, pick
one (with ido/fuzzy completion) and then it adds the import line at
the correct place with the desired spacing and with the necessary
import.

You also sometimes refactor part of a module to another module, and
then you need to copy over all the necessary imports. I tend to copy
all my imports over and then remove the ones GHCi tells me aren't
necessary. So, one solution to make this automatic copy over all the
imports from the current module and then prune.

Perhaps I will attempt some of this on the weekend, as it's the
biggest pain I have right now writing Haskell code. I spend a lot of
time just maintaining my imports.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Monad instance for partially applied type constructor?

[Ryan Ingram]

On Wed, Sep 29, 2010 at 9:13 PM, Alexander Solla  wrote:
>  On 09/29/2010 02:15 PM, DavidA wrote:
>>>
>>> instance Monad (\v ->  Vect k (Monomial v))
>>> >
>>
>> Yes, that is exactly what I am trying to say. And since I'm not allowed to
>> say
>> it like that, I was trying to say it using a type synonym parameterised
>> over v
>> instead.
>
> Why not:
>
> instance Monad ((->) Vect k (Monomial v))

No, what he's trying to say is

> instance Monad (Vect k . Monomial)

with some type-level composition for .

which would give these signatures:

> return :: forall a. a -> Vect k (Monomial a)
> (>>=) :: forall a b. Vect k (Monomial a) -> (a -> Vect k (Monomial b)) -> 
> Vect k (Monomial b)

Notice that the "forall" variables are inside parentheses in the type;
this is what Haskell doesn't allow.

Of course you can

> newtype VectMonomial k a = VM { unVM :: Vect k (Monomial a) }
> instance Monad (VectMonomial k) where ...

But now you need to wrap/unwrap using VM/unVM.

  -- ryan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Coding conventions for Haskell?

[Bas van Dijk]

On Thu, Sep 30, 2010 at 11:24 PM, Bas van Dijk  wrote:
> For what it's worth: '::' shows up correctly in my terminals (Konsole
> or urxvt with Bitstream Vera Sans Mono font).

Turns out that I'm actually using the 'DejaVu Sans Mono' font...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Coding conventions for Haskell?

[Roel van Dijk]

Here is a list of fonts that support that particular character:
http://www.fileformat.info/info/unicode/char/2237/fontsupport.htm

I think I'll add a little font overview to my unicode-symbols wiki
page. Most Unicode symbols that are useful in Haskell are not terribly
obscure and supported by a wide range of fonts.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Coding conventions for Haskell?

[Bas van Dijk]

On Thu, Sep 30, 2010 at 10:51 PM, Henning Thielemann
 wrote:
>
> On Thu, 30 Sep 2010, Bas van Dijk wrote:
>
>> I believe UnicodeSyntax and symbols make code easier to read.
>
> If it can be read at all ... your Unicode symbol for '::' isn't shown in my
> terminal.
>

Ah what a bummer! I thought most terminals where capable of showing a
wide range of Unicode these days.

For what it's worth: '::' shows up correctly in my terminals (Konsole
or urxvt with Bitstream Vera Sans Mono font).

Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Coding conventions for Haskell?

[Donn Cave]

Quoth Henning Thielemann ,

> On Thu, 30 Sep 2010, Bas van Dijk wrote:
>
>> I believe UnicodeSyntax and symbols make code easier to read.
>
> If it can be read at all ... your Unicode symbol for '::' isn't shown in 
> my terminal.

Same here, of course.  Win small, lose big.

Donn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Coding conventions for Haskell?

[Henning Thielemann]

On Thu, 30 Sep 2010, Bas van Dijk wrote:


I believe UnicodeSyntax and symbols make code easier to read.


If it can be read at all ... your Unicode symbol for '::' isn't shown in 
my terminal.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Coding conventions for Haskell?

[Bas van Dijk]

Here are a few other styles I use:


* Unicode syntax and symbols

I use the UnicodeSyntax extension in all my projects. It allows you to
write nice Unicode syntax instead of the normal ASCII art. For
example: '→' instead of '->' and '∀' instead of 'forall'.

Additionally I'm a power-user of my brother's base-unicode-symbols
package[1]. I'm especially fond of the '∘' function composition
operator which you can use instead of '.'.

I believe UnicodeSyntax and symbols make code easier to read.
Although, it makes it slightly harder to write (see [2] for nice input
methods however).


* Use lambdas to group function arguments.

When I have a function which returns another function with a type that
is explicitly named, instead of listing all the arguments before the
=, I usually use a lambda to indicate that the function returns
another function. Take [3] for example:

readControl ∷ DeviceHandle → ControlAction ReadAction
readControl devHndl = \reqType reqRecipient request value index
→ \size timeout
→ ...

writeControl ∷ DeviceHandle → ControlAction WriteAction
writeControl devHndl = \reqType reqRecipient request value index
 → \input timeout
 → ...

where

type ControlAction α = RequestType
 → Recipient
 → Request
 → Value
 → Index
 → α

type ReadAction = Size → Timeout → IO (B.ByteString, TimedOut)
type WriteAction = B.ByteString → Timeout → IO (Size, TimedOut)

(I'm not sure if this has a negative effect on inlining tough.)

Regards,

Bas

[1] http://hackage.haskell.org/package/base-unicode-symbols
[2] http://haskell.org/haskellwiki/Unicode-symbols#Input_methods
[3] 
http://hackage.haskell.org/packages/archive/usb/0.6.0.1/doc/html/src/System-USB-Internal.html#readControl
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Spell-checking lhs files

[Petr Pudlak]

Hi,

recently I was spell-checking a literate Haskell source file (within the 
vim editor). The spell checker correctly ignored LaTeX commands, but I 
had to manually skip over code blocks inside |...|. This was really 
annoying and I couldn't figure out how to configure the spell checker to 
skip over code. Does anybody have a solution for that?


Thanks a lot,
Petr


signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Coding conventions for Haskell?

[Henning Thielemann]

On Thu, 30 Sep 2010, Bas van Dijk wrote:


On Thu, Sep 30, 2010 at 5:15 PM, Christopher Done
 wrote:

... One thing that makes figuring out a code base hard is when the
code doesn't have explicit imports. Sometimes I can load the code in
GHCi and inspect the symbols manually, sometimes I can't. If the
import list explicitly said where stuff came from I wouldn't have to
deal with this.


Indeed. I strictly use this style in all my projects. See the
following for example:

http://hackage.haskell.org/packages/archive/usb/0.6.0.1/doc/html/src/System-USB-Internal.html

I see it as a service to my readers. In order to find out where a
symbol is coming from they only need to scroll up and look it up in
the import list. Note that for further convenience I group the imports
by package so they don't need to figure out which package exports what
module.


It is also necessary when you want x.y.* style version dependencies on 
packages that follow the package versioning policy.


http://www.haskell.org/haskellwiki/Import_modules_properly
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Coding conventions for Haskell?

[Bas van Dijk]

On Thu, Sep 30, 2010 at 5:15 PM, Christopher Done
 wrote:
> ... One thing that makes figuring out a code base hard is when the
> code doesn't have explicit imports. Sometimes I can load the code in
> GHCi and inspect the symbols manually, sometimes I can't. If the
> import list explicitly said where stuff came from I wouldn't have to
> deal with this.

Indeed. I strictly use this style in all my projects. See the
following for example:

http://hackage.haskell.org/packages/archive/usb/0.6.0.1/doc/html/src/System-USB-Internal.html

I see it as a service to my readers. In order to find out where a
symbol is coming from they only need to scroll up and look it up in
the import list. Note that for further convenience I group the imports
by package so they don't need to figure out which package exports what
module.

I try to follow this style very strictly. I'm even using
NoImplicitPrelude to not miss any implicitly imported symbol. I also
import symbols from their defining module instead as from the Prelude.
For example, instead of importing fmap from the Prelude I import it
from Data.Functor. This ensures that when a reader looks up a symbol
she doesn't need to skim through a lot of unrelated code.

To be honest, there are cases where I violate my own rule. In the USB
module for example, I import Bindings.Libusb without explicitly
listing the used symbols. In this case I think it's justified because
I pretty much use all the symbols from that module and all symbols are
prefixed with 'c'libusb_' which clearly indicates where they are
coming from.

Note that, although I don't use it myself, the GHC flag:
-ddump-minimal-imports can help you with this style:

http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/separate-compilation.html#hi-options

Regards,

Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Inverse of HaskellDB

[Jeremy Shaw]

On Wed, Sep 29, 2010 at 5:21 AM, Michael Snoyman  wrote:
> I think this approach is not possible without involving some fairly
> ugly unsafeInterleaveIO/unsafePerformIO calls. A simple example using
> a common web programming example: support I have a multi-user blog
> site, where each user can have multiple entries. I would model this
> using standard Haskell datatypes as:
>
> data Entry = Entry { title :: String, content :: String }
> data Blogger = Blogger { name :: String, entries :: [Entry] }
>
> Obviously we'll need some kind of blogger loading function:
>
> getBloggerByName :: String -> IO Blogger

That is pretty close to how it would look using happstack-state. Here
is a complete, runnable example which defines the types, a query,
creates/initializes the database, performs the query, and prints the
results.

> {-# LANGUAGE DeriveDataTypeable, FlexibleContexts, MultiParamTypeClasses, 
> TemplateHaskell, TypeSynonymInstances, TypeFamilies #-}
> module Main where
>
> import Control.Exception (bracket)
> import Control.Monad.Reader (ask)
> import Data.Data
> import Happstack.Data
> import Happstack.Data.IxSet
> import Happstack.State

A simple type to identify a particular blogger:

> newtype Blogger = Blogger { name :: String }
> deriving (Eq, Ord, Read, Show, Data, Typeable)
> $(deriveSerialize ''Blogger)
> instance Version Blogger

The deriveSerialize instance automatically creates the instances for
serializing and deserializing to/from a binary representation for
storage, transmission, etc.

The Version instance is used for migration when the data type changes.
(Since there is no previous version of this type to migrate from, we
don't have to specify anything).

We create a similar type for the title of the blog post:

> newtype Title = Title { unTitle :: String }
> deriving (Eq, Ord, Read, Show, Data, Typeable)
> $(deriveSerialize ''Title)
> instance Version Title

And a simple record which actually contains a blog post:

> data Entry =
> Entry { title   :: Title
>   , blogger :: Blogger
>   , content :: String
>   }
> deriving (Eq, Ord, Read, Show, Data, Typeable)
> $(deriveSerialize ''Entry)
> instance Version Entry

Obviously, it could be expanded to support tags, posted date, whether
or not in is published, etc. Next we create an IxSet which holds all
the Entries that have been posted:

> $(inferIxSet "Entries" ''Entry 'noCalcs [''Blogger, ''Title])

An IxSet is a bit like a normal Set, except it has indexes, which you
can use for performing queries. In this case, we use Blogger and Title
as indexes.

Next we define a component that actually stores the Entries:

> instance Component Entries where
> type Dependencies Entries = End
> initialValue = fromList [ Entry { title   = Title "10 Reasons you should 
> use Happstack."
> , blogger = Blogger "stepcut"
> , content = "..."
> }
> , Entry { title   = Title "Persistence made easy!"
> , blogger = Blogger "Jeremy Shaw"
> , content = "..."
> }
> ]

This component is prepopulated with 2 entries. Now we want to define a
query which retrieves all the entries by a particular Blogger:

> getEntriesByBlogger :: Blogger -> Query Entries Entries
> getEntriesByBlogger blogger =
> do e <- ask
>return (e @= blogger)

The Query monad is essentially a specialized version of the Reader
monad. So we use 'ask' to get the Entries from the Entries
component. (@=) is an IxSet function which selects all the Entries with
the specified blogger.

Next we 'register' all the functions we want to use as queries for the
Entries Component:

> $(mkMethods ''Entries ['getEntriesByBlogger])

And finally, here is a main function which initializes the transaction
system, performs a query, prints the results, and shuts the
transaction system down:

> main :: IO ()
> main =
> bracket (startSystemState (Proxy :: Proxy Entries)) shutdownSystem $ \_ ->
> do postsByStepcut <- query (GetEntriesByBlogger (Blogger "stepcut"))
>print postsByStepcut

Note that there is no outside or additional configuration which needs
to be done. If you have the happstack-state libraries installed on
your system, then you can simply run this program. You do not need to
configure or initialize any external database system.

The queries and updates are thread-safe, ACID-transactions. You can
use almost any Haskell datatype declared using the normal Haskell
syntax. Basically, if you could write a pair of Read/Show instances
for the type, then you can probably use it directly with
happstack-state. So that means the type can not have functions,
existentials, and a few other things. But Trees, etc, are no problem.

The queries and updates are just straight-forward 

[Haskell-cafe] Fourth Ghent Functional Programming Group Meeting on Thursday, Oct 7th: Program, Final Details and BelHac Commercial

[Jeroen Janssen]

(apologies if you receive multiple copies)

Dear All,

We are pleased to announce that the fourth Ghent Functional Programming Group 
(GhentFPG) meeting will take place on Thursday, October 7th, at 19h in the 
Technicum building of Ghent University (Sint-Pietersnieuwstraat 41, 9000 Gent). 
As before, you should enter through the electronic sliding doors on the left. 
The doors will be locked, but there will be a sign with a number that you can 
call to get in.

The final program for our fourth meeting is as follows:

1. Stijn Timbermont - Mapping Interpreters onto Runtime Support

When constructing an interpreter, it is hard to achieve a concise and abstract 
definition of the language semantics and at the same time have sufficient 
control over how the underlying runtime support is implemented. We illustrate 
with a number of examples that gaining more control over runtime support 
implementation forces us to adopt a more machine-like interpreter structure. 
This is problematic for reuse and evolution of interpreters. We present a 
solution to this problem that automates this restructuring of interpreters. The 
solution is based on three cornerstones: the theory of defunctionalized 
interpreters, effect-driven transformations and generic programming. It allows 
us to start from a concise and abstract definition of the language features and 
automatically transform it into a more machine-like form that allows for a 
customized runtime support implementation to be integrated.

2. Tom Schrijvers - Dictionaries: Eager or Lazy Type Class Witnesses?

Type classes are Haskell’s acclaimed solution to ad-hoc overloading.
This talk gives an introductory overview of type classes and their
runtime witnesses, dictionaries.
It asks the questions whether dictionaries should abide by Haskell’s
default lazy evaluation strategy.

   Conceptually, a type class is a type-level predicate: a type is an
   instance of a type class iff it provides an implementation for
   overloaded functions. For instance, `Eq a’ declares that type `a’
   implements a function `(==) :: a → a → Bool’ for checking equality.

   Type classes are used as constraints on type variables, in so-called
   constrained polymorphic functions. E.g. `sort :: Ord a => [a] → [a]’
   sorts a list with any type of elements `a’ that are an instance of the
   Ord type class, i.e. provide implementations for comparison.

Witnesses for type class constraints are necessary to select the
appropriate implementation
for the overloaded functions at runtime. For instance, if `sort’ is
called with Int elements,
the Int comparison must be used, versus say Float comparison for Float elements.

Two forms of witnesses have been considered in the literature, runtime
type representations
and so-called dictionaries, of which the latter are the most most
commonly implementation,
e.g., in GHC . Haskell implementations treat dictionaries just like
all other data, as lazy values
that may potentially consists of non-terminating computations. This
way part of the type checker’s
work, who has made sure that the dictionaries do exist, is simply forgotten.
Is this really necessary?

3. Dominique Devriese - Grammar Combinators - A new model for shallow parser 
DSL's

Parser combinator libraries are a well-known alternative to parser
generators in the functional programming community. However, their
power is currently fundamentally limited by their representation of
recursion in context-free grammars. We present the grammar-combinators
Haskell library which removes these limitations, and brings some other
advantages (semantic value family polymorphism, natural concepts). In
this talk, I will briefly explain the motivation for the library, and
then present our approach and some of its most important aspects in a
live demonstration and finish with a discussion.

Last, note that GhentFPG is organizing the first Belgian Haskell Hackathon, 
called BelHac, on 5-7 November 2010. The fifth GhentFPG meeting will take place 
at BelHac and will focus on talks concerning the use of functional programming 
in industry.
More info will be provided soon.

As usual, if you want get all the latest info on GhentFPG, you can subscribe to 
our google group (http://groups.google.com/group/ghent-fpg) or follow us on 
twitter (@ghentfpg).

Hope to see you at both of these events!

The GhentFPG Organizing 
committee.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: A parsec question

[Ben Franksen]

Christian Maeder wrote:
> Am 29.09.2010 20:01, schrieb Daniel Fischer:
>> On Wednesday 29 September 2010 19:10:22, Ben Franksen wrote:

 Note the last line mentions only '}'. I would rather like to see

   expecting "}" or digit

 since the parser could very well accept another digit here.
>> 
>> parsec2 did that, I don't know whether that change is intentional or
>> accidental.
> 
> Right, parsec2 or parsec-2.1.0.1 still does so. (parsec-3 behaves
> differently wrt error messages.)
> 
> Try "ghc-pkg hide parsec" so that parsec-2.1.0.1 will be taken:

I need parsec-3 since I use it as a monad transformer over IO so I can do IO
during parsing. And I want efficiency, too, so did not consider
parsec-3.0.*.

Cheers
Ben

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] EDSL for Makefile

[Neil Mitchell]

>> What great timing! I will be giving a talk at the Haskell Implementors
>> Workshop tomorrow about the Make system Shake. It will be video taped
>> and I can send you the slides after I've given the talk. So wait a
>> day, and I'll give you all the answers.
>
> Will you publish the tool too? ;-)

No :-( [or at least not yet]

Wait for the talk, and I'll explain more.

Thanks, Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Inverse of HaskellDB

[Michael Snoyman]

On Thu, Sep 30, 2010 at 4:35 PM, Felipe Lessa  wrote:
> On Wed, Sep 29, 2010 at 7:21 AM, Michael Snoyman  wrote:
>> I think this approach is not possible without involving some fairly
>> ugly unsafeInterleaveIO/unsafePerformIO calls. A simple example using
>> a common web programming example: support I have a multi-user blog
>> site, where each user can have multiple entries. I would model this
>> using standard Haskell datatypes as:
>>
>> data Entry = Entry { title :: String, content :: String }
>> data Blogger = Blogger { name :: String, entries :: [Entry] }
>>
>> Obviously we'll need some kind of blogger loading function:
>>
>> getBloggerByName :: String -> IO Blogger
>>
>> Either this will load up all entries (a potentially incredibly costly
>> operation) or use unsafe IO down the road. Especially when using
>> database connections, this can be incredibly bad: the connection could
>> be closed, the SQL statement could be reused by another request, etc.
>
> It may be possible to tag those data fields that are not to be
> loaded on the spot.  For example,
>
>> data Entry = Entry { title :: String, content :: String }
>> data Blogger db = Blogger { name :: String, entries :: OnDB db [Entry] }
>>
>> class Monad db => Database db where
>>   data OnDB db :: * -> *
>>   fetch :: OnDB db a -> db a
>>   fetchSome :: Criteria a -> OnDB db [a] -> db [a]
>>
>> newtype InMemory a = InMemory a
>> instance Database InMemory where
>>   newtype OnDB db a = OnDBMem a
>>   fetch (OnDBMem x) = return x
>>   fetchSome = ...
>>
>> instance Database SQL where
>>   ...

I wasn't claiming my approach was the *only* approach, just stating
that it doesn't seem feasible to use the "simple" Haskell data type
declarations.

Michael
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Inverse of HaskellDB

[Christopher Done]

While we're on the topic of databases, I really wanted to try out
query/inserting from/to my database with records like this:
http://hpaste.org/40240/db_library_approach

Define a record:

data Person f =
  Person { pid:: f Integer
 , firstName  :: f String
 , middleName :: f (Maybe String)
 , lastName   :: f String
 , age:: f Integer
 }

then I'd query it like

personById :: Integer -> Query Person
personById i =
  Person { pid= constant i
 , firstName  = anything
 , middleName = anything
 , lastName   = anything
 , age= anything
 }  deriving (Typeable,Data)

Or with a Data.Default instance:

personById :: Integer -> Query Person
personById i = def { pid = constant i }

But I have yet to figure out how to derive a Typeable instance for
such a type. I don't want to write any instances of anything.
Technically I can get the field names and values using a
Data.Data.Data instance, but I don't know, maybe I should make a
TypeablePolymorphicKinds class or something and try to derive for it.
UHC's generic deriving would probably be good for something like this,
but I want GHC.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Coding conventions for Haskell?

[Christopher Done]

On 30 September 2010 16:47, Roel van Dijk  wrote:
> On the subject of coding style, I can work with almost any style as
> long as it is used somewhat consistently. Personally I try to optimize
> my code for ease of reading because I spend much more time reading
> code than writing. Aligning stuff vertically makes it easier to spot
> differences.

Me too. One thing that makes figuring out a code base hard is when the
code doesn't have explicit imports. Sometimes I can load the code in
GHCi and inspect the symbols manually, sometimes I can't. If the
import list explicitly said where stuff came from I wouldn't have to
deal with this.

Regarding style I've come to believe the best style is one that can be
enforced by your software, whatever it is. I don't want to have to
think about style.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Coding conventions for Haskell?

[Roel van Dijk]

I align my imports by hand, but your Emacs scripts look useful. I
think I'm going to use them too.

Another extremely useful function for aligning is align-regexp.

On the subject of coding style, I can work with almost any style as
long as it is used somewhat consistently. Personally I try to optimize
my code for ease of reading because I spend much more time reading
code than writing. Aligning stuff vertically makes it easier to spot
differences.

On Thu, Sep 30, 2010 at 4:02 PM, Christopher Done
 wrote:
> FWIW, I align all my module imports up, as seen here:
> http://github.com/chrisdone/amelie/raw/master/src/Web/Codepad.hs  and
> here http://github.com/chrisdone/amelie/raw/master/src/Amelie/HTML.hs
> etc.
>
> I use the following Emacs library to do it for me:
> http://github.com/chrisdone/haskell-mode-exts/raw/master//haskell-align-imports.el
>
> I also sort them with this:
> http://github.com/chrisdone/haskell-mode-exts/blob/master//haskell-sort-imports.el
> but it only works for one-line imports, which I advocate anyway.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Inverse of HaskellDB

[Felipe Lessa]

On Wed, Sep 29, 2010 at 7:21 AM, Michael Snoyman  wrote:
> I think this approach is not possible without involving some fairly
> ugly unsafeInterleaveIO/unsafePerformIO calls. A simple example using
> a common web programming example: support I have a multi-user blog
> site, where each user can have multiple entries. I would model this
> using standard Haskell datatypes as:
>
> data Entry = Entry { title :: String, content :: String }
> data Blogger = Blogger { name :: String, entries :: [Entry] }
>
> Obviously we'll need some kind of blogger loading function:
>
> getBloggerByName :: String -> IO Blogger
>
> Either this will load up all entries (a potentially incredibly costly
> operation) or use unsafe IO down the road. Especially when using
> database connections, this can be incredibly bad: the connection could
> be closed, the SQL statement could be reused by another request, etc.

It may be possible to tag those data fields that are not to be
loaded on the spot.  For example,

> data Entry = Entry { title :: String, content :: String }
> data Blogger db = Blogger { name :: String, entries :: OnDB db [Entry] }
>
> class Monad db => Database db where
>   data OnDB db :: * -> *
>   fetch :: OnDB db a -> db a
>   fetchSome :: Criteria a -> OnDB db [a] -> db [a]
>
> newtype InMemory a = InMemory a
> instance Database InMemory where
>   newtype OnDB db a = OnDBMem a
>   fetch (OnDBMem x) = return x
>   fetchSome = ...
>
> instance Database SQL where
>   ...

Cheers,

--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Coding conventions for Haskell?

[Christopher Done]

FWIW, I align all my module imports up, as seen here:
http://github.com/chrisdone/amelie/raw/master/src/Web/Codepad.hs  and
here http://github.com/chrisdone/amelie/raw/master/src/Amelie/HTML.hs
etc.

I use the following Emacs library to do it for me:
http://github.com/chrisdone/haskell-mode-exts/raw/master//haskell-align-imports.el

I also sort them with this:
http://github.com/chrisdone/haskell-mode-exts/blob/master//haskell-sort-imports.el
but it only works for one-line imports, which I advocate anyway.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Coding conventions for Haskell?

[Henning Thielemann]

Andrew Coppin schrieb:
>  On 29/09/2010 02:18 PM, Henning Thielemann wrote:
>>
>> The truth is: Given the separator style of constructor definition,
>> there is no correct way to format those declarations. :-) The correct
>> way would be to allow terminator style.
> 
> Well, yes, there is that. (And this isn't the only place in the syntax
> where it applies either. Tried editing export lists lately? Or Cabal
> module lists?)

In export and import lists you can use commas as terminators, however in
constructor lists you cannot.

module A (a, b, c, T(A,B,C), ) where

import X (x, Y(M,N,O), z, )


In Cabal you can write one module per line and need no separator or
terminator at all.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: contstuff: CPS-based monad transformers

[Felipe Lessa]

Very interesting!  And the API seems very nice, although I haven't
used the package.

Are there benchmarks for monad transformers?  How big is the
difference between CPS and non-CPS monad libraries?

Cheers!

-- 
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] EDSL for Makefile

[Magnus Therning]

On Thu, Sep 30, 2010 at 13:05, Neil Mitchell  wrote:
> Hi,
>
> What great timing! I will be giving a talk at the Haskell Implementors
> Workshop tomorrow about the Make system Shake. It will be video taped
> and I can send you the slides after I've given the talk. So wait a
> day, and I'll give you all the answers.

Will you publish the tool too? ;-)

/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] Re: Distribution needs

[Ivan Lazar Miljenovic]

On 30 September 2010 23:06, Joachim Breitner  wrote:
>
> Hi,
>
> Am Donnerstag, den 30.09.2010, 11:15 +0200 schrieb Heinrich Apfelmus:
> > Joachim Breitner wrote:
> > > on planet.debian.org, there is some ill-tempered discussion about the
> > > seemingly bad relationship between the Ruby community and Debian
> > > maintainers. The following blog post summarizes the issues quite well
> > > and calmly:
> > > http://gwolf.org/blog/ruby-dissonance-debian-again
> >
> > (The link doesn't seem to work, only  http://gwolf.org/blog  is available.)
>
> I’m attaching the entry as it was produced by feed2imap.

I did have a read through all that and have discussed it with a ruby
developer I know.  My understanding is that the biggest difference
here between the Ruby and Haskell developer communities is that they
try to push through the whole "release early and release often" mantra
to the extreme, whereas we typically try to support as many versions
as possible.  Furthermore, we _try_ (and keep discussing how to
improve testing and detection for this) to specify API breakage via
version numbers, etc. and to keep such breakage to a minimum.

For another set of distro maintainer woes regarding Ruby, have a read
through Diego Elio “Flameeyes” Pettenò's (a Gentoo developer) blog
entries: http://blog.flameeyes.eu/tag/ruby

--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Distribution needs

[Joachim Breitner]

Hi,

Am Donnerstag, den 30.09.2010, 11:15 +0200 schrieb Heinrich Apfelmus:
> Joachim Breitner wrote:
> > on planet.debian.org, there is some ill-tempered discussion about the
> > seemingly bad relationship between the Ruby community and Debian
> > maintainers. The following blog post summarizes the issues quite well
> > and calmly:
> > http://gwolf.org/blog/ruby-dissonance-debian-again
> 
> (The link doesn't seem to work, only  http://gwolf.org/blog  is available.)

I’m attaching the entry as it was produced by feed2imap.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
  mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C
  JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/
  Debian Developer: nome...@debian.org
--- Begin Message ---



[A]

Lucas has written two long, insightful posts on the frustration about 
the social aspects of integrating Ruby stuff Debian – The first one, 
on September 12[1] and the second one, on September 29[2].


I cannot really blame (thoroughly) the Ruby guys for their position. 
After all, they have a vibrant community, and they are advancing great 
pieces of work. And they know who that code is meant for — Fellow 
programmers. And yes, although it is a pain to follow their API changes 
(and several of the Gems I regularly use do often get refactorings and 
functionality enhancements which break compatibility but introduce very 
nice new features), they say that's solved with one of Gems' main 
features being the simultaneous installability of different versions.


The key difference in Debian's worldview with Ruby's is they cater to 
*Fellow programmers*. Even leaving aside heaps of different positions 
and worldview/mindset, we have a fundamental difference: Debian cares 
about its *users*, whatever that means. So, our users should not even 
care what *language* a given application is implemented in – They 
should only care that it works. We, as packagers, should take care of 
all the infrastructural stuff.


And yes, that's where we find the conflicting spot: We don't want to 
ship many versions of a system library (that in this case would be a 
Gem). Specially if later versions fix known bugs in earlier versions and 
backports are not available or supported. Specially if upstream authors' 
only response to a bug in an older release will be "upgrade and rewrite 
whatever breaks in your application".


As an example of this, I am not currently updating the gems I maintain, 
as Debian is on a freeze to get out the next stable release. Or if at 
all, I am targetting those uploads to our Experimental branch, in order 
not to create a huge backlog for me when the freeze is over (just a 
series of rebuilds targetted at unstable). And yes, I will have to be 
responsible for any bugs that will most likely not be supported by most 
of my upstreams during the next ~2 years.


That's the role of a Linux distribution. And yes, as Lucas writes in the 
comments he got as responses to the first post – This dissonance comes 
in no small part because the Ruby developer community is mostly made 
from non-linuxers. People coming from a background where (mostly 
propietary) applications bundle up everything they need, where static 
linking is more popular than dynamic libraries, where there is no 
coordination between parts of the system are much less likely to 
understand our work.


And yes, the Perl community is a joy to work with in this regard. And 
that's the same I understand from the Python one. Because of their 
origins and where their main strength was grown and remains.


PS - And yes, I will join the flock of people saying that... The 
specific person that attacked your work is a great programmer, but well 
known as intolerant and obnoxious. Fortunately, even if our respective 
cultures fail to mix so much, most of our interactions just end with a 
"sigh" of lack of understanding, and not with the flames you got 
targetted with :-/


[1] http://www.lucas-nussbaum.net/blog/?p=566
[2] http://www.lucas-nussbaum.net/blog/?p=582

[A] http://planet.debian.org/heads/gwolf.png
--
Feed: Planet Debian

Item: Gunnar Wolf: Ruby dissonance with Debian, again

Date: Wed Sep 29 18:48:48 +0200 2010
<>--- End Message ---


signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] EDSL for Makefile

[Neil Mitchell]

Hi,

What great timing! I will be giving a talk at the Haskell Implementors
Workshop tomorrow about the Make system Shake. It will be video taped
and I can send you the slides after I've given the talk. So wait a
day, and I'll give you all the answers.

Thanks, Neil

On Thu, Sep 30, 2010 at 6:02 AM, Neil Brown  wrote:
> On 30/09/10 09:41, C K Kashyap wrote:
>>
>> Hi All,
>> I was thinking about doing an EDSL for Makefile (as an exercise)
>> I put down my line of thought here -
>> http://hpaste.org/40233/haskell_makefile_edsl
>>
>> I'd appreciate some feedback on the approach. Also, I wanted some idea
>> on how(in the current approach) I could make the target name and the
>> dependency available to the action writer - as shown below.
>>
>> r1 = Rule {
>>        target = "file1",
>>        dependsOn = ["file2"],
>>        action = do
>>                        execute ("gcc -c " ++ dependencyList ++ " -o " ++
>> target)
>> }
>>
>>
>
> Neil Mitchell gave a talk at AngloHaskell 2009 on doing a better make in
> Haskell.  I've found the abstract on the wiki:
> http://www.haskell.org/haskellwiki/AngloHaskell/2009 but, alas, no slides to
> be found.  My memory was that he had implemented the system successfully for
> internal use at a company and it had worked out quite well.  Perhaps you can
> contact him about the slides.
>
> Thanks,
>
> Neil.
> ___
> 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] EDSL for Makefile

[Emil Axelsson]

How about:

  execute ("gcc -c " ++ dependencyList ++ " -o " ++ target r1)

/ Emil


2010-09-30 10:41, C K Kashyap skrev:

Also, I wanted some idea
on how(in the current approach) I could make the target name and the
dependency available to the action writer - as shown below.

r1 = Rule {
target = "file1",
dependsOn = ["file2"],
action = do
execute ("gcc -c " ++ dependencyList ++ " -o " ++ 
target)
}



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] I still cannot seem to get a GUI working under Windows.

[jutaro]

Hi,

I would like to see that we add gtk2hs and/or wxHaskell to the Haskell
Platform. 
That would improve the situation!

I used gtk2hs and found it usable to build a cross platform GUI App. On
Windows you 
need an installer, which includes the gtk library part. There are some (on
Windows quite popular) programs like Pidgin, which are gtk based.

Jürgen Nicklisch-Franken 


caseyh wrote:
> 
> I still cannot seem to get a GUI working under Windows.
> 
> For Haskell GUI's is Ubuntu easier to setup.
> 
> If so, we're losing people if Haskell GUI's are so hard to get working  
> under Windows.
> 
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 

-- 
View this message in context: 
http://old.nabble.com/I-still-cannot-seem-to-get-a-GUI-working-under-Windows.-tp29839513p29846499.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] I still cannot seem to get a GUI working under Windows.

[Andrew Butterfield]

On 30 Sep 2010, at 12:02, Serguey Zefirov wrote:

> 2010/9/30 Andrew Coppin :
>> And even then, your
>> developed application will only run on Windows boxes that have GTK+
>> installed (i.e., none of them).
> 
> You can copy GTK+ DLLs with application.

Works fine with wxHaskell as well 
> 
> It works very well.
> ___
> 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 still cannot seem to get a GUI working under Windows.

[Serguey Zefirov]

2010/9/30 Andrew Coppin :
> And even then, your
> developed application will only run on Windows boxes that have GTK+
> installed (i.e., none of them).

You can copy GTK+ DLLs with application.

It works very well.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] EDSL for Makefile

[C K Kashyap]

Hi Warren,

> You might want to take a look at http://github.com/nfjinjing/nemesis
> which is somewhat related.

The above looks like a DSL approach and not an EDSL approach.

-- 
Regards,
Kashyap
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: A parsec question

[Christian Maeder]

Am 29.09.2010 20:01, schrieb Daniel Fischer:
> On Wednesday 29 September 2010 19:10:22, Ben Franksen wrote:
>>>
>>> Note the last line mentions only '}'. I would rather like to see
>>>
>>>   expecting "}" or digit
>>>
>>> since the parser could very well accept another digit here.
> 
> parsec2 did that, I don't know whether that change is intentional or 
> accidental.

Right, parsec2 or parsec-2.1.0.1 still does so. (parsec-3 behaves
differently wrt error messages.)

Try "ghc-pkg hide parsec" so that parsec-2.1.0.1 will be taken:

 import Text.ParserCombinators.Parsec
 import Control.Monad

 infixl 1 <<

 (<<) :: Monad m => m a -> m b -> m a
 (<<) = liftM2 const

 block p = char '{' >> p << char '}'
 parser = block (many (digit))
 main = parseTest parser "{123a}"

*Main> main
Loading package parsec-2.1.0.1 ... linking ... done.
parse error at (line 1, column 5):
unexpected "a"
expecting digit or "}"

>>> (1) What is the reason for this behaviour?
>>> (2) Is there another combinator that behaves as I would like?
>>> (3) Otherwise, how do I write one myself?

ask derek.a.elk...@gmail.com (CCed)

Cheers Christian

>>
>> I just saw that Christian Maeder answered a similar question recently. I
>>
>> tried his suggestion of using manyTill and bingo:
>>> {-# LANGUAGE NoMonomorphismRestriction #-}
>>> import Control.Applicative ((*>),(<*))
>>> import Text.Parsec
>>> block p = char '{' *> p <* char '}'
>>> parser = block (manyTill digit (char '}'))
>>> main = parseTest parser "{123a}"
>>
>> gives
>>
>>   parse error at (line 1, column 5):
>>   unexpected "a"
>>   expecting "}" or digit
>>
>> So far so good. I wonder whether this parser is as efficient as the
>> original one.
> 
> manyTill p end  = scan
> where
>   scan  = do{ end; return [] }
> <|>
>   do{ x <- p; xs <- scan; return (x:xs) }
> 
> I'm not sure, but I suspect it's less efficient.
> 
> Perhaps
> 
> manyTill' p end = scan []
> where
>   scan acc = do { end; return (reverse acc) }
> <|> do { x <- p; scan (x:acc) }
> 
> is more efficient (depends on Parsec's bind which is more efficient), you 
> could test.
> 
>> Also, this style is less modular, as I have to mention the
>> terminator in two places.
> 
> That's not the main problem. `manyTill' consumes the ending token, so
> 
> block (manyTill whatever (char '}')) needs two '}' to succeed.
> You would need
> 
> block (manyTill digit (lookAhead (char '}'))
> 
> to replicate the behaviour of block (many digit).
> 
>> Is there a non-greedy variant of 'many' so
>> that modularity gets restored and efficiency is not lost?
>>
>> Cheers
>> Ben
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] EDSL for Makefile

[C K Kashyap]

Thanks Neil and Warren.


On Thu, Sep 30, 2010 at 3:32 PM, Neil Brown  wrote:
> On 30/09/10 09:41, C K Kashyap wrote:
>>
>> Hi All,
>> I was thinking about doing an EDSL for Makefile (as an exercise)
>> I put down my line of thought here -
>> http://hpaste.org/40233/haskell_makefile_edsl
>>
>> I'd appreciate some feedback on the approach. Also, I wanted some idea
>> on how(in the current approach) I could make the target name and the
>> dependency available to the action writer - as shown below.
>>
>> r1 = Rule {
>>        target = "file1",
>>        dependsOn = ["file2"],
>>        action = do
>>                        execute ("gcc -c " ++ dependencyList ++ " -o " ++
>> target)
>> }
>>
>>
>
> Neil Mitchell gave a talk at AngloHaskell 2009 on doing a better make in
> Haskell.  I've found the abstract on the wiki:
> http://www.haskell.org/haskellwiki/AngloHaskell/2009 but, alas, no slides to
> be found.  My memory was that he had implemented the system successfully for
> internal use at a company and it had worked out quite well.  Perhaps you can
> contact him about the slides.
>
> Thanks,
>
> Neil.
>



-- 
Regards,
Kashyap
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] EDSL for Makefile

[Neil Brown]

On 30/09/10 09:41, C K Kashyap wrote:

Hi All,
I was thinking about doing an EDSL for Makefile (as an exercise)
I put down my line of thought here -
http://hpaste.org/40233/haskell_makefile_edsl

I'd appreciate some feedback on the approach. Also, I wanted some idea
on how(in the current approach) I could make the target name and the
dependency available to the action writer - as shown below.

r1 = Rule {
target = "file1",
dependsOn = ["file2"],
action = do
execute ("gcc -c " ++ dependencyList ++ " -o " ++ 
target)
}

   
Neil Mitchell gave a talk at AngloHaskell 2009 on doing a better make in 
Haskell.  I've found the abstract on the wiki: 
http://www.haskell.org/haskellwiki/AngloHaskell/2009 but, alas, no 
slides to be found.  My memory was that he had implemented the system 
successfully for internal use at a company and it had worked out quite 
well.  Perhaps you can contact him about the slides.


Thanks,

Neil.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Distribution needs

[Magnus Therning]

On Thu, Sep 30, 2010 at 10:15, Heinrich Apfelmus
 wrote:
> Joachim Breitner wrote:
>>
>> on planet.debian.org, there is some ill-tempered discussion about the
>> seemingly bad relationship between the Ruby community and Debian
>> maintainers. The following blog post summarizes the issues quite well
>> and calmly:
>> http://gwolf.org/blog/ruby-dissonance-debian-again
>
> (The link doesn't seem to work, only  http://gwolf.org/blog  is available.)


It did work yesterday, but is gone today.  Anyway, here's a copy of it
http://www.debianblogs.com/ruby_dissonance_with_debian_again

/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] I still cannot seem to get a GUI working under Windows.

[Andrew Butterfield]

On 29 Sep 2010, at 20:34, Steve Schafer wrote:

> 
> This is an attitude that just doesn't fly in the Windows world. Which is
> unfortunate, because the Windows market is HUGE compared to OS X, and
> STUNNINGLY HUGE compared to everything else.
> 
> The fix isn't going to be to find a developer who's willing to do the
> work to make Haskell+GUI more seamless under Windows. The fix is for the
> Haskell community--as a whole--to wake up and realize what the wxWidgets
> folks did a while ago: "Hey, you know what? This GUI stuff is
> _important_ if we want people to pay any attention to the software that
> we write!"

This is why, when I developed my theorem prover, I put GUI aspects top of the 
list

I chose wxHaskell because I wanted portability

Ironically, given the thrust of this thread, I got it working without too much 
difficulty on Windows

GHC 10.6.4, latest binaries for wxHaskell - easy to install and get working

I gather several of my students have successfully done Linux builds of same

I switched over recently  to Mac OS X (10.6), and (more irony) am having real 
difficulties
getting it to work - installing wxHaskell is a real bear on this platform


The GUI theorem prover - see http://www.scss.tcd.ie/Andrew.Butterfield/Saoithin/

(I was going to announce this project to the Haskell Community real soon now, 
so I guess this is as good a time as any .)


> 
> -Steve Schafer
> ___
> 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] EDSL for Makefile

[Warren Henning]

Hi,

You might want to take a look at http://github.com/nfjinjing/nemesis
which is somewhat related.

Warren

On Thu, Sep 30, 2010 at 1:41 AM, C K Kashyap  wrote:
> Hi All,
> I was thinking about doing an EDSL for Makefile (as an exercise)
> I put down my line of thought here -
> http://hpaste.org/40233/haskell_makefile_edsl
>
> I'd appreciate some feedback on the approach. Also, I wanted some idea
> on how(in the current approach) I could make the target name and the
> dependency available to the action writer - as shown below.
>
> r1 = Rule {
>        target = "file1",
>        dependsOn = ["file2"],
>        action = do
>                        execute ("gcc -c " ++ dependencyList ++ " -o " ++ 
> target)
> }
>
>
> --
> Regards,
> Kashyap
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Distribution needs

[Heinrich Apfelmus]

Joachim Breitner wrote:

on planet.debian.org, there is some ill-tempered discussion about the
seemingly bad relationship between the Ruby community and Debian
maintainers. The following blog post summarizes the issues quite well
and calmly:
http://gwolf.org/blog/ruby-dissonance-debian-again


(The link doesn't seem to work, only  http://gwolf.org/blog  is available.)


Regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] EDSL for Makefile

[C K Kashyap]

Hi All,
I was thinking about doing an EDSL for Makefile (as an exercise)
I put down my line of thought here -
http://hpaste.org/40233/haskell_makefile_edsl

I'd appreciate some feedback on the approach. Also, I wanted some idea
on how(in the current approach) I could make the target name and the
dependency available to the action writer - as shown below.

r1 = Rule {
target = "file1",
dependsOn = ["file2"],
action = do
execute ("gcc -c " ++ dependencyList ++ " -o " ++ 
target)
}


-- 
Regards,
Kashyap
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Problem with a sample from RWH

[C K Kashyap]

> The change looks good; note, however, that you're doing something
> subtly different if an error occurs: in the original, if an error
> occured then "fail" was used to forcibly terminate the program.  Your
> variant however returns the shown error message.  Depending on the
> situation, this is usually a bad thing (better off to use Maybe or
> Either).
>
> Also, here's the official rationale about why SomeException is not
> recommended: 
> http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Control-Exception.html#4
> .  My main summation of this is that it even catches when you try to
> use Ctrl-c to kill a program.
>
I tried this - this is consistent with the original in terms of the
exiting out ... but the error message does not show up.

run s = handle (\e@(SomeException{}) -> exitWith (ExitFailure 1)) $ do

How can I achieve both?


-- 
Regards,
Kashyap
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe