Re: [Haskell-cafe] Monoid wants a (++) equivalent

[Alexander Dunlap]

On Tue, Jun 30, 2009 at 11:24 PM, Ketil Malde wrote:
>
> You know, this might be the right time to start expanding our
> vocabulary beyond seven bits.  Since we're likely to keep mappend
> around as an alias for some time, people would have a grace period to
> adjust.
>
> How about U+2295 (circle with plus inside it)?
>
> Or, if we would like to stick to the 8-bit subset to keep those 8859-1
> users happy, how about ¤ (funny circle over an x, U+00A4)
>
> -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
>

The major disadvantage of that is that those symbols are not on my
keyboard and thus are more of a pain to type, especially on the Linux
console where compose key is not available...

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

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[Ketil Malde]

You know, this might be the right time to start expanding our
vocabulary beyond seven bits.  Since we're likely to keep mappend
around as an alias for some time, people would have a grace period to
adjust. 

How about U+2295 (circle with plus inside it)?

Or, if we would like to stick to the 8-bit subset to keep those 8859-1
users happy, how about ¤ (funny circle over an x, U+00A4)

-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] ORM for haskell?

[Ketil Malde]

Mads Lindstrøm  writes:

> I do not get this explanation, could you expand? I would have thought it
> should be: "difference? Because SQLAlchemy knows about the relationships
> (not relations, but relation_ships_), it do not have to explicitly join
> on foreign keys.".

I think this is a common terminology issue - lots of people think
"relational" refers linking tables together (foreign keys), and not the
mathematical definition of a relation as a subset of T1 x T2 x ... x
Tn -- i.e. a table.

-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] Monoid wants a (++) equivalent

[ajb]

G'day all.

On Tue, Jun 30, 2009 at 08:02:48PM -0400, Daniel Peebles wrote:


But we don't want to imply it's commutative either. Having something
"bidirectional" like <> or <+> feels more commutative than associative
to me.


Quoting John Meacham :


Not really, think of '++', which doesn't commute but is visually
symmetric, or Data.Sequence.<>, or the common use of <> to mean
concatination in pretty printers.


Other good examples are && and ||.

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

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[ajb]

G'day all.

Quoting John Meacham :


(+>) seems to imply to me that the operator is non-associative. Something
like (<>) or (<+>) would be better.


I tend to agree.  Moreover, and I realise this may be a losing battle,
I want (++) to be the generic operator.

I understand the argument.  I even agreed with it at the time.  In 1998,
academic use of Haskell (both for research and education) was the most
important imperative.

Today, Haskell is officially cool, so the good names and operators should
not be stolen by operations that are distinguished only by being less
useful (e.g. by working on lists alone).

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

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[Lanny Ripple]

Ok.  When nobody can agree on a graphical operator can it be
shortened to "mop" and "munit"?  (Personally I'm for (++).  (Yeah, I
know.))

  -ljr

Daniel Peebles wrote:
> But we don't want to imply it's commutative either. Having something
> "bidirectional" like <> or <+> feels more commutative than associative
> to me.
> 
> On Tue, Jun 30, 2009 at 6:39 PM, John Meacham wrote:
>> On Tue, Jun 30, 2009 at 02:54:38PM -0400, Brent Yorgey wrote:
>>> On Tue, Jun 30, 2009 at 09:45:45AM -0700, Bryan O'Sullivan wrote:
 I've thought for a while that it would be very nice indeed if the Monoid
 class had a more concise operator for infix appending than "a `mappend` b".
 I wonder if other people are of a similar opinion, and if so, whether this
 is worth submitting a libraries@ proposal over.
>>> +1.
>>>
>>> IIRC Jules Bean has proposed using (+>) for this purpose, which I
>>> like. Â It has the advantages of (a) not clashing with any other
>>> (common) operators, (b) making more obvious the fact that mappend is
>>> not necessarily commutative, and (c) providing the obvious (<+) for
>>> 'flip mappend' which is sometimes useful.
>> (+>) seems to imply to me that the operator is non-associative. Something
>> like (<>) or (<+>) would be better.
>>
>>
>> Â  Â  Â  Â John
>>
>> --
>> John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
>> ___
>> 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: Re[2]: [Haskell-cafe] Re: Could FFI support pass-by-value of structs?

[John Meacham]

On Tue, Jun 30, 2009 at 01:18:32AM +0100, Duncan Coutts wrote:
> On IA32 structs/unions passed as parameters go by value on the stack.
> For structs/unions as function results, they are stored into a
> caller-allocated area on the stack, pointed to by a "hidden" first arg.
> 
> It's different on each arch, but it's all completely specified.
> 
> > moreover, even for pointers-to-structures, there is no definitive
> > layout due to packing problem
> 
> Actually the padding is also specified by the C ABI. See section 3-3.
> Compiler pragmas to use packed layout are not ABI conformant (and so
> typically are only used internally).

Yup. Unfortunately this doesn't help us, since in order to pass
structures we need to know more than just the layout (offset and size)
of the type, but we need to know the underlying C types as well which a
Storable instance doesn't give us. depending on the ABI, struct passing
may not be as simple as 'pass on stack' vs 'pass in registers'. it may
be something like 'the floating point components get pulled out and put
in registers, which the other components get pushed onto the stack'. So,
without some compiler magic, like a 'deriving Storable' instance that
derived some hidden methods to contain this extra information, or
additions to storable, this won't work in general.

John

-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell on JVM

[wren ng thornton]

Claus Reinke wrote:
|Basically, the JVM lacks a native ability to do tail calls. It does  
|not have an instruction to remove/replace a stack frame without 
|executing an actual return to the calling method/function.


There is a conflict between preserving stack layout and efficient
tail calls. Unfortunately, stack inspection appears to be used for
security aspects in JVM. That doesn't make tail calls impossible,
but may have slowed down progress as this argument always
comes up in discussing tail calls on the JVM (since its byte code
isn't just an internal detail, but an externally used API).


It's a bugbear, but it's not impossible:

http://www.ccs.neu.edu/scheme/pubs/esop2003-cf.pdf

http://www.ccs.neu.edu/scheme/pubs/cf-toplas04.pdf

Maybe one day it'll be here.

--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[John Meacham]

On Tue, Jun 30, 2009 at 08:02:48PM -0400, Daniel Peebles wrote:
> But we don't want to imply it's commutative either. Having something
> "bidirectional" like <> or <+> feels more commutative than associative
> to me.

Not really, think of '++', which doesn't commute but is visually
symmetric, or Data.Sequence.<>, or the common use of <> to mean
concatination in pretty printers. I think there is a fair amount of
precedence for using '<>' actually. As it appears when it is used, it
is also the natural mappend operator for the Monoid instance.

John

-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[Daniel Peebles]

But we don't want to imply it's commutative either. Having something
"bidirectional" like <> or <+> feels more commutative than associative
to me.

On Tue, Jun 30, 2009 at 6:39 PM, John Meacham wrote:
> On Tue, Jun 30, 2009 at 02:54:38PM -0400, Brent Yorgey wrote:
>> On Tue, Jun 30, 2009 at 09:45:45AM -0700, Bryan O'Sullivan wrote:
>> > I've thought for a while that it would be very nice indeed if the Monoid
>> > class had a more concise operator for infix appending than "a `mappend` b".
>> > I wonder if other people are of a similar opinion, and if so, whether this
>> > is worth submitting a libraries@ proposal over.
>>
>> +1.
>>
>> IIRC Jules Bean has proposed using (+>) for this purpose, which I
>> like.  It has the advantages of (a) not clashing with any other
>> (common) operators, (b) making more obvious the fact that mappend is
>> not necessarily commutative, and (c) providing the obvious (<+) for
>> 'flip mappend' which is sometimes useful.
>
> (+>) seems to imply to me that the operator is non-associative. Something
> like (<>) or (<+>) would be better.
>
>
>        John
>
> --
> John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
> ___
> 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] Monoid wants a (++) equivalent

[Tony Morris]

David Leimbach wrote:
>
>
> On Tue, Jun 30, 2009 at 11:54 AM, Brent Yorgey  > wrote:
>
> On Tue, Jun 30, 2009 at 09:45:45AM -0700, Bryan O'Sullivan wrote:
> > I've thought for a while that it would be very nice indeed if
> the Monoid
> > class had a more concise operator for infix appending than "a
> `mappend` b".
> > I wonder if other people are of a similar opinion, and if so,
> whether this
> > is worth submitting a libraries@ proposal over.
>
> +1.
>
> IIRC Jules Bean has proposed using (+>) for this purpose, which I
> like.  It has the advantages of (a) not clashing with any other
> (common) operators, (b) making more obvious the fact that mappend is
> not necessarily commutative, and (c) providing the obvious (<+) for
> 'flip mappend' which is sometimes useful.
>
>
> I actually think this proposal is pretty excellent.  
I happen to agree.

