Re: [Haskell-cafe] Re: What I wish someone had told me...

[Paul Johnson]

Derek Elkins wrote:

All you need is a T-shirt: http://www.cafepress.com/skicalc
  

Or http://www.cafepress.com/l_revolution

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

RE: [Haskell-cafe] Haskell newbie indentation query.

[Ramaswamy, Vivek]

Thanks Jules and Daniel.

That was very helpful.

Regards
-Vivek Ramaswamy-


-Original Message-
From: Jules Bean [mailto:[EMAIL PROTECTED] 
Sent: 15 October 2008 18:19
To: Ramaswamy, Vivek
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Haskell newbie indentation query.

Ramaswamy, Vivek wrote:
> Hello All~
> 
> I have just started with Haskell, and I must confess; I am in love
with it.
> 
> However one area that I am really confused about is indentation.
> 
> Lets take a look at if-else if- else block.

Important point 1.

There are two contexts in haskell programs. Layout and non-layout.

In a non-layout context you can do whatever you like with indentation. 
You can put the newlines wherever you want.

In practice, almost everyone uses layout for the 'top-level' of a 
module. That means that anything flush to the left margin starts a new 
declaration. However, making sure we are not flush to the left margin, 
the following are all fine


x = if True then 1 else 2
x = if True
  then 1
  else 2
x =
  if True
  then 1
  else 2

x =
if True
   then 1
  else 2

because, layout is not relevant in expressions.


Now, "do blocks" are layout blocks. So what you really want us to look 
at is the use of if/then/else in do blocks.

x =
  do
   if True
   then (return 1)
   else (return 2)

The first line in the do block defines the left margin for this block. 
In this example, the first line is the "if" line, that defines the left 
margin. Since the "then" and the "else" are also both on the left 
margin, they are new statements. So, the layout interprets as:

do {if True; then (return 1); else (return 2)}

...which is a parse error, because a statement cannot begin with 'then' 
or 'else'.

any pattern of indentation which keeps the if expression indented 
further to the right will be OK, such as

x =
  do
   if True
then (return 1)
 else (return 2)

x =
  do
   if True
 then (return 1)
else (return 2)

..are both fine.

Does that help?

Jules


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

Re: Re[2]: [Haskell-cafe] Re: What I wish someone had told me...

[Richard O'Keefe]

On 17 Oct 2008, at 9:53 am, Daryoush Mehrtash wrote:

So does this mean that the reason for complexity of generics is the  
Java inheritance?


No.  The reason for the complexity of generics in Java is that
they weren't designed into the language in the first place.
It took several attempts and quite a lot of work to come up with
a version of generics that was 100% interoperable with earlier
JVMs *and* still worth having.

The central fact about Java generics is "erasure semantics";
every Java generic class is equivalent to (and is compiled
as if it were) a Java class without any generics at all.
One has the odd result that there is elaborate type checking
for Java collection classes all of which can be bypassed by
linking it with code compiled in Java 1.4 mode, so that all
the run-time type checking *still* has to be done.

You could have something very like Java generics but without
the strangeness if you designed it into the language from the
beginning, as Betrand Meyer did with Eiffel.  Of course, what
_he_ didn't design in from the beginning was lambdas, now
present as "agents".  Eiffel has its own kinds of strangeness.

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

Re: [Haskell-cafe] List as input

[Brandon S. Allbery KF8NH]

On 2008 Oct 16, at 22:22, leledumbo wrote:
...  If there isn't enough information to set a concrete type at  
the call,

type inference fails. This is what you get with strong typing.

In my case, where does type inference fail? Strong typing is good,  
but quite

confusing when combined with polymorphism.


Consider the types of "show" and "read":

show :: Show a => a -> String -- you could use any variable names but
read :: Read b => String -> b -- I'm doing it this way to make a point

and therefore the type of (read . show) is

	(read . show) :: (Show a, Read b) => a -> b -- a cannot be unified  
with b!


It has no clue that (read . show) are effectively inverses, nor can  
it; you can't describe that with Show and Read.


It would be possible to combine the Show and Read classes into a  
single class which allowed this to work.  What you lose is  
flexibility:  it is possible to define Show for types which cannot be  
read.  Consider, for example, functions:  the Typeable class can be  
used to show a function in terms of its types (as long as it isn't  
polymorphic), but that's useless to read back in.  And outputting a  
function such that it could be read back in would require either  
disassembler+assembler or a virtual machine runtime like the JVM  
or .NET/Mono.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [Haskell-cafe] List as input

[leledumbo]

> How about a list of functions from int to int?

Hmm... it does make sense.
-- 
View this message in context: 
http://www.nabble.com/List-as-input-tp19987726p20026222.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] List as input

[Jason Dagit]

On Thu, Oct 16, 2008 at 7:22 PM, leledumbo <[EMAIL PROTECTED]>wrote:

>
> > ...  If there isn't enough information to set a concrete type at the
> call,
> type inference fails. This is what you get with strong typing.
>
> In my case, where does type inference fail? Strong typing is good, but
> quite
> confusing when combined with polymorphism.
>
> > It isn't. The type of data in the list must be able to be compared.
>
> Oops, sorry. What I mean by "any" is exactly as what you said: "anything
> than can be compared". Can you tell me an example of list whose elements
> can't be compared (don't include user defined types, please) ?


How about a list of functions from int to int?

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

Re: [Haskell-cafe] List as input

[leledumbo]

> ...  If there isn't enough information to set a concrete type at the call,
type inference fails. This is what you get with strong typing.

In my case, where does type inference fail? Strong typing is good, but quite
confusing when combined with polymorphism.

> It isn't. The type of data in the list must be able to be compared. 

Oops, sorry. What I mean by "any" is exactly as what you said: "anything
than can be compared". Can you tell me an example of list whose elements
can't be compared (don't include user defined types, please) ?
-- 
View this message in context: 
http://www.nabble.com/List-as-input-tp19987726p20026066.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] What is this function? (RESOLVED)

[John Ky]

Hi Luke,

Thankyou so much.  I need the sequence function.

What I was after was this:

class Scramblable a where
   scramble :: a -> [a]

instance Scramblable [MyType] where
   scramble values = sequence (map scramble values)

instance Scramblable MyType where
   scramble myType = {- blah blah -}

I was basically after exhaustively generating lots ASTs given a template AST
with lots of leaf values changed.

Thanks,

-John

On Thu, Oct 16, 2008 at 8:39 PM, Luke Palmer <[EMAIL PROTECTED]> wrote:

> 2008/10/16 John Ky <[EMAIL PROTECTED]>:
> > Hi,
> >
> > I've written this function here:
> >
> >scramble [] = []
> >scramble [x] = [[z] | z <- scramble x]
> >scramble (x:xs) =
> >   [(y:z)|y <- scramble x, z <- scramble xs]
> >
> > and (I think) it roughly does what I want it to:
> >
> >*Main> scramble ([]::[Int])
> >[]
> >*Main> scramble ([1]::[Int])
> >[[1],[2]]
>
> So, um, this is nonsense.  You've given it only 1, and yet it outputs
> a 2, yet there is no mention of addition or the literal 2 anywhere in
> your function.
>
> This function looks a lot like the more sensible:
>
>  scramble' n xs = sequence (replicate n xs)
>
> >>> scramble' 0 [1,2,3]
> [[]]
> >>> scramble' 1 [1,2,3]
> [[1],[2],[3]]
> >>> scramble' 2 [1,2,3]
> [[1,1],[1,2],[1,3],[2,1],[2,2],[2,3],[3,1],[3,2],[3,3]]
>
> Where your examples all had [1,2] as the argument.
>
> Luke
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [fun] HaskellDB Talk trailer

[Don Stewart]

kyagrd:
> There is an impressive HaskellDB Talk trailer on the web.
> 
> http://www.vimeo.com/1983774
> 
> Cheers to the HaskellDB developers :-)

AWESOME!

Trailers for talks, eh? The bar has been raised.

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

Re: [Haskell-cafe] Terminal-like Application Design

[Jason Dusek]

Jeff Wheeler <[EMAIL PROTECTED]> wrote:
> I suspect I should be using some sort of monad to represent the commands,
> but I don't fully understand monads, and am not sure how it would apply in
> this context.
>
> Should I be using a monad here, and if so, how?

  At risk of stating the obvious, you will need to us the IO
  monad...

  When you say "use a monad to represent" the commands, that is
  perhaps not necessary. You can represent the commands as data,
  for example:

data MyLanguage = Go | Stop | Left | Right

runMyLanguage :: MyLanguage -> IO ()

  The `runMyLanguage` function serves to transform commands
  as pure data into real IO actions.

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

Re: [Haskell-cafe] Terminal-like Application Design

[Arnar Birgisson]

Hi Jeff,

On Fri, Oct 17, 2008 at 01:29, Jeff Wheeler <[EMAIL PROTECTED]> wrote:
> I'm a slight Haskell newbie, but I'm trying to write a terminal-like
> application that accepts simple commands with optional arguments, and can
> then execute them. Most of these commands will need IO, as later I will want
> to communicate over USB for most of them.

Do you mean a terminal application that runs a "session", accepting
commands interactively? If so, check out Shellac [1].

[1] http://www.cs.princeton.edu/~rdockins/shellac/home/

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

[Haskell-cafe] Terminal-like Application Design

[Jeff Wheeler]

Hi,

I'm a slight Haskell newbie, but I'm trying to write a terminal-like  
application that accepts simple commands with optional arguments, and  
can then execute them. Most of these commands will need IO, as later I  
will want to communicate over USB for most of them.


I was hoping, though, that I could get some comments on the initial  
architecture I've been playing with [1].


I suspect I should be using some sort of monad to represent the  
commands, but I don't fully understand monads, and am not sure how it  
would apply in this context.


Should I be using a monad here, and if so, how?

Thanks in advance,
Jeff Wheeler

