Re: 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.

[Curt Sampson]

On 2009-10-01 18:47 +0200 (Thu), Alberto G. Corona  wrote:

> May be because consciousness is relatively new and thus, not optimized.

Actually, no; our brains are very, very highly optimized. Only they're
optimized for minimum power usage, not making the best decisions.

For more information, see Read Montague's _Your Brain Is (Almost)
Perfect: How We Make Decisions_.

cjs
-- 
Curt Sampson   +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[2]: [Haskell-cafe] Creating an alias for a function

[Bulat Ziganshin]

Hello Ross,

Wednesday, October 7, 2009, 6:02:28 AM, you wrote:

> car = head

unfortunately it doesn't work without -fno-monomorphism-restriction


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: Re[2]: [Haskell-cafe] Creating an alias for a function

[Luke Palmer]

On Wed, Oct 7, 2009 at 1:26 AM, Bulat Ziganshin
 wrote:
> Hello Ross,
>
> Wednesday, October 7, 2009, 6:02:28 AM, you wrote:
>
>> car = head
>
> unfortunately it doesn't work without -fno-monomorphism-restriction

It should be fine without the monomorphism restriction.  Said
restriction only applies to functions with typeclass constraints, of
which this has none.

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

Re[4]: [Haskell-cafe] Creating an alias for a function

[Bulat Ziganshin]

Hello Luke,

Wednesday, October 7, 2009, 11:35:47 AM, you wrote:

>>> car = head
>>
>> unfortunately it doesn't work without -fno-monomorphism-restriction

> It should be fine without the monomorphism restriction.  Said
> restriction only applies to functions with typeclass constraints, of
> which this has none.

oh, i don't known this. but anyway michael may have such
functions about those you need to alias


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: [Haskell-cafe] better way to do this?

[Peter Verswyvelen]

--- BEGIN NOSTALGIA ---

Well, I have to add to this, that when I coded my first games in assembler
in the eighties, I did exactly the same thing: just recording the input of
the joystick was enough to get full replays and make auto playing demos.
 But on the old computers, this was all so easy, since you had full control
over every bit of the system (it was even easy to count exactly how many
cycles a routine would take :-), so it was just a matter of starting the
system in the same initial state, which was very easy.
As Ryan says, this was a blessing for debugging; after a bug was found (but
of course when writing in assembler one did not make bugs ;-), the testers
just returned a small log file of the input and version number, and this
allowed reproducing the problem *before* the bug occurred (aka known as
reverse debugging?).

Also since the mutable part of the game was just a couple of kilobytes (most
of the memory was used for immutable graphics, sounds and code), taking a
snapshot at regular intervals and embedding this into the log-file made it
easy to quickly go backwards and forwards in time.

To me, that was the joy of imperative programming: I could reason about
those systems as a whole, they behaved in a very predictable way, and since
all home computers (and game console) where basically identical, you knew
that if it behaved correctly on your system, it would also work on the
millions of other systems out there. Now IMO imperative programming is more
like playing Russian roulette...

--- END NOSTALGIA ---

But I find it so much harder or impossible on modern systems to do this, or
as Ryan says, it requires a high discipline from coders...

So yes, without using IO, Haskell forces you into this safe spot (there's of
course the unsafePerformIO function as backdoor to break all that :). But we
still need to see the first commercial games written in Haskell; hope to see
those soon, without using IO everywhere of course :)

Actually, it might be interesting to make a special mailing list for Haskell
and games? Or even a broader list for applying FP to games and simulations?
Or maybe that already exists?

On Sun, Oct 4, 2009 at 7:16 PM, Ryan Ingram  wrote:

> And, to go further, once you embrace "determinism" in your randomness, you
> can do all sorts of really cool things.
>
> From the perspective of a games programmer:
>
> You can run the same simulation code on two different network nodes, and
> reliably get the same result, allowing you to just transfer user inputs
> between the nodes instead of game state.  This has applications in reducing
> latency as well, as you only need to transfer the input one way across the
> network.
>
> You can save off the user inputs and initial into a tiny "replay" buffer,
> allowing you to re-run the game from the beginning without much memory
> cost.  This is not only a cool end-user feature, but it aids *tremendously*
> in debugging.  When something goes wrong, you can always just rewind as many
> times as you want while you narrow down the cause of the problem.
>
> However, we always had problems with determinism failures, where somebody
> would use the wrong random-number generator, or forget that they aren't
> allowed to have the simulation depend on something that came from the
> graphics RNG.  In Haskell you can encode the purity of the simulation into
> its type and it won't break!
>
>   -- ryan
>
>
> On Sun, Oct 4, 2009 at 6:20 AM, Duncan Coutts <
> duncan.cou...@googlemail.com> wrote:
>
>> On Sun, 2009-10-04 at 05:11 -0700, Michael Mossey wrote:
>> > Duncan Coutts wrote:
>>
>> > > Others have already answered but I'd like to suggest that you avoid
>> > > using IO here. There's no need for this to be impure.
>>
>> > Can you point me to a tutorial that covers the basics of randomness in
>> > Hasell? I find it very confusing.
>>
>>
>> http://en.wikibooks.org/wiki/Haskell/Hierarchical_libraries/Randoms
>>
>> http://learnyouahaskell.com/input-and-output#randomness
>>
>>
>> The main thing to realise is that random number generators are pure and
>> predictable. Given the state of a random number generator, if you ask
>> for a random number, it always gives the same answer. It has to, because
>> it is pure.
>>
>> Let's make one, and seed it with the starting state 12345
>>
>> ghci> :module System.Random
>> ghci> let g0 = mkStdGen 12345
>>
>> Now we can ask for the next random number in the sequence:
>>
>> ghci> let (n1, g1) = next g0
>> ghci> n1
>> 493972152
>>
>> Now of course if we asked for the random number from g0 again then we
>> must get the same result. But notice that when we use 'next' it also
>> gives us back g1 which is the next state of the random number generator.
>>
>> ghci> let (n2, g2) = next g1
>> ghci> n2
>> 335387100
>>
>> So this is the basic way that random number generators work in a pure
>> language. The generator has to be passed around the pure function, for
>> example from one recursion to the next.
>>
>> So you end up with pure fun

Re: [Haskell-cafe] better way to do this?

[David Virebayre]

On Wed, Oct 7, 2009 at 10:05 AM, Peter Verswyvelen  wrote:
> over every bit of the system (it was even easy to count exactly how many
> cycles a routine would take :-), so it was just a matter of starting the

You sound like you used to code on the Commodore 64 :)

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

Re: [Haskell-cafe] better way to do this?

[Ketil Malde]

Peter Verswyvelen  writes:

> So yes, without using IO, Haskell forces you into this safe spot

One could argue that IO should be broken down into a set of "sub-monads"
encapsulating various subsets of the functionality - file system,
network access, randomness, and so on.  This could extend the "safe
spot" to cover much more computational real estate, and effectively
sandbox programs in various ways.

So instead of 'main :: IO ()', a text processing program using stdin and
stdout could have type 'main :: MonadStdIO m => m ()'.  For testing, you
could then define your own monad implementing 'putStrLn' and 'readLn'
etc, and a function 'runStdIO :: MonadStdIO m => m () -> String' that
you are free to use in your quickcheck properties.

(ObAttribution: I think it was a posting by Lennart Augustsson on unique
names that brought this to my mind, but a quick googling didn't find
that exact mail.) 

-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] better way to do this?

[Eugene Kirpichov]

Or you can use an effect system (however that doesn't give you the
opportunity of overriding IO functions, but I think that providing
such an opportunity with the means you suggest (splitting IO into many
sub-monads) is not going to be usable in the large scale)

By the way, I am surprised that there seems to not exist any
non-purely-academic language at all that supports effect systems!
(except for Java's checked exceptions being a poor analogue). The only
language with an effect system *and* a compiler that I know of is DDC,
but it seems to be purely experimental.

2009/10/7 Ketil Malde :
> Peter Verswyvelen  writes:
>
>> So yes, without using IO, Haskell forces you into this safe spot
>
> One could argue that IO should be broken down into a set of "sub-monads"
> encapsulating various subsets of the functionality - file system,
> network access, randomness, and so on.  This could extend the "safe
> spot" to cover much more computational real estate, and effectively
> sandbox programs in various ways.
>
> So instead of 'main :: IO ()', a text processing program using stdin and
> stdout could have type 'main :: MonadStdIO m => m ()'.  For testing, you
> could then define your own monad implementing 'putStrLn' and 'readLn'
> etc, and a function 'runStdIO :: MonadStdIO m => m () -> String' that
> you are free to use in your quickcheck properties.
>
> (ObAttribution: I think it was a posting by Lennart Augustsson on unique
> names that brought this to my mind, but a quick googling didn't find
> that exact mail.)
>
> -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
>



-- 
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] better way to do this?

[Duncan Coutts]

On Tue, 2009-10-06 at 13:22 -0700, Michael P Mossey wrote:
> Duncan Coutts wrote:
> 
> > So you end up with pure functions like:
> > 
> > shuffle :: RandomGen g => g -> [x] -> [x]
> 
> Thanks for the help, Duncan. I'm confused on one point. Don't you always need 
> the new state of the generator back? So wouldn't this need to be:
> 
> shuffle :: RandomGen g => g -> [x] -> (g,[x])

Yes if you want it back at the end.

This is actually an interesting case for split, which is another member
of the RandomGen class. Having the luxury to discard the tail of the
sequence relies on us being able to split the RNG first so that we don't
end up loosing the RNG completely.

Why might we want to be able to discard the tail? In the shuffle case
above we can actually do the shuffle lazily. If we use the right
algorithm we can use a single random number per element returned, and
only have to compute each random number when each element of the result
is demanded. But if we had to return the final state of the RNG then
that would force us to have used all the random numbers we might
eventually need, which would defeat the lazy shuffle.


> > Another approach is to hide the 'g' inside a monad. That's what
> > MonadRandom is all about. eg:
> > 
> > shuffle :: [x] -> Rand [x]
> 
> One tutorial mentions the class Gen in the Test.QuickCheck module. Is "Rand" 
> a 
> different class defined somewhere else?

It's a monad type from the MonadRandom package. Essentially it deals
with passing the RNG in and returning the new one at the end. It's
similar to QC's Gen monad, but not specialised to the task of generating
random elements of various types.

> > The tutorials above explain about the other random functions, for
> > getting values of different types (not just Int) and restricted ranges
> > of number etc.
> > 
> > Of course at some point you want to seed the random number generator
> > with some initial genuinely random value (not like the 12345 we used
> > above). That is the only place in your random-handling code that needs
> > to do IO. All the rest of it can be pure.
> 
> What function gives you that initial random seed? (Grabs it from the system 
> clock?)

System.Random doesn't have an explicit "initialise from the system"
action. It has a global StdGen that is always available and gets
initialised once from the system.

To get a new, independent StdGen use

newStdGen :: IO StdGen

which works just by applying 'split' to the global StdGen.

Duncan

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

Re: [Haskell-cafe] better way to do this?

[Peter Verswyvelen]

Yep. Commodore 64, Amiga. I really loved those machined, especially the
Amiga (mmm, maybe someone should port a Haskell compiler to the Amiga. ha,
how "nerdy" can one get? ;-)
On Wed, Oct 7, 2009 at 10:50 AM, David Virebayre

> wrote:

> On Wed, Oct 7, 2009 at 10:05 AM, Peter Verswyvelen 
> wrote:
> > over every bit of the system (it was even easy to count exactly how many
> > cycles a routine would take :-), so it was just a matter of starting the
>
> You sound like you used to code on the Commodore 64 :)
>
> David.
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] better way to do this?

[Peter Verswyvelen]

On Wed, Oct 7, 2009 at 11:13 AM, Ketil Malde  wrote:
>
> One could argue that IO should be broken down into a set of "sub-monads"
> encapsulating various subsets of the functionality - file system,
> network access, randomness, and so on.  This could extend the "safe
> spot" to cover much more computational real estate, and effectively
> sandbox programs in various ways.


Yes, a similar and very long thread I unintentionally started  (sorry
for that :p)  was:

DDC compiler and effects; better than Haskell?
http://thread.gmane.org/gmane.comp.lang.haskell.cafe/62205
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Network.Curl and posting XML data

[mf-hcafe-15c311f0c]

Hi Erik,

I am not aware of any SSL implementation in haskell either (even
though I think it should go not into HTTP but into Crypto (which is a
neat piece of code, but needs a lot more work)).

I can think of two "quick" solutions if you need your Haskell code to
use an SSL link: run stunnel.org and make your application connect to
that, or write a Haskell wrapper around openssl.org.

As for the latter, I don't know your requirements and resources so
this may be possible, but from what i've seen of openssl i wouldn't
want to have to do that.

good luck,
matthias



On Wed, Oct 07, 2009 at 02:38:05PM +1100, Erik de Castro Lopo wrote:
> To: haskell-cafe@haskell.org
> From: Erik de Castro Lopo 
> Date: Wed, 7 Oct 2009 14:38:05 +1100
> Subject: Re: [Haskell-cafe] Network.Curl and posting XML data
> 
> Dmitry Olshansky wrote:
> 
> > Hi, Erik,
> > 
> > Did you try Network.HTTP? Is it not enough?
> 
> Apparently not.
> 
> Now I need to do a post to a HTTPS server and Network.HTTP does
> not seem to support HTTPS. Is that really right?
> 
> Erik
> -- 
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] better way to do this?