-- 
Tony Morris
http://tmorris.net/


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

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[Bryan O'Sullivan]

On Tue, Jun 30, 2009 at 3:56 PM, Ross Paterson  wrote:

> On Tue, Jun 30, 2009 at 03:39:39PM -0700, John Meacham wrote:
> > (+>) seems to imply to me that the operator is non-associative.
>
> It does seem to imply some asymmetry between the arguments.
>

Well, the canonical instance of Monoid is to mappend over lists, where it
doesn't commute, so I think that the pointiness of the operator makes a
reasonable kind of sense.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[Ross Paterson]

On Tue, Jun 30, 2009 at 03:39:39PM -0700, John Meacham wrote:
> (+>) seems to imply to me that the operator is non-associative.

It does seem to imply some asymmetry between the arguments.

> Something like (<>) or (<+>) would be better.

(<+>) is used in Control.Arrow.

(<>) is used in Data.Sequence, but as the mappend for Seq a; it could
be stolen and generalized.  (So could empty, for that matter.)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[Bryan O'Sullivan]

On Tue, Jun 30, 2009 at 3:50 PM, Dougal Stanton  wrote:

> > (+>) seems to imply to me that the operator is non-associative. Something
> > like (<>) or (<+>) would be better.
>
> It's too similar to the applicative (*>), and implies all sorts of
> things like different types of the two arguments and so on.


If you have comments like the above, please add them to the Trac ticket.
Speaking for myself, I'll be happiest to give weight to comments that
suggest alternative operators.

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

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[Dougal Stanton]

On Tue, Jun 30, 2009 at 11:39 PM, John Meacham wrote:

>
> (+>) seems to imply to me that the operator is non-associative. Something
> like (<>) or (<+>) would be better.
>

It's too similar to the applicative (*>), and implies all sorts of
things like different types of the two arguments and so on.


D

-- 
Dougal Stanton
dou...@dougalstanton.net // http://www.dougalstanton.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[John Meacham]

On Tue, Jun 30, 2009 at 02:54:38PM -0400, Brent Yorgey wrote:
> On Tue, Jun 30, 2009 at 09:45:45AM -0700, Bryan O'Sullivan wrote:
> > I've thought for a while that it would be very nice indeed if the Monoid
> > class had a more concise operator for infix appending than "a `mappend` b".
> > I wonder if other people are of a similar opinion, and if so, whether this
> > is worth submitting a libraries@ proposal over.
> 
> +1.
> 
> IIRC Jules Bean has proposed using (+>) for this purpose, which I
> like.  It has the advantages of (a) not clashing with any other
> (common) operators, (b) making more obvious the fact that mappend is
> not necessarily commutative, and (c) providing the obvious (<+) for
> 'flip mappend' which is sometimes useful.

(+>) seems to imply to me that the operator is non-associative. Something
like (<>) or (<+>) would be better.


John

-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] List spine traversal

[Ryan Ingram]

seq allows you to distinguish (undefined) from (const undefined)
case allows you to distinguish (undefined) from the pair (undefined, undefined)

   isFun f = f `seq` True
   isPair p = case p of (_,_) -> True


isFun undefined -> undefined
isFun (const undefined) -> True
isPair undefined -> undefined
isPair (undefined, undefined) -> True

I don't think either of these violate equational reasoning or
referential transparency, though.  You cannot treat a call to seq as
"flip const", though, it has to be a bit more magic than that.

You do get different bottoms, however; (length xs1 + length xs1) isn't
terminating, while (length xs2 + length xs2) will probably consume
your heap.  But that just means that you can distinguish them in IO,
which is allowed :)

  -- ryan


On Tue, Jun 30, 2009 at 1:38 PM, Don Stewart wrote:
> andrewhhunter:
>> On Mon, Jun 29, 2009 at 11:30 PM, Ryan Ingram wrote:
>> > There can't be a way to do so that is pure, because such a function
>> > could distinguish between
>> >> xs1 = () : xs1
>> > and
>> >> xs2 = f () where f () = () : f ()
>> >
>>
>> But doesn't seq and friends cause many of our normal referential
>> transparency guarantees to be invalid?
>
> Equational reasoning, in the presence of bottoms, anyway.
>
> -- Don
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ORM for haskell?

[Jeremy Shaw]

At Tue, 30 Jun 2009 19:52:08 +0200,
Marc Weber wrote:

> Is there anyone interested in helping building a library which
> a) let's you define kind of model of you data
> b) let's you store you model in any backend (maybe a relational
> database)
> c) does static checking of your queries at compilation time?

> Maybe this does already exist and I've missed it?

Happstack-state is close in many respects. Your persistent state can
basically be any haskell data type for which you could create
instances of Read/Show where, read . show == id. (Note, happstack
state doesn't actually use Read/Show, but it does use a similar class
with similar restrictions).

Your queries are just normal functions in the Reader or State
monad. Reader if you only want to read the data, State if you want to
read and update the data. So, you don't have to learn any special
query language or DSL. And you get all your favorite (pure) haskell
functions, static type checking, etc. If you want a relation type
storage you can use happstack-ixset.

You also get write-ahead logging and checkpointing for recovery, data
migration, and more.

Additionaly, there is multimater support (though not quite suitable
for real deployment yet), and plans for sharding support.

It does not currently provide a mechanism for mapping the data to a
relational database. In theory it would be possible to write a layer
that mapped the current state into a SQL database. That would allow
other programs to use SQL to read the values. However, it would not be
able to support other apps writing updates to the database.

- jeremy

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

Re: [Haskell-cafe] Leksah works!

[jutaro]

Hi David,


david48 wrote:
> 
> 
> I would love to try leksah, but on my machine there a weird bug: I
> can't type a space. When I press the space bar, nothing happens.( it
> writes "CTRL-Space : Start complete" at the bottom though)
> 
> ...

Thats indeed strange, as we use standard gtk handling for simple keystrokes.
Have
you expeienced problems with the keyboard with other gtk apps like gedit?
You can take out the line :
space →   StartComplete   "Initiate complete in a
source buffer"
from the leksah keymap file, but the question remains why a control is send,
when you
simply type a space? 

When I look on my Ubuntu machine under 
"System/Settings/Keyboard" their are some settings which translates like (I
have a german 
installation) "Ctrl key position: Make CapsLock an additional Ctrl" and a
bunch of other options. 
Can you investigate in this direction if you have some special settings on
your machine, 
as it is a new phenomena for Leksah.

Jürgen


-- 
View this message in context: 
http://www.nabble.com/Leksah-works%21-tp24266240p24280921.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] ORM for haskell?

[Marc Weber]

Hi Mads!

On Tue, Jun 30, 2009 at 11:49:40PM +0200, Mads Lindstrøm wrote:
> Hi Marc Weber
> 
> > Another example: Updating the age of a pupil:
> > 
> >   row = SELECT * FROM pupils where age = 13;
> >   UPDATE pupils SET age = 14 WHERE id = 
> > 
> >   p = session.query(Pupil).filter(Pupil.age==13).one().age=14
> >   session.commit()
> > 
> >   difference?
> >   You don't have to care about ids. you just assign a new value and
> > tell
> >   the engine that it should commit.
> >   So again less chances to get something wrong.
> > 
> 
> Could you not do in SQL:
> 
> UPDATE pupils SET age = 14 WHERE age = 13
Of course.
But: you can pass around that pupil object to another function and still assign 
a new age
then run session.commit().
When passing around the pupile you can follow the relation_ships
(relations?) back to school.

def doSomething(pupil):
  pupil['age'] = 13
  pupil.teacher.school.rating += 1

doSomething(session.query(Pupil).filter(Pupil.age==13))
session.commit()

Now how would you do this using SQL?

Sorry about the confustion (relation / relation-ship). I mixed up the 
terminology.
Anyway I guess you can see here how powerful an ORM can be and why
we should write such a library for haskell.

I think it's very hard to invent such a short synax in haskell cause
you have to take monads into account etc..

And it matters how much time you have to spend writing code.

Thanks for your feedback. I hope there will be some more.

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

Re: [Haskell-cafe] ORM for haskell?

[Mads Lindstrøm]

Hi Marc Weber

> Another example: Updating the age of a pupil:
> 
>   row = SELECT * FROM pupils where age = 13;
>   UPDATE pupils SET age = 14 WHERE id = 
> 
>   p = session.query(Pupil).filter(Pupil.age==13).one().age=14
>   session.commit()
> 
>   difference?
>   You don't have to care about ids. you just assign a new value and
> tell
>   the engine that it should commit.
>   So again less chances to get something wrong.
> 

Could you not do in SQL:

UPDATE pupils SET age = 14 WHERE age = 13

That is, without using ids.


Greetings,

Mads Lindstrøm



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

Re: [Haskell-cafe] Leksah works!

[david48]

On Tue, Jun 30, 2009 at 4:28 PM, jutaro wrote:
>
> As Leksah developer I approve your comment.
>
> Even better we will soon have a new release that integrates GHCi and a
> !visual debugger! plus other useful features like much enhanced text search
> with regex and grep and enhanced GUI framework with a tentative support
> for multiple screens. So stay tuned and we appreciate help of any kind.

I would love to try leksah, but on my machine there a weird bug: I
can't type a space. When I press the space bar, nothing happens.( it
writes "CTRL-Space : Start complete" at the bottom though)

I've build leksah from a fresh darcs get, ghc is 6.10.3 with the packages :

da...@whizz:~/leksah$ ghc-pkg list
/usr/local/lib/ghc-6.10.3/./package.conf:
Cabal-1.6.0.3, GLUT-2.1.1.2, HTTP-4000.0.6, HUnit-1.2.0.3,
OpenGL-2.2.1.1, QuickCheck-1.2.0.0, array-0.2.0.0, base-3.0.3.1,
base-4.1.0.0, binary-0.5.0.1, bytestring-0.9.1.4, cairo-0.10.1,
cgi-3001.1.7.1, containers-0.2.0.1, directory-1.0.0.3,
(dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3),
(dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3),
editline-0.2.1.0, extensible-exceptions-0.1.1.0, fgl-5.4.2.2,
filepath-1.1.0.2, (ghc-6.10.3), ghc-prim-0.1.0.0, gio-0.10.1,
glade-0.10.1, glib-0.10.1, gtk-0.10.1, gtkglext-0.10.1,
gtksourceview2-0.10.1, haddock-2.4.2, haskell-platform-2009.2.0.1,
haskell-src-1.0.1.3, haskell98-1.0.1.0, hpc-0.5.0.3, html-1.0.1.2,
integer-0.1.0.1, mtl-1.1.0.2, network-2.2.1, network-2.2.1.1,
old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1,
parallel-1.1.0.1, parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.1,
random-1.0.0.1, regex-base-0.72.0.2, regex-compat-0.71.0.1,
regex-posix-0.72.0.3, rts-1.0, soegtk-0.10.1, stm-2.1.1.2,
svgcairo-0.10.1, syb-0.1.0.1, template-haskell-2.3.0.1,
time-1.1.2.4, time-1.1.3, unix-2.3.2.0, utf8-string-0.3.5,
xhtml-3000.2.0.1, zlib-0.5.0.0
da...@whizz:~/leksah$