[1] http://media.nokrev.com/junk/cli/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] [fun] HaskellDB Talk trailer

[Ahn, Ki Yung]

There is an impressive HaskellDB Talk trailer on the web.

http://www.vimeo.com/1983774

Cheers to the HaskellDB developers :-)

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

Re: [Haskell-cafe] About do notation.

[Jason Dusek]

Thomas M. DuBuisson <[EMAIL PROTECTED]> wrote:
> Story not historically accurate.

  Indeed, you forgot the attribution to Laozi...

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

[Haskell-cafe] Re: Pandoc questions

[John MacFarlane]

+++ Andrew Coppin [Oct 12 08 11:21 ]:
> There doesn't seem to be any option to make Pandoc produce actual MathML  
> output. Is there a reason for this?

1. Nobody has written the LaTeX -> MathML code yet, and I've been too
lazy.  Anyone who is interested in doing this should get in touch.

2. Not all browsers can process MathML. The current system (using the
LaTeXMathML.js javascript) has the advantage of "falling back" to raw
LaTeX in browsers that don't support MathML.

John

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

Re: Re[2]: [Haskell-cafe] Re: What I wish someone had told me...

[Jonathan Cast]

On Thu, 2008-10-16 at 16:25 -0500, Derek Elkins wrote:
> On Thu, 2008-10-16 at 13:53 -0700, Daryoush Mehrtash wrote:
> > So does this mean that the reason for complexity of generics is the
> > Java inheritance?
> > 
> > BTW, in addition to the article I posted, This site:
> > http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html   has a
> > FAQ on Java generics that is 500+ pages long! In Haskell you have
> > parametrized types but I don't think you need 500+ page faq to explain
> > it.  
> 
> All you need is a T-shirt: http://www.cafepress.com/skicalc

I think the same explanation would work for Java, too, except:

* Many more people know Java than know generics (or this was true at one
time), leading to
* A substantial market for teaching generics as a separate language
feature.

I think the market for pedagogical material for teaching polymorphism
(exclusively) to Haskellers is much smaller.  Instead, polymorphism is
taught as an integral part of the language, to people who can't be said
to have mastered Haskell yet at all.

So I don't think counting page sizes of documents associated to the two
language features gives a fair comparison of there complexity.

jcc


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

Re: Re[2]: [Haskell-cafe] Re: What I wish someone had told me...

[Don Stewart]

derek.a.elkins:
> On Thu, 2008-10-16 at 13:53 -0700, Daryoush Mehrtash wrote:
> > So does this mean that the reason for complexity of generics is the
> > Java inheritance?
> > 
> > BTW, in addition to the article I posted, This site:
> > http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html   has a
> > FAQ on Java generics that is 500+ pages long! In Haskell you have
> > parametrized types but I don't think you need 500+ page faq to explain
> > it.  
> 
> All you need is a T-shirt: http://www.cafepress.com/skicalc

Indeed, implementing "generics" is an undergraduate exercise, also,

https://cgi.cse.unsw.edu.au/~cs3161/08s2/cgi-bin/moin.cgi/Assignment%202

And the full spec. fits in one page (or one tshirt, if that's your
preferred medium for typing rules).

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

Re: [Haskell-cafe] Re: Where did House/hOp go?

[Creighton Hogg]

On Thu, Oct 16, 2008 at 3:47 PM, Kenny Graunke <[EMAIL PROTECTED]> wrote:
> Hello!
>
> On Thu, Oct 16, 2008, Donnie Jones  wrote:
> [snip]
>> The site is working for me even now.
>> Unfortunately, the site hasn't really been updated much over the past
>> couple of years and when I e-mailed some people on the Programatica
>> project about the status of House & Osker I never got anything back.
>> The biggest obstacle you may find when trying to set up House & hOp is
>> that hOp is based upon a modified version of a very old GHC and from
>> the last time I looked at it the GHC runtime has changed enough that
>> making a new hOp will be non-trivial.
>
> Indeed!  House 0.8, as listed on the official programatica page, is
> based on GHC 6.2...not so fun to work with these days.
>
> I've spent the last year or so working on House as part of my research,
> and have updated it to GHC 6.8.2 (with a lot of help).  You can get a
> copy of my unofficial "House 0.8.91" sources here:
> http://web.cecs.pdx.edu/~kennyg/house/
>
> It's still a bit of a challenge to build.  Notably, you'll need a 32-bit
> Linux system - it doesn't build on 64-bit linux nor Mac OS X (yet).
>
> If you just want a floppy image, you may as well stick with House 0.8 from
> http://programatica.cs.pdx.edu/House/ ... it's basically the same.

Awesome!  Thanks for working on this!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[2]: [Haskell-cafe] Re: What I wish someone had told me...

[Derek Elkins]

On Thu, 2008-10-16 at 13:53 -0700, Daryoush Mehrtash wrote:
> So does this mean that the reason for complexity of generics is the
> Java inheritance?
> 
> BTW, in addition to the article I posted, This site:
> http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html   has a
> FAQ on Java generics that is 500+ pages long! In Haskell you have
> parametrized types but I don't think you need 500+ page faq to explain
> it.  

All you need is a T-shirt: http://www.cafepress.com/skicalc
> 

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

[Haskell-cafe] Re: Haskell-Cafe Digest, Vol 46, Issue 118

[Alberto G. Corona]

>Personally, I'm loving the whole concept of this puppy:

> GHC.Prim.*reallyUnsafePtrEquality#

>I have absolutely no idea what it does, but it must be something really
>unsafe! ;-)i
I really need reallyUnsafePtrEquality# !  .  I  need it in inside
GHC.Exts if GHC.Prim is being removed. Please!.. I´m involved in a project
for storage and retrieval of heavily autoreferenced data structures. This
functionality is absolutely needed for that!!.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: 2008-10-12 Hackage status with GHC 6.10 release candidate

[Don Stewart]

wren:
> Simon Marlow wrote:
> >wren ng thornton wrote:
> >>Simon Marlow wrote:
> >>>Don Stewart wrote:
>  * GHC.Prim was moved,
> >>>
> >>>Nobody should be importing GHC.Prim, use GHC.Exts instead.
> >>
> >>
> >>This is oft declared, but as things stand I don't think it's a tenable 
> >>position. If someone's bothering to dig as far as GHC.Exts then it's 
> >>very likely they're trying to optimize numeric computations and for 
> >>that there are a number of functions in GHC.Prim which are essential, 
> >>in particular the fast conversion functions for numeric types[1]. If 
> >>those were moved to GHC.Exts then I think many people would be more 
> >>inclined to heed the advice.
> >
> >GHC.Exts re-exports the whole of GHC.Prim.  There's no reason to import 
> >GHC.Prim at all.  Admittedly this isn't immediately obvious from the 
> >documentation, but it is there.  Hopefully in the future we can improve 
> >Haddock so that it'll be able to paste in the whole of GHC.Prim into the 
> >GHC.Exts documentation, and we can then hide GHC.Prim.
> 
> On more recent checking that seems to be the case, however I do recall 
> having issues with it in the past. Seems to work on 6.6 too so I'll 
> switch my stuff over.
> 
> FWIW, if you explicitly re-export the entities by name Haddock will 
> paste them in (though that's a lot of copying in the export list).
> 

Topic added to the wiki,

http://haskell.org/haskellwiki/Upgrading_packages#No_more_GHC.Prim

I'm glad we know how to handle the majority of migration issues
prior to the release. This is a first :)

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

Re: Re[2]: [Haskell-cafe] Re: What I wish someone had told me...

[Daryoush Mehrtash]

So does this mean that the reason for complexity of generics is the Java
inheritance?

BTW, in addition to the article I posted, This site:
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html   has a FAQ
on Java generics that is 500+ pages long! In Haskell you have
parametrized types but I don't think you need 500+ page faq to explain it.

daryoush

On Thu, Oct 16, 2008 at 12:27 PM, Jonathan Cast
<[EMAIL PROTECTED]>wrote:

> On Thu, 2008-10-16 at 12:27 -0700, Robert Greayer wrote:
> > --- On Thu, 10/16/08, Jonathan Cast <[EMAIL PROTECTED]> wrote:
> > > So if I say
> > >
> > > void wrong(List foo, List bar)
> > >
> > > I get two /different/ type variables implicitly filled in?
> > >
> > > If I declare a generic class, and then have a method, is
> > > there a way, in
> > > that method's parameter list, to say `the type
> > > parameter that was
> > > supplied when my class was instantiated'?
> > >
> >
> > Yes -
> > class Foo {
> >...
> >void right(List foo, List bar) {
> >   foo.add(bar.get(0));
> >}
> >
> > Can also do it at the method level...
> >
> > void  alsoRight(List foo, List bar) { ... }
> >
> > > Yikes.  So, in this instance, the difference between
> > > Haskell and Java
> > > is: if you want to disallow that call to wrong, in Haskell
> > > you can...
> > >
> >
> > Not exactly... Java disallows 'wrong' from being written (without
> > class casts and such), because it disallows calling a method which has
> > a wildcard type in a contravariant position.  IIRC, Scala handles all
> > this more elegantly.  If you stay away from '?', and stick to type
> > variables with Java generics, though, how type checking with generics
> > works in Java should be mostly unsurprising to a Haskeller.
>
> Oh, good.
>
> Daryoush Mehrtash:
>
> It looks like the answer to your original question --- gotchas with Java
> generics vs. Haskell polymorphism --- is that the `gotchas' you linked
> to are consequent on using ? in your code, instead of true type
> variables.  So the truly problematic construct is ?, and the difference
> is just that Haskell doesn't have an analogue to it.
>
> jcc
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Where did House/hOp go?

[Kenny Graunke]

Hello!

On Thu, Oct 16, 2008, Donnie Jones  wrote:
[snip]
> The site is working for me even now.
> Unfortunately, the site hasn't really been updated much over the past
> couple of years and when I e-mailed some people on the Programatica
> project about the status of House & Osker I never got anything back.
> The biggest obstacle you may find when trying to set up House & hOp is
> that hOp is based upon a modified version of a very old GHC and from
> the last time I looked at it the GHC runtime has changed enough that
> making a new hOp will be non-trivial.

Indeed!  House 0.8, as listed on the official programatica page, is
based on GHC 6.2...not so fun to work with these days.

I've spent the last year or so working on House as part of my research,
and have updated it to GHC 6.8.2 (with a lot of help).  You can get a
copy of my unofficial "House 0.8.91" sources here:
http://web.cecs.pdx.edu/~kennyg/house/

It's still a bit of a challenge to build.  Notably, you'll need a 32-bit
Linux system - it doesn't build on 64-bit linux nor Mac OS X (yet).

If you just want a floppy image, you may as well stick with House 0.8 from
http://programatica.cs.pdx.edu/House/ ... it's basically the same.

--Kenny

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

Re: [Haskell-cafe] Re: Haskell newbie indentation query.

[Reid Barton]

On Thu, Oct 16, 2008 at 12:57:05PM -0700, Simon Michael wrote:
>> Basically it has a more accurate haskell parser, and it has a simpler  
>> way of cycling through possible indentations: TAB moves to the right 
>> and BACKSPACE to the left.
>
> Unfortunately, it can sometimes fail to parse what's in the buffer, get  
> balky and event prevent you typing anything at all. I had to back out of  
> it for now..

You can use C-q followed by any character to insert a literal copy of
that character, disregarding modes in effect (C-q C-j for a newline).
I have to use this every so often to get around the kind of parse
errors you mention, but I think it's still well worth the improved
tab/backspace behavior.  (In my experience these parsing bugs only
affect editing on the same line or maybe the next line.)

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

[Haskell-cafe] Re: Haskell newbie indentation query.

[Simon Michael]

Basically it has a more accurate haskell parser, and it has a simpler 
way of cycling through possible indentations: TAB moves to the right and 
BACKSPACE to the left.


Unfortunately, it can sometimes fail to parse what's in the buffer, get 
balky and event prevent you typing anything at all. I had to back out of 
it for now..


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

Re: [Haskell-cafe] Very silly

[Dan Weston]

Not that I want or need to defend C++ on this list, but 
reference-counted smart pointers (e.g. boost::shared_ptr<>), embedded 
inside copy-on-write proxy classes, largely simulates eager garbage 
collection. Targeted overriding of the new operator can make this lazier 
for efficiency.


In other words, there are well established idioms in most successful 
languages to solve obvious problems. Haskell's strengths are more in 
making these idioms simple and robust enough for the average user, not 
just the guru, and to make difficult or impossible the misuse of unsafe 
idioms.


Dan

Don Stewart wrote:

asandroq:

Hallo,

Andrew Coppin wrote:

C++ has some interesting ideas. I haven't learned how to use templates
yet, but what I do find interesting is that there is no automatic memory
management, and yet you can still do fairly dynamic programming. I've
never seen any other language that allows this. (I had assumed it's
impossible...) This makes me wonder just now necessary GC really is, and
whether there is some way to avoid it...


 Garbage collection was invented by Lisp implementors because of a
common pattern in functional languages: The sharing of parts of
structures, like lists. In an imperative world this is straightforward,
one allocates a linked list, uses it, and then releases the memory. In a


This is why memory management is a notoriously trivial problem in C++ ;)

-- Don (who thinks that complicated access patterns aren't unique to FP)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe





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

Re: [Haskell-cafe] Re: Haskell newbie indentation query.

[Jules Bean]

Svein Ove Aas wrote:

On Wed, Oct 15, 2008 at 5:25 PM, Jules Bean <[EMAIL PROTECTED]> wrote:

There is a new indentation module which does much better at the indentation
stuff:

http://kuribas.hcoop.net/haskell-indentation.el


I didn't realize until I tried to use yours that there are two
indentation modules in haskell-mode, and I'd been using the inferior
one.


This one isn't mine. It was written by the IRC nick 'kuribas'. His real 
name is in the elisp.




This does mean I can't tell what changes you have made, though. If
it's not too much trouble, could you summarize your changes?


Basically it has a more accurate haskell parser, and it has a simpler 
way of cycling through possible indentations: TAB moves to the right and 
BACKSPACE to the left.



Also, is this code going to make it into haskell-mode proper, or are
there issues preventing that?
If the latter, I wouldn't mind having a darcs repository to pull from.


Good question. I don't know.

I don't know if haskell-mode is actively maintained.

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

Re: Re[2]: [Haskell-cafe] Re: What I wish someone had told me...

[Jonathan Cast]

On Thu, 2008-10-16 at 12:27 -0700, Robert Greayer wrote:
> --- On Thu, 10/16/08, Jonathan Cast <[EMAIL PROTECTED]> wrote:
> > So if I say
> > 
> > void wrong(List foo, List bar)
> > 
> > I get two /different/ type variables implicitly filled in?
> > 
> > If I declare a generic class, and then have a method, is
> > there a way, in
> > that method's parameter list, to say `the type
> > parameter that was
> > supplied when my class was instantiated'?
> > 
> 
> Yes -
> class Foo {
>...
>void right(List foo, List bar) {
>   foo.add(bar.get(0));
>}
> 
> Can also do it at the method level...
> 
> void  alsoRight(List foo, List bar) { ... }
> 
> > Yikes.  So, in this instance, the difference between
> > Haskell and Java
> > is: if you want to disallow that call to wrong, in Haskell
> > you can...
> > 
> 
> Not exactly... Java disallows 'wrong' from being written (without
> class casts and such), because it disallows calling a method which has
> a wildcard type in a contravariant position.  IIRC, Scala handles all
> this more elegantly.  If you stay away from '?', and stick to type
> variables with Java generics, though, how type checking with generics
> works in Java should be mostly unsurprising to a Haskeller.

Oh, good.

Daryoush Mehrtash:

It looks like the answer to your original question --- gotchas with Java
generics vs. Haskell polymorphism --- is that the `gotchas' you linked
to are consequent on using ? in your code, instead of true type
variables.  So the truly problematic construct is ?, and the difference
is just that Haskell doesn't have an analogue to it.

jcc


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

Re: Re[2]: [Haskell-cafe] Re: What I wish someone had told me...

[Robert Greayer]

--- On Thu, 10/16/08, Jonathan Cast <[EMAIL PROTECTED]> wrote:
> So if I say
> 
> void wrong(List foo, List bar)
> 
> I get two /different/ type variables implicitly filled in?
> 
> If I declare a generic class, and then have a method, is
> there a way, in
> that method's parameter list, to say `the type
> parameter that was
> supplied when my class was instantiated'?
> 

Yes -
class Foo {
   ...
   void right(List foo, List bar) {
  foo.add(bar.get(0));
   }

Can also do it at the method level...

void  alsoRight(List foo, List bar) { ... }

> Yikes.  So, in this instance, the difference between
> Haskell and Java
> is: if you want to disallow that call to wrong, in Haskell
> you can...
> 

Not exactly... Java disallows 'wrong' from being written (without class casts 
and such), because it disallows calling a method which has a wildcard type in a 
contravariant position.  IIRC, Scala handles all this more elegantly.  If you 
stay away from '?', and stick to type variables with Java generics, though, how 
type checking with generics works in Java should be mostly unsurprising to a 
Haskeller.




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

Re: [Haskell-cafe] Re: Haskell in Artificial Intelligence

[Chryssochoidis Christos]

I appreciate very much your response sir.
I'm very interested in studying the material on your course's website,  
as well as the links kindly given in the other responses, since in the  
survey I'm making, besides citing and describing the uses of Haskell  
in AI, I should also elaborate  on the advantages that Haskell has as  
a language for AI, some of which you mentioned already.


I'm excited doing this research about Haskell, because it seems that  
the faculty members in the CS department I attend are considering  
introducing Haskell to the AI course offered there, which for a long  
time has been stuck to using imperative languages.


Thank you very much again,

Christos Chryssochoidis


On 14 Οκτ 2008, at 3:29 ΜΜ, Chung-chieh Shan wrote:

Christos Chryssochoidis <[EMAIL PROTECTED]> wrote in  
article <[EMAIL PROTECTED]> in gmane.comp.lang.haskell.cafe:
I'm interested in doing a survey about the use of Haskell in the  
field

of Artificial Intelligence. I searched in Google, and found in the
HaskellWiki, at www.haskell.org/haskellwiki/Haskell_in_industry, two
organizations that use Haskell and do work related to AI. Besides  
that,

I haven't found much else. Could somebody from the Haskell community
give me some pointer to a project or system related to AI that uses
Haskell?


I started using Haskell in my graduate introductory AI course.  The
basic advantage is that of embedding domain-specific languages in
Haskell (well documented in, for example, "Composing Contracts" and
"Playing the DSL Card").  In this case, the embedded language is that
of probability distributions and decision processes.  The Haskell
implementation can simulate a decision process as well as find a best
response strategy.

Unfortunately, the documentation is sparse outside my class lectures,
but you can find the code with comments at
http://conway.rutgers.edu/~ccshan/wiki/cs530/
(search for "Process.lhs").

--
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
Human cognition is not equipped to update the list of players in our
complex social rosters by accommodating a particular person's sudden
inexistence. -- Jesse Bering, Never Say Die: Why We Can't Imagine  
Death.

Scientific American Mind -  October 22, 2008

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


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

Re: [Haskell-cafe] Re: Ubuntu Haskell

[Duncan Coutts]

On Tue, 2008-10-14 at 11:25 +0100, Magnus Therning wrote:

> > It seems to me that it adds confusion (two ways of installing things
> > rather than one) while reducing flexibility and 'freshness' of
> > installation.
> 
> To me it adds simplicity.  I might be developing an in-house tool at
> work, having all the libraries available in distros makes my work
> easier.

Yes, we want distros providing as many good Haskell libs and tools as
possible. Having Cabal -> native translation tools and doing central
package QA seems to me to be the right strategy.

> Playing the devil's advocate I'd say that cabal (not the library
> Cabal, but the tool cabal in cabal-install) is only needed on systems
> with pacakge managers that are broken or completely missing (e.g.
> Windows).  As such cabal is a waste of time and shouldn't have been
> written at all; on many systems it's of no use, on the ones where it
> is useful it's a fix at the wrong level.  Somewhat harsh, and not
> completely in line with my own opinion, but it can be argued that way.

I think they're actually complementary. Sure on Windows it's needed in
place of a native packaging system, but even on systems like debian it's
still needed in places. It's needed for packages that are too new or are
not sufficiently mature or popular to have been packaged yet for the
distro. There will always be such packages. Of course many ordinary
users would be able to make do with the subset of packages that are
provided by the distro and that's great.

Duncan

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

Re: Re[2]: [Haskell-cafe] Re: What I wish someone had told me...

[Jonathan Cast]

On Thu, 2008-10-16 at 11:41 -0700, Robert Greayer wrote:
> --- On Thu, 10/16/08, Jonathan Cast <[EMAIL PROTECTED]> wrote:
> 
> > But I can't say new HashSet()?
> > 
> No... but you can say 'new HashSet()' where T is a type variable,
> and then put a value of type T into your set, which is probably
> generally what you want.  HashSet is a set of unknown (at compile
> time) element type.  It is not safe to put any element into such a
> set.  Consider:
> 
> void wrong(List foo, List bar) {
>foo.add(bar.get(0)); // illegal... but if it weren't...
> }

So if I say

void wrong(List foo, List bar)

I get two /different/ type variables implicitly filled in?

If I declare a generic class, and then have a method, is there a way, in
that method's parameter list, to say `the type parameter that was
supplied when my class was instantiated'?

> ...
> List x = ...;
> List y = ...;
> wrong(x, y); // then this would put an String into a list of ints...

Yikes.  So, in this instance, the difference between Haskell and Java
is: if you want to disallow that call to wrong, in Haskell you can...

> ---

> Perhaps there was confusion over what you meant by 'conjure up a value
> of an unknown type'... you can't explicitly instantiate a
> parameterized class with a wildcard type variable (e.g. new
> HashSet).

Right.  Which is a logical consequence of parametric polymorphism.

> However, you can conjure up an instance of any class for which you
> have a Class object handy, provided it is non-abstract and has public
> constructors, and then assign it to a variable with a wildcard in its
> type.

(Which is a logical consequence of non-parametric polymorphism,
concerning which: yikes!)

jcc


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

Re: Re[2]: [Haskell-cafe] Re: What I wish someone had told me...

[Robert Greayer]

--- On Thu, 10/16/08, Jonathan Cast <[EMAIL PROTECTED]> wrote:

> But I can't say new HashSet()?
> 
No... but you can say 'new HashSet()' where T is a type variable, and then 
put a value of type T into your set, which is probably generally what you want. 
 HashSet is a set of unknown (at compile time) element type.  It is not safe 
to put any element into such a set.  Consider:

void wrong(List foo, List bar) {
   foo.add(bar.get(0)); // illegal... but if it weren't...
}

...
List x = ...;
List y = ...;
wrong(x, y); // then this would put an String into a list of ints...

---

Perhaps there was confusion over what you meant by 'conjure up a value of an 
unknown type'... you can't explicitly instantiate a parameterized class with a 
wildcard type variable (e.g. new HashSet).  However, you can conjure up an 
instance of any class for which you have a Class object handy, provided it is 
non-abstract and has public constructors, and then assign it to a variable with 
a wildcard in its type.





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

[Haskell-cafe] ledger manual available

[Simon Michael]

From: Simon Michael <[EMAIL PROTECTED]>
Date: October 16, 2008 11:36:15 AM PDT
To: haskell-cafe@haskell.org, [EMAIL PROTECTED]
Subject: ledger manual available

This seems to have fallen off the ledger site: the latest ledger  
manual in easily-browsable form. To be clear, this documents the  
mature ledger, not the young hledger released yesterday. But it's a  
good read, gives the big picture and some of it is directly  
applicable to hledger.


one big page: http://joyful.com/repos/ledger/doc/ledger.html
many pages: http://joyful.com/repos/ledger/doc/ledger/
pdf: http://joyful.com/repos/ledger/doc/ledger.pdf




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

[Haskell-cafe] Re: Cabal package with library and tests

[Mauricio]

You might consider looking at the EMGM cabal file in the source.

 https://svn.cs.uu.nl:12443/viewvc/dgp-haskell/EMGM/

 > (...)

 >From the site:

 Échec de la connexion sécurisée
 svn.cs.uu.nl:12443  utilise un
certificat de sécurité invalide.
 Le certificat n'est pas sûr car l'autorité délivrant le certificat est
 inconnue.
 (Code d'erreur : sec_error_unknown_issuer)


That looks like what I see in Firefox when I go to a site that's using a 
non-verified SSL certificate. (...)


Right. I didn't know I could just accept that
and go further...

Yours is actually a very good example on how
to build a customized cabal package :)

Thanks,
Maurício

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

Re: [Haskell-cafe] Very silly

[Don Stewart]

asandroq:
> Hallo,
> 
> Andrew Coppin wrote:
> > 
> > C++ has some interesting ideas. I haven't learned how to use templates
> > yet, but what I do find interesting is that there is no automatic memory
> > management, and yet you can still do fairly dynamic programming. I've
> > never seen any other language that allows this. (I had assumed it's
> > impossible...) This makes me wonder just now necessary GC really is, and
> > whether there is some way to avoid it...
> > 
> 
>  Garbage collection was invented by Lisp implementors because of a
> common pattern in functional languages: The sharing of parts of
> structures, like lists. In an imperative world this is straightforward,
> one allocates a linked list, uses it, and then releases the memory. In a

This is why memory management is a notoriously trivial problem in C++ ;)

-- Don (who thinks that complicated access patterns aren't unique to FP)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] An irritating Parsec problem

[Philippa Cowderoy]

On Thu, 16 Oct 2008, Andrew Coppin wrote:

> Actually, I added this to my real parser, and it actually seems to do exactly
> what I want. Give it an invalid expression and it immediately pinpoints
> exactly where the problem is, why it's a problem, and what you should be doing
> instead. Neat!
> 

Yep. There're some wrinkles (normally involving negation in the grammar), 
but by and large it gets it right - and doubly so if you sprinkle s 
around.

-- 
[EMAIL PROTECTED]

"I think you mean Philippa. I believe Phillipa is the one from an
alternate universe, who has a beard and programs in BASIC, using only
gotos for control flow." -- Anton van Straaten on Lambda the Ultimate
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Where did House/hOp go?

[Creighton Hogg]

2008/10/16 Donnie Jones <[EMAIL PROTECTED]>:
> Hello Svein Ove Aas,
>
> On Thu, Oct 16, 2008 at 12:31 PM, Svein Ove Aas <[EMAIL PROTECTED]> wrote:
>>
>> I'd finally gotten to the point in learning haskell at which they
>> might be interesting to look at, and then.. they were gone.
>>
>> Does anyone know what happened to these projects? They used to be
>> open-source, so the code should still be around somewhere, right?
>
> Below are a few links that hopefully you will find useful.
>
> Haskell and Operating Systems:
> http://www.haskell.org/haskellwiki/Applications_and_libraries/Operating_system
>
> House OS official home page:
> http://programatica.cs.pdx.edu/House/
> This page doesn't seem to be loading at the moment, which I hope is only a
> temporary problem.  I know the source code was available there a few months
> ago since I downloaded the code to House myself.

The site is working for me even now.
Unfortunately, the site hasn't really been updated much over the past
couple of years and when I e-mailed some people on the Programatica
project about the status of House & Osker I never got anything back.
The biggest obstacle you may find when trying to set up House & hOp is
that hOp is based upon a modified version of a very old GHC and from
the last time I looked at it the GHC runtime has changed enough that
making a new hOp will be non-trivial.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Where did House/hOp go?

[Donnie Jones]

Hello Svein Ove Aas,

On Thu, Oct 16, 2008 at 12:31 PM, Svein Ove Aas <[EMAIL PROTECTED]> wrote:

> I'd finally gotten to the point in learning haskell at which they
> might be interesting to look at, and then.. they were gone.
>
> Does anyone know what happened to these projects? They used to be
> open-source, so the code should still be around somewhere, right?
>

Below are a few links that hopefully you will find useful.

Haskell and Operating Systems:
http://www.haskell.org/haskellwiki/Applications_and_libraries/Operating_system

House OS official home page:
http://programatica.cs.pdx.edu/House/
This page doesn't seem to be loading at the moment, which I hope is only a
temporary problem.  I know the source code was available there a few months
ago since I downloaded the code to House myself.

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

Re: [Haskell-cafe] Very silly

[Alex Sandro Queiroz e Silva]

Hallo,

Andrew Coppin wrote:
> 
> C++ has some interesting ideas. I haven't learned how to use templates
> yet, but what I do find interesting is that there is no automatic memory
> management, and yet you can still do fairly dynamic programming. I've
> never seen any other language that allows this. (I had assumed it's
> impossible...) This makes me wonder just now necessary GC really is, and
> whether there is some way to avoid it...
> 

 Garbage collection was invented by Lisp implementors because of a
common pattern in functional languages: The sharing of parts of
structures, like lists. In an imperative world this is straightforward,
one allocates a linked list, uses it, and then releases the memory. In a
world full of closures that may have captured parts of your list, manual
memory management is near impossible.

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

Re: [Haskell-cafe] An irritating Parsec problem

[Andrew Coppin]

Andrew Coppin wrote:

Philippa Cowderoy wrote:

On Wed, 15 Oct 2008, Andrew Coppin wrote:

 

Philippa Cowderoy wrote:
   

expressions = do es <- many1 expression
 eof
 return es


Ah - so "eof" fails if it isn't the end of the input?




eof = notFollowedBy anyChar

(assuming I've got the identifiers right, that's the actual 
definition too)
  


OK, well that'll make it fail alright. Now I just gotta figure out how 
to get a sane error message out of it! ;-)


(The example I showed is very simple; real parsers generally aren't.)


Actually, I added this to my real parser, and it actually seems to do 
exactly what I want. Give it an invalid expression and it immediately 
pinpoints exactly where the problem is, why it's a problem, and what you 
should be doing instead. Neat!


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

Re: [Haskell-cafe] Very silly

[Andrew Coppin]

Juan Carlos Arevalo Baeza wrote:

Andrew Coppin wrote:
Some guy told me that templates are "the best feature in the 
language", and proceeded to show me a huge chunk of highly 
complex-looking code which is approximately equivilent to


 join :: Array x -> Array x -> Array x

I was unimpressed.


  Now I'm curious to know what chunk of code he showed you. FWIW, that 
declaration you put there is done in C++ like so:


template < typename X >
Array join(Array const&, Array const&);

  Nothing more. I like both languages for very different reasons. C++ 
for its insane amount of flexibility, and Haskell for its 
expressiveness. And I've encountered equally harsh roadblocks in both 
whenever I try to get "too crazy" while using them.


Well no, he included the implementation as well as just the signature.

Actually, that's a lie. I was impressed that such a low-level 
language could manage even that much abstraction. But I still prefer 
the Haskell way...


  The dynamic range of the C++ language is probably unparalleled. In 
particular, templates enable implementing high level abstractions in a 
way such that we're still discovering how far it can go. But of 
course, it's not just templates: it's templates when united to all 
other language features like overloading.


C++ has some interesting ideas. I haven't learned how to use templates 
yet, but what I do find interesting is that there is no automatic memory 
management, and yet you can still do fairly dynamic programming. I've 
never seen any other language that allows this. (I had assumed it's 
impossible...) This makes me wonder just now necessary GC really is, and 
whether there is some way to avoid it...


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

Re: Re[2]: [Haskell-cafe] Re: What I wish someone had told me...

[Jonathan Cast]

On Thu, 2008-10-16 at 10:02 -0700, Robert Greayer wrote:
> 
> 
> --- On Thu, 10/16/08, Jonathan Cast <[EMAIL PROTECTED]> wrote:
> 
> > Can I have HashSet?  Could I construct
> > HashSet, if I did?
> 
> Yes:
> 
> HashSet blah = (HashSet) hashSetClass.newInstance();
> 
> ... compiles, and won't throw an exception if hashSetClass truly is
> the class object for HashSet.

But I can't say new HashSet()?

> Pretty useless, because you can't put anything *into* a HashSet
> object...

Even if my client hands my a ? object?

> blah.add("foo"); // doesn't typecheck...
> 
> but you can do:
> HashSet blah = (HashSet) hashSetClass.newInstance();
> blah.add("foo");
> 
> works fine..

jcc


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

Re: Re[2]: [Haskell-cafe] Re: What I wish someone had told me...

[Robert Greayer]

--- On Thu, 10/16/08, Jonathan Cast <[EMAIL PROTECTED]> wrote:

> Can I have HashSet?  Could I construct
> HashSet, if I did?

Yes:

HashSet blah = (HashSet) hashSetClass.newInstance();

... compiles, and won't throw an exception if hashSetClass truly is the class 
object for HashSet.  Pretty useless, because you can't put anything *into* a 
HashSet object...

blah.add("foo"); // doesn't typecheck...

but you can do:
HashSet blah = (HashSet) hashSetClass.newInstance();
blah.add("foo");

works fine..




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

Re: [Haskell-cafe] Very silly

[Juan Carlos Arevalo Baeza]

Andrew Coppin wrote:
Some guy told me that templates are "the best feature in the 
language", and proceeded to show me a huge chunk of highly 
complex-looking code which is approximately equivilent to


 join :: Array x -> Array x -> Array x

I was unimpressed.


 Now I'm curious to know what chunk of code he showed you. FWIW, that 
declaration you put there is done in C++ like so:


template < typename X >
Array join(Array const&, Array const&);

 Nothing more. I like both languages for very different reasons. C++ 
for its insane amount of flexibility, and Haskell for its 
expressiveness. And I've encountered equally harsh roadblocks in both 
whenever I try to get "too crazy" while using them.


Actually, that's a lie. I was impressed that such a low-level language 
could manage even that much abstraction. But I still prefer the 
Haskell way...


 The dynamic range of the C++ language is probably unparalleled. In 
particular, templates enable implementing high level abstractions in a 
way such that we're still discovering how far it can go. But of course, 
it's not just templates: it's templates when united to all other 
language features like overloading.


 Maybe I can take a crack at my own comparison of simple polymorphism 
between C++ and Haskell.


C++:
  template < typename A > struct B { A m; }; // Polymorphic type 
definition
  template <> struct B { int m; }; // Polymorphic type 
specialization
  template < typename A > struct B > { A m; }; // Polymorphic type 
partial specialization
  template < int N > struct B { int m[N]; }; // Non-type 
polymorphic parameters
  template < typename A > struct C { typedef B > type; }; // 
Polymorphic type aliases (type functions) must use trickery and bad syntax

  B const b = { 8 }; // Declare object of polymorphic type
  template < typename A > A get(B const& b) { return b.m; } // 
Polymorphic function using polymorphic type
  int get(B const& b) { return b.m + 1; } // Specialization of 
polymorphic function (actually, it is an overload - functions can't be 
specialized, but this is nearly equivalent)

Haskell:
  data B a = B { m :: a } -- Polymorphic type definition
  // Polymorphic type specializations not available
  // Non-type polymorphic parameters not available (must emulate using 
Peano and such)

  type C a = B (B a) -- Polymorphic type aliases (type functions)
  let b = B 8 :: B Int in -- Declare object of polymorphic type
  get :: B a -> a; get b = m b -- Polymorphic function using 
polymorphic type (declaration and definition separate)
  // Specialization of polymorphic function not available without 
putting the function in a type class


 C++ templates are clearly more flexible, but they are also a lot 
clunkier to use (and both things are very much related). If you look at 
the specializations, and understand them, you'll see that it's easy to 
make a specialization that is incompatible with the main parametric 
(template) type definition. Sometimes, that's a good thing. I've created 
main templates that purposefully fail to compile when used, as a means 
to detect types that need their own particular specialization. But it's 
easy to see how they can have... unexpected consequences. For instance:


B > const bint = { 7 };
B const bintresult = get(bint); // Compiler error! Can you see why? 
A specialization is to blame.


 But the main hurdle is that a template's definition is partially 
untyped. Type-checking of the innards of a template is finalized at the 
time the template is invoked, at which point it is too late for the 
compiler to root-cause any failures it encounters. Thus, using complex 
template-based libraries can be quite inconvenient if you don't get 
things right on your first try. For instance:


C++:
  template < typename A > bool compare(B const& b1, B const& b2) 
{ return b1.m == b2.m; }; // Another polymorphic function

  B val;
  compare(val, val); // This gives out horrible errors if SomeType 
doesn't have the equality operator defined

Haskell:
  compare :: Eq a => B a -> B a -> Bool; compare b1 b2 = m b1 == m b2 
-- Another polymorphic function

  let val = ... :: B SomeType in
  compare val val // This Complains if SomeType is not an instance of Eq

 This is a silly example, and the C++ errors you get are not quite so 
bad. But they can get really, really bad. The new C++ standard they are 
finalizing will "fix" this by adding concepts (akin to type classes) and 
concept_maps (akin to instances). It is interesting to realize, though, 
that in C++, templates must all be resolved at compile time,  whether 
they use concepts or not. There's never any dictionary-passing happening 
anywhere, and all polymorphic functions must be specialized for all the 
different types that are used with them. For runtime polymorphism, C++ 
uses OO classes which are completely separate. OO classes are in some 
way like Haskell classes, but the dictionaries must be embedded in the 
objects themselves, whereas Haskell classes pass the dircti

Re: [Haskell-cafe] Re: Haskell newbie indentation query.

[Svein Ove Aas]

On Wed, Oct 15, 2008 at 5:25 PM, Jules Bean <[EMAIL PROTECTED]> wrote:
>
> There is a new indentation module which does much better at the indentation
> stuff:
>
> http://kuribas.hcoop.net/haskell-indentation.el
>
I didn't realize until I tried to use yours that there are two
indentation modules in haskell-mode, and I'd been using the inferior
one.

This does mean I can't tell what changes you have made, though. If
it's not too much trouble, could you summarize your changes?

Also, is this code going to make it into haskell-mode proper, or are
there issues preventing that?
If the latter, I wouldn't mind having a darcs repository to pull from.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[2]: [Haskell-cafe] Re: What I wish someone had told me...

[Jonathan Cast]

On Thu, 2008-10-16 at 09:48 -0700, Robert Greayer wrote:
> > On Thu, 2008-10-16 at 15:02 +1300, Richard O'Keefe
> > wrote:
> > > On 16 Oct 2008, at 12:09 pm, Jonathan Cast wrote:
> > > >> I am not sure how say in a Java language a
> > constructor can "conjure  
> > > >> up
> > > >> a value of an unknown type".
> > > >
> > > > Well, that's the point.  It can't, in
> > Haskell or in Java.  If you
> > > > understand that --- that you can't call the
> > default constructor of a
> > > > class that is not statically known at compile
> > time
> > > 
> > > If you understand that about Java, then you don't
> > understand Java.
> > 
> > God, I hope never to understand Java.  *shudder*
> > 
> > > Java reflection means that compile-time types are
> > backed up by
> > > runtime objects belonging to Type in general, to Class
> > if they
> > > are class types.  It also means that you can discover
> > the
> > > default constructor by using aClass.getConstructor(),
> > and you
> > > can invoke it by using .newInstance().
> > 
> > Wait, what?  Why can't Java use this to keep template
> > parameters around
> > at run time?  Or is the article (as per which
> > Set and
> > Set are identical at run time) full of it?
> > 
> 
> The article (whichever it was) wasn't full of it... Set and
> Set are identical at runtime.  You cannot, given a Class
> object at runtime that happens to be the Class object corresponding to
> Set, conjure up an instance of Set... but simply for the reason
> that Set has no constructors (it is an interface).

I think we've found our difference between Haskell and Java...

So Set is an interface, thus you can't copy construct it.  Makes
sense --- but does it belong in an article about gotchas with
*generics*?

> You can, however, given a class object that happens to be the class
> object corresponding to (say) HashSet,

Can I have HashSet?  Could I construct HashSet, if I did?

>  conjure up an instance of a HashSet, and assign it to a variable of
> the (static) type Set or Set... i.e.
> 
> Set foo = (Set) hashSetClass.newInstance();
> Set bar = (Set) hashSetClass.newInstance();
> 
> which will generate warnings about unsafe casts, but nevertheless can
> compile, and won't cause any exceptions at runtime.

jcc


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

Re: Re[2]: [Haskell-cafe] Re: What I wish someone had told me...

[Robert Greayer]

> On Thu, 2008-10-16 at 15:02 +1300, Richard O'Keefe
> wrote:
> > On 16 Oct 2008, at 12:09 pm, Jonathan Cast wrote:
> > >> I am not sure how say in a Java language a
> constructor can "conjure  
> > >> up
> > >> a value of an unknown type".
> > >
> > > Well, that's the point.  It can't, in
> Haskell or in Java.  If you
> > > understand that --- that you can't call the
> default constructor of a
> > > class that is not statically known at compile
> time
> > 
> > If you understand that about Java, then you don't
> understand Java.
> 
> God, I hope never to understand Java.  *shudder*
> 
> > Java reflection means that compile-time types are
> backed up by
> > runtime objects belonging to Type in general, to Class
> if they
> > are class types.  It also means that you can discover
> the
> > default constructor by using aClass.getConstructor(),
> and you
> > can invoke it by using .newInstance().
> 
> Wait, what?  Why can't Java use this to keep template
> parameters around
> at run time?  Or is the article (as per which
> Set and
> Set are identical at run time) full of it?
> 

The article (whichever it was) wasn't full of it... Set and 
Set are identical at runtime.  You cannot, given a Class object at 
runtime that happens to be the Class object corresponding to Set, conjure up 
an instance of Set... but simply for the reason that Set has no constructors 
(it is an interface).  You can, however, given a class object that happens to 
be the class object corresponding to (say) HashSet, conjure up an instance of a 
HashSet, and assign it to a variable of the (static) type Set or 
Set... i.e.

Set foo = (Set) hashSetClass.newInstance();
Set bar = (Set) hashSetClass.newInstance();

which will generate warnings about unsafe casts, but nevertheless can compile, 
and won't cause any exceptions at runtime.



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

[Haskell-cafe] Where did House/hOp go?

[Svein Ove Aas]

I'd finally gotten to the point in learning haskell at which they
might be interesting to look at, and then.. they were gone.

Does anyone know what happened to these projects? They used to be
open-source, so the code should still be around somewhere, right?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[2]: [Haskell-cafe] Re: What I wish someone had told me...

[Jonathan Cast]

On Thu, 2008-10-16 at 15:02 +1300, Richard O'Keefe wrote:
> On 16 Oct 2008, at 12:09 pm, Jonathan Cast wrote:
> >> I am not sure how say in a Java language a constructor can "conjure  
> >> up
> >> a value of an unknown type".
> >
> > Well, that's the point.  It can't, in Haskell or in Java.  If you
> > understand that --- that you can't call the default constructor of a
> > class that is not statically known at compile time
> 
> If you understand that about Java, then you don't understand Java.

God, I hope never to understand Java.  *shudder*

> Java reflection means that compile-time types are backed up by
> runtime objects belonging to Type in general, to Class if they
> are class types.  It also means that you can discover the
> default constructor by using aClass.getConstructor(), and you
> can invoke it by using .newInstance().

Wait, what?  Why can't Java use this to keep template parameters around
at run time?  Or is the article (as per which Set and
Set are identical at run time) full of it?

jcc


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

Re: [Haskell-cafe] Re: Repair to floating point enumerations?

[David Roundy]

On Thu, Oct 16, 2008 at 05:36:35PM +0200, Henning Thielemann wrote:
> On Wed, 15 Oct 2008, David Roundy wrote:
>> On Wed, Oct 15, 2008 at 11:25:57PM +0200, Henning Thielemann wrote:
>>> David Roundy schrieb:
>>>
 Why not look for a heuristic that gets the common cases right, rather
 than going with an elegant wrong solution? After all, these
 enumerations are most often used by people who neither care nor know
 how they're implemented, but who most likely would prefer if haskell
 worked as well as matlab, python, etc.
>>>
>>>  Although MatLab has a lot of bad heuristics, they fortunately didn't
>>> try to be too clever with respect to rounding errors. Floating point
>>> enumerations have the same problems in MatLab as in all other languages.
>>
>> I presume you say this because you haven't tried qusing matlab?
>
> I had to use MatLab in the past and remembered problems with rounding
> errors. What you show indicates that they try to be more clever, though.
> But they can't make floating point numbers precise rationals.

Of course not.  It doesn't mean that we shouldn't try to make the
common cases work.

> I suspect that all algorithms that try to solve problems of floating
> point numbers will do something unexpected in certain circumstances. So,
> I think it is better they do it in a way that can be predicted easily. I
> feel much safer with enumeration of integers which are converted to
> floating point numbers than using a heuristics for floating point
> numbers.

I agree that it's nice to have functions whose behavior can be
predicted easily.  This isn't always possible with floating point
numbers due to roundoff error.  The proposed change to the Prelude
removes this "easy-predicting" behavior.  The Prelude was written such
that it was easy to predict what the result would be unless the stop
value is a half-integer number of steps.  This change makes behavior
hard to predict when the stop value is an integer number of steps.  I
assert that an integer number of steps is a more common situation than
a half-integer number of steps, and therefore the Haskell 98 Prelude's
behavior was better.  It isn't be best solution, but it's better than
the proposed alternative.

And with simple syntax, I think simple behavior is best--which means
it should not be dependent on details of roundoff error.

Another alternative would be to say

import Data.Ratio ( (%) )

xxx m n p = map (scale . fromRational . (%num)) [0..num]
  where num = round ((p-m)/(n-m))
scale f = m*(1-f) + p*f

This gives up even approximating the property that each element of the
output differs by (m-n) (which was never true in any of the proposed
implementations, and is impossible in any case).  And in exchange, we
always get a sequence with the requested beginning and ending values.

It has the downside that

(map fromInteger [0,2..9]) :: [Float]

gives a different result from [0,2..9] :: [Float].

But we gain the new feature that

(map fromInteger [1,2..1]) :: [Float]

gives the same result as

[1,2..1] :: [Float]

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

Re: [Haskell-cafe] Rewrite rules

[Henning Thielemann]

On Thu, 16 Oct 2008, George Pollard wrote:


However, in the case he has written about this won't fire, since the LHS
cannot be substituted as `cycle list` is used more than once:


let rlist = cycle list
print ( rlist !! (10^9), rlist !! 0 )


I can get it to fire again if I write it like this:


Perhaps {-# INLINE rlist #-}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Repair to floating point enumerations?

[Henning Thielemann]

On Wed, 15 Oct 2008, David Roundy wrote:


On Wed, Oct 15, 2008 at 11:25:57PM +0200, Henning Thielemann wrote:

David Roundy schrieb:


Why not look for a heuristic that gets the common cases right, rather
than going with an elegant wrong solution? After all, these
enumerations are most often used by people who neither care nor know
how they're implemented, but who most likely would prefer if haskell
worked as well as matlab, python, etc.


 Although MatLab has a lot of bad heuristics, they fortunately didn't
try to be too clever with respect to rounding errors. Floating point
enumerations have the same problems in MatLab as in all other languages.


I presume you say this because you haven't tried qusing matlab?


I had to use MatLab in the past and remembered problems with rounding 
errors. What you show indicates that they try to be more clever, though.

But they can't make floating point numbers precise rationals.




length(0:1/10:0.)


ans =

11


length((0:1:9.999)/10)


ans =

10



zeros(1,10/77*77)

Warning: Size vector should be a row vector with integer elements.

ans =

 0 0 0 0 0 0 0 0 0


I suspect that all algorithms that try to solve problems of floating point 
numbers will do something unexpected in certain circumstances. So, I think 
it is better they do it in a way that can be predicted easily. I feel much 
safer with enumeration of integers which are converted to floating point 
numbers than using a heuristics for floating point numbers.



Haskell or the underlying math library has also heuristics that I don't 
like.


Prelude> (-1)**2 :: Double
1.0
Prelude> (-1)**(2 + 1e-15 - 1e-15) :: Double
NaN

So I think, (**) should be limited to positive bases.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] (OT) Humorous definition for fixed points?

[Holger Siegel]

On Thursday 16 October 2008 02:01:57 Corey O'Connor wrote:
> I was just reminded of one of the joke definitions of recursion:
> "recursion: see recursion".
>
> Perhaps there is a similar one for fixed points?
> "To learn about fixed points find the fixed point of the process:
> Given somebody learn about fixed points from them."

According to the Curry-Howard isomorphism, a fixed point is the center of a 
hermeneutic circle.

Hope this helps.


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

Re: [Haskell-cafe] Re: Cabal package with library and tests

[Sean Leather]

You might consider looking at the EMGM cabal file in the source.
>>
>>  https://svn.cs.uu.nl:12443/viewvc/dgp-haskell/EMGM/
>>
>>  > (...)
>
> From the site:
>
>  Échec de la connexion sécurisée
>  svn.cs.uu.nl:12443 utilise un certificat de sécurité invalide.
>  Le certificat n'est pas sûr car l'autorité délivrant le certificat est
>  inconnue.
>  (Code d'erreur : sec_error_unknown_issuer)
>

That looks like what I see in Firefox when I go to a site that's using a
non-verified SSL certificate. Is that from Firefox and not from the site?
But if it is due to the site, I'm not surprised, but I don't have any
control over that. If the SSL certificate bothers you, you can also look at
the Cabal file and the other source on the Hackage page:

  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/emgm

But of course the Setup.lhs is not there.

The test argument to Setup seems nice. Is there some
> already defined on the hook for tests?
>

Yes, that's the 'runTests' that we use. It's documented in the Cabal user's
guide:


http://www.haskell.org/cabal/release/latest/doc/users-guide/builders.html#setup-test

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

Re: [Haskell-cafe] List as input

[David Leimbach]

On Wed, Oct 15, 2008 at 9:53 PM, leledumbo <[EMAIL PROTECTED]>wrote:

>
> > The compiler doesn't know what kind of list you are trying to read,
> sort, and print.
>
> So, the type must be specific? Then why it's possible to call the sorting
> function with any list?


It isn't.  The type of data in the list must be able to be compared.

See the type signature for Data.List.sort

Data.List.sort :: (Ord a) => [a] -> [a]

So "any" list may be sorted if the items in the list are of Ord.


>
>
> > I'm curious as to why taking the pivot from the middle is an
> 'optimized' version.
>
> Consider if it's used in a GUI program which calls the function when a
> button is pressed. Often, users clicks the button more than once. If the
> pivot is the first (or last) element, the second (and further) click will
> cause worst case scenario to happen. OTOH, if the pivot is the middle
> element, best case scenario will happen.


> --
> View this message in context:
> http://www.nabble.com/List-as-input-tp19987726p20007078.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] FFI Newbie: c functions that want pointers to objects

[Creighton Hogg]

On Thu, Oct 16, 2008 at 7:28 AM, Mauricio <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Some functions in C changes data using pointers,
> like this example:
>
> void change_int (int *n)
> {
>  *n ++;
> }
>
> What is the proper way to handle that? I
> guess I should wrap it like this:
>
> foreign ccall "change_int" change_int
>  :: Ptr CInt -> IO ()
>
> Can I use that on a CInt in Haskell code?
> Like this obviously wrong code, but that
> probably shows what I want:
>
> do
>  let myN = 5
>  change_int myN
>
> Thanks,
> Maurício
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
(Sending to the list as well as just Mauricio this time...oops)
You are wrapping the function correctly, but you need to actually
create the Ptr CInt using the function malloc from
Foreign.Marshal.Alloc, or more conveniently, the function new from
Foreign.Marshal.Utils.

Your code snippet would become
do
  myNPtr <- new 5
  change_int myNPtr
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] FFI Newbie: c functions that want pointers to objects

[Mauricio]

Hi,

Some functions in C changes data using pointers,
like this example:

void change_int (int *n)
{
  *n ++;
}

What is the proper way to handle that? I
guess I should wrap it like this:

foreign ccall "change_int" change_int
 :: Ptr CInt -> IO ()

Can I use that on a CInt in Haskell code?
Like this obviously wrong code, but that
probably shows what I want:

do
  let myN = 5
  change_int myN

Thanks,
Maurício

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

Re: [Haskell-cafe] Monadic Floating Point [was: Linking and unsafePerformIO]

[Scott Turner]

On 2008 October 16 Thursday, Duncan Coutts wrote:
> On Thu, 2008-10-16 at 01:24 +0200, Ariel J. Birnbaum wrote:
> > Floating point operations, at least by IEEE754, depend on environmental
> > settings like the current rounding mode. They may modify state, like the
> > sticky bits that indicate an exception occurred.

> It is an interesting question: can IEEE floating point be done purely
> while preserving the essential features.

The trouble is that the best numerical algorithms have been written using the 
imperative-style IEEE operations for more than 20 years.  If Haskell had a 
floating point monad, then those algorithms could be coded in Haskell. But 
that doesn't seem like an interesting and fruitful approach. Haskell can 
access those algorithms using FFI. 

The test of making IEEE floating point accessible in pure Haskell code is 
whether it stirs any interest in the numerical analysis community.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Cabal package with library and tests

[Mauricio]

I'm writing a Cabal package, using main=defaultMain
in Setup.hs. It has a library, and I want to also
build a few executables so I can test the library.
How am I supposed to do that? (...)


You might consider looking at the EMGM cabal file in the source.

  https://svn.cs.uu.nl:12443/viewvc/dgp-haskell/EMGM/


> (...)

From the site:

  Échec de la connexion sécurisée
  svn.cs.uu.nl:12443 utilise un certificat de sécurité invalide.
  Le certificat n'est pas sûr car l'autorité délivrant le certificat est
  inconnue.
  (Code d'erreur : sec_error_unknown_issuer)


The test argument to Setup seems nice. Is there some
already defined on the hook for tests?

Thanks,
Maurício

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

Re: [Haskell-cafe] Rewrite rules

[George Pollard]

On Thu, 2008-10-16 at 09:01 +0100, Ryan Ingram wrote:
> Isn't this an unsound rewrite?

Yeah, hence the just for fun :)

> Anyways, the reason for inlining not being done if an expression is
> used more than once is that it duplicates work that you explicitly
> specified should only be done once (by placing it in a let).

Okay, thanks :)


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

[Haskell-cafe] Re: 2008-10-12 Hackage status with GHC 6.10 release candidate

[wren ng thornton]

Simon Marlow wrote:

wren ng thornton wrote:

Simon Marlow wrote:

Don Stewart wrote:
> * GHC.Prim was moved,

Nobody should be importing GHC.Prim, use GHC.Exts instead.



This is oft declared, but as things stand I don't think it's a tenable 
position. If someone's bothering to dig as far as GHC.Exts then it's 
very likely they're trying to optimize numeric computations and for 
that there are a number of functions in GHC.Prim which are essential, 
in particular the fast conversion functions for numeric types[1]. If 
those were moved to GHC.Exts then I think many people would be more 
inclined to heed the advice.


GHC.Exts re-exports the whole of GHC.Prim.  There's no reason to import 
GHC.Prim at all.  Admittedly this isn't immediately obvious from the 
documentation, but it is there.  Hopefully in the future we can improve 
Haddock so that it'll be able to paste in the whole of GHC.Prim into the 
GHC.Exts documentation, and we can then hide GHC.Prim.


On more recent checking that seems to be the case, however I do recall 
having issues with it in the past. Seems to work on 6.6 too so I'll 
switch my stuff over.


FWIW, if you explicitly re-export the entities by name Haddock will 
paste them in (though that's a lot of copying in the export list).


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

Re: [Haskell-cafe] What is this function?

[Luke Palmer]

2008/10/16 John Ky <[EMAIL PROTECTED]>:
> Hi,
>
> I've written this function here:
>
>scramble [] = []
>scramble [x] = [[z] | z <- scramble x]
>scramble (x:xs) =
>   [(y:z)|y <- scramble x, z <- scramble xs]
>
> and (I think) it roughly does what I want it to:
>
>*Main> scramble ([]::[Int])
>[]
>*Main> scramble ([1]::[Int])
>[[1],[2]]

So, um, this is nonsense.  You've given it only 1, and yet it outputs
a 2, yet there is no mention of addition or the literal 2 anywhere in
your function.

This function looks a lot like the more sensible:

  scramble' n xs = sequence (replicate n xs)

>>> scramble' 0 [1,2,3]
[[]]
>>> scramble' 1 [1,2,3]
[[1],[2],[3]]
>>> scramble' 2 [1,2,3]
[[1,1],[1,2],[1,3],[2,1],[2,2],[2,3],[3,1],[3,2],[3,3]]

Where your examples all had [1,2] as the argument.

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

[Haskell-cafe] What does laziness buy you?

[Ryan Ingram]

One thing that is hard to communicate to people in industry is what
value laziness has.  You can point people at the WhyFP paper, and talk
about infinite data structures and decoupling generation from search
until you're blue in the face, but it's so far beyond the day-to-day
work of regular programmers that they don't really comprehend.

But I was talking to Simon Marlow yesterday and he pointed out
something that strikes me as a great example to give of "what laziness
buys you".

Lets talk about atomic changes.  In particular, I want to examine the function

atomicModifyIORef :: IORef a -> (a -> (a,b)) -> IO b

This takes an IORef, reads the value out of it, calls some code that
gets a new value and may return some derived data, writes the new
value into the IORef, and returns the derived data.  It has the
invariant that no other change to that IORef can happen in between.

Now, there are all sorts of issues like "what if 'f' has a side
effect" that get sidestepped entirely by purity, but I don't want to
talk about those; I think the benefits of purity are easier to argue
in many contexts.

Lets just look at a simple Haskell implementation:

> atomicModifyIORef p f = do
>a <- readIORef p
>let r = f a
>writeIORef p (fst r)
>return (snd r)

This is a non-atomic implementation, but we can fix it assuming we
have "compare-and-swap" available; any language with boxed types can
do this:

> -- low-level primitive that uses pointer equality behind the scenes
> compareAndSwap# :: IORef a -> a -> a -> IO Bool

> atomicModifyIORef p f = do
> a <- readIORef p
> let r = f a
> let aNew = fst r
> ok <- compareAndSwap# p a aNew
> if ok
> then return (snd r)
> else atomicModifyIORef p f

This loops until compareAndSwap# succeeds and is a simple lock-free
implementation.

But what if f takes a long time to run?  In a strict language, if
there was contention on p, it's likely that atomicModifyIORef never
finishes executing due to starvation!  But since Haskell is lazy, each
attempt to modify p is a constant-time operation!  We just allocate
thunks for "r" and "aNew" and do the compare-and-swap.

Now, the responsibility for executing f is shifted to anyone who reads
from the IORef; they get a thunk.  It's likely that this thread will
do so, as the value returned by atomicModifyIORef depends on f
executing, but if this thread gets suspended or there is contention,
the next reader can pick up the slack!

In fact, at the low level we can improve this further; we can build
the thunks for "r" and "aNew" with a hole to put the value we read out
of the IORef; the inner loop then looks like this:

> a <- readIORef p
> update thunk hole in "r" with "a"
> ok <- compareAndSwap# p a aNew

which compiles down to just a pointer read, assignment, and CAS instruction.

This blew my mind; from the "imperative, strict" point of view, this
sort of operation is impossible to do reasonably, and here in Haskell
we can get a great "probability of success"; the "critical section"
where we have to loop if someone else modified the value behind our
back is just a few instructions long!

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

Re: [Haskell-cafe] What is this function?

[Janis Voigtlaender]

John Ky wrote:

Hi,

I've written this function here:

   scramble [] = []
   scramble [x] = [[z] | z <- scramble x]
   scramble (x:xs) =
  [(y:z)|y <- scramble x, z <- scramble xs]

and (I think) it roughly does what I want it to:


That is strange, as it does not even type-check ;-)

See the "y <- scramble x" part.

--
Dr. Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
mailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Object-oriented programming, Haskell and existentials

[Mitchell, Neil]

> Yes, hbc had existential types around 1993.
> 
> I've used an encoding of existentials in O'Caml (well F#), 
> and it works, but I find it painful.
> And when a very smart but non-CS person saw it his mind 
> boggled, whereas he understood the existential version just fine.

I'm a CS person, and when I saw the encoding of existentials my mind
boggled. I just ended up giving up type checking entirely and using obj
(the F# equivalent of Data.Dynamic) throughout.

Thanks

Neil

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

[Haskell-cafe] What is this function?

[John Ky]

Hi,

I've written this function here:

   scramble [] = []
   scramble [x] = [[z] | z <- scramble x]
   scramble (x:xs) =
  [(y:z)|y <- scramble x, z <- scramble xs]

and (I think) it roughly does what I want it to:

   *Main> scramble ([]::[Int])
   []
   *Main> scramble ([1]::[Int])
   [[1],[2]]
   *Main> scramble ([1,2]::[Int])
   [[1,1],[1,2],[2,1],[2,2]]
   *Main> scramble ([1,2,3]::[Int])
   [[1,1,1],[1,1,2],[1,2,1],[1,2,2],[2,1,1],[2,1,2],[2,2,1],[2,2,2]]

Three questions:

1. What should I call this function?
2. Is there already one in the standard library that does the same thing?
3. Is it possible to rewrite it with only "scramble []" and "scramble
(x:xs)" and not the "scramble[x]"?

Thanks

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

Re: [Haskell-cafe] Object-oriented programming, Haskell and existentials

[Lennart Augustsson]

Yes, hbc had existential types around 1993.

I've used an encoding of existentials in O'Caml (well F#), and it
works, but I find it painful.
And when a very smart but non-CS person saw it his mind boggled,
whereas he understood the existential version just fine.

On Thu, Oct 16, 2008 at 8:26 AM,  <[EMAIL PROTECTED]> wrote:
>
> Lennart Augustsson wrote:
>> We don't need them [existentials] from a theoretical perspective,
>> but in practice I'd rather use existentials than encodinging them
>> in some tricky way.
>
> If the claim that we don't need existentials theoretically is obvious,
> I don't have the argument. Still, existentials are the recurrent topic
> on the OCaml list; quite a few people perceive them as a needed
> feature and their perceived absence as a drawback of OCaml.
>
> The principle of encoding existentials is straightforward: represent
> the existential datatype by a set of its possible
> observations. Existentials demonstrate once again what I sloppily call
> initial-final dichotomy: initial encodings are easier to think of
> upfront, yet require fancier type systems (second-order types,
> dependent types, GADTs). Final encodings are elementary, yet take
> (far) longer to imagine. That difficulty may be just the matter of
> habit.
>
> BTW, wasn't hbc the first Haskell compiler to introduce existentials?
>
>
> The performance grounds for existentials are justified, for example,
> by the following paper
>
> Yasuhiko Minamide, J. Gregory Morrisett and Robert Harper
> Typed Closure Conversion, POPL 1996, pp. 271--283.
> http://www.cs.cmu.edu/~rwh/papers/closures/popl96.ps
>
> Many object encodings may be considered instances of the type closure
> conversion. On the other hand, existential elimination may be seen as
> an inverse process.
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Rewrite rules

[Ryan Ingram]

Isn't this an unsound rewrite?

> cycle [(0 :: Integer)..] !! 100 => 100
> [(0 :: Integer) ..] !! (100 `mod` length [(0::Integer)..]) => _|_

Anyways, the reason for inlining not being done if an expression is
used more than once is that it duplicates work that you explicitly
specified should only be done once (by placing it in a let).  If you
want these declarations to get inlined so rules can fire, you should
be able to do something like this:

> let rlist = cycle list
> {-# INLINE rlist #-}
> print ...

  -- ryan

2008/10/16 George Pollard <[EMAIL PROTECTED]>:
> Section 8.13.2 of the GHC manual[1] states:
>
>> GHC keeps trying to apply the rules as it optimises the program. For
>> example, consider:
>>
>> let s = map f
>>   t = map g
>>   in
>>   s (t xs)
>>
>> The expression s (t xs) does not match the rule "map/map", but GHC
>> will substitute for s and t, giving an expression which does match. If
>> s or t was (a) used more than once, and (b) large or a redex, then it
>> would not be substituted, and the rule would not fire.
>>
> The part I'm interested in here is (a); if an expression is used more
> than one then it cannot be substituted for. Is there any way to work
> around this or force it?
>
> The reason I ask is that as a bit of fun (and inspired by Joachim
> Breitner's blog post [2]) I was going to try writing a rewrite rule for
> the first time. What I had in mind was this:
>
> {-# RULES
>  "index cycled list" forall list n. cycle list !! n =
>list !! (n `mod` length list)
>  #-}
>
> However, in the case he has written about this won't fire, since the LHS
> cannot be substituted as `cycle list` is used more than once:
>
>> let rlist = cycle list
>> print ( rlist !! (10^9), rlist !! 0 )
>
> I can get it to fire again if I write it like this:
>
>> {-# RULES
>>  "!!/cycle" forall list. (!!) (cycle list)  = (\n -> list !! (n `mod` length 
>> list))
>>  #-}
>>
>> ...
>>
>> let rlist = (!!) (cycle list)
>> print (rlist (10^9), rlist 0)
>
> But this is non-obvious and I'd rather have it fire in the first case
> (i.e. when used naïvely). So, back to my question; is there a workaround
> or force for this... or does it break too many things if done?
>
> [1]
> http://www.haskell.org/ghc/docs/latest/html/users_guide/rewrite-rules.html#id414792
>
> [2]
> http://www.joachim-breitner.de/blog/archives/308-guid.html
>
> ___
> 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] Object-oriented programming, Haskell and existentials

[oleg]

Lennart Augustsson wrote:
> We don't need them [existentials] from a theoretical perspective, 
> but in practice I'd rather use existentials than encodinging them 
> in some tricky way.

If the claim that we don't need existentials theoretically is obvious,
I don't have the argument. Still, existentials are the recurrent topic
on the OCaml list; quite a few people perceive them as a needed
feature and their perceived absence as a drawback of OCaml. 

The principle of encoding existentials is straightforward: represent
the existential datatype by a set of its possible
observations. Existentials demonstrate once again what I sloppily call
initial-final dichotomy: initial encodings are easier to think of
upfront, yet require fancier type systems (second-order types,
dependent types, GADTs). Final encodings are elementary, yet take
(far) longer to imagine. That difficulty may be just the matter of
habit.

BTW, wasn't hbc the first Haskell compiler to introduce existentials?


The performance grounds for existentials are justified, for example,
by the following paper

Yasuhiko Minamide, J. Gregory Morrisett and Robert Harper
Typed Closure Conversion, POPL 1996, pp. 271--283.
http://www.cs.cmu.edu/~rwh/papers/closures/popl96.ps

Many object encodings may be considered instances of the type closure
conversion. On the other hand, existential elimination may be seen as
an inverse process.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: What I wish someone had told me...

[Daryoush Mehrtash]

The best analogy I have found on Monads (written for Scala)  is the one that
compared them to Elephants.  The author was referring the the blind men and
elephant story:  http://en.wikipedia.org/wiki/Blind_Men_and_an_Elephant



On Wed, Oct 15, 2008 at 6:40 PM, Derek Elkins <[EMAIL PROTECTED]>wrote:

> On Wed, 2008-10-15 at 08:16 -0700, David Leimbach wrote:
> >
> > On Wed, Oct 15, 2008 at 8:08 AM, John Lato <[EMAIL PROTECTED]> wrote:
> > I'd like to thank everyone who replied to my OP, and also
> > perhaps
> > clarify one point.  I wasn't trying to be argumentative or
> > negative
> > about any work people have done to make Haskell approachable
> > for OO
> > programmers (or any other programmers, for that matter).  I
> > simply
> > wanted to know what others thought about one item that was
> > misleading
> > to me in particular, and to see if others either agreed with
> > me or had
> > similar experiences.
> >
> > That being said, I know that it's a great deal of work to put
> > together
> > a useful tutorial, and I appreciate every one I read.
> >  Especially the
> > monad tutorials, of which it took a half dozen before I got
> > it.
> >
> >
> > I've read a lot of the Monad tutorials, and I feel like I only get "most
> of it" to be 100% honest.
>
> Maybe the problem isn't you, but what you are reading...
> >
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Daryoush

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