[Bulat Ziganshin]

Hello Peter,

Wednesday, October 7, 2009, 2:04:49 PM, you wrote:

afair, nhc was started there. it was a small compiler exactly because
Amiga was a rather small computer (comapred to RISC stations)

> Yep. Commodore 64, Amiga. I really loved those machined, especially
> the Amiga (mmm, maybe someone should port a Haskell compiler to the
> Amiga. ha, how "nerdy" can one get? ;-) 

> On Wed, Oct 7, 2009 at 10:50 AM, David Virebayre
>  wrote:
>  
> On Wed, Oct 7, 2009 at 10:05 AM, Peter Verswyvelen  wrote:
 >> over every bit of the system (it was even easy to count exactly how many
 >> cycles a routine would take :-), so it was just a matter of starting the
>  
>  
> You sound like you used to code on the Commodore 64 :)
>  
>  David.
>  

>   


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: Re[2]: [Haskell-cafe] better way to do this?

[Malcolm Wallace]

afair, nhc was started there. it was a small compiler exactly because
Amiga was a rather small computer (comapred to RISC stations)


nhc12 (for Haskell 1.2) was first developed on an Acorn Archimedes  
with 2Mb of RAM, under RiscOS.


Regards,
Malcolm

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

Re: [Haskell-cafe] Network.Curl and posting XML data

[Erik de Castro Lopo]

mf-hcafe-15c311...@etc-network.de wrote:

> I am not aware of any SSL implementation in haskell either (even

I really find this rather surprising. Ocaml has a very decent wrapper
around Openssl that works rather well so it can't be that hard.
 
> though I think it should go not into HTTP but into Crypto (which is a
> neat piece of code, but needs a lot more work)).

But why shouldn't it should go into Network.HTTP? All I want to do
is a HTTP POST of text/xml data to a HTTPS server and retrieve the
text/xml data response and the HTTP response code. Whether that 
URL is HTTP vs HTTPS shouldn't matter.

With a sane API I should just be able to change from a HTTP url to 
a HTTPS url and have it JustWork (tm). To have to use a different
library depending on whether I'm doing http vs https is just
horrible.

> I can think of two "quick" solutions if you need your Haskell code to
> use an SSL link: run stunnel.org

Sorry, thats way too cludgy for my application.

> and make your application connect to
> that, or write a Haskell wrapper around openssl.org.

I've used openssl directly from C and C++ so  I know its doable, but
I consider openssl a real blemish on the FOSS world.

There is however this:

   
http://hackage.haskell.org/packages/archive/HsOpenSSL/0.6.5/doc/html/OpenSSL-Session.html

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Network.Curl and posting XML data

[Magnus Therning]

On Wed, Oct 7, 2009 at 11:37 AM, Erik de Castro Lopo
 wrote:
> mf-hcafe-15c311...@etc-network.de wrote:
>
>> I am not aware of any SSL implementation in haskell either (even
>
> I really find this rather surprising. Ocaml has a very decent wrapper
> around Openssl that works rather well so it can't be that hard.
>
>> though I think it should go not into HTTP but into Crypto (which is a
>> neat piece of code, but needs a lot more work)).
>
> But why shouldn't it should go into Network.HTTP? All I want to do
> is a HTTP POST of text/xml data to a HTTPS server and retrieve the
> text/xml data response and the HTTP response code. Whether that
> URL is HTTP vs HTTPS shouldn't matter.
>
> With a sane API I should just be able to change from a HTTP url to
> a HTTPS url and have it JustWork (tm). To have to use a different
> library depending on whether I'm doing http vs https is just
> horrible.

There is more to SSL than securing transport, as I'm sure you know,
arguably the functions that deal with HTTPS should be in Network.HTTP,
but all the crypto and cert handling (including verification/checking
of attributes of certs) should probably be housed somewhere else.

/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

[Haskell-cafe] Re: Generalizing IO

[Heinrich Apfelmus]

David Menendez wrote:
> Floptical Logic wrote:
>> The code below is a little interactive program that uses some state.
>> It uses StateT with IO to keep state.  My question is: what is the
>> best way to generalize this program to work with any IO-like
>> monad/medium?  For example, I would like the program to function as it
>> does now using stdin but I would also like it to function over IRC
>> using the Net monad from
>> .  Thanks for
>> any suggestions.
> 
> Instead of specifying the monad implementation, specify the interface.
> That is, you are using state operations (from MonadState) and IO
> operations (from MonadIO). Try removing all the type signatures that
> mention PDState and see what you get.
> 
> E.g., loop :: (MonadState PD m, MonadIO m) => m a

Alternatively, you can use algebraic data types instead of type classes
to generalize one program to different implementations. For monads, this
can be achieved with

 http://hackage.haskell.org/package/MonadPrompt

In particular, the idea is to turn every effect like

  getLine

into a constructor

  GetLine

and have different implementations pattern match on that.


Regards,
apfelmus

--
http://apfelmus.nfshost.com

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

Re: Re[4]: [Haskell-cafe] Creating an alias for a function

[michael rice]

Actually I used it to fake the Pascal ord(x) function:


ord = fromEnum

Problem?

Michael


--- On Wed, 10/7/09, Bulat Ziganshin  wrote:

From: Bulat Ziganshin 
Subject: Re[4]: [Haskell-cafe] Creating an alias for a function
To: "Luke Palmer" 
Cc: "Bulat Ziganshin" , haskell-cafe@haskell.org
Date: Wednesday, October 7, 2009, 3:41 AM

Hello Luke,

Wednesday, October 7, 2009, 11:35:47 AM, you wrote:

>>> car = head
>>
>> unfortunately it doesn't work without -fno-monomorphism-restriction

> It should be fine without the monomorphism restriction.  Said
> restriction only applies to functions with typeclass constraints, of
> which this has none.

oh, i don't known this. but anyway michael may have such
functions about those you need to alias


-- 
Best regards,
 Bulat                            mailto:bulat.zigans...@gmail.com

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



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

Re: Re[4]: [Haskell-cafe] Creating an alias for a function

[Deniz Dogan]

2009/10/7 michael rice 
>
> Actually I used it to fake the Pascal ord(x) function:
>
> ord = fromEnum
>
> Problem?
>
> Michael
>

If the monomorphism restriction applies, the compiler (assuming you're
using GHC) will tell you about it.

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

Re[6]: [Haskell-cafe] Creating an alias for a function

[Bulat Ziganshin]

Hello Deniz,

Wednesday, October 7, 2009, 5:03:59 PM, you wrote:

it depends. what i see with ghc 6.6.1:

C:\!\Haskell>runghc test.hs

test.hs:1:6:
Ambiguous type variable `a' in the constraint:
  `Enum a' arising from use of `fromEnum' at test.hs:1:6-13
Possible cause: the monomorphism restriction applied to the following:
  ord :: a -> Int (bound at test.hs:1:0)
Probable fix: give these definition(s) an explicit type signature
  or use -fno-monomorphism-restriction


C:\!\Haskell>ghc --make test.hs
[1 of 1] Compiling Main ( test.hs, test.o )
Linking test.exe ...


test.hs:

ord = fromEnum
main = print (ord 'a')


> 2009/10/7 michael rice 
>>
>> Actually I used it to fake the Pascal ord(x) function:
>>
>> ord = fromEnum
>>
>> Problem?
>>
>> Michael
>>

> If the monomorphism restriction applies, the compiler (assuming you're
> using GHC) will tell you about it.

> --
> Deniz Dogan


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: Re[6]: [Haskell-cafe] Creating an alias for a function

[Deniz Dogan]

2009/10/7 Bulat Ziganshin :
> Hello Deniz,
>
> Wednesday, October 7, 2009, 5:03:59 PM, you wrote:
>
> it depends. what i see with ghc 6.6.1:
>
> [snip]
>
>    Possible cause: the monomorphism restriction applied to the following:
>      ord :: a -> Int (bound at test.hs:1:0)
>    Probable fix: give these definition(s) an explicit type signature
>                  or use -fno-monomorphism-restriction

I don't see the problem? GHC seems to tell you about the monomorphism
restriction in your example.

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

Re[8]: [Haskell-cafe] Creating an alias for a function

[Bulat Ziganshin]

Hello Deniz,

Wednesday, October 7, 2009, 5:23:24 PM, you wrote:

>>    Possible cause: the monomorphism restriction applied to the following:
>>      ord :: a -> Int (bound at test.hs:1:0)
>>    Probable fix: give these definition(s) an explicit type signature
>>                  or use -fno-monomorphism-restriction

> I don't see the problem? GHC seems to tell you about the monomorphism
> restriction in your example.

look further. runghc complains, ghc - don't. may be runghc enables -Wall?

-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: [Haskell-cafe] better way to do this?

[John A. De Goes]

On Oct 7, 2009, at 3:13 AM, Ketil Malde wrote:


Peter Verswyvelen  writes:


So yes, without using IO, Haskell forces you into this safe spot


One could argue that IO should be broken down into a set of "sub- 
monads"

encapsulating various subsets of the functionality - file system,
network access, randomness, and so on.  This could extend the "safe
spot" to cover much more computational real estate, and effectively
sandbox programs in various ways.


Good idea in theory, in practice I suspect it would lead to  
unmanageable boilerplate.


Regards,

John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration

http://www.n-brain.net|877-376-2724 x 101


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

[Haskell-cafe] Dutch HUG: meeting next week (October 12th) in Utrecht

[Tom Lokhorst]

I'd like to invite functional programmers in The Netherlands to the
Dutch Haskell User Group [1, 2] meeting next Monday at 19:00.

Each meeting I see new faces, so that's why I continue to send these
invitations to several mailing lists; it's working!

At this meeting we'll have two talks. Andres Löh will talk about
lhs2TeX, a tool for typesetting Haskell code using LaTeX. Yaakov Nemoy
will talk about the status of Haskell packaging in Fedora and how to
do it yourself.

Like last month, the meeting will be in the Booth Hall [3] of the
Utrecht University Library. There's free car parking [4] at the
library, and it's easily accessible by bike and bus [5].

Unfortunately, I won't be able to attend, but I hope you will!


- Tom Lokhorst

[1]: http://www.haskell.org/haskellwiki/Dutch_HUG
[2]: http://groups.google.com/group/dutch-hug
[3]: 
http://www.uu.nl/EN/library/contact/university_library/zaalverhuur/Pages/default.aspx#booth
[4]: 
http://www.uu.nl/EN/library/contact/university_library/Parkeren/Pages/default.aspx
[5]: 
http://www.uu.nl/EN/library/contact/university_library/plattegrondenrou/Pages/default.aspx
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [Haskell] ANNOUNCE: GPipe-1.0.0: A functional graphics API for programmable GPUs

[Petr Pudlak]

Hi Tobias,

(I'm completely new to GPU programming, so my question may be completely
stupid or unrelated. Please be patient :-).)

Some time ago I needed to perform some large-scale computations
(searching for first-order logic models) and a friend told me that GPUs
can be used to perform many simple computations in parallel. Could GPipe
be used for such a task? I.e. to program some non-graphical,
parallelized algorithm, which could be run on a GPU cluster?

Thanks for your answer,

Petr

On Sun, Oct 04, 2009 at 08:32:56PM +0200, Tobias Bexelius wrote:
> I'm proud to announce the first release of GPipe-1.0.0: A functional graphics
> API for programmable GPUs.
>  
> GPipe models the entire graphics pipeline in a purely functional, immutable
> and typesafe way. It is built on top of the programmable pipeline (i.e.
> non-fixed function) of OpenGL 2.1 and uses features such as vertex buffer
> objects (VBO's), texture objects and GLSL shader code synthetisation to create
> fast graphics programs. Buffers, textures and shaders are cached internally to
> ensure fast framerate, and GPipe is also capable of managing multiple windows
> and contexts. By creating your own instances of GPipes classes, it's possible
> to use additional datatypes on the GPU.
>  
> You'll need full OpenGL 2.1 support, including GLSL 1.20 to use GPipe. Thanks
> to OpenGLRaw, you may still build GPipe programs on machines lacking this
> support.
>  
> The package, including full documentation, can be found at:
> http://hackage.haskell.org/package/GPipe-1.0.0
>  
> Of course, you may also install it with:
> cabal install gpipe
>  
>  
> Cheers!
> Tobias Bexelius
> 
> ━━
> kolla in resten av Windows LiveT. Inte bara e-post - Windows LiveT är mycket
> mer än din inkorg. Mer än bara meddelanden
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] better way to do this?

[John A. De Goes]

It's a complex area not a lot of people are working in. Similar  
(actually worse than) dependent typing.


Regards,

John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration

http://www.n-brain.net|877-376-2724 x 101

On Oct 7, 2009, at 3:32 AM, Eugene Kirpichov wrote:


Or you can use an effect system (however that doesn't give you the
opportunity of overriding IO functions, but I think that providing
such an opportunity with the means you suggest (splitting IO into many
sub-monads) is not going to be usable in the large scale)