The OS is Kubuntu Jaunty (9.04) and GTK comes from the Jaunty repositories.

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

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[Bryan O'Sullivan]

On Tue, Jun 30, 2009 at 1:33 PM, Thomas Davie  wrote:

> I excellently think your proposal is a correct assessment.
>

Well then, here's the library enhancement ticket:

http://hackage.haskell.org/trac/ghc/ticket/3339
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ORM for haskell?

[Mads Lindstrøm]

Hi Marc


> Example why it matters:
> schools - 1:n - teachers - 1:n - pupils
> 
> If you want to list all schools which have a pupil with age > 3 you'd
> write an sql query like this:
> 
>   SELECT dictinct * FROM schools as s JOIN teachers t ON (t.school_id = s.id) 
> JOIN pupils as p ON (p.teacher_id = t.id) WHERE p.age > 3
> 
>   in SQLAlchemy it looks like this:
>   
> session.query(School).join(School.teachers).join(Teacher.pupils).filter(Pupil.age
>  > 3).all()
> 
>   difference? Because SQLAlchemy knows about the relations you don't have
>   to remember alias names. So there is no chance to get that wrong.

I do not get this explanation, could you expand? I would have thought it
should be: "difference? Because SQLAlchemy knows about the relationships
(not relations, but relation_ships_), it do not have to explicitly join
on foreign keys.".

Actually SQL has natural joins, where you can do without explicit join
conditions. Unfortunately, natural joins seems like they were explicitly
designed to create trouble. It would be nice if "they" fixed SQL to
consider relationships. 


Greetings,

Mads Lindstrøm



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

Re: [Haskell-cafe] List spine traversal

[Don Stewart]

andrewhhunter:
> On Mon, Jun 29, 2009 at 11:30 PM, Ryan Ingram wrote:
> > There can't be a way to do so that is pure, because such a function
> > could distinguish between
> >> xs1 = () : xs1
> > and
> >> xs2 = f () where f () = () : f ()
> >
> 
> But doesn't seq and friends cause many of our normal referential
> transparency guarantees to be invalid?

Equational reasoning, in the presence of bottoms, anyway.

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

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[Thomas Davie]

On 30 Jun 2009, at 22:19, Daniel Fischer wrote:


Am Dienstag 30 Juni 2009 20:56:10 schrieb David Leimbach:
On Tue, Jun 30, 2009 at 11:54 AM, Brent Yorgey >wrote:

On Tue, Jun 30, 2009 at 09:45:45AM -0700, Bryan O'Sullivan wrote:

I've thought for a while that it would be very nice indeed if the
Monoid class had a more concise operator for infix appending than  
"a

`mappend`


b".

I wonder if other people are of a similar opinion, and if so,  
whether


this


is worth submitting a libraries@ proposal over.


+1.

IIRC Jules Bean has proposed using (+>) for this purpose, which I
like.  It has the advantages of (a) not clashing with any other
(common) operators, (b) making more obvious the fact that mappend is
not necessarily commutative, and (c) providing the obvious (<+) for
'flip mappend' which is sometimes useful.


I actually think this proposal is pretty excellent.


I actually think your assessment of the proposal is correct.


I excellently think your proposal is a correct assessment.

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

Re: [Haskell-cafe] List spine traversal

[Andrew Hunter]

On Mon, Jun 29, 2009 at 11:30 PM, Ryan Ingram wrote:
> There can't be a way to do so that is pure, because such a function
> could distinguish between
>> xs1 = () : xs1
> and
>> xs2 = f () where f () = () : f ()
>

But doesn't seq and friends cause many of our normal referential
transparency guarantees to be invalid?  Are you certain that claim
holds in the presence of seq?

As a side note, (allowing seq and unsafePerformIO if necessary) is it
possible to implement a map that preserves cycles (instead of
transparently replacing them with infinite copies?  Not horribly
useful, but would be quite cute.

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

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[Daniel Fischer]

Am Dienstag 30 Juni 2009 20:56:10 schrieb David Leimbach:
> On Tue, Jun 30, 2009 at 11:54 AM, Brent Yorgey wrote:
> > On Tue, Jun 30, 2009 at 09:45:45AM -0700, Bryan O'Sullivan wrote:
> > > I've thought for a while that it would be very nice indeed if the
> > > Monoid class had a more concise operator for infix appending than "a
> > > `mappend`
> >
> > b".
> >
> > > I wonder if other people are of a similar opinion, and if so, whether
> >
> > this
> >
> > > is worth submitting a libraries@ proposal over.
> >
> > +1.
> >
> > IIRC Jules Bean has proposed using (+>) for this purpose, which I
> > like.  It has the advantages of (a) not clashing with any other
> > (common) operators, (b) making more obvious the fact that mappend is
> > not necessarily commutative, and (c) providing the obvious (<+) for
> > 'flip mappend' which is sometimes useful.
>
> I actually think this proposal is pretty excellent.

I actually think your assessment of the proposal is correct.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: package Boolean: Generalized booleans

[Tom Lokhorst]

It compiles fine :-)

If you want, you can take a look at this [1] version of the code (or
the tarball [2]).

Load Main.hs in GHCi and run `test`, it will evaluate to `True`.
Then, in the source code, switch the type of `test` from `P.Bool` to
`Js JsBool` (in the comments) and run `test` again, now it will
evaluate to a JavaScript expression.

The code is still very immature (basically only that one example
works), but it demonstrates our intend.

- Tom

[1]: http://github.com/tomlokhorst/AwesomePrelude/tree/master
[2]: http://github.com/tomlokhorst/AwesomePrelude/tarball/master

On Tue, Jun 30, 2009 at 8:21 PM, Conal Elliott wrote:
> Does this code compile?  I'd expect that
>
>   instance Bool (Js JsBool) (Js r) where
>
> violates the fundep, since it applies for *all* values of r, not just to
> one.
>
>    - Conal
>
> On Tue, Jun 30, 2009 at 8:53 AM, Sebastiaan Visser 
> wrote:
>>
>> On Jun 30, 2009, at 5:24 PM, Conal Elliott wrote:
>>>
>>> Hi Sebastiaan,
>>>
>>> I like your extensions of generalized booleans to other common Haskell
>>> types!
>>>
>>> I also prefer using type families to fundeps.  In this case I didn't
>>> because of some awkwardness with vector operations, but I'm going to try
>>> again.
>>>
>>> I'm confused about your particular fundep choice.  For instance,
>>>
>>> class Bool f r | f -> r where
>>>  bool  :: r -> r -> f -> r
>>>  false :: f
>>>  true  :: f
>>>
>>> Do you *really* mean that the boolean type f determines the value type r?
>>
>> Yes, that is really what I mean. This can be used to enforce that the
>> return value of elimination can be restricted by the boolean type. This is
>> especially useful when using GADTs to encode your domain language.
>>
>> For example, take this simple JavaScript language:
>>  data Js a where
>>    Prim :: String -> Js a                -- Primitive embedding.
>>    App :: Js (a -> b) -> Js a -> Js b    -- Function application.
>>
>>  data JsBool
>>
>> Now the functional dependencies can be used to enforce that eliminating
>> booleans in the Js domain always returns a value in the Js domain:
>>  instance Bool (Js JsBool) (Js r) where
>>    bool f t c = Prim "(function ifthenelse (f, t, c) c ? t : f)" `App` f
>> `App` t `App` c
>>    true  = Prim "true"
>>    false = Prim "false"
>> Getting rid of this fundep and using type families will probably be a lot
>> more intuitive.
>>
>> Any suggestions on how to enforce elimination to be able to go from `Js
>> JsBool -> Js r' using other techniques?
>>>
>>> Regards,   - Conal
>>>
>>> ...
>>
>> --
>> Sebastiaan Visser
>>
>>
>>
>
>
> []
> ___
> 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] Monoid wants a (++) equivalent

[David Leimbach]

On Tue, Jun 30, 2009 at 11:54 AM, Brent Yorgey wrote:

> On Tue, Jun 30, 2009 at 09:45:45AM -0700, Bryan O'Sullivan wrote:
> > I've thought for a while that it would be very nice indeed if the Monoid
> > class had a more concise operator for infix appending than "a `mappend`
> b".
> > I wonder if other people are of a similar opinion, and if so, whether
> this
> > is worth submitting a libraries@ proposal over.
>
> +1.
>
> IIRC Jules Bean has proposed using (+>) for this purpose, which I
> like.  It has the advantages of (a) not clashing with any other
> (common) operators, (b) making more obvious the fact that mappend is
> not necessarily commutative, and (c) providing the obvious (<+) for
> 'flip mappend' which is sometimes useful.


I actually think this proposal is pretty excellent.


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

Re: [Haskell-cafe] ORM for haskell?

[Rick R]

It has to do with treating groups of records from a table like an object.
You have the object Employee, which consists of rows from the Person table,
the Account table and the Building table.
When you instantiate the object. if you don't ask to view the Employee's
building information, it doesn't bother to retrieve it.

In the case you mention, the data hasn't yet been loaded, and even if it
were, it can be loaded with traditional transactional semantics (read only,
read with possible write, write, etc)


On Tue, Jun 30, 2009 at 2:29 PM, Daniel Peebles wrote:

> I don't have a good answer to your question, but I'm curious of how
> lazy loading of SQL-based records would work. It seems like having
> another user of the database modify your record before you've loaded
> it all could lead to an inconsistent record (assuming you've already
> loaded and memoized some fields and not others).
>
> On Tue, Jun 30, 2009 at 1:52 PM, Marc Weber wrote:
> > Some time ago I stumbled upon SQLAlchemy which is a great ORM wrapper
> > library for python. It has a nice syntax I'd like to see in a haskell
> > library as well.
> >
> > SQLAlchemy already provides some lazy features such as loading subitems
> > on access etc.
> >
> > All haskell SQL libraries I know only let you run SQL statements but not
> > much more. To start real business you no longer want to write many SQL
> > commands.
> >
> > Example why it matters:
> > schools - 1:n - teachers - 1:n - pupils
> >
> > If you want to list all schools which have a pupil with age > 3 you'd
> > write an sql query like this:
> >
> >  SELECT dictinct * FROM schools as s JOIN teachers t ON (t.school_id =
> s.id) JOIN pupils as p ON (p.teacher_id = t.id) WHERE p.age > 3
> >
> >  in SQLAlchemy it looks like this:
> >
>  
> session.query(School).join(School.teachers).join(Teacher.pupils).filter(Pupil.age
> > 3).all()
> >
> >  difference? Because SQLAlchemy knows about the relations you don't have
> >  to remember alias names. So there is no chance to get that wrong.
> >
> >
> > Another example: Updating the age of a pupil:
> >
> >  row = SELECT * FROM pupils where age = 13;
> >  UPDATE pupils SET age = 14 WHERE id = 
> >
> >  p = session.query(Pupil).filter(Pupil.age==13).one().age=14
> >  session.commit()
> >
> >  difference?
> >  You don't have to care about ids. you just assign a new value and tell
> >  the engine that it should commit.
> >  So again less chances to get something wrong.
> >
> >
> > What about trees (eg web site navigation)
> >
> >  id   |  title| parent_id
> >  1   |  top  | null
> >  2   |  submenu  | 1
> >  3   |  submenu2 | 1
> >
> > should result in
> >
> > top
> >  - submenu
> >  - submenu2
> >
> > using SQLAlchemy you can just do
> >
> > parent = session.query('nodes').filter(Node.id = 1)
> >
> > def print(node):
> >  print node.title
> >  print node.subnodes # this will run a subquery automatically for you
> returning submenu{,2}
> >
> > Again no sql. No chance to get something wrong?
> >
> > You can skim the manual to get a better idea how SQLAlchemy works
> > http://www.sqlalchemy.org/docs/05/sqlalchemy_0_5_5.pdf
> >
> > I have to admit that I haven't used SQLAlchemy in a real project yet.
> > However I can imagine doing so. Comparing this to what we have on
> > hackage I'd say some work has to be done to get close to SQLAlchemy.
> >
> > The backend doesn't have to be a relational database. However I'd like
> > to use this kind of abstraction in haskell.
> >
> > Is there anyone interested in helping building a library which
> > a) let's you define kind of model of you data
> > b) let's you store you model in any backend (maybe a relational
> >database)
> > c) does static checking of your queries at compilation time?
> >
> > Right now I'd say the best way to go is define the model in the
> > application and not get the scheme from an existing database because
> > there is not way to store all scheme details within a relational model.
> > I think SQLAlchemy does it right by providing a way to define the model
> > in python.
> >
> > Of course haskell doesn't have "objects" to store. But GADTs could be
> > stored (data Foo = ...)
> >
> > So are there any volunteers who are interested in helping writing this
> > kind of storage solution for haskell which could be used in real world
> > business apps?
> >
> > Maybe this does already exist and I've missed it?
> >
> > Marc Weber
> > ___
> > 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
>



-- 
"The greatest obstacle to discovering the shape of the earth, the
continents, and the oceans was not ignorance but the illusion of knowledge."

- Daniel J. Boorstin
___
Haskell-Cafe mailing list
Ha

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[Brent Yorgey]

On Tue, Jun 30, 2009 at 09:45:45AM -0700, Bryan O'Sullivan wrote:
> I've thought for a while that it would be very nice indeed if the Monoid
> class had a more concise operator for infix appending than "a `mappend` b".
> I wonder if other people are of a similar opinion, and if so, whether this
> is worth submitting a libraries@ proposal over.

+1.

IIRC Jules Bean has proposed using (+>) for this purpose, which I
like.  It has the advantages of (a) not clashing with any other
(common) operators, (b) making more obvious the fact that mappend is
not necessarily commutative, and (c) providing the obvious (<+) for
'flip mappend' which is sometimes useful.

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

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[Daniel Peebles]

Except that in this case the operator is associative :P

On Tue, Jun 30, 2009 at 2:42 PM, David Leimbach wrote:
>
>
> On Tue, Jun 30, 2009 at 10:04 AM, Bryan O'Sullivan 
> wrote:
>>
>> On Tue, Jun 30, 2009 at 9:50 AM, David Leimbach  wrote:
>>>
>>> I actually worry that this will make people think, more incorrectly, that
>>> Monoids are about appending stuff only.
>>
>> I think that adding a graphical operator as a synonym for mappend would
>> actually help to address that, since the magic word "append" would no longer
>> be nearly as common in source code, and that textual name certainly is
>> (unhelpfully) suggestive of a specific semantics.
>
> Yeah the textual name doesn't help one bit.  Much like "return" confuses
> folks in Monads.  However, I think most people learn Haskell in stages where
> ++ is introduced as an append operation *before* they even
> come across the term "Monoid".  I feel that though this may have a lesser degenerative impact on the newbie's ability to learn Monoids, that it still contributes to the confusion a bit.
> Then again, anyone who's had to deal with overloaded operators in any language should learn never to assume anything about overloaded operators...
>
> Dave
> ___
> 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] Monoid wants a (++) equivalent

[David Leimbach]

On Tue, Jun 30, 2009 at 10:04 AM, Bryan O'Sullivan wrote:

> On Tue, Jun 30, 2009 at 9:50 AM, David Leimbach  wrote:
>
>> I actually worry that this will make people think, more incorrectly, that
>> Monoids are about appending stuff only.
>>
>
> I think that adding a graphical operator as a synonym for mappend would
> actually help to address that, since the magic word "append" would no longer
> be nearly as common in source code, and that textual name certainly is
> (unhelpfully) suggestive of a specific semantics.
>

Yeah the textual name doesn't help one bit.  Much like "return" confuses
folks in Monads.  However, I think most people learn Haskell in stages where
++ is introduced as an append operation *before* they even
come across the term "Monoid".  I feel that though this may have a
lesser degenerative impact on the newbie's ability to learn Monoids,
that it still contributes to the confusion a bit.

Then again, anyone who's had to deal with overloaded operators in any
language should learn never to assume anything about overloaded
operators...


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

Re: [Haskell-cafe] Making a strict (non-lazy) GCL Interpreter

[Hector Guilarte]

Thanks Ketil, I'll try to give that a try, but as I said beforen, I don't know 
anything about monads, and since this project is for next monday and I have 
many other projects for the University for next week too I can't learn them 
right now... What I need to do is randomly select an element from a List... Any 
Ideas? Also, I had another question in my original e-mail... Any ideas about 
that?
--Original Message--
From: Ketil Malde
To: Hector Guilarte
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Making a strict (non-lazy) GCL Interpreter
Sent: Jun 30, 2009 05:00

Hector Guilarte  writes:

>   I need to randomly select ONE of the valid conditions and execute it's
> instruction. I know there is a Random Monad, but it returns an IO
> Int,

No, this is not right.  Values in the Random monad are computations
that rely on randomness, but they can produce values of arbitrary
type.  (The 'a' in 'Random a', no?)

> Is there anyway I can do some Random that doesn't involve IO? or any other
> solution?

Some options are:  

1.  Use the IO monad
2.  Use the Random monad
3.  Pass around a RandomGen explicitly
4.  Generate an infinite stream of random values, and pass that around 

I think option 2 is the nicest, but option 4 may work if the use of
randomness is limited.  No. 3 does the same as 2 (I presume, I never
looked) but with a lot more noise in your code, and no. 1 erases the
separation between real IO, and computations -- which IME includes a
lot of them -- that happen to depend on randomness (but require no
other IO).

-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] ORM for haskell?

[Daniel Peebles]

I don't have a good answer to your question, but I'm curious of how
lazy loading of SQL-based records would work. It seems like having
another user of the database modify your record before you've loaded
it all could lead to an inconsistent record (assuming you've already
loaded and memoized some fields and not others).

On Tue, Jun 30, 2009 at 1:52 PM, Marc Weber wrote:
> Some time ago I stumbled upon SQLAlchemy which is a great ORM wrapper
> library for python. It has a nice syntax I'd like to see in a haskell
> library as well.
>
> SQLAlchemy already provides some lazy features such as loading subitems
> on access etc.
>
> All haskell SQL libraries I know only let you run SQL statements but not
> much more. To start real business you no longer want to write many SQL
> commands.
>
> Example why it matters:
> schools - 1:n - teachers - 1:n - pupils
>
> If you want to list all schools which have a pupil with age > 3 you'd
> write an sql query like this:
>
>  SELECT dictinct * FROM schools as s JOIN teachers t ON (t.school_id = s.id) 
> JOIN pupils as p ON (p.teacher_id = t.id) WHERE p.age > 3
>
>  in SQLAlchemy it looks like this:
>  session.query(School).join(School.teachers).join(Teacher.pupils).filter(Pupil.age
>  > 3).all()
>
>  difference? Because SQLAlchemy knows about the relations you don't have
>  to remember alias names. So there is no chance to get that wrong.
>
>
> Another example: Updating the age of a pupil:
>
>  row = SELECT * FROM pupils where age = 13;
>  UPDATE pupils SET age = 14 WHERE id = 
>
>  p = session.query(Pupil).filter(Pupil.age==13).one().age=14
>  session.commit()
>
>  difference?
>  You don't have to care about ids. you just assign a new value and tell
>  the engine that it should commit.
>  So again less chances to get something wrong.
>
>
> What about trees (eg web site navigation)
>
>  id   |  title    | parent_id
>  1   |  top      | null
>  2   |  submenu  | 1
>  3   |  submenu2 | 1
>
> should result in
>
> top
>  - submenu
>  - submenu2
>
> using SQLAlchemy you can just do
>
> parent = session.query('nodes').filter(Node.id = 1)
>
> def print(node):
>  print node.title
>  print node.subnodes # this will run a subquery automatically for you 
> returning submenu{,2}
>
> Again no sql. No chance to get something wrong?
>
> You can skim the manual to get a better idea how SQLAlchemy works
> http://www.sqlalchemy.org/docs/05/sqlalchemy_0_5_5.pdf
>
> I have to admit that I haven't used SQLAlchemy in a real project yet.
> However I can imagine doing so. Comparing this to what we have on
> hackage I'd say some work has to be done to get close to SQLAlchemy.
>
> The backend doesn't have to be a relational database. However I'd like
> to use this kind of abstraction in haskell.
>
> Is there anyone interested in helping building a library which
> a) let's you define kind of model of you data
> b) let's you store you model in any backend (maybe a relational
>    database)
> c) does static checking of your queries at compilation time?
>
> Right now I'd say the best way to go is define the model in the
> application and not get the scheme from an existing database because
> there is not way to store all scheme details within a relational model.
> I think SQLAlchemy does it right by providing a way to define the model
> in python.
>
> Of course haskell doesn't have "objects" to store. But GADTs could be
> stored (data Foo = ...)
>
> So are there any volunteers who are interested in helping writing this
> kind of storage solution for haskell which could be used in real world
> business apps?
>
> Maybe this does already exist and I've missed it?
>
> Marc Weber
> ___
> 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] ANN: package Boolean: Generalized booleans

[Conal Elliott]

Does this code compile?  I'd expect that

  instance Bool (Js JsBool) (Js r) where

violates the fundep, since it applies for *all* values of r, not just to
one.

   - Conal

On Tue, Jun 30, 2009 at 8:53 AM, Sebastiaan Visser wrote:

> On Jun 30, 2009, at 5:24 PM, Conal Elliott wrote:
>
>> Hi Sebastiaan,
>>
>> I like your extensions of generalized booleans to other common Haskell
>> types!
>>
>> I also prefer using type families to fundeps.  In this case I didn't
>> because of some awkwardness with vector operations, but I'm going to try
>> again.
>>
>> I'm confused about your particular fundep choice.  For instance,
>>
>> class Bool f r | f -> r where
>>  bool  :: r -> r -> f -> r
>>  false :: f
>>  true  :: f
>>
>> Do you *really* mean that the boolean type f determines the value type r?
>>
>
> Yes, that is really what I mean. This can be used to enforce that the
> return value of elimination can be restricted by the boolean type. This is
> especially useful when using GADTs to encode your domain language.
>
> For example, take this simple JavaScript language:
>  data Js a where
>Prim :: String -> Js a-- Primitive embedding.
>App :: Js (a -> b) -> Js a -> Js b-- Function application.
>
>  data JsBool
>
> Now the functional dependencies can be used to enforce that eliminating
> booleans in the Js domain always returns a value in the Js domain:
>  instance Bool (Js JsBool) (Js r) where
>bool f t c = Prim "(function ifthenelse (f, t, c) c ? t : f)" `App` f
> `App` t `App` c
>true  = Prim "true"
>false = Prim "false"
> Getting rid of this fundep and using type families will probably be a lot
> more intuitive.
>
> Any suggestions on how to enforce elimination to be able to go from `Js
> JsBool -> Js r' using other techniques?
>
>> Regards,   - Conal
>>
>> ...
>>
>
> --
> Sebastiaan Visser
>
>
>
>

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

Re: [Haskell-cafe] Suggestions for simulating Object ID

[Jan Christiansen]

Hi,

On 30.06.2009, at 11:55, Hemanth Kapila wrote:

Can some one please suggest something on simulating some sort of  
"object-Ids" in Haskell?


I mean, something like the following relation will hold:
> a1 == a2  =  (objectID a1) == (objectID a2)


I am not quite sure but perhaps Stable Names are also interesting for  
you.


They only provide the following:

 mkStableName x == mkStableName y => x == y

http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName.html
"Stable names are a way of performing fast (O(1)), not-quite-exact  
comparison between objects.


Stable names solve the following problem: suppose you want to build a  
hash table with Haskell objects as keys, but you want to use pointer  
equality for comparison; maybe because the keys are large and hashing  
would be slow, or perhaps because the keys are infinite in size. We  
can't build a hash table using the address of the object as the key,  
because objects get moved around by the garbage collector, meaning a  
re-hash would be necessary after every garbage collection."


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

Re: [Haskell-cafe] How to read safely?

[Marcos Viera]

The package ChristmasTree includes an alternative version of read which 
catches (and repairs if you want) errors.


The package contains the code of the paper
@inproceedings{1411296,
author = {Marcos Viera and S. Doaitse Swierstra and Eelco Lempsink},

title = {Haskell, do you read me?: constructing and composing efficient 
top-down parsers at runtime}, booktitle = {Haskell '08: Proceedings of 
the first ACM SIGPLAN symposium on Haskell},


year = {2008},
isbn = {978-1-60558-064-7},
pages = {63--74},
location = {Victoria, BC, Canada},
doi = {http://doi.acm.org/10.1145/1411286.1411296},
publisher = {ACM},
address = {New York, NY, USA},
}


cheers,
 marcos

[1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ChristmasTree



Magicloud Magiclouds wrote:

Hi,
  Read often throws runtime errors, which breaks the robust of the
problem. How to deal with it? Without lost too much proformance (so
reads is a no).
  At least, if its error could be catched, that'd be better.


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

[Haskell-cafe] ORM for haskell?

[Marc Weber]

Some time ago I stumbled upon SQLAlchemy which is a great ORM wrapper
library for python. It has a nice syntax I'd like to see in a haskell
library as well.

SQLAlchemy already provides some lazy features such as loading subitems
on access etc.

All haskell SQL libraries I know only let you run SQL statements but not
much more. To start real business you no longer want to write many SQL
commands.

Example why it matters:
schools - 1:n - teachers - 1:n - pupils

If you want to list all schools which have a pupil with age > 3 you'd
write an sql query like this:

  SELECT dictinct * FROM schools as s JOIN teachers t ON (t.school_id = s.id) 
JOIN pupils as p ON (p.teacher_id = t.id) WHERE p.age > 3

  in SQLAlchemy it looks like this:
  
session.query(School).join(School.teachers).join(Teacher.pupils).filter(Pupil.age
 > 3).all()

  difference? Because SQLAlchemy knows about the relations you don't have
  to remember alias names. So there is no chance to get that wrong.


Another example: Updating the age of a pupil:

  row = SELECT * FROM pupils where age = 13;
  UPDATE pupils SET age = 14 WHERE id = 

  p = session.query(Pupil).filter(Pupil.age==13).one().age=14
  session.commit()

  difference?
  You don't have to care about ids. you just assign a new value and tell
  the engine that it should commit.
  So again less chances to get something wrong.


What about trees (eg web site navigation)

 id   |  title| parent_id
  1   |  top  | null
  2   |  submenu  | 1
  3   |  submenu2 | 1

should result in

top
  - submenu
  - submenu2

using SQLAlchemy you can just do

parent = session.query('nodes').filter(Node.id = 1)

def print(node):
  print node.title
  print node.subnodes # this will run a subquery automatically for you 
returning submenu{,2}

Again no sql. No chance to get something wrong?

You can skim the manual to get a better idea how SQLAlchemy works
http://www.sqlalchemy.org/docs/05/sqlalchemy_0_5_5.pdf

I have to admit that I haven't used SQLAlchemy in a real project yet.
However I can imagine doing so. Comparing this to what we have on
hackage I'd say some work has to be done to get close to SQLAlchemy.

The backend doesn't have to be a relational database. However I'd like
to use this kind of abstraction in haskell.

Is there anyone interested in helping building a library which
a) let's you define kind of model of you data
b) let's you store you model in any backend (maybe a relational
database)
c) does static checking of your queries at compilation time?