By the way, I am surprised that there seems to not exist any
non-purely-academic language at all that supports effect systems!
(except for Java's checked exceptions being a poor analogue). The only
language with an effect system *and* a compiler that I know of is DDC,
but it seems to be purely experimental.

2009/10/7 Ketil Malde :

Peter Verswyvelen  writes:


So yes, without using IO, Haskell forces you into this safe spot


One could argue that IO should be broken down into a set of "sub- 
monads"

encapsulating various subsets of the functionality - file system,
network access, randomness, and so on.  This could extend the "safe
spot" to cover much more computational real estate, and effectively
sandbox programs in various ways.

So instead of 'main :: IO ()', a text processing program using  
stdin and
stdout could have type 'main :: MonadStdIO m => m ()'.  For  
testing, you

could then define your own monad implementing 'putStrLn' and 'readLn'
etc, and a function 'runStdIO :: MonadStdIO m => m () -> String' that
you are free to use in your quickcheck properties.

(ObAttribution: I think it was a posting by Lennart Augustsson on  
unique

names that brought this to my mind, but a quick googling didn't find
that exact mail.)

-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





--
Eugene Kirpichov
Web IR developer, market.yandex.ru
___
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] better way to do this?

[Conor McBride]

On 7 Oct 2009, at 15:04, John A. De Goes wrote:


On Oct 7, 2009, at 3:13 AM, Ketil Malde wrote:


Peter Verswyvelen  writes:


So yes, without using IO, Haskell forces you into this safe spot


One could argue that IO should be broken down into a set of "sub- 
monads"

encapsulating various subsets of the functionality - file system,
network access, randomness, and so on.  This could extend the "safe
spot" to cover much more computational real estate, and effectively
sandbox programs in various ways.


Good idea in theory, in practice I suspect it would lead to  
unmanageable boilerplate.


Aye, but today's boilerplate is tomorrow's language design.

Cheers

Conor

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

[Haskell-cafe] What *is* a DSL?

[Günther Schmidt]

Hi all,


for people that have followed my posts on the DSL subject this question  
probably will seem strange, especially asking it now.


I have read quite a lot lately on the subject, most of it written by the  
great old ones, (come on guys you know whom I mean :)).


What I could gather from their papers was, that a DSL is basically  
something entirely abstract as such, ie. it allows you build and combine  
expressions in a language which is specific for your problem domain.
Irregardless of further details on how to do that, and there are quite a  
few, the crux as such is that they are abstract of "meaning".


The meaning depends how you *evaluate* the expression, which can be in  
more than merely one way, which is where, as far as I understand it, the  
true power lies.



So, you might wonder, since I figured it out this far, why ask what a DSL  
is?


Because out there I see quite a lot of stuff that is labeled as DSL, I  
mean for example packages on hackage, quite useuful ones too, where I  
don't see the split of assembling an expression tree from evaluating it,  
to me that seems more like combinator libraries.


Thus:

What is a DSL?


Günther


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

Re: [Haskell-cafe] better way to do this?

[Edward Z. Yang]

Excerpts from Ketil Malde's message of Wed Oct 07 05:13:19 -0400 2009:
> One could argue that IO should be broken down into a set of "sub-monads"
> encapsulating various subsets of the functionality - file system,
> network access, randomness, and so on.  This could extend the "safe
> spot" to cover much more computational real estate, and effectively
> sandbox programs in various ways.

You can approximate this using the Prompt monad.

http://hackage.haskell.org/packages/archive/MonadPrompt/1.0.0.1/doc/html/Control-Monad-Prompt.html

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

Re: [Haskell-cafe] What *is* a DSL?

[Emil Axelsson]

Hi,

A DSL is just a domain-specific language. It doesn't imply any specific 
implementation technique.


An *embedded* DSL is a library implemented in a more general language, 
which has been designed to give the "feeling" of a stand-alone language. 
Still nothing about implementation.


A *shallow embedding* of a DSL is when the "evaluation" is done 
immediately by the functions and combinators of the DSL. I don't think 
it's possible to draw a line between a combinator library and a 
shallowly embedded DSL.


A *deep embedding* is when interpretation is done on an intermediate 
data structure.


/ Emil



Günther Schmidt skrev:

Hi all,


for people that have followed my posts on the DSL subject this question 
probably will seem strange, especially asking it now.


I have read quite a lot lately on the subject, most of it written by the 
great old ones, (come on guys you know whom I mean :)).


What I could gather from their papers was, that a DSL is basically 
something entirely abstract as such, ie. it allows you build and combine 
expressions in a language which is specific for your problem domain.
Irregardless of further details on how to do that, and there are quite a 
few, the crux as such is that they are abstract of "meaning".


The meaning depends how you *evaluate* the expression, which can be in 
more than merely one way, which is where, as far as I understand it, the 
true power lies.



So, you might wonder, since I figured it out this far, why ask what a 
DSL is?


Because out there I see quite a lot of stuff that is labeled as DSL, I 
mean for example packages on hackage, quite useuful ones too, where I 
don't see the split of assembling an expression tree from evaluating it, 
to me that seems more like combinator libraries.


Thus:

What is a DSL?


Günther


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

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

Re: [Haskell-cafe] What *is* a DSL?

[Joe Fredette]

Let me add to this, as I've used the term "DSL" without (*gasp*) fully  
understanding it before.


In addition to "What is a DSL", I'd like to ask:

"How is a DSL different from an API?" -- in the sense that an API is a  
set of, say, combinators to filter email + a monad in which to combine  
them. Or even the API in the more traditional sense of the set of  
exposed operations on a given type. Is an API a kind of DSL? A kind of  
Embedded DSL?


Also,

"What is the difference between an EDSL and a DSL?" -- I've got a  
vague intuition of the difference, but am unsure how to particularly  
delineate them.


Also, any good introductory papers/books/other resources on DSLs and  
how to design, build and use them would be _lovely_.


/Joe

On Oct 7, 2009, at 11:10 AM, Günther Schmidt wrote:


Hi all,


for people that have followed my posts on the DSL subject this  
question probably will seem strange, especially asking it now.


I have read quite a lot lately on the subject, most of it written by  
the great old ones, (come on guys you know whom I mean :)).


What I could gather from their papers was, that a DSL is basically  
something entirely abstract as such, ie. it allows you build and  
combine expressions in a language which is specific for your problem  
domain.
Irregardless of further details on how to do that, and there are  
quite a few, the crux as such is that they are abstract of "meaning".


The meaning depends how you *evaluate* the expression, which can be  
in more than merely one way, which is where, as far as I understand  
it, the true power lies.



So, you might wonder, since I figured it out this far, why ask what  
a DSL is?


Because out there I see quite a lot of stuff that is labeled as DSL,  
I mean for example packages on hackage, quite useuful ones too,  
where I don't see the split of assembling an expression tree from  
evaluating it, to me that seems more like combinator libraries.


Thus:

What is a DSL?


Günther


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


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

Re: [Haskell-cafe] What *is* a DSL?

[Günther Schmidt]

Hi Emil,

now that is an interpretation I could live with!

Glad I posted the question.

Günther

Am 07.10.2009, 17:24 Uhr, schrieb Emil Axelsson :


Hi,

A DSL is just a domain-specific language. It doesn't imply any specific  
implementation technique.


An *embedded* DSL is a library implemented in a more general language,  
which has been designed to give the "feeling" of a stand-alone language.  
Still nothing about implementation.


A *shallow embedding* of a DSL is when the "evaluation" is done  
immediately by the functions and combinators of the DSL. I don't think  
it's possible to draw a line between a combinator library and a  
shallowly embedded DSL.


A *deep embedding* is when interpretation is done on an intermediate  
data structure.


/ Emil




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

Re: [Haskell-cafe] What *is* a DSL?

[Joe Fredette]

So, if I understand this:

Parsec is a DSL, I'm going to venture it's a "Deep embedding" -- I  
don't understand the internals, but if I were to build something like  
Parsec, I would probably build up a "Parser" datastructure and then  
apply optimizations to it, then "run" it with another function.


Am I on the right track here?

/Joe


On Oct 7, 2009, at 11:24 AM, Emil Axelsson wrote:


Hi,

A DSL is just a domain-specific language. It doesn't imply any  
specific implementation technique.


An *embedded* DSL is a library implemented in a more general  
language, which has been designed to give the "feeling" of a stand- 
alone language. Still nothing about implementation.


A *shallow embedding* of a DSL is when the "evaluation" is done  
immediately by the functions and combinators of the DSL. I don't  
think it's possible to draw a line between a combinator library and  
a shallowly embedded DSL.


A *deep embedding* is when interpretation is done on an intermediate  
data structure.


/ Emil



Günther Schmidt skrev:

Hi all,
for people that have followed my posts on the DSL subject this  
question probably will seem strange, especially asking it now.
I have read quite a lot lately on the subject, most of it written  
by the great old ones, (come on guys you know whom I mean :)).
What I could gather from their papers was, that a DSL is basically  
something entirely abstract as such, ie. it allows you build and  
combine expressions in a language which is specific for your  
problem domain.
Irregardless of further details on how to do that, and there are  
quite a few, the crux as such is that they are abstract of "meaning".
The meaning depends how you *evaluate* the expression, which can be  
in more than merely one way, which is where, as far as I understand  
it, the true power lies.
So, you might wonder, since I figured it out this far, why ask what  
a DSL is?
Because out there I see quite a lot of stuff that is labeled as  
DSL, I mean for example packages on hackage, quite useuful ones  
too, where I don't see the split of assembling an expression tree  
from evaluating it, to me that seems more like combinator libraries.

Thus:
What is a DSL?
Günther
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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


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

Re: [Haskell-cafe] What *is* a DSL?

[Günther Schmidt]

Hi Joe
Am 07.10.2009, 17:26 Uhr, schrieb Joe Fredette :

Let me add to this, as I've used the term "DSL" without (*gasp*) fully  
understanding it before.




Welcome to the club then! :)



In addition to "What is a DSL", I'd like to ask:

"How is a DSL different from an API?" -- in the sense that an API is a  
set of, say, combinators to filter email + a monad in which to combine  
them. Or even the API in the more traditional sense of the set of  
exposed operations on a given type. Is an API a kind of DSL? A kind of  
Embedded DSL?


Also,

"What is the difference between an EDSL and a DSL?" -- I've got a vague  
intuition of the difference, but am unsure how to particularly delineate  
them.


Well that part I think I can answer.

An EDSL is when you don't start from scratch. IE. when you do not, let's  
say build a compiler that parses a String and then eventually "executes"  
it.


Rather you define the "Terms", ie. primitive Terms (Terminals) and  
Non-Terminals with the means of the "host" language (Haskell in my case).





Also, any good introductory papers/books/other resources on DSLs and how  
to design, build and use them would be _lovely_.




Well as a book I could recommend Paul Hudaks "School of Expression". The  
way he abstracts is by means of using a DSL. He assembles objects,  
Geometrics Regions, Triangles, circles, squares etc. combines them with  
the help of functions and *later* evaluates them. Now he is definatly  
using a DSL here, but that is by no means the only way of implementing the  
abstract through a DSL. Once that has sunk in I suggest papers from Oleg  
and others on the subject, but to get started SOE would be a good idea.



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

Re: [Haskell-cafe] What *is* a DSL?

[minh thu]

Hi,

Some random observation:

A (E)DSL and an API fall on the same plane when they just expose
functionality of a library.

The difference between EDSL and a DSL is really just the E which means
embedded into a host language so the embedded language can be built on
top of some existing machinery, in Haskell typically the type system.

Haskell is particularly good for EDSL (but also Scheme or CL) because
the syntax of Haskell lets have a nice syntax for the embedded
language and the type system makes it possible to have, with more or
less simplicity, typing guarantees for the specifi language.

A regular expression library comprises often a regexp language, which
is considerd part of the API. That language is (or can be) parsed,
compiled and executed.

Some EDSL require to execute the Haskell program to output some
"object" code, others require only the execution of some function
equivalent to runState for the particular monad the EDSL uses.

Providing a specialised language on top of a library is quite common,
for instance command line tools to process images. Those command line
tool can later be used in some progreams (think scripting languages).
For instance, the "dot" program of the graphviz suite can be run with
unsafePerformIO to get graphviz features inside Haskell.

Parsing a String into some data structure is just a special case of
transforming some data structure into other data structure because it
easier to process that way. For instance HOAS into de Bruijn and vice
versa.

So for me, there is not a so strong distinction between API and language.

Cheers,
Thu

2009/10/7 Joe Fredette :
> Let me add to this, as I've used the term "DSL" without (*gasp*) fully
> understanding it before.
>
> In addition to "What is a DSL", I'd like to ask:
>
> "How is a DSL different from an API?" -- in the sense that an API is a set
> of, say, combinators to filter email + a monad in which to combine them. Or
> even the API in the more traditional sense of the set of exposed operations
> on a given type. Is an API a kind of DSL? A kind of Embedded DSL?
>
> Also,
>
> "What is the difference between an EDSL and a DSL?" -- I've got a vague
> intuition of the difference, but am unsure how to particularly delineate
> them.
>
> Also, any good introductory papers/books/other resources on DSLs and how to
> design, build and use them would be _lovely_.
>
> /Joe
>
> On Oct 7, 2009, at 11:10 AM, Günther Schmidt wrote:
>
>> Hi all,
>>
>>
>> for people that have followed my posts on the DSL subject this question
>> probably will seem strange, especially asking it now.
>>
>> I have read quite a lot lately on the subject, most of it written by the
>> great old ones, (come on guys you know whom I mean :)).
>>
>> What I could gather from their papers was, that a DSL is basically
>> something entirely abstract as such, ie. it allows you build and combine
>> expressions in a language which is specific for your problem domain.
>> Irregardless of further details on how to do that, and there are quite a
>> few, the crux as such is that they are abstract of "meaning".
>>
>> The meaning depends how you *evaluate* the expression, which can be in
>> more than merely one way, which is where, as far as I understand it, the
>> true power lies.
>>
>>
>> So, you might wonder, since I figured it out this far, why ask what a DSL
>> is?
>>
>> Because out there I see quite a lot of stuff that is labeled as DSL, I
>> mean for example packages on hackage, quite useuful ones too, where I don't
>> see the split of assembling an expression tree from evaluating it, to me
>> that seems more like combinator libraries.
>>
>> Thus:
>>
>> What is a DSL?
>>
>>
>> Günther
>>
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Num instances for 2-dimensional types

[Ben Franksen]

Daniel Fischer wrote:
> Am Montag 05 Oktober 2009 16:29:02 schrieb Job Vranish:
>> In what way is it not a number?
> 
> If there's a natural[1] implementation of fromInteger, good.
> If there isn't, *don't provide one*.
> fromInteger _ = error "Not sensible" is better than doing something
> strange.
> 
> [1] In the case of residue class rings, you may choose between restricting
> [the range of
> legitimate arguments for fromInteger or doing a modulo operation on the
> argument, both ways are natural and meet expectations sufficiently well.

More generally, any ring with multiplicative unit (let's call it 'one') will
do. If there were 'one' and 'zero' methods in class Num, we could even give
a default implementation (however inefficient) as

  fromInteger n | n < 0 = negate (fromInteger n)
  fromInteger n | n > 0 = one + fromInteger (n-1)
  fromInteger _ = zero

In fact, I'd argue that the existence of fromInteger in class Num "morally"
implies a unit for multiplication (namely 'fromInteger 1'), otherwise
fromInteger isn't even a ring morphism.

Cheers
Ben

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

Re: [Haskell-cafe] What *is* a DSL?

[Robert Atkey]

On Wed, 2009-10-07 at 11:32 -0400, Joe Fredette wrote:
> So, if I understand this:
> 
> Parsec is a DSL, I'm going to venture it's a "Deep embedding" -- I  
> don't understand the internals, but if I were to build something like  
> Parsec, I would probably build up a "Parser" datastructure and then  
> apply optimizations to it, then "run" it with another function.
> 
> Am I on the right track here?

Parsec, like most other parser combinator libraries, is a shallowly
embedded DSL. The "Parser a" type is a Haskell function that does
parsing, i.e. a function of type String -> Maybe (String, a).
(Obviously, the real Parsec library allows more than strings, and has
better error reporting than this type, but this is the basic idea).

You can't analyse it further---you can't transform it into another
grammar to optimise it or print it out---because the information about
what things it accepts has been locked up into a non-analysable Haskell
function. The only thing you can do with it is feed it input and see
what happens.

A deep embedding of a parsing DSL (really a context-sensitive grammar
DSL) would look something like the following. I think I saw something
like this in the Agda2 code somewhere, but I stumbled across it when I
was trying to work out what "free" applicative functors were.

First we define what a production with a semantic action is,
parameterised by the type of non-terminals in our grammar and the result
type:

> data Production nt a
>   =   Stopa
>   |   TerminalChar   (Production nt a)
>   | forall b. NonTerminal (nt b) (Production nt (b -> a))

You can think of a production as a list of either terminals or
non-terminals, terminated by the "value" of that production. The
non-regular nested type argument in NonTerminal means that the final
value can depend on the values that will be returned when parsing the
strings that match other non-terminals.

Productions are functors: 

> instance Functor (Production nt) where
> fmap f (Stop a)   = Stop (f a)
> fmap f (Terminal c p) = Expect c (fmap f p)
> fmap f (NonTerminal nt p) = NonTerminal nt (fmap (fmap f) p)

They are also applicative functors:

> instance Applicative (Production nt) where
> pure = Stop
> (Stop f)   <*> a = fmap f a
> (Terminal c t) <*> a = Terminal c (t <*> a)
> (NonTerminal nt t) <*> a = NonTerminal nt (fmap flip t <*> a)

A rule in one of our grammars is just a list of alternative productions:

> newtype Rule nt a = Rule [Production nt a]

Since lists are (applicative) functors and (applicative) functors
compose, Rule nt is also a Functor and Applicative functor:

> instance Functor (Rule nt) where
> fmap f (Rule l) = Rule (fmap (fmap f) l)

> instance Applicative (Rule nt) where
>pure x  = Rule $ pure (pure x)
>(Rule lf) <*> (Rule la) = Rule $ (<*>) <$> lf <*> la

It is also an instance of Alternative, because we composed with lists:

> instance Alternative (Rule nt) where
> empty   = Rule []
> (Rule r1) <|> (Rule r2) = Rule $ r1 <|> r2

A grammar is a map from nonterminals to rules, which are lists of
alternative productions, which may themselves refer back to nonterminals
in the grammar:

> type Grammar nt = forall a. nt a -> Rule nt a

Given a value of type "Grammar nt", and a starting nonterminal in "nt a"
for some "a", one can easily write a function that translates it into a
Parsec grammar to do actual parsing, or implement a different parsing
strategy using memoisation or something similar. The translation to a
traditional parser combinator library is actually a
(indexed-)homomorphism of applicative functors + extra operations, which
is pretty cool.

If you also know some extra facts about the "nt" type (e.g. that it is
finite), then it should be possible implement an CYK or Earley parser
using this, or to print out the grammar (for documentation purposes, or
for telling another node in a distributed network what things you
accept, for instance).

Note that these grammars are strictly less powerful than the ones that
can be expressed using Parsec because we only have a fixed range of
possibilities for each rule, rather than allowing previously parsed
input to determine what the parser will accept in the future. This is
the fundamental reason for using the applicative functor interface
rather than the monad interface here.


I'll give an example grammar for parsing expressions modelled by the
following data type:

> data Expr = ENum Int
>   | ESum Expr Expr
>   | EProduct Expr Expr
>   deriving Show

To define a grammar in this formalism, one first has to define the set
of nonterminals that one wants to use:

> data NT a where
>Value   :: NT Expr
>Product :: NT Expr
>Sum :: NT Expr

Now, a grammar is simply a function from members of this type to
productions. We use the applicative/alternative functor interface to
build up the productions. Conor's S

Re: [Haskell-cafe] What *is* a DSL?

[Dan Piponi]

2009/10/7 Joe Fredette :
> Let me add to this, as I've used the term "DSL" without (*gasp*) fully
> understanding it before.
>
> In addition to "What is a DSL", I'd like to ask:
>
> "How is a DSL different from an API?"

I don't think there is a sharp divide here. A nice example was given
by Pat Hanrahan at the recent nvidia GPU conference. He proposed the
idea that OpenGL was a DSL. His reasoning was that he could give a
formal grammar that accurately captured the structure of many
fragments of code making calls to OpenGL. For example you have blocks
of code bracketed by glBegin() and glEnd() with sequences of
primitives in between. In fact, some people indent their code to
reflect this structure as if glBegin() and glEnd() were control
structures within the host language.

I've argued that every monad gives a DSL. They all have the same
syntax - do-notation, but each choice of monad gives quite different
semantics for this notation. For example the list monad gives a DSL
for non-determinism.
--
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Network.Curl and posting XML data

[mf-hcafe-15c311f0c]

I stand corrected.  The answer was 'cabal install HsOpenSSL'.


On Wed, Oct 07, 2009 at 09:37:38PM +1100, Erik de Castro Lopo wrote:
> To: haskell-cafe@haskell.org
> From: Erik de Castro Lopo 
> Date: Wed, 7 Oct 2009 21:37:38 +1100
> Subject: Re: [Haskell-cafe] Network.Curl and posting XML data
> 
> mf-hcafe-15c311...@etc-network.de wrote:
> 
> > I am not aware of any SSL implementation in haskell either (even
> 
> I really find this rather surprising. Ocaml has a very decent wrapper
> around Openssl that works rather well so it can't be that hard.

Does this mean something that has been done in Ocaml can't be tedious
and/or difficult?

I'm just saying that openssl has a very complex (and IMHO not very
efficient) API, and that I am not at all certain whether writing a
wrapper is better for your project than adding the functionality you
need to Crypto.  But I may be wrong.


> > though I think it should go not into HTTP but into Crypto (which is a
> > neat piece of code, but needs a lot more work)).
> 
> But why shouldn't it should go into Network.HTTP? All I want to do
> is a HTTP POST of text/xml data to a HTTPS server and retrieve the
> text/xml data response and the HTTP response code. Whether that 
> URL is HTTP vs HTTPS shouldn't matter.
> 
> With a sane API I should just be able to change from a HTTP url to 
> a HTTPS url and have it JustWork (tm). To have to use a different
> library depending on whether I'm doing http vs https is just
> horrible.

As Magnus has pointed out (thanks), that's not what I mean.  I am just
saying that hacking SSL into an HTTP library is wrong, since SSL is
something different.  For instance, it is also commonly used for POP,
IMAP, SMTP, and generic TCP tunneling.


> > I can think of two "quick" solutions if you need your Haskell code to
> > use an SSL link: run stunnel.org
> 
> Sorry, thats way too cludgy for my application.
> 
> > and make your application connect to
> > that, or write a Haskell wrapper around openssl.org.
> 
> I've used openssl directly from C and C++ so  I know its doable, but
> I consider openssl a real blemish on the FOSS world.

agreed!


> There is however this:
> 
>
> http://hackage.haskell.org/packages/archive/HsOpenSSL/0.6.5/doc/html/OpenSSL-Session.html

I really should look at hackage next time I am about to claim
something doesn't exist.  I just assumed you already had.  :)

Anyway, until somebody finds the time to put all these little related
libraries together, this is probably what you want to use.


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

Re: [Haskell-cafe] What *is* a DSL?

[Don Stewart]

dpiponi:
> 2009/10/7 Joe Fredette :
> > Let me add to this, as I've used the term "DSL" without (*gasp*) fully
> > understanding it before.
> >
> > In addition to "What is a DSL", I'd like to ask:
> >
> > "How is a DSL different from an API?"
> 
> I don't think there is a sharp divide here. A nice example was given
> by Pat Hanrahan at the recent nvidia GPU conference. He proposed the
> idea that OpenGL was a DSL. His reasoning was that he could give a
> formal grammar that accurately captured the structure of many
> fragments of code making calls to OpenGL. For example you have blocks
> of code bracketed by glBegin() and glEnd() with sequences of
> primitives in between. In fact, some people indent their code to
> reflect this structure as if glBegin() and glEnd() were control
> structures within the host language.
> 
> I've argued that every monad gives a DSL. They all have the same
> syntax - do-notation, but each choice of monad gives quite different
> semantics for this notation. For example the list monad gives a DSL
> for non-determinism.

I've informally argued that a true DSL -- separate from a good API --
should have semantic characteristics of a language: binding forms,
control structures, abstraction, composition. Some have type systems.

Basic DSLs may only have a few charateristics of languages though -- a
(partial) grammar. That's closer to a well-defined API in my books.

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

Re: [Haskell-cafe] Calling Haskell from C, Linking with gcc?

[John Velman]

This is probably an Xcode problem now, rather than a strictly Haskell
problem.  

There are a bunch of libgmp.a and libgmp.dylib files in existence on this
computer, some in /usr/local/lib, or linked from there.

I've got my errors down to references in libgmp, whether or not I try to
include libgmp.a in the project.

Whenever I try to add libgmp.a, or libgmp.dylib to my project, I get the
error message:

--
ld warning: 
 in /Developer/SDKs/MacOSX10.5.sdk/usr/local/lib/libgmp.dylib, 
 file is not of required architecture
-

followed by a list of undefined symbols, all of which (well, all I've
checked!) are defined in the Haskell Platform version of libgmp.a

I'm sure there must be a way around this in the Xcode IDE, but haven't
found it.  I'll take the question to the Xcode mailing list.

Thanks to all for help on this.  I'll let you know how it works out!

Best,

John Velman



On Tue, Oct 06, 2009 at 07:56:07PM -0400, Brandon S. Allbery KF8NH wrote:
> On Oct 6, 2009, at 19:20 , John Velman wrote:
>>  HSghc-prim-0.1.0.0.o, HSinteger-0.1.0.1.o,   libffi.a,   libgmp.a,
>>  libHSbase-3.0.3.1.a,   libHSbase-3.0.3.1_p.a,   libHSbase-4.1.0.0.a,
>>  libHSghc-prim-0.1.0.0_p.a,   libHSrts.a
>
> Note that library order matters; libgmp.a should probably be last on the 
> command line.
>
> -- 
> 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
>
[previous messages snipped to save virtual paper]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] What *is* a DSL?

[Günther Schmidt]

Hi Don,


I've informally argued that a true DSL -- separate from a good API --
should have semantic characteristics of a language: binding forms,
control structures, abstraction, composition. Some have type systems.



That is one requirement that confuses me, abstraction.

I thought of DSLs as "special purpose" languages, ie. you give your DSL  
everything it needs for that purpose.


Why would it also need the ability to express even further abstractions,  
it is supposed to *be* the abstraction.


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

Re: [Haskell-cafe] What *is* a DSL?

[minh thu]