Right now I'd say the best way to go is define the model in the
application and not get the scheme from an existing database because
there is not way to store all scheme details within a relational model.
I think SQLAlchemy does it right by providing a way to define the model
in python.

Of course haskell doesn't have "objects" to store. But GADTs could be
stored (data Foo = ...)

So are there any volunteers who are interested in helping writing this
kind of storage solution for haskell which could be used in real world
business apps?

Maybe this does already exist and I've missed it?

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

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[Josh Lee]

Isn't "++" itself the perfect Monoid operator? Lambdabot seems to think so.

On Tue, Jun 30, 2009 at 13:04, Edward Kmett wrote:
> I love the idea, but its tricky to come up with one that is good that won't
> break a lot of user code that imports Data.Monoid unqualified.
> -Edward Kmett
>
> On Tue, Jun 30, 2009 at 12:45 PM, Bryan O'Sullivan 
> wrote:
>>
>> I've thought for a while that it would be very nice indeed if the Monoid
>> class had a more concise operator for infix appending than "a `mappend` b".
>> I wonder if other people are of a similar opinion, and if so, whether this
>> is worth submitting a libraries@ proposal over.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monoid wants a (++) equivalent

[Edward Kmett]

I love the idea, but its tricky to come up with one that is good that won't
break a lot of user code that imports Data.Monoid unqualified.
-Edward Kmett


On Tue, Jun 30, 2009 at 12:45 PM, Bryan O'Sullivan wrote:

> I've thought for a while that it would be very nice indeed if the Monoid
> class had a more concise operator for infix appending than "a `mappend` b".
> I wonder if other people are of a similar opinion, and if so, whether this
> is worth submitting a libraries@ proposal over.
>
> ___
> 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] Monoid wants a (++) equivalent

[Bryan O'Sullivan]

On Tue, Jun 30, 2009 at 9:50 AM, David Leimbach  wrote:

> I actually worry that this will make people think, more incorrectly, that
> Monoids are about appending stuff only.
>

I think that adding a graphical operator as a synonym for mappend would
actually help to address that, since the magic word "append" would no longer
be nearly as common in source code, and that textual name certainly is
(unhelpfully) suggestive of a specific semantics.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Monoid wants a (++) equivalent

[Bryan O'Sullivan]

I've thought for a while that it would be very nice indeed if the Monoid
class had a more concise operator for infix appending than "a `mappend` b".
I wonder if other people are of a similar opinion, and if so, whether this
is worth submitting a libraries@ proposal over.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Suggestions for simulating Object ID

[Ryan Ingram]

On Tue, Jun 30, 2009 at 9:16 AM, Felipe Lessa wrote:
> On Tue, Jun 30, 2009 at 07:57:07PM +0530, Hemanth Kapila wrote:
>> Can't we come up with something like this staying within the
>> limits of purity?
>
> No, because that would break referential transparency :(.  I.e.,
> it would be possible to distinguish things that should be
> "equal", such as '3' from '1+2'.

This isn't entirely true; you can do something like this:

> newtype Unique = U Integer deriving (Eq)
> newtype UniqueM a = UniqueM (State Integer a) deriving Monad
> runUniqueM (UniqueM a) = evalState a 0

> newUnique = UniqueM $ do
>u <- get
>put $! (u+1)
>return (U u)

Also, if you are willing to go inside of IO/ST for some bits of your
code, you can use some tricks with unsafeInterleaveIO/ST to create
data structures with unique ids that only get created if they are
used; this allows creating infinite data structures and still keeping
object ID.  The returned data structure is still pure if the "U"
constructor is hidden; all we can do is compare uniques for equality.
You can relax this slightly by adding an Ord derivation; this
technically allows you to observe creation order for the uniques which
is wrong, but it's quite useful to be able to use Uniques as map keys.

> data Tree a = Tree a (Tree a) (Tree a)
> infTree :: IO (Tree Unique)
> infTree = do
>r <- newIORef 0
>mkTree r
> mkTree :: IORef Integer -> IO (Tree Unique)
> mkTree r = unsafeInterleaveIO $ do
> v <- readIORef r
> writeIORef r $! (v+1)
> l <- mkTree r
> r <- mkTree r
> return (Tree (U v) l r)

I believe GHC uses this technique internally.

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

Re: [Haskell-cafe] Suggestions for simulating Object ID

[Felipe Lessa]

On Tue, Jun 30, 2009 at 07:57:07PM +0530, Hemanth Kapila wrote:
> Can't we come up with something like this staying within the
> limits of purity?

No, because that would break referential transparency :(.  I.e.,
it would be possible to distinguish things that should be
"equal", such as '3' from '1+2'.

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

Re: [Haskell-cafe] Re: Reflections on the ICFP 2009 programming contest

[Edward Kmett]

The main thing my team implemented in Haskell was a simulator simulator that
took the first two rounds worth of port information and used that to
back into the velocity for each of the satellites. This meant we really only
had to appeal to the actual VM implementation for canonical scoring and to
validate results, which was kind of nice. We implemented the VM itself
independently in python and C to cross-check ourselves and I later put
together a small VM->C compiler once we knew we had the implementation
right.
-Edward Kmett

2009/6/30 Eugene Kirpichov 

> We implemented the VM by writing a smallish compiler to C for it in
> Haskell. It ran *damn* fast, but we couldn't get rid of some bug that
> did not let us run the 4rth task at all, although the others worked
> fine :(
>
> 2009/6/30 Ahn, Ki Yung :
>  > John Meacham 쓴 글:
> >>
> >> I implemented the VM in C, it was pretty obviously geared towards
> >> such an implementation and it took all of an hour. Then I interfaced
> >> with it via the FFI. Why use just one language when you can use two? :)
> >
> > You could also have used Data.Binary.  That's what I did.
> >
> >> I wasn't able to make any time on sunday though so didn't end up
> >> submitting a final entry which is too bad. this was an interesting one.
> >>
> >>John
> >
> >
> > ___
> > 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] Leksah works!

[David Leimbach]

I would love to have a standalone Mac OS X compatible build to try.  As it
stands, I have not been successful getting a Cocoa/Carbon GTK running on
Leopard, and can't afford the time to fight with making it work.
I too typically use Emacs, but also like to use Yi once in a while as well.

Dave

On Tue, Jun 30, 2009 at 7:28 AM, jutaro  wrote:

>
> As Leksah developer I approve your comment.
>
> Even better we will soon have a new release that integrates GHCi and a
> !visual debugger! plus other useful features like much enhanced text search
> with regex and grep and enhanced GUI framework with a tentative support
> for multiple screens. So stay tuned and we appreciate help of any kind.
>
> Jürgen
>
>
> jkff wrote:
> >
> > Hi.
> > Quite a while ago I launched Leksah and couldn't get anything done at
> > all; so I thought it is probably never be completed and abandoned
> > attempts to find an IDE for Haskell.
> >
> > However, 3 days ago I launched the new version and it works fantastic!
> > It has an IntelliSense popup with type annotations, a module browser,
> > build-on-the-fly and other things, even though I used it only for 15
> > minutes (then the ICFP contest began, where I wrote in Python and
> > Java).
> >
> > Main point: It seems a vastly more convenient IDE for Haskell than vim
> > (don't know about emacs-mode).
> >
> > So, I'd like to encourage haskellers to install it and give it a try :)
> >
> > --
> > Eugene Kirpichov
> > Web IR developer, market.yandex.ru
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Leksah-works%21-tp24266240p24272909.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] ANN: package Boolean: Generalized booleans

[Sebastiaan Visser]

On Jun 30, 2009, at 5:24 PM, Conal Elliott wrote:

Hi Sebastiaan,

I like your extensions of generalized booleans to other common  
Haskell types!


I also prefer using type families to fundeps.  In this case I didn't  
because of some awkwardness with vector operations, but I'm going to  
try again.


I'm confused about your particular fundep choice.  For instance,

class Bool f r | f -> r where
 bool  :: r -> r -> f -> r
 false :: f
 true  :: f

Do you *really* mean that the boolean type f determines the value  
type r?


Yes, that is really what I mean. This can be used to enforce that the  
return value of elimination can be restricted by the boolean type.  
This is especially useful when using GADTs to encode your domain  
language.


For example, take this simple JavaScript language:
  data Js a where
Prim :: String -> Js a-- Primitive embedding.
App :: Js (a -> b) -> Js a -> Js b-- Function application.

  data JsBool

Now the functional dependencies can be used to enforce that  
eliminating booleans in the Js domain always returns a value in the Js  
domain:

  instance Bool (Js JsBool) (Js r) where
bool f t c = Prim "(function ifthenelse (f, t, c) c ? t : f)"  
`App` f `App` t `App` c

true  = Prim "true"
false = Prim "false"
Getting rid of this fundep and using type families will probably be a  
lot more intuitive.


Any suggestions on how to enforce elimination to be able to go from  
`Js JsBool -> Js r' using other techniques?

Regards,   - Conal

...


--
Sebastiaan Visser



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

Re: [Haskell-cafe] ANN: package Boolean: Generalized booleans

[Conal Elliott]

Hi Sebastiaan,

I like your extensions of generalized booleans to other common Haskell
types!

I also prefer using type families to fundeps.  In this case I didn't because
of some awkwardness with vector operations, but I'm going to try again.

I'm confused about your particular fundep choice.  For instance,

class Bool f r | f -> r where
 bool  :: r -> r -> f -> r
 false :: f
 true  :: f

Do you *really* mean that the boolean type f determines the value type r?

Regards,   - Conal

On Tue, Jun 30, 2009 at 1:34 AM, Sebastiaan Visser wrote:

>
> On Jun 30, 2009, at 2:44 AM, Conal Elliott wrote:
>
>> I just uploaded a new package [1] for generalized booleans, which provides
>> type classes with generalizations of boolean values & operations,
>> if-then-else, Eq and Ord.  These values & types come up for me with every
>> new deep DSEL, and I think they do for others as well.  The design space has
>> some tricky trade-offs, and I'm not positive I've found the optimum yet.
>>  Users & comments are very welcome.  Please direct discussion to the
>> haskell-cafe list (rather than haskell list).
>>
>
> Conal,
>
> Good work!
>
> Together with Tom Lokhorst I've been working on something very similar.
> We've been using a rather consistent way of eliminating data structures that
> scales well to other data types. Although we are also using functional
> dependencies I think we might want to change them to type families.
>
> Examples:
>
>> class Bool f r | f -> r where
>>  bool  :: r -> r -> f -> r
>>  false :: f
>>  true  :: f
>>
>> class Maybe f a r | f -> a, f -> r where
>>  maybe   :: r -> (a -> r) -> f a -> r
>>  nothing :: f a
>>  just:: a -> f a
>>
>> class Either f a b r | f -> a, f -> b, f -> r where
>>  either :: (a -> r) -> (b -> r) -> f a b -> r
>>  left   :: a -> f a b
>>  right  :: b -> f a b
>>
> Currently we have a very limited and somewhat messy code base on github[1]
> which shows how to instantiate these types to get back the original Haskell
> functionality and how to produce JavaScript code that runs in a browser. The
> the JavaScript instance is very much the same as I used in my FRP to JS
> EDSL[4]. Next target will, off course, be Objective C. :-)
> Our code is not yet release worthy and probably never will be in this form.
> But is would be very nice to see some kind of generalized prelude evolving.
>
>
>  [1]: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Boolean
>>
>>   - Conal
>>
>
> --
> Sebastiaan Visser
>
> [1] http://github.com/tomlokhorst/AwesomePrelude/tree/master
> [2] http://github.com/sebastiaanvisser/frp-js
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Leksah works!

[jutaro]

As Leksah developer I approve your comment.

Even better we will soon have a new release that integrates GHCi and a 
!visual debugger! plus other useful features like much enhanced text search
with regex and grep and enhanced GUI framework with a tentative support 
for multiple screens. So stay tuned and we appreciate help of any kind.

Jürgen   


jkff wrote:
> 
> Hi.
> Quite a while ago I launched Leksah and couldn't get anything done at
> all; so I thought it is probably never be completed and abandoned
> attempts to find an IDE for Haskell.
> 
> However, 3 days ago I launched the new version and it works fantastic!
> It has an IntelliSense popup with type annotations, a module browser,
> build-on-the-fly and other things, even though I used it only for 15
> minutes (then the ICFP contest began, where I wrote in Python and
> Java).
> 
> Main point: It seems a vastly more convenient IDE for Haskell than vim
> (don't know about emacs-mode).
> 
> So, I'd like to encourage haskellers to install it and give it a try :)
> 
> -- 
> Eugene Kirpichov
> Web IR developer, market.yandex.ru
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Leksah-works%21-tp24266240p24272909.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] Suggestions for simulating Object ID

[Hemanth Kapila]

Thank you. It looks perfect for now.
Just that I can create it only inside an IO
(newUnique  is of type  IO Unique)

Perhaps it involves some magic with random numbers or system time.

Can't we come up with something like this staying within the limits of purity?

Thanks
Hemanth





On 6/30/09, Felipe Lessa  wrote:
> On Tue, Jun 30, 2009 at 03:25:26PM +0530, Hemanth Kapila wrote:
>> Can some one please suggest something on simulating some sort of
>> "object-Ids" in Haskell?
>
> Data.Unique[1]?
>
> [1]
> http://hackage.haskell.org/packages/archive/base/latest/doc/html/Data-Unique.html
>
> --
> Felipe.
> ___
> 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] [help] Creating the simplest possible adhoc network

[lysgaard]

Hi. I'm in the quest of exploring adhoc networks together with Haskell. Both
are quite new to me.
I found the  http://hackage.haskell.org/package/adhoc-network-1.0.3 adhoc 
package in Hackage, it's made for the p2p chat client 
http://hackage.haskell.org/package/Barracuda Barracuda .
I've tried to understand the barracuda client, but since my understanding of
Haskell is not the best (yet!) the package becomes to massive for me to
understand. 
I wondered if someone would be kind enough to help me build the simplest
possible adhoc network peer using the 
http://hackage.haskell.org/package/adhoc-network-1.0.3 adhoc library 
What i want to make is just command line proof of concept code for the adhoc
library. But since the documentation is rather sparse (German pdfs) I'm
having real problems understanding how to achieve this.
Have a nice summer!
-Morten
-- 
View this message in context: 
http://www.nabble.com/-help--Creating-the-simplest-possible-adhoc-network-tp24272608p24272608.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] RE: 6.12.1 planning

[Simon Peyton-Jones]

I've dumped all this on a release plans wiki page:
http://hackage.haskell.org/trac/ghc/wiki/Status/Releases

Manuel, Duncan: maybe you can modify the wiki directly?

Simon

| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Simon Marlow
| Sent: 30 June 2009 11:14
| To: glasgow-haskell-us...@haskell.org
| Cc: Manuel M T Chakravarty; Duncan Coutts; Haskell Cafe
| Subject: 6.12.1 planning
| 
| Hi Folks,
| 
| As usual, we're planning a major release of GHC around September.
| Here's our list of the main items currently scheduled for 6.12.1, and
| their status.  If you have the time and inclination to help with any of
| these, please get involved!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Breaking ghci

[Guenther Schmidt]

Hi guys,

actually it involved haskelldb and a table that had 183 columns. In 
order to specify the table with its 183 columns I had to increase the 
context-stack slightly from 20 to a mere 190.


Günther

BTW there is one thing I find a bit unfortunate in otherwise flawless 
haskelldb, each column has to be made an instance of the class FieldTag, 
which makes it impossible to do this in a higer-orderish sort of way.




Yitzchak Gale schrieb:

Günther Schmidt wrote:
  

...*I*
have managed to write code that ghc is not even able to compile due to
exhausting virtual memory!
Top that!
  


Good work Günther!

Joe Fredette wrote:
  

Code or it didn't happen. :)



Yes, how did you do it?

Did it involve very large literals? GHC is known to have some
limitations with that. For example, on my machine, a String
literal that is larger than about 1 Gb will cause GHC to
overflow the RTS stack. And a list literal with only a few
thousand elements can cause GHC to suck up all memory and
bring my computer to its knees.

Examples:

choke1 = "\
\0123456789abcdef\
\0123456789abcdef\
.
.
.
\"

choke2 = [
 0,1,2,3,4,5,6,7,
 0,1,2,3,4,5,6,7,
.
.
.
 0,1,2,3,4,5,6,7,
 99]

Regards,
Yitz
  


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

Re: [Haskell-cafe] Suggestions for simulating Object ID

[Felipe Lessa]

On Tue, Jun 30, 2009 at 03:25:26PM +0530, Hemanth Kapila wrote:
> Can some one please suggest something on simulating some sort of
> "object-Ids" in Haskell?

Data.Unique[1]?

[1] 
http://hackage.haskell.org/packages/archive/base/latest/doc/html/Data-Unique.html

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

[Haskell-cafe] Re: BerkeleyDBXML linking problems.

[Sebastiaan Visser]

(crosspost from haskell-libraries)

Hello all, again.

Meanwhile I've been able to install this package without too much  
trouble on a Linux system. Unfortunately MacOSX is still a problem.  
Both on Linux and Mac I installed the Berkeley DB and DBXML packages  
with `--prefix=/usr' so all include files and libraries end up in a  
standard place.


Also both on Linux and Mac I installed the Haskell BerkeleyDB bindings  
just with:


  cabal install BerkeleyDB

Because the DBXML include files are installed under /usr/include/dbxml/ 
*.hpp and the BerkeleyDBXML binding accesses them without this prefix  
I did:


  cabal install BerkeleyDBXML --extra-include-dirs=/usr/include/dbxml

On both system installation is not a problem. Compiling the demo  
`adventure' included in de bindings distribution works fine on Linux  
but fails on MacOSX. The errors are the ones in my previous mail  
below. A full hpaste of it can be found here[1].


Any idea where the difference in behaviour comes from on these  
platforms and how to fix this? Unfortunately, my knowledge of the c++  
toolchain and Haskell FFI bindings using these is _very_ limited.


Thanks,
Sebastiaan

[1] http://www.hpaste.org/fastcgi/hpaste.fcgi/view?id=6389#a6389

On Jun 26, 2009, at 12:56 PM, Sebastiaan Visser wrote:

Hello all,

After manually specifying where to find the appropriate include and  
library directories for the dbxml distribution, I succeeded to  
install both the BerkeleyDB and the BerkeleyDBXML Haskell bindings.  
They both nicely show up in `ghc-pkg list'.


But when I try to compile my own test or the demo program included  
in the BerkeleyDBXML package it will kindly present me a dozen or so  
pages of linking errors. The top lines are:


 Undefined symbols:
   "std::basic_string,  
std::allocator >::_Rep::_M_destroy(std::allocator  
const&)", referenced from:
   __xmlDocument_setContent in  
libHSBerkeleyDBXML-0.6.2.a(dbxml_helper.o)

   ...

Do I have to tell GHC where to find the original dbxml libraries  
when compiling my BerkeleyDBXML aware Haskell programs?


Small system overview:
 - Mac OS X 10.5.7
 - GHC 6.10.3
 - BerkeleyDB 0.7.1
 - BerkeleyDBXML 0.6.2
 - gcc/g++ 4.0.1

Any clue on how to fix this?

Thanks,

--
Sebastiaan Visser



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

Re: [Haskell-cafe] 6.12.1 planning

[minh thu]

2009/6/30 Simon Marlow :
> Hi Folks,
>
> As usual, we're planning a major release of GHC around September. Here's our
> list of the main items currently scheduled for 6.12.1, and their status.  If
> you have the time and inclination to help with any of these, please get
> involved!
>
> * Parallel performance.  6.12.1 will ship with the improvements to parallel
> performance described in our ICFP 2009 paper.  Still to do: overhaul the
> +RTS GC settings, tune for good performance by default.
>
> * Parallel profiling: the new RTS tracing features will be included, and we
> hope to have a release of ThreadScope to coincide with GHC 6.12.1.
> ThreadScope is written using gtk2hs, and could benefit from someone with
> expertise in producing polished gtk2hs apps - if you can lend a hand,
> contact Satnam Singh .
>
> * Unicode I/O: the new Unicode I/O library is in, and will ship with 6.12.1.
>  Still to do: decide on the public API for changing encodings and newline
> conversion.
>
> * Shared libraries: we intend to ship with shared library support on at
> least x86/Linux and x86-64/Linux.  There are various tasks remaining to do
> here - Duncan, can we have a summary?
>
> * Data Parallel Haskell.  Manuel, can you comment on the state of play?
>  What can we expect in time for 6.12.1?
>
> * Plugin support in GHC.  The patches are not yet in GHC, and as far as I
> know are awaiting review - Simon, can you say more?
>
> * The new backend code generator.  At the moment, it seems unlikely that GHC
> 6.12.1 will ship with the new code generator enabled by default, although it
> may well be available for testing.  Meanwhile, work on it continues.
>
> The smaller items are all embodied in tickets, here are the tickets
> currently in the 6.12.1 milestone (135):
>
> http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.12.1
>
> and on the 6.12 branch (251):
>
> http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.12+branch
>
> I estimate there are 2 man years of work here - needless to say, we aren't
> going to fix all these tickets :)  As usual, if you want to vote for
> something, add your email to the CC field of the ticket.
>
> Several of these tickets would make good tasks for a fledgling GHC hacker.
>  e.g.  http://hackage.haskell.org/trac/ghc/ticket/2362 (allow full import
> syntax in GHCi) has a lot of support, and is a nice self-contained task (but
> not a small one).
>
> Even if you're not a GHC hacker you can still help, e.g. by helping to
> narrow down the cause of a bug, or verifying a bug on your platform.
>
> Let me remind people that GHC HEAD has the new build system, and it's
> actually rather pleasant to work with.  Even if you have no idea what you're
> doing, you can always say 'make' at the top level and the build system will
> figure out what needs doing (ok, so that's what build systems are supposed
> to do, but GHC's has never quite managed it until now!).

It won't help a lot but ... Thanks for all those things, especially
shared libraries support !

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

[Haskell-cafe] 6.12.1 planning

[Simon Marlow]

Hi Folks,

As usual, we're planning a major release of GHC around September. 
Here's our list of the main items currently scheduled for 6.12.1, and 
their status.  If you have the time and inclination to help with any of 
these, please get involved!


* Parallel performance.  6.12.1 will ship with the improvements to 
parallel performance described in our ICFP 2009 paper.  Still to do: 
overhaul the +RTS GC settings, tune for good performance by default.


* Parallel profiling: the new RTS tracing features will be included, and 
we hope to have a release of ThreadScope to coincide with GHC 6.12.1. 
ThreadScope is written using gtk2hs, and could benefit from someone with 
expertise in producing polished gtk2hs apps - if you can lend a hand, 
contact Satnam Singh .


* Unicode I/O: the new Unicode I/O library is in, and will ship with 
6.12.1.  Still to do: decide on the public API for changing encodings 
and newline conversion.


* Shared libraries: we intend to ship with shared library support on at 
least x86/Linux and x86-64/Linux.  There are various tasks remaining to 
do here - Duncan, can we have a summary?


* Data Parallel Haskell.  Manuel, can you comment on the state of play? 
 What can we expect in time for 6.12.1?


* Plugin support in GHC.  The patches are not yet in GHC, and as far as 
I know are awaiting review - Simon, can you say more?


* The new backend code generator.  At the moment, it seems unlikely that 
GHC 6.12.1 will ship with the new code generator enabled by default, 
although it may well be available for testing.  Meanwhile, work on it 
continues.


The smaller items are all embodied in tickets, here are the tickets 
currently in the 6.12.1 milestone (135):


http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.12.1

and on the 6.12 branch (251):

http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.12+branch

I estimate there are 2 man years of work here - needless to say, we 
aren't going to fix all these tickets :)  As usual, if you want to vote 
for something, add your email to the CC field of the ticket.


Several of these tickets would make good tasks for a fledgling GHC 
hacker.  e.g.  http://hackage.haskell.org/trac/ghc/ticket/2362 (allow 
full import syntax in GHCi) has a lot of support, and is a nice 
self-contained task (but not a small one).


Even if you're not a GHC hacker you can still help, e.g. by helping to 
narrow down the cause of a bug, or verifying a bug on your platform.


Let me remind people that GHC HEAD has the new build system, and it's 
actually rather pleasant to work with.  Even if you have no idea what 
you're doing, you can always say 'make' at the top level and the build 
system will figure out what needs doing (ok, so that's what build 
systems are supposed to do, but GHC's has never quite managed it until 
now!).


Cheers,
Simon

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

Re: [Haskell-cafe] Leksah works!

[Hemanth Kapila]

Hi,

Thanks for the update. I just tried it and it is quite cool.Atlhough I am
too addicted to emacs and can't imagine leaving it (at least before hIDE),
I still think leksah is quite useful.

Thanks again



On Tue, Jun 30, 2009 at 10:45 AM, Eugene Kirpichov wrote:

> Hi.
> Quite a while ago I launched Leksah and couldn't get anything done at
> all; so I thought it is probably never be completed and abandoned
> attempts to find an IDE for Haskell.
>
> However, 3 days ago I launched the new version and it works fantastic!
> It has an IntelliSense popup with type annotations, a module browser,
> build-on-the-fly and other things, even though I used it only for 15
> minutes (then the ICFP contest began, where I wrote in Python and
> Java).
>
> Main point: It seems a vastly more convenient IDE for Haskell than vim
> (don't know about emacs-mode).
>
> So, I'd like to encourage haskellers to install it and give it a try :)
>
> --
> 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] coding standard question

[Loup Vaillant]

2009/6/22 Malcolm Wallace :
> Erik de Castro Lopo  wrote:
>
>> Vasili I. Galchin wrote:
>>
>> >  "where/let" functions use the
>> > same name for function parameters as the outer function and hence
>> > there is a "shadow" warning from the compiler.
>>
>> In Haskell there is an easy way around this. Variables can
>> be name a, a', a'' and so on. ...
>> ... its a good idea to fix these warnings.
>
> I would _strongly_ advise not to do that.  By trying to silence the
> spurious warning about shadowing, there is enormous potential to
> introduce new bugs that were not there before.
>
> Example:
>
>  f a b = g (a+b) (b-a)
>        where g a c = a*c
>
> ghc warns that g's parameter a shadows the parameter to f.  So we
> introduce a primed identifier to eliminate the warning:
>
>  f a b = g (a+b) (b-a)
>        where g a' c = a*c
>
> Now, no warnings!  But, oops, this function does not do the same thing.
> We forgot to add a prime to all occurrences of a on the right-hand-side.
>
> Particularly in larger examples, it can be remarkably easy to miss an
> occurrence of the variable whose name you are refactoring.  The key
> point is that in this situation, unlike most refactorings, the compiler
> _cannot_ help you find the mistake with useful error messages or
> warnings.

What about an editor (or emacs mode or…) that support variable renaming?
Maybe there is already one?

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

[Haskell-cafe] Suggestions for simulating Object ID

[Hemanth Kapila]

Hello all,
Can some one please suggest something on simulating some sort of
"object-Ids" in Haskell?

I mean, something like the following relation will hold:
> a1 == a2  =  (objectID a1) == (objectID a2)

Currently I have something like
> import Data.Hash
>import qualified Data.ByteString.Char8  as B

> newtype UniqueID = UniqueID (Hash, B.ByteString)

I have a type class called Identifiable, the instances of which are supposed
to give a unqiue bytestring representation of the instance which can be
arbitrarily long but should satisfy the condition mentioned earlier.

> class  Identifiable a  where
>instanceID :: a  -> B.ByteString


and finally, the required funtion objectID is defined as :
> objectID :: (Hashable a, Identifiable a) => a -> UniqueID
> objectID a1 = UniqueID (hash a1, instanceID a1)


while comparing object Ids, I compare the hash values first (which can be
faster for arbitrary values). Only if they are equal then I
compare the instanceIDs and count on laziness for avoiding the construction
of the bytestrings where they are not needed.

Can you please suggest a better approach?
 I also toyed with the idea of storing all the data 'objects' in an array
and use the index as the identifier but the trouble is I am not aware of all
the number of instances before hand under all the circumstances.

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

Re: [Haskell-cafe] Wondering about c type in haskell.

[John Meacham]

On Tue, Jun 30, 2009 at 10:01:48AM +0800, Magicloud Magiclouds wrote:
> Hi,
>   There are times, when we need to make some system calls, or call C
> library. So we have to deal with C data types.
>   For example, CPid, which is an integer, actually. So we can do
> "fromIntegral pid". Then why do not we define "type CPid = Integer",
> and convert Haskell Integer with C Int internally. So the "user" does
> not have to care about the type convert (everywhere, which is ugly).
> And, specially, when doing something like serialisation, for Haskell
> Integer, the user does not have to do things with precision. But for
> CPid, without the fromIntegral, we have to specify its precision,
> well, on different machine/OS, the precision may not be the same.

Because we need to actually convey to the haskell implementation what
the proper calling conventions for the function are, if we used type
synonyms, we would have no way to know whether the type passed is a
long, short, or whatever. We need to use real types to tell the FFI spec
how to bind to the external function properly.

John

-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Making a strict (non-lazy) GCL Interpreter

[Ketil Malde]

Hector Guilarte  writes:

>   I need to randomly select ONE of the valid conditions and execute it's
> instruction. I know there is a Random Monad, but it returns an IO
> Int,

No, this is not right.  Values in the Random monad are computations
that rely on randomness, but they can produce values of arbitrary
type.  (The 'a' in 'Random a', no?)

> Is there anyway I can do some Random that doesn't involve IO? or any other
> solution?

Some options are:  

1.  Use the IO monad
2.  Use the Random monad
3.  Pass around a RandomGen explicitly
4.  Generate an infinite stream of random values, and pass that around 

I think option 2 is the nicest, but option 4 may work if the use of
randomness is limited.  No. 3 does the same as 2 (I presume, I never
looked) but with a lot more noise in your code, and no. 1 erases the
separation between real IO, and computations -- which IME includes a
lot of them -- that happen to depend on randomness (but require no
other IO).

-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] Breaking ghci