2009/10/7 Günther Schmidt :
> Hi Don,
>
>> I've informally argued that a true DSL -- separate from a good API --
>> should have semantic characteristics of a language: binding forms,
>> control structures, abstraction, composition. Some have type systems.
>>
>
> That is one requirement that confuses me, abstraction.
>
> I thought of DSLs as "special purpose" languages, ie. you give your DSL
> everything it needs for that purpose.
>
> Why would it also need the ability to express even further abstractions, it
> is supposed to *be* the abstraction.
>
> Günther
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

Hi,

Programming abstractions at the DSL level, not to further abstract
what the DSL covers.

Functions, for instance, are typical abstraction means offered by
programming languages. Even if your language is specific to some
domain, being able to create your own functions, and not only rely on
those provided by the DSL implementation, is important.

Imagine a (E)DSL for 3D programming (e.g. shading language): the
language is designed to fit well the problem (e.g. in this case, 3D
linear algebra, color operations, ...) but you'll agree it would be a
shame to not be able to provide your own functions.

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

[Haskell-cafe] Re: better way to do this?

[Ben Franksen]

Eugene Kirpichov wrote:
> Or you can use an effect system (however that doesn't give you the
> opportunity of overriding IO functions, but I think that providing
> such an opportunity with the means you suggest (splitting IO into many
> sub-monads) is not going to be usable in the large scale)
> 
> By the way, I am surprised that there seems to not exist any
> non-purely-academic language at all that supports effect systems!
> (except for Java's checked exceptions being a poor analogue). The only
> language with an effect system *and* a compiler that I know of is DDC,
> but it seems to be purely experimental.

What about ATS (http://www.ats-lang.org/)?

Ben

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

[Haskell-cafe] Re: What *is* a DSL?

[Ben Franksen]

minh thu wrote:
> 2009/10/7 Günther Schmidt :
>>> I've informally argued that a true DSL -- separate from a good API --
>>> should have semantic characteristics of a language: binding forms,
>>> control structures, abstraction, composition. Some have type systems.
>>>
>>
>> That is one requirement that confuses me, abstraction.
>>
>> I thought of DSLs as "special purpose" languages, ie. you give your DSL
>> everything it needs for that purpose.
>>
>> Why would it also need the ability to express even further abstractions,
>> it is supposed to *be* the abstraction.
>
> Programming abstractions at the DSL level, not to further abstract
> what the DSL covers.
> 
> Functions, for instance, are typical abstraction means offered by
> programming languages. Even if your language is specific to some
> domain, being able to create your own functions, and not only rely on
> those provided by the DSL implementation, is important.
> 
> Imagine a (E)DSL for 3D programming (e.g. shading language): the
> language is designed to fit well the problem (e.g. in this case, 3D
> linear algebra, color operations, ...) but you'll agree it would be a
> shame to not be able to provide your own functions.

But isn't one of the advantages of an _E_DSL that we can use the host
language (Haskell) as a meta or macro language for the DSL? I would think
that this greatly reduces the need to provide abstraction
facilities /inside/ the DSL. In fact most existing (and often cited
examples of) EDSLs in Haskell do not provide abstraction.

Cheers
Ben

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

Re: [Haskell-cafe] Re: What *is* a DSL?

[John Van Enk]

On Wed, Oct 7, 2009 at 2:52 PM, Ben Franksen

>
> But isn't one of the advantages of an _E_DSL that we can use the host
> language (Haskell) as a meta or macro language for the DSL?
>

Substantially so. I've used brief examples where the EDSL syntax is
basically the data declaration (perhaps with some operators overloading
constructors) to demonstrate Haskell's fitness as a host language for EDSLs.

This is also a credit to the expressiveness of Haskell's data declarations.

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

Re: [Haskell-cafe] Re: What *is* a DSL?

[minh thu]

2009/10/7 Ben Franksen :
> minh thu wrote:
>> 2009/10/7 Günther Schmidt :
 I've informally argued that a true DSL -- separate from a good API --
 should have semantic characteristics of a language: binding forms,
 control structures, abstraction, composition. Some have type systems.

>>>
>>> That is one requirement that confuses me, abstraction.
>>>
>>> I thought of DSLs as "special purpose" languages, ie. you give your DSL
>>> everything it needs for that purpose.
>>>
>>> Why would it also need the ability to express even further abstractions,
>>> it is supposed to *be* the abstraction.
>>
>> Programming abstractions at the DSL level, not to further abstract
>> what the DSL covers.
>>
>> Functions, for instance, are typical abstraction means offered by
>> programming languages. Even if your language is specific to some
>> domain, being able to create your own functions, and not only rely on
>> those provided by the DSL implementation, is important.
>>
>> Imagine a (E)DSL for 3D programming (e.g. shading language): the
>> language is designed to fit well the problem (e.g. in this case, 3D
>> linear algebra, color operations, ...) but you'll agree it would be a
>> shame to not be able to provide your own functions.
>
> But isn't one of the advantages of an _E_DSL that we can use the host
> language (Haskell) as a meta or macro language for the DSL?

It is.

> I would think
> that this greatly reduces the need to provide abstraction
> facilities /inside/ the DSL. In fact most existing (and often cited
> examples of) EDSLs in Haskell do not provide abstraction.

Even when you have good macro supports, you don't code everything at
the macro level. But it all depends on the particular EDSL we talk
about. If the EDSL is close to a regular programming language, it is
likely to provide the ability to create functions.

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

Re: [Haskell-cafe] What *is* a DSL?

[Robert Atkey]

> What is a DSL?

How about this as a formal-ish definition, for at least a pretty big
class of DSLs:

A DSL is an algebraic theory in the sense of universal algebra. I.e. it
is an API of a specific form, which consists of:
  a) a collection of abstract types, the carriers. Need not all be of 
 kind *.
  b) a collection of operations, of type 
 t1 -> t2 -> ... -> tn
 where tn must be one of the carrier types from (a), but the others 
 can be any types you like.
  c) (Optional) a collection of properties about the operations (e.g. 
 equations that must hold)

Haskell has a nice way of specifying such things (except part (c)): type
classes.

Examples of type classes that fit this schema include Monad, Applicative
and Alternative. Ones that don't include Eq, Ord and Show. The Num type
class would be, if it didn't specify Eq and Show as superclasses.

An implementation of a DSL is just an implementation of corresponding
type class. Shallowly embedded DSLs dispense with the type class step
and just give a single implementation. Deeply embedded implementations
are *initial* implementations: there is a unique function from the deep
embedding to any of the other implementations that preserves all the
operations. The good thing about this definition is that anything we do
to the deep embedding, we can do to any of the other implementations via
the unique map.

Thanks to Church and Reynolds, we can always get a deep embedding for
free (free as in "Theorems for Free"). If our DSL is defined by some
type class T, then the deep embedding is:
   type DeepT = forall a. T a => a
(and so on, for multiple carrier types, possibly with type
parameterisation).

Of course, there is often an easier and more efficient way of
representing the initial algebra using algebraic data types.

Conor McBride often goes on about how the initial algebra (i.e. the deep
embedding) of a given specification is the one you should be worrying
about, because it often has a nice concrete representation and gives you
all you need to reason about any of the other implementations.

Bob


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

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

Re: [Haskell-cafe] Finally tagless - stuck with implementation of "lam"

[Robert Atkey]

On Mon, 2009-10-05 at 19:22 -0400, David Menendez wrote:
> > The two obvious options are
> > call-by-name and call-by-value.
> 
> I wonder how easily one can provide both, like in Algol.

Fairly easy, you can either do a language that has an explicit monad (a
bit like Haskell with only the IO monad), or you can go the whole hog
and embed Paul Levy's Call-by-push-value. This requires a bit more
cleverness, and an explicit representation of the embedded types in
order to define the algebra maps on the computation types.

> Obviously, doing a deterministic version is simpler. You can probably
> get away with representing values as simple self-evaluating thunks.
> 
> data Thunk s a = STRef s (Either a (ST s a))
> 
> evalThunk :: Thunk s a -> ST s a
> evalThunk r = readSTRef r >>= either return update
> where
> update m = m >>= \x -> writeSTRef r (Left x) >> return x

I had a go at this and it seems to work. Happily, it is a tiny tweak to
the CBV implementation I gave: you just replace "return" with your
"evalThunk" (or something like it) and wrap the argument in the 'app'
case with a function that creates a thunk.

Bob



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

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

Re: [Haskell-cafe] Re: Finally tagless - stuck with implementation of?"lam"

[Robert Atkey]

On Mon, 2009-10-05 at 22:06 -0400, Chung-chieh Shan wrote:
> Robert Atkey  wrote in article 
> <1254778973.3675.42.ca...@bismuth> in gmane.comp.lang.haskell.cafe:
> > To implement the translation of embedded language types to Haskell types
> > in Haskell we use type families.
> 
> This type-to-type translation is indeed the crux of the trickiness.  By
> the way, Section 4.3 of our (JFP) paper describes how to follow such a
> translation without type families.  If I were to avoid type families in
> Haskell, I would make Symantics into a multiparameter type class

Yes, this is another way to do it. I prefer having an explicit
representation of the types of the embedded language though. For one,
the multi-parameter type classes get a bit unwieldy if you have lots of
types in your embedded language. Also, sometimes you might want to do
special things with the denotations of each type. For instance, I did an
embedding of Levy's CBPV, where the type system is split into value
types and computation types. For the computation types X there is always
an algebra map of type m [[ X ]] -> [[ X ]]. To define this I needed a
term level representative of the type, and also the type family to give
the semantics of the embedded type. I don't know if this is easily done
using multi-parameter type classes.

> > The underlying problem with the implementation of 'lam' is that 
> > you have to pick an evaluation order for the side effects you want in
> > the semantics of your embedded language. The two obvious options are
> > call-by-name and call-by-value.
> 
> (Section 5 of our (JFP) paper addresses both CBN and CBV.)

Yes, thanks for reminding me. I vaguely remembered when I went to bed
after posting that you had done something via Plotkin's CPS
transformations. I rather like the direct approach though; sometimes it
is nice not to have to solve every problem by hitting it with the
continuations hammer ;).

Bob


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

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

[Haskell-cafe] RE: [Haskell] ANNOUNCE: GPipe-1.0.0: A functional graphics API for programmable GPUs

[Tobias Bexelius]

Hi Petr,
 
Your question is completely justified! Yes, I beleive GPipe is a good 
foundation for such GPGPU-computations (general purpose GPU-programming), 
giving you easy access to data parallelism.
 
A way of doing this is to start with one or more equally sized textures that is 
your input (1 component depth textures perserves most floating point precision) 
. Then you rasterize a quad that covers the entire FrameBuffer, and for each 
fragment point sample these input textures and perform some computation on the 
samples. The resulting framebuffer can then be converted to a normal list in 
main memory, or converted to another texture to be used as input in another 
pass. 
 
To gather data, e.g. sum up all values in a texture, you could make a fragment 
program that uses a half-sized quad in which you sample two parts of the 
texture which you add and return in a half-sized texture. If you repeat this 
log2 texturesize times, you end up with one single value that is the sum of all 
values.
 
All texture loading and retrieving functions in GPipe are in IO, but safe to 
wrap in unsafePerformIO as long as you guarantee that the Ptr's are safe. So I 
think its easy to modularize GPGPU computations in GPipe and for instance 
create something like:
> simpleGPUmap :: (Fragment Float -> Fragment Float) -> [Float] -> [Float]
 
So, why dont you have a go on it? It might just turn out to be a pretty useful 
library... ;)
 
 
Cheers
/Tobias
 
 
 