[Yitzchak Gale]

Günther Schmidt wrote:
>> ...*I*
>> have managed to write code that ghc is not even able to compile due to
>> exhausting virtual memory!
>> Top that!

Good work Günther!

Joe Fredette wrote:
> Code or it didn't happen. :)

Yes, how did you do it?

Did it involve very large literals? GHC is known to have some
limitations with that. For example, on my machine, a String
literal that is larger than about 1 Gb will cause GHC to
overflow the RTS stack. And a list literal with only a few
thousand elements can cause GHC to suck up all memory and
bring my computer to its knees.

Examples:

choke1 = "\
\0123456789abcdef\
\0123456789abcdef\
.
.
.
\"

choke2 = [
 0,1,2,3,4,5,6,7,
 0,1,2,3,4,5,6,7,
.
.
.
 0,1,2,3,4,5,6,7,
 99]

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

Re: [Haskell-cafe] ANN: package Boolean: Generalized booleans

[Sebastiaan Visser]

On Jun 30, 2009, at 2:44 AM, Conal Elliott wrote:
I just uploaded a new package [1] for generalized booleans, which  
provides type classes with generalizations of boolean values &  
operations, if-then-else, Eq and Ord.  These values & types come up  
for me with every new deep DSEL, and I think they do for others as  
well.  The design space has some tricky trade-offs, and I'm not  
positive I've found the optimum yet.  Users & comments are very  
welcome.  Please direct discussion to the haskell-cafe list (rather  
than haskell list).


Conal,

Good work!

Together with Tom Lokhorst I've been working on something very  
similar. We've been using a rather consistent way of eliminating data  
structures that scales well to other data types. Although we are also  
using functional dependencies I think we might want to change them to  
type families.


Examples:

class Bool f r | f -> r where
  bool  :: r -> r -> f -> r
  false :: f
  true  :: f

class Maybe f a r | f -> a, f -> r where
  maybe   :: r -> (a -> r) -> f a -> r
  nothing :: f a
  just:: a -> f a

class Either f a b r | f -> a, f -> b, f -> r where
  either :: (a -> r) -> (b -> r) -> f a b -> r
  left   :: a -> f a b
  right  :: b -> f a b
Currently we have a very limited and somewhat messy code base on  
github[1] which shows how to instantiate these types to get back the  
original Haskell functionality and how to produce JavaScript code that  
runs in a browser. The the JavaScript instance is very much the same  
as I used in my FRP to JS EDSL[4]. Next target will, off course, be  
Objective C. :-)
Our code is not yet release worthy and probably never will be in this  
form. But is would be very nice to see some kind of generalized  
prelude evolving.


[1]: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ 
Boolean


   - Conal


--
Sebastiaan Visser

[1] http://github.com/tomlokhorst/AwesomePrelude/tree/master
[2] http://github.com/sebastiaanvisser/frp-js

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

Re: [Haskell-cafe] [: Where the bracket things are? :]

[minh thu]

But it won't help to get the knowledge of GHC's internal he was after...

Thu

2009/6/29 Robert Greayer :
> You can use QuasiQuotation, where your bracketing syntax looks like:
>
> [$foo| blah blah blah |]
>
> and 'foo' represents a quasi-quoter, and the stuff inside the brackets
> is any arbitrary syntax recognized by it.
>
> http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.html#th-quasiquotation
>
>
> On Mon, Jun 29, 2009 at 4:51 PM, Paul Keir wrote:
>> I'd like to add my own custom list delimiters to ghc; such as the [: and :]
>> of Data Parallel Haskell. The purpose is mainly to learn a little about
>> GHC's internals.
>>
>> Any suggestions on the GHC files I should look at first? Alternatively,
>> maybe this is actually possible from outside the compiler.
>>
>> Cheers,
>> Paul
>>
>> ___
>> 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