> Date: Wed, 7 Oct 2009 16:47:15 +0200
> From: d...@pudlak.name
> To: tobias_bexel...@hotmail.com
> CC: haskell-cafe@haskell.org
> Subject: Re: [Haskell] ANNOUNCE: GPipe-1.0.0: A functional graphics API for 
> programmable GPUs
> 
> Hi Tobias,
> 
> (I'm completely new to GPU programming, so my question may be completely
> stupid or unrelated. Please be patient :-).)
> 
> Some time ago I needed to perform some large-scale computations
> (searching for first-order logic models) and a friend told me that GPUs
> can be used to perform many simple computations in parallel. Could GPipe
> be used for such a task? I.e. to program some non-graphical,
> parallelized algorithm, which could be run on a GPU cluster?
> 
> Thanks for your answer,
> 
> Petr
> 
> On Sun, Oct 04, 2009 at 08:32:56PM +0200, Tobias Bexelius wrote:
> > I'm proud to announce the first release of GPipe-1.0.0: A functional 
> > graphics
> > API for programmable GPUs.
> > 
> > GPipe models the entire graphics pipeline in a purely functional, immutable
> > and typesafe way. It is built on top of the programmable pipeline (i.e.
> > non-fixed function) of OpenGL 2.1 and uses features such as vertex buffer
> > objects (VBO's), texture objects and GLSL shader code synthetisation to 
> > create
> > fast graphics programs. Buffers, textures and shaders are cached internally 
> > to
> > ensure fast framerate, and GPipe is also capable of managing multiple 
> > windows
> > and contexts. By creating your own instances of GPipes classes, it's 
> > possible
> > to use additional datatypes on the GPU.
> > 
> > You'll need full OpenGL 2.1 support, including GLSL 1.20 to use GPipe. 
> > Thanks
> > to OpenGLRaw, you may still build GPipe programs on machines lacking this
> > support.
> > 
> > The package, including full documentation, can be found at:
> > http://hackage.haskell.org/package/GPipe-1.0.0
> > 
> > Of course, you may also install it with:
> > cabal install gpipe
> > 
> > 
> > Cheers!
> > Tobias Bexelius
> > 
> > ━━
> > kolla in resten av Windows LiveT. Inte bara e-post - Windows LiveT är mycket
> > mer än din inkorg. Mer än bara meddelanden







Windows Live: Håll dina vänner uppdaterade om vad du gör online.
  
_
Hitta kärleken nu i vår!
http://dejting.se.msn.com/channel/index.aspx?trackingid=1002952___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Finally tagless - stuck with implementation of "lam"

[Robert Atkey]

On Mon, 2009-10-05 at 22:42 +0100, Robert Atkey wrote:

> There is a difference in the syntax between CBN and CBV that is not
> always obvious from the usual paper presentations. There is a split
> between pieces of syntax that are "values" and those that are
> "computations". Values do not have side-effects, while computations may.
> In this presentation, I have chosen that the only values are variables,
> while everything else is a computation.
> 

I should correct this: it is possible to give the CBV semantics to the
original syntax definition (with the single parameter in the type
class), you just have to move the "return" of the monad into the "lam"
case. I implied in the paragraph above that the split between values and
computations was required for CBV case; this is not true.

Bob


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

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

Re: [Haskell-cafe] Re: What *is* a DSL?

[Emil Axelsson]

Ben Franksen skrev:

minh thu wrote:

2009/10/7 Günther Schmidt :

I've informally argued that a true DSL -- separate from a good API --
should have semantic characteristics of a language: binding forms,
control structures, abstraction, composition. Some have type systems.


That is one requirement that confuses me, abstraction.

I thought of DSLs as "special purpose" languages, ie. you give your DSL
everything it needs for that purpose.

Why would it also need the ability to express even further abstractions,
it is supposed to *be* the abstraction.

Programming abstractions at the DSL level, not to further abstract
what the DSL covers.

Functions, for instance, are typical abstraction means offered by
programming languages. Even if your language is specific to some
domain, being able to create your own functions, and not only rely on
those provided by the DSL implementation, is important.

Imagine a (E)DSL for 3D programming (e.g. shading language): the
language is designed to fit well the problem (e.g. in this case, 3D
linear algebra, color operations, ...) but you'll agree it would be a
shame to not be able to provide your own functions.


But isn't one of the advantages of an _E_DSL that we can use the host
language (Haskell) as a meta or macro language for the DSL? I would think
that this greatly reduces the need to provide abstraction
facilities /inside/ the DSL. In fact most existing (and often cited
examples of) EDSLs in Haskell do not provide abstraction.


I would say that the DSL is what the user sees. In this view, I think 
it's correct to say that many (or most) DSLs need function abstraction. 
Whether or not the internal data structure has function abstraction is 
an implementation detail.


/ Emil


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

Re: [Haskell-cafe] Re: Num instances for 2-dimensional types

[David Menendez]

On Wed, Oct 7, 2009 at 12:08 PM, Ben Franksen  wrote:
>
> More generally, any ring with multiplicative unit (let's call it 'one') will
> do.

Isn't that every ring? As I understand it, the multiplication in a
ring is required to form a monoid.

-- 
Dave Menendez 

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

Re: [Haskell-cafe] Re: Num instances for 2-dimensional types

[Joe Fredette]

A ring is an abelian group in addition, with the added operation (*)  
being distributive over addition, and 0 annihilating under  
multiplication. (*) is also associative. Rings don't necessarily need  
_multiplicative_ id, only _additive_ id. Sometimes Rings w/o ID is  
called a Rng (a bit of a pun).


/Joe


On Oct 7, 2009, at 4:41 PM, David Menendez wrote:

On Wed, Oct 7, 2009 at 12:08 PM, Ben Franksen  
 wrote:


More generally, any ring with multiplicative unit (let's call it  
'one') will

do.


Isn't that every ring? As I understand it, the multiplication in a
ring is required to form a monoid.

--
Dave Menendez 

___
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] New to Haskell - List Comprehension Question

[Steven1990]

Hi, I'm currently learning Haskell, and I've been trying to work out a
function for the following problem for a couple of days now. 

I want to use a list comprehension method to change the first letter of a
string to upper case, and the rest of the string to lower case. 

Eg: "heLLo" -> "Hello" 

As I'm trying to learn this, I would appreciate hints rather than the
explicit solution if possible? I'm sure I'm close to a solution, I must be
missing something though. Driving me crazy! 

My attempts are something similar to this: 

upperCase :: String -> String 
upperCase xs = [toUpper(x):toLower(xs) | x <- xs] 

I think 'toLower' expects a single character rather than the list which is
one place I'm going wrong? 

Thanks in advance, 
Steven
-- 
View this message in context: 
http://www.nabble.com/New-to-Haskell---List-Comprehension-Question-tp25794144p25794144.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] New to Haskell - List Comprehension Question

[Ross Mellgren]

I don't think a list comprehension is the easiest way to do it, how  
about


upperCase :: String -> String
upperCase [] = []
upperCase (x:xs) = toUpper x : map toLower xs

-Ross

On Oct 7, 2009, at 4:48 PM, Steven1990 wrote:



Hi, I'm currently learning Haskell, and I've been trying to work out a
function for the following problem for a couple of days now.

I want to use a list comprehension method to change the first letter  
of a

string to upper case, and the rest of the string to lower case.

Eg: "heLLo" -> "Hello"

As I'm trying to learn this, I would appreciate hints rather than the
explicit solution if possible? I'm sure I'm close to a solution, I  
must be

missing something though. Driving me crazy!

My attempts are something similar to this:

upperCase :: String -> String
upperCase xs = [toUpper(x):toLower(xs) | x <- xs]

I think 'toLower' expects a single character rather than the list  
which is

one place I'm going wrong?

Thanks in advance,
Steven
--
View this message in context: 
http://www.nabble.com/New-to-Haskell---List-Comprehension-Question-tp25794144p25794144.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com 
.


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


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

Re: [Haskell-cafe] New to Haskell - List Comprehension Question

[Gregory Crosswhite]

Hint:  Move the boundary case outside the comprehension, and then use  
the comprehension to handle the normal case.


Also, FYI, a comprehension feeds each value of the list xs into x, and  
then evaluates the expression to the left of the pipe with that single  
value of x.


Cheers,
Greg


On Oct 7, 2009, at 1:48 PM, Steven1990 wrote:



Hi, I'm currently learning Haskell, and I've been trying to work out a
function for the following problem for a couple of days now.

I want to use a list comprehension method to change the first letter  
of a

string to upper case, and the rest of the string to lower case.

Eg: "heLLo" -> "Hello"

As I'm trying to learn this, I would appreciate hints rather than the
explicit solution if possible? I'm sure I'm close to a solution, I  
must be

missing something though. Driving me crazy!

My attempts are something similar to this:

upperCase :: String -> String
upperCase xs = [toUpper(x):toLower(xs) | x <- xs]

I think 'toLower' expects a single character rather than the list  
which is

one place I'm going wrong?

Thanks in advance,
Steven
--
View this message in context: 
http://www.nabble.com/New-to-Haskell---List-Comprehension-Question-tp25794144p25794144.html
Sent from the Haskell - Haskell-Cafe mailing list archive at  
Nabble.com.


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


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

[Haskell-cafe] random question

[Michael Mossey]

My thread about randomness got hijacked so I need to restate my remaining 
question here. Is it acceptable to write pure routines that use but do not 
return generators, and then call several of them from an IO monad with a 
generator obtained by several calls to newStdGen?


shuffle :: RandomGen g => g -> [a] -> [a]
shuffle = ...

foo :: [a] -> [a] -> IO ()
foo xs ys = do
  g1 <- newStdGen
  print $ shuffle g1 xs
  g2 <- newStdGen
  print $ shuffle g2 ys

Does this kind of thing exhibit good pseudorandomness?

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

Re: [Haskell-cafe] random question

[Luke Palmer]

On Wed, Oct 7, 2009 at 2:59 PM, Michael Mossey  wrote:
> My thread about randomness got hijacked so I need to restate my remaining
> question here. Is it acceptable to write pure routines that use but do not
> return generators, and then call several of them from an IO monad with a
> generator obtained by several calls to newStdGen?

It's gross.  What if you don't want IO as part of this computation?

If you have a random generator that supports splitting (something
rather hard to do from what I understand), I prefer not to return the
new generator but instead to split it.  So, using your shuffle:

> shuffle :: RandomGen g => g -> [a] -> [a]
> shuffle = ...

foo :: RandomGen g => [a] -> [a] -> g -> ([a],[a])
foo xs ys gen =
  let (gen1, gen2) = split gen in
  (shuffle gen1 xs, shuffle gen2 ys)

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

Re: [Haskell-cafe] New to Haskell - List Comprehension Question

[minh thu]

2009/10/7 Steven1990 :
>
> Hi, I'm currently learning Haskell, and I've been trying to work out a
> function for the following problem for a couple of days now.
>
> I want to use a list comprehension method to change the first letter of a
> string to upper case, and the rest of the string to lower case.
>
> Eg: "heLLo" -> "Hello"
>
> As I'm trying to learn this, I would appreciate hints rather than the
> explicit solution if possible? I'm sure I'm close to a solution, I must be
> missing something though. Driving me crazy!
>
> My attempts are something similar to this:
>
> upperCase :: String -> String
> upperCase xs = [toUpper(x):toLower(xs) | x <- xs]
>
> I think 'toLower' expects a single character rather than the list which is
> one place I'm going wrong?

Hi,

try to work little things by little things:

$ ghci
Prelude> let f xs = [x:xs | x <- xs]
Prelude> f "hello"
["hhello","ehello","lhello","lhello","ohello"]
Prelude>

Prelude> :m + Data.Char
Prelude Data.Char> :t toLower
toLower :: Char -> Char
Prelude Data.Char> :t toUpper
toUpper :: Char -> Char
Prelude Data.Char>

So xs is the whole list (the "hello" part of each element in the
resilt of f "hello") and x gets the value of each character. toLower
and toUpper have the same type; indeed toLower expects a single
character while you feed it a list.

The part on the left of the pipe is "executed" for each x drawn from
the xs list. This means that if you want to make something specific to
the first element of xs, you have to provide more information: the x
alone is not enough to know it is the first one or not.

The easiest way to do that is with pattern matching on the upperCase argument:
upperCase (x:xs) = ...

(Don't forget for the "other" case, the empty list:
upperCase [] = ...)

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

Re: [Haskell-cafe] random question

[Bryan O'Sullivan]

On Wed, Oct 7, 2009 at 1:59 PM, Michael Mossey wrote:

> My thread about randomness got hijacked so I need to restate my remaining
> question here. Is it acceptable to write pure routines that use but do not
> return generators, and then call several of them from an IO monad with a
> generator obtained by several calls to newStdGen?
>
> shuffle :: RandomGen g => g -> [a] -> [a]
> shuffle = ...
>
> foo :: [a] -> [a] -> IO ()
> foo xs ys = do
>  g1 <- newStdGen
>  print $ shuffle g1 xs
>  g2 <- newStdGen
>  print $ shuffle g2 ys
>
> Does this kind of thing exhibit good pseudorandomness?
>

If you believe in the safety of the split operation (which I don't), then
yes, since use of it is what's happening behind the scenes. In other words,
provided you're a faithful sort and split doesn't make you squirm too much,
you don't need to plug all that ugly IO in there.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] random question

[Michael Mossey]

Luke Palmer wrote:

On Wed, Oct 7, 2009 at 2:59 PM, Michael Mossey  wrote:

My thread about randomness got hijacked so I need to restate my remaining
question here. Is it acceptable to write pure routines that use but do not
return generators, and then call several of them from an IO monad with a
generator obtained by several calls to newStdGen?


It's gross.  What if you don't want IO as part of this computation?



I don't quite follow your response. I want a program that initializes the 
generator from the global generator because I want different behavior every 
time I run it. So it will need IO. That's what I was trying to demonstrate. 
And I was wondering if one can get around the difficulty of passing the 
generator from call to call by using newStdGen in this way.


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

[solved] Re: [Haskell-cafe] Calling Haskell from C, Linking with gcc?

[John Velman]

For anyone following this:  The XCode ld script is complex, and has mac
specific defaults early in the search path specification, and I probably
don't want to change these.  A library in a default path is the wrong
libgmp.[dylib | a].  

My solution:
do a

ln -s libgmp.a lib-h-gmp.a 

in the /Library/Frameworks/GHC.Framework//usr/lib folder.

Then add lib-h-gmp.a to my Xcode project.

Compiled, linked, and ran and got the right output.

Thanks to everyone who helped.

John V.

On Wed, Oct 07, 2009 at 10:38:53AM -0700, John Velman wrote:
> This is probably an Xcode problem now, rather than a strictly Haskell
> problem.  
> 
> There are a bunch of libgmp.a and libgmp.dylib files in existence on this
> computer, some in /usr/local/lib, or linked from there.
> 
> I've got my errors down to references in libgmp, whether or not I try to
> include libgmp.a in the project.
> 
> Whenever I try to add libgmp.a, or libgmp.dylib to my project, I get the
> error message:
> 
> --
> ld warning: 
>  in /Developer/SDKs/MacOSX10.5.sdk/usr/local/lib/libgmp.dylib, 
>  file is not of required architecture
> -
> 
> followed by a list of undefined symbols, all of which (well, all I've
> checked!) are defined in the Haskell Platform version of libgmp.a
> 
> I'm sure there must be a way around this in the Xcode IDE, but haven't
> found it.  I'll take the question to the Xcode mailing list.
> 
> Thanks to all for help on this.  I'll let you know how it works out!
> 
> Best,
> 
> John Velman
> 
> 
> 
> On Tue, Oct 06, 2009 at 07:56:07PM -0400, Brandon S. Allbery KF8NH wrote:
> > On Oct 6, 2009, at 19:20 , John Velman wrote:
> >>  HSghc-prim-0.1.0.0.o, HSinteger-0.1.0.1.o,   libffi.a,   libgmp.a,
> >>  libHSbase-3.0.3.1.a,   libHSbase-3.0.3.1_p.a,   libHSbase-4.1.0.0.a,
> >>  libHSghc-prim-0.1.0.0_p.a,   libHSrts.a
> >
> > Note that library order matters; libgmp.a should probably be last on the 
> > command line.
> >
> > -- 
> > 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
> >
> [previous messages snipped to save virtual paper]
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Num instances for 2-dimensional types

[Daniel Fischer]

Am Mittwoch 07 Oktober 2009 22:44:19 schrieb Joe Fredette:
> A ring is an abelian group in addition, with the added operation (*)
> being distributive over addition, and 0 annihilating under
> multiplication. (*) is also associative. Rings don't necessarily need
> _multiplicative_ id, only _additive_ id. Sometimes Rings w/o ID is
> called a Rng (a bit of a pun).
>
> /Joe

In my experience, the definition of a ring more commonly includes the 
multiplicative 
identity and abelian groups with an associative multiplication which 
distributes over 
addition are called semi-rings.

There is no universally employed definition (like for natural numbers, is 0 
included or 
not; fields, is the commutativity of multiplication part of the definition or 
not; 
compactness, does it include Hausdorff or not; ...).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Num instances for 2-dimensional types

[Joe Fredette]

I was just quoting from Hungerford's Undergraduate text, but yes, the  
"default ring" is in {Rng, Ring}, I haven't heard semirings used in  
the sense of a Rng. I generally find semirings defined as a ring  
structure without additive inverse and with 0-annihilation (which one  
has to assume in the case of SRs, I included it in my previous  
definition because I wasn't sure if I could prove it via the axioms, I  
think it's possible, but I don't recall the proof).


Wikipedia seems to agree with your definition, though it does have a  
note which says some authors use the definition of Abelian Group +  
Semigroup (my definition) as opposed to Abelian Group + Monoid (your  
defn).


Relevant:

http://en.wikipedia.org/wiki/Semiring
http://en.wikipedia.org/wiki/Ring_(algebra)
http://en.wikipedia.org/wiki/Ring_(algebra)#Notes_on_the_definition

/Joe

On Oct 7, 2009, at 5:41 PM, Daniel Fischer wrote:


Am Mittwoch 07 Oktober 2009 22:44:19 schrieb Joe Fredette:

A ring is an abelian group in addition, with the added operation (*)
being distributive over addition, and 0 annihilating under
multiplication. (*) is also associative. Rings don't necessarily need
_multiplicative_ id, only _additive_ id. Sometimes Rings w/o ID is
called a Rng (a bit of a pun).

/Joe


In my experience, the definition of a ring more commonly includes  
the multiplicative
identity and abelian groups with an associative multiplication which  
distributes over

addition are called semi-rings.

There is no universally employed definition (like for natural  
numbers, is 0 included or
not; fields, is the commutativity of multiplication part of the  
definition or not;

compactness, does it include Hausdorff or not; ...).
___
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] random question

[Daniel Fischer]

Am Mittwoch 07 Oktober 2009 23:28:59 schrieb Michael Mossey:
> Luke Palmer wrote:
> > On Wed, Oct 7, 2009 at 2:59 PM, Michael Mossey  
> > wrote:
> >> My thread about randomness got hijacked so I need to restate my
> >> remaining question here. Is it acceptable to write pure routines that
> >> use but do not return generators, and then call several of them from an
> >> IO monad with a generator obtained by several calls to newStdGen?
> >
> > It's gross.  What if you don't want IO as part of this computation?
>
> I don't quite follow your response. I want a program that initializes the
> generator from the global generator because I want different behavior every
> time I run it. So it will need IO. That's what I was trying to demonstrate.
> And I was wondering if one can get around the difficulty of passing the
> generator from call to call by using newStdGen in this way.
>
> Mike

Documentation says:

newStdGen :: IO StdGen
Applies split to the current global random generator, updates it with one of 
the results, 
and returns the other.

So it's as safe as split is.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] New to Haskell - List Comprehension Question

[michael rice]

Try just writing a function that will change ALL the characters to uppercase 
(or lower case) using list comprehension and then see if you can isolate how to 
factor out the special case of the first character.

Michael

--- On Wed, 10/7/09, minh thu  wrote:

From: minh thu 
Subject: Re: [Haskell-cafe] New to Haskell - List Comprehension Question
To: "Steven1990" 
Cc: haskell-cafe@haskell.org
Date: Wednesday, October 7, 2009, 5:20 PM

2009/10/7 Steven1990 :
>
> Hi, I'm currently learning Haskell, and I've been trying to work out a
> function for the following problem for a couple of days now.
>
> I want to use a list comprehension method to change the first letter of a
> string to upper case, and the rest of the string to lower case.
>
> Eg: "heLLo" -> "Hello"
>
> As I'm trying to learn this, I would appreciate hints rather than the
> explicit solution if possible? I'm sure I'm close to a solution, I must be
> missing something though. Driving me crazy!
>
> My attempts are something similar to this:
>
> upperCase :: String -> String
> upperCase xs = [toUpper(x):toLower(xs) | x <- xs]
>
> I think 'toLower' expects a single character rather than the list which is
> one place I'm going wrong?

Hi,

try to work little things by little things:

$ ghci
Prelude> let f xs = [x:xs | x <- xs]
Prelude> f "hello"
["hhello","ehello","lhello","lhello","ohello"]
Prelude>

Prelude> :m + Data.Char
Prelude Data.Char> :t toLower
toLower :: Char -> Char
Prelude Data.Char> :t toUpper
toUpper :: Char -> Char
Prelude Data.Char>

So xs is the whole list (the "hello" part of each element in the
resilt of f "hello") and x gets the value of each character. toLower
and toUpper have the same type; indeed toLower expects a single
character while you feed it a list.

The part on the left of the pipe is "executed" for each x drawn from
the xs list. This means that if you want to make something specific to
the first element of xs, you have to provide more information: the x
alone is not enough to know it is the first one or not.

The easiest way to do that is with pattern matching on the upperCase argument:
upperCase (x:xs) = ...

(Don't forget for the "other" case, the empty list:
upperCase [] = ...)

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



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

Re: [Haskell-cafe] Re: Num instances for 2-dimensional types

[Daniel Fischer]

Am Mittwoch 07 Oktober 2009 23:51:54 schrieb Joe Fredette:
> I was just quoting from Hungerford's Undergraduate text, but yes, the
> "default ring" is in {Rng, Ring}, I haven't heard semirings used in
> the sense of a Rng.

It's been looong ago, I seem to have misremembered :?
But there used to be a german term for Rngs, and it was neither Pseudoring nor 
quasiring, 
so I thought it was Halbring.

> I generally find semirings defined as a ring
> structure without additive inverse and with 0-annihilation (which one
> has to assume in the case of SRs, I included it in my previous
> definition because I wasn't sure if I could prove it via the axioms, I
> think it's possible, but I don't recall the proof).

0*x = (0+0)*x = 0*x + 0*x ==> 0*x = 0

>
> Wikipedia seems to agree with your definition, though it does have a
> note which says some authors use the definition of Abelian Group +
> Semigroup (my definition) as opposed to Abelian Group + Monoid (your
> defn).
>
> Relevant:
>
> http://en.wikipedia.org/wiki/Semiring
> http://en.wikipedia.org/wiki/Ring_(algebra)
> http://en.wikipedia.org/wiki/Ring_(algebra)#Notes_on_the_definition
>
> /Joe
>
> On Oct 7, 2009, at 5:41 PM, Daniel Fischer wrote:
> > Am Mittwoch 07 Oktober 2009 22:44:19 schrieb Joe Fredette:
> >> A ring is an abelian group in addition, with the added operation (*)
> >> being distributive over addition, and 0 annihilating under
> >> multiplication. (*) is also associative. Rings don't necessarily need
> >> _multiplicative_ id, only _additive_ id. Sometimes Rings w/o ID is
> >> called a Rng (a bit of a pun).
> >>
> >> /Joe
> >
> > In my experience, the definition of a ring more commonly includes
> > the multiplicative
> > identity and abelian groups with an associative multiplication which
> > distributes over
> > addition are called semi-rings.
> >
> > There is no universally employed definition (like for natural
> > numbers, is 0 included or
> > not; fields, is the commutativity of multiplication part of the
> > definition or not;
> > compactness, does it include Hausdorff or not; ...).


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

[Haskell-cafe] ANNOUNCE: htzaar-0.0.1

[Tom Hawkins]

HTZAAR is a Haskell implementation of TZAAR, a great little two-player
abstract strategy game designed by Kris Burm.  TZAAR won Games
Magazine's Game-of-the-Year in 2008.

TZAAR has some interesting game dynamics.  At each turn a player must
decide whether to attack or strengthen his own pieces.  The unbalanced
number of tzaars, tzarras, and totts pieces leads to several phase
transitions in the game.  At first tzaars are targeted, but once
they're fortified, tzarras become the targets, then totts.  It also
has a rather distinct transition from mid to end game.  Midway
through, most effort is on positioning power pieces for attack.  But
as more pieces come off the board, movement is restricted to the point
where groups become isolated from others, which can work for or
against you.

Anyway, I thought the game would be a fun AI problem.  HTZAAR comes
with a very simple AI opponent (lame), but I did my best to structure
the interface to make it easy to create new AI strategies.  I hope a
few people try to build and contribute AI strategies to HTZAAR.  And
if there's anyway I can improve the AI interface, let me know.

HTZAAR can also pit AI against AI.  The following is a game between
two instances of the "lame" AI.  For an idea of the complexity of
TZAAR, the number in parentheses indicates the number of possible
moves at each turn.  TZAAR has a large number of choices at each turn
because each turn consists of two different moves (n^2).  Typical
games are between 15 to 25 turns.

$ htzaar -s 22 lame lame
 1. white (lame) : D7 -> E7(42)
 2. black (lame) : F6 -> F5G1 -> F2(6355)
 3. white (lame) : D6 -> E6A5 -> A4(5867)
 4. black (lame) : F3 -> E4H2 -> G2(5227)
 5. white (lame) : I2 -> I1C5 -> C6(4992)
 6. black (lame) : F5 -> G4H1 -> H3(4345)
 7. white (lame) : H5 -> G6C6 -> C7(4176)
 8. black (lame) : F7 -> E7D4 -> C3(4265)
 9. white (lame) : G6 -> E5H4 -> G5(3464)
10. black (lame) : H6 -> I5F2 -> E2(2870)
11. white (lame) : E5 -> G4D2 -> D1(2303)
12. black (lame) : B2 -> C2G7 -> I5(2742)
13. white (lame) : G5 -> I5E6 -> I3(1965)
14. black (lame) : E7 -> B5G3 -> E3(2055)
15. white (lame) : E1 -> F1I4 -> I3(1303)
16. black (lame) : E2 -> D1C4 -> D5(1656)
17. white (lame) : I5 -> F8C7 -> I3(913)
18. black (lame) : B5 -> A4E4 -> B4(1480)
19. white (lame) : D3 -> C2B1 -> C2(608)
20. black (lame) : B4 -> B6C3 -> C2(526)
21. white (lame) : D8 -> E8F1 -> F4(185)
22. black (lame) : H3 -> G4B3 -> B6(314)
23. white (lame) : C1 -> A1F4 -> G4(47)
24. black (lame) : B6 -> E8E8 -> F8(125)
black (lame) Wins!

Screenshots and links: http://tomahawkins.org

Known bugs: Occasionally HTZAAR throws a Prelude.head: empty list.
I'm still trying to track this down.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] dsl and gui toolkit

[Alp Mestan]

Note that the Qt library supports CSS, and it's pretty fun and easy to use.

On Wed, Oct 7, 2009 at 5:05 AM, John A. De Goes  wrote:

>
> Then change to "early generation" language. Point being CSS has plenty of
> pioneering flaws.
>
> Regards,
>
> John A. De Goes
> N-Brain, Inc.
> The Evolution of Collaboration
>
> http://www.n-brain.net|877-376-2724 x 101
>
> On Oct 6, 2009, at 7:52 AM, Richard O'Keefe wrote:
>
>
>> On Oct 7, 2009, at 5:47 AM, John A. De Goes wrote:
>>
>>
>>> CSS is a good start by it's beset by all the problems of a 1st generation
>>> presentation language, and is not particularly machine-friendly.
>>>
>>
>> Considering that CSS is _at least_ a 2nd generation language
>> (it was preceded by DSSSL), that's rather funny.
>>
>>>
>>>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Alp Mestan
http://alpmestan.wordpress.com/
http://alp.developpez.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Libraries for Commercial Users

[Curt Sampson]

On 2009-10-02 09:03 -0600 (Fri), John A. De Goes wrote:

> [Haskell] is missing many key libraries that would be of great
> commercial value.

Just out of curiousity, can you give me some examples of what you feel
these are?

cjs
-- 
Curt Sampson   +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] Market Place for Haskell development teams?

[Curt Sampson]

On 2009-10-02 09:04 -0600 (Fri), John A. De Goes wrote:

> I'm not saying Haskell is unstable. I'm saying that the attitude  
> expressed in the following quote is at odds with the needs of business:
>
> "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."

I don't know how much commercial experience you have, but I've been a
founder of two companies, CTO or CEO of several businesses, a "chief
architect" in a couple more, and consider myself as much a businessman
and manager as a developer.

The attitude you express is certainly common in many businesses, but
it's not the only way to run a successful business.

I won't go further here, since this kind of argument generally leads
into a, "no, what you do isn't possible" kind of flamewar, but I did
want to point this out here, so that others can know that, the attitude
John De Goes expresses, while comon, is not the only way busineses look
at the world.

I should note, too, the the agile development momement over the past
ten years has had and still does have exactly the same sort of attacks
on it, and yet has successfully moved into the mainstream and is
well-accepted by many parts of it.

cjs
-- 
Curt Sampson   +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] random question

[Ryan Ingram]

On Wed, Oct 7, 2009 at 2:28 PM, Michael Mossey wrote:

> I don't quite follow your response. I want a program that initializes the
> generator from the global generator because I want different behavior every
> time I run it. So it will need IO. That's what I was trying to demonstrate.
> And I was wondering if one can get around the difficulty of passing the
> generator from call to call by using newStdGen in this way.
>

You should only have to call newStdGen once:

main = do
   g <- newStdGen
   let (g1,g2) = split g
   let xs = [1..10]
   print $ shuffle g1 xs
   print $ shuffle g2 xs
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] What *is* a DSL?

[Creighton Hogg]

2009/10/7 Robert Atkey :
>
>> What is a DSL?
>
> How about this as a formal-ish definition, for at least a pretty big
> class of DSLs:
>
> A DSL is an algebraic theory in the sense of universal algebra. I.e. it
> is an API of a specific form, which consists of:
>  a) a collection of abstract types, the carriers. Need not all be of
>     kind *.
>  b) a collection of operations, of type
>         t1 -> t2 -> ... -> tn
>     where tn must be one of the carrier types from (a), but the others
>     can be any types you like.
>  c) (Optional) a collection of properties about the operations (e.g.
>     equations that must hold)
>
> Haskell has a nice way of specifying such things (except part (c)): type
> classes.
>
> Examples of type classes that fit this schema include Monad, Applicative
> and Alternative. Ones that don't include Eq, Ord and Show. The Num type
> class would be, if it didn't specify Eq and Show as superclasses.
>
> An implementation of a DSL is just an implementation of corresponding
> type class. Shallowly embedded DSLs dispense with the type class step
> and just give a single implementation. Deeply embedded implementations
> are *initial* implementations: there is a unique function from the deep
> embedding to any of the other implementations that preserves all the
> operations. The good thing about this definition is that anything we do
> to the deep embedding, we can do to any of the other implementations via
> the unique map.
>
> Thanks to Church and Reynolds, we can always get a deep embedding for
> free (free as in "Theorems for Free"). If our DSL is defined by some
> type class T, then the deep embedding is:
>   type DeepT = forall a. T a => a
> (and so on, for multiple carrier types, possibly with type
> parameterisation).
>
> Of course, there is often an easier and more efficient way of
> representing the initial algebra using algebraic data types.
>
> Conor McBride often goes on about how the initial algebra (i.e. the deep
> embedding) of a given specification is the one you should be worrying
> about, because it often has a nice concrete representation and gives you
> all you need to reason about any of the other implementations.

It's funny, because I wouldn't have thought about this in terms of
type classes from the top of my head.  What I've been thinking about a
lot lately (because I'm trying to prepare notes on it) is building
classifying categories from signatures, then considering the category
of all possible functorial "models" (read: "dsl embeddings") into the
target category.I guess we're essentially talking about the same
thing.  The difference from looking at it as type classes is that you
really do get all your equations preserved with product preserving
functors from your classifying category; however, the topic came up
earlier today of what would a language look like if it had a built in
notion of functorial semantics - my guess is that it'd be like a
stronger version of ML functors, but I don't really know.

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

[Haskell-cafe] Test.QuickCheck: generate

[Michael Mossey]

In Test.QuickCheck, the type of 'generate' is

generate :: Int -> StdGen -> Gen a -> a

I can't find docs that explain what the Int does. Some docs are here:



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

Re: [Haskell-cafe] Libraries for Commercial Users

[Erik de Castro Lopo]

Curt Sampson wrote:

> On 2009-10-02 09:03 -0600 (Fri), John A. De Goes wrote:
> 
> > [Haskell] is missing many key libraries that would be of great
> > commercial value.
> 
> Just out of curiousity, can you give me some examples of what you feel
> these are?

A version of Network.HTTP that accepts HTTPS URLs and does the right
thing instead of attempting to do a HTTP connection instead.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Num instances for 2-dimensional types

[Jason McCarty]

Daniel Fischer wrote:
> Am Mittwoch 07 Oktober 2009 23:51:54 schrieb Joe Fredette:
> > I generally find semirings defined as a ring
> > structure without additive inverse and with 0-annihilation (which one
> > has to assume in the case of SRs, I included it in my previous
> > definition because I wasn't sure if I could prove it via the axioms, I
> > think it's possible, but I don't recall the proof).
> 
> 0*x = (0+0)*x = 0*x + 0*x ==> 0*x = 0

This proof only works if your additive monoid is cancellative, which
need not be true in a semiring. The natural numbers extended with
infinity is one example (if you don't take 0*x = 0 as an axiom, I think
there are two possibilities for 0*∞).

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

Re: [Haskell-cafe] Libraries for Commercial Users

[Don Stewart]

mle+hs:
> Curt Sampson wrote:
> 
> > On 2009-10-02 09:03 -0600 (Fri), John A. De Goes wrote:
> > 
> > > [Haskell] is missing many key libraries that would be of great
> > > commercial value.
> > 
> > Just out of curiousity, can you give me some examples of what you feel
> > these are?
> 
> A version of Network.HTTP that accepts HTTPS URLs and does the right
> thing instead of attempting to do a HTTP connection instead.

Yeah, we use the curl library for all our HTTPS stuff.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Num instances for 2-dimensional types

[Felipe Lessa]

On Wed, Oct 07, 2009 at 08:44:27PM -0400, Jason McCarty wrote:
> Daniel Fischer wrote:
> > Am Mittwoch 07 Oktober 2009 23:51:54 schrieb Joe Fredette:
> > > I generally find semirings defined as a ring
> > > structure without additive inverse and with 0-annihilation (which one
> > > has to assume in the case of SRs, I included it in my previous
> > > definition because I wasn't sure if I could prove it via the axioms, I
> > > think it's possible, but I don't recall the proof).
> >
> > 0*x = (0+0)*x = 0*x + 0*x ==> 0*x = 0
>
> This proof only works if your additive monoid is cancellative, which
> need not be true in a semiring. The natural numbers extended with
> infinity is one example (if you don't take 0*x = 0 as an axiom, I think
> there are two possibilities for 0*∞).

Given that

x = 1*x = (0+1)*x = 0*x + 1*x = 0*x + x

we can show that

x = x + 0*x  (right)
x = 0*x + x  (left)

so, by definition of 'zero', we have that 0*x is a zero.  But we
can easily prove that there can be only one zero: suppose we have
two zeros z1 and z2; it follows that

z1 = z1 + z2 = z2

So 0*x = 0.  Any flaws?

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

Re: [Haskell-cafe] Re: Num instances for 2-dimensional types

[Daniel Fischer]

Am Donnerstag 08 Oktober 2009 03:05:13 schrieb Felipe Lessa:
> On Wed, Oct 07, 2009 at 08:44:27PM -0400, Jason McCarty wrote:
> > Daniel Fischer wrote:
> > > Am Mittwoch 07 Oktober 2009 23:51:54 schrieb Joe Fredette:
> > > > I generally find semirings defined as a ring
> > > > structure without additive inverse and with 0-annihilation (which one
> > > > has to assume in the case of SRs, I included it in my previous
> > > > definition because I wasn't sure if I could prove it via the axioms,
> > > > I think it's possible, but I don't recall the proof).
> > >
> > > 0*x = (0+0)*x = 0*x + 0*x ==> 0*x = 0
> >
> > This proof only works if your additive monoid is cancellative, which
> > need not be true in a semiring. The natural numbers extended with
> > infinity is one example (if you don't take 0*x = 0 as an axiom, I think
> > there are two possibilities for 0*∞).

It was a proof for a ring (with or without unit), which Joe stated above he 
didn't recall.
There your additive monoid is cancellative since it's a group :D

>
> Given that
>
> x = 1*x = (0+1)*x = 0*x + 1*x = 0*x + x
>
> we can show that
>
> x = x + 0*x  (right)
> x = 0*x + x  (left)
>
> so, by definition of 'zero', we have that 0*x is a zero.

Not necessarily, we don't know 0*x + y = y for arbitrary y yet.
If the additive monoid isn't cancellative, that needn't be the case.
In Jason's example, you can indeed set 0*∞ = ∞.

> But we can easily prove that there can be only one zero: suppose we have
> two zeros z1 and z2; it follows that
>
> z1 = z1 + z2 = z2
>
> So 0*x = 0.  Any flaws?
>
> --
> Felipe.


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

Re: [Haskell-cafe] Libraries for Commercial Users

[Erik de Castro Lopo]

Don Stewart wrote:

> > A version of Network.HTTP that accepts HTTPS URLs and does the right
> > thing instead of attempting to do a HTTP connection instead.
> 
> Yeah, we use the curl library for all our HTTPS stuff.

Well there is a big difference between Network.Curl and Network.HTTP.
HTTP is really easy to understand and use, while Curl is not.

What I would like to do is a POST operation to a HTTPS server with
Content-Type "text/xml" and then get the HTTP response code as well
as the body which is also "text/xml". This should be easy and should
be obvious, but unfortunately does not even seem to be supported by
Network.Curl.

The Network.Curl API is rather weird. It has a very sensible and
obvious GET function:

curlGetString :: URLString -> [CurlOption] -> IO (CurlCode, String)

but no corresponding POST function. Instead it has:

curlPost :: URLString -> [String] -> IO ()
curlMultiPost :: URLString -> [CurlOption] -> [HttpPost] -> IO ()

both of which seem to only support x-www-form-urlencoded data and not
text/xml. Furthermore, whats with the 'IO ()' result? Wouldn't it make
more sense to return 'IO (CurlCode, String)' like curlGetString?

I don't like to be critical of other people's projects, but Network.Curl
seems to be one huge ball of confusion.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANNOUNCE: vty-ui 0.2

[Jonathan Daugherty]

I'm happy to announce the release of vty-ui 0.2.

Get it from Hackage:

  http://hackage.haskell.org/package/vty-ui

Or get the source with darcs:

  http://repos.codevine.org/vty-ui

This version of vty-ui is everything you hoped it would be: fewer
bugs, more widget types, cleaner code, better abstractions, and more
generality.  If you've written any applications to use vty-ui, only a
few of your type signatures will need to change.

Here's a summary of changes:

General
  * Unify HBorder and VBorder types (now called Border)
  * Unify HFill and VFill types (now called Fill)
  * Unify HBox and VBox types (now called Box)
  * Box layout: layout documentation, edge case bug fixes
  * Widget class: refactor growthPolicy into growHorizontal and
growVertical
  * Add Graphics.Vty.Widgets.Composed for high-level widget
compositions
  * Add Graphics.Vty.Widgets.All convenience module to export
everything in the library

Lists
  * List items may now be of any widget type!
  * Add resize, pageUp, pageDown, scrollBy functions and expose other
list functionality
  * Generalize scrolling API
  * Add convenience API for using lists of Text widgets
  * Support internal identifiers for list items
  * Always consume scrollWindowSize lines of space even if the list is
smaller

New widgets
  * WrappedText: automatically wraps text in available space; try
resizing the demo.
  * Borders module: one-row/one-column ASCII borders between boxed
widgets; ASCII art box container
  * Demo: use crazy boxed list items to show off border boxes and
generic widget support in Lists!
  * Demo: support PageUp/PageDown to demonstrate List paging API

Enjoy!

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

Re: [Haskell-cafe] Test.QuickCheck: generate

[David Menendez]

On Wed, Oct 7, 2009 at 8:29 PM, Michael Mossey  wrote:
> In Test.QuickCheck, the type of 'generate' is
>
> generate :: Int -> StdGen -> Gen a -> a
>
> I can't find docs that explain what the Int does. Some docs are here:
>
> 

Judging by the source code, the integer is the upper bound for the
size parameter. If you are generating a list, for example, it gives
the maximum size of the list.

-- 
Dave Menendez 

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

[Haskell-cafe] #include path

[Sean McLaughlin]

Hi,

  I'm trying to compile some code using Cabal.  One of the files has a CPP
directive

#include "undefined.h"

The file undefined.h is in the same directory as the file with the
directive.
If I use the full path name, cabal can compile it.  However, if I use the
relative path,
it complains about not being able to find the file.   I tried adding it to
extra-source-files, but that didn't help.  I see that Hackage packages like
Agda use
this trick, so I know it's possible.  How can I get these paths worked out
correctly?
There isn't much comment in the Cabal docs.

Thanks,

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