Re: [Haskell-cafe] ghci identifier listing question

2009-07-28 Thread Jeff Wheeler
On Mon, Jul 27, 2009 at 6:37 PM, Daniel van den Eijkeld...@gmx.net wrote:

 Is it possible, to reach the (shadowed) values in any way?

I'm not sure about this, but . . .

 Another question: Is it possible to show only those identifiers that are
 defined during the interactive session? I only can list all identifiers
 which start with a given prefix, but I would like to know if GHCi can show
 me all identifiers defined in a given module or in the current session (by
 pressing Tab or alike).

Yes, this will list the current bindings:

 :show bindings

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


RE: [Haskell-cafe] Proposal: TypeDirectedNameResolution

2009-07-28 Thread Sittampalam, Ganesh
Cale Gibbard wrote:

 There was a great related idea on #haskell the other day: Make
 explicit qualification unnecessary whenever there is a *unique*
 choice of module qualifications from those imported which would make
 the expression typecheck. Ambiguities would still need to be
 qualified, but I feel that this would eliminate 99% of all ugly
 qualified names from code. It would be especially good in the case of
 infix operators, which as far as I know, nobody actually enjoys
 qualifying explicitly.   
 
[...]
 What do people think of this idea? Personally, it really annoys me
 whenever I'm forced to give explicit module qualifications, and I
 think this would really help. It would also subsume the
 DisambiguateRecordFields extension rather handily.   

I think this idea would severely damage compositionality. One example of
this is that it would make it substantially less likely that
subexpressions could be abstracted into a separate declaration without
giving a type signature to fix the type of the new declaration.

Ganesh

=== 
 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


Re: [Haskell-cafe] A Question of Restriction

2009-07-28 Thread Wouter Swierstra

Would you be so kind as to elaborate?


Sure. I'll just sketch how to deal the example in your e-mail. If you  
want to use recursive data types (like Lists or Trees), you'll need to  
use the Expr data type from the paper.


Instead of defining:

 data Foo = One | Two | Three | Four

Define the following data types:

 data One = One
 data Two = Two
 data Three = Three
 data Four = Four

You can define the following data type to assemble the pieces:

 infixr 6 :+:
 data (a :+: b) = Inl a | Inr b

So, for example you could define:

 type Odd = One :+: Three
 type Even = Two :+: Four
 type Foo = One :+: Two :+: Three :+: Four

To define functions modularly, it's a good idea to use Haskell's  
clasess to do some of the boring work for you. Here's another example:


 class ToNumber a where
   toNumber :: a - Int

 instance ToNumber One where
toNumber One = 1

(and similar instances for Two, Three, and Four)

The key instance, however, is the following:

 instance (ToNumber a, ToNumber b) = ToNumber (a :+: b) where
toNumber (Inl a) = toNumber a
toNumber (Inr b) = toNumber b

This instance explains how to build instances for Odd, Even, and Foo  
from the instances for One, Two, Three, and Four. An example ghci  
sessions might look like:


*Main let x = Inl One :: Odd
*Main toNumber x
1
*Main let y = Inr (Inr (Inl Three) :: Foo
*Main toNumber y
3

Of course, writing all these injections (Inr (Inr (Inl ...))) gets  
dull quite quickly. The () class in the paper explains how to avoid  
this.


I hope this gives you a better idea of how you might go about solving  
your problem. All the best,


  Wouter



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


Re: [Haskell-cafe] A Question of Restriction

2009-07-28 Thread wren ng thornton

Brian Troutwine wrote:

Hello Wouter.

I've had a go at the paper linked and perused other references found
with Google. Unfortunately, such sophisticated use of the type system
is pretty far out of my normal problem domain and I can't see how to
apply the techniques presented to my motivating example. Would you be
so kind as to elaborate?


data Foo = One | Two | Three | Four
data Odd = One | Three
data Even = Two | Four

==

{-
data Fix f = Fix { unFix :: f (Fix f) }
data (:+:) f g x = Inl (f x) | Inr (g x)
...
-}

data One   r = One
data Two   r = Two
data Three r = Three
data Four  r = Four

instance Functor One   where fmap _ One   = One
instance Functor Two   where fmap _ Two   = Two
instance Functor Three where fmap _ Three = Three
instance Functor Four  where fmap _ Four  = Four

type Foo  = Fix (One :+: Two :+: Three :+: Four)
type Odd  = Fix (One :+: Three)
type Even = Fix (Two :+: Four)


If your original types were actually recursive, then the unfixed 
functors should use their r parameter in place of the recursive call, e.g.


data List a = Nil | Cons a (List a)
==
data List a r = Nil | Cons a r

Also, if you know a certain collection of component types must always 
occur together, then you can flatten parts of the coproduct and use 
normal unions as well. E.g.


data Odd  r = One | Three
data Two  r = Two
data Four r = Four
type Foo= Fix (Odd :+: Two :+: Four)

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


Re: [Haskell-cafe] Proposal: TypeDirectedNameResolution

2009-07-28 Thread Johannes Waldmann
Sittampalam, Ganesh wrote:

 ... it would make it substantially less likely that
 subexpressions could be abstracted into a separate declaration without
 giving a type signature to fix the type of the new declaration.

OK, then give a type signature to fix the type of
(really, to document) the new declaration.

I can't understand why declarative programmers
insist they should be able to omit (type) declarations ...

Best, J.W.



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


RE: [Haskell-cafe] Proposal: TypeDirectedNameResolution

2009-07-28 Thread Sittampalam, Ganesh
(To be clear, this about Cale's proposal, not simonpj's one)

Johannes Waldmann wrote:
 Sittampalam, Ganesh wrote:
 
 ... it would make it substantially less likely that subexpressions
 could be abstracted into a separate declaration without giving a type
 signature to fix the type of the new declaration.
 
 OK, then give a type signature to fix the type of (really, to
 document) the new declaration. 
 
 I can't understand why declarative programmers insist they should be
 able to omit (type) declarations ... 

I find type inference a valuable feature. Generally at some point I
annotate top-level declarations, but while developing it's nice not to
have to worry about it. Having to annotate every single declaration
would be painful.

Ganesh

=== 
 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] Re: Proposal: TypeDirectedNameResolution

2009-07-28 Thread Heinrich Apfelmus
Cale Gibbard wrote:
 There was a great related idea on #haskell the other day: Make
 explicit qualification unnecessary whenever there is a *unique* choice
 of module qualifications from those imported which would make the
 expression typecheck. Ambiguities would still need to be qualified,
 but I feel that this would eliminate 99% of all ugly qualified names
 from code. It would be especially good in the case of infix operators,
 which as far as I know, nobody actually enjoys qualifying explicitly.
 
 [...]
 
 What do people think of this idea? Personally, it really annoys me
 whenever I'm forced to give explicit module qualifications, and I
 think this would really help. It would also subsume the
 DisambiguateRecordFields extension rather handily.

While I do agree that qualified names are annoying at times, I think
that type directed name disambiguation is a Pandora's box.

Furthermore, we already have a mechanism for type based disambiguation,
namely good old type classes. For instance, the qualifications required
when importing  Data.Map  are actually a sign that we are lacking proper
container type classes à la Edison.


There are other possible language extension that may make qualification
easier, Pascal's  with  statement comes to mind.

  http://freepascal.decenturl.com/with-statement-pascal

In Haskell, this would work something like this:

  histogram xs =
  with Data.Map
  foldl' f empty xs
  where
  f m x = case lookup m x where
 Just k  - insertWith x (+1) m
 Nothing - insert x 1 m

In the scope of  with , ambiguous qualifications default to  Data.Map .


Regards,
apfelmus

--
http://apfelmus.nfshost.com

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


Re: [Haskell-cafe] lifting restrictions on defining instances

2009-07-28 Thread wren ng thornton

Tillmann Rendel wrote:

wren ng thornton wrote:
[1] In System F the capital-lambda binder is used for the term-level 
abstraction of passing type representations. So for example we have,


id :: forall a. a - a
id = /\a. \(x::a). x

Thus, the forall keyword is serving as the type-level abstraction. 
Perhaps this is suboptimal syntax, but it is the standard. We could, 
of course, have both a term-level /\ and a type-level /\ where the 
latter is the type of the former (since the namespaces are separate) 
though that's also dubious. Capital-pi is the canonical type-level 
abstraction, though that evokes the idea of dependent types which are 
much more complex.


What do you mean by type-level abstraction here?


I mean an abstraction, as in a lambda-abstraction (aka a 
lambda-expression), at the type level.



In a language with type functions and polymorphism, we need three 
different lambda binders:


  (1) abstraction over terms in terms (to construct functions)
  (2) abstraction over types in terms (to construct polymorphic values)
  (3) abstraction over types in types (to construct type functions)

I think only (2) should be written as upper-case lambdas, while (1) and 
(3) should both be written as lower-case lambdas. Since (1) and (3) 
belong to different syntactic categories, they can not be confused, and 
we can reuse the lower-case lambda at the type-level.


I'm sure that's fine. I was merely pointing out precedent.

The syntax of #3 could also be conflated with the syntax of #2, for the 
same reason: they are in different syntactic categories. I pointed this 
out because the capital-lambda was the syntax others in the thread were 
using. Also, it makes sense to me to have #2 and #3 (abstraction over 
types in _) paired together, rather than #1 and #3 (abstraction over X 
in X). Pairing #2/#3 also gives term/type symmetry as we have for other 
built-ins like [], (,), and - (though the symmetry is imperfect for -).



Furthermore, we need three function types / kinds to describe the three 
lambdas one level higher:


  (4) the type of functions
  (5) the type of polymorphic values
  (6) the kind of type functions

In ghc, we already have forall for (5), and arrows for (4) and (6).

I would say that (3) is the type-level abstraction, not (5).


I'm not sure I follow what you mean. Given the relationship between /\ 
and forall as demonstrated in the definition of id above, I don't see 
such a difference between #3 and #5. That is, given the need for #2 the 
need for #5 follows; from there #3 follows by extending the wording of 
#5. (Though #6 is desirable from a theoretical perspective I'm not sure 
whether the language needs to be able to express it. There's much else 
at the kind-layer we cannot express.)


In other words, just because forall is the type of /\ doesn't mean that 
that's all it is. All of these are effectively identical:


-- Just a type-level lambda
five :: (forall a. a) Int
five = 5

-- Making the term-level match the type exactly
five :: (forall a. a) Int
five = (/\a. 5::a) @Int

-- Hiding a CAF behind a constant type
-- (somewhat like how numeric constants really work)
five :: Int
five = (/\a. 5::a) @Int

-- Boring
five :: Int
five = 5

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


Re: [Haskell-cafe] powerSet = filterM (const [True, False]) ... is this obfuscated haskell?

2009-07-28 Thread Sebastian Fischer
The M is the list, i.e. nondeterminism monad.   For each element in  
the list, there is one return value where it appears (True), and one  
where it does not (False).


This discussion made Curry [1] programmers realise the beauty of non- 
determinism and lead to interesting reformulations of common list  
functions [2].


Here are some of them translated to Haskell:

inits = takeWhileM (const [True,False])
tails = dropWhileM (const [True,False])
perms = sortByM (const [True,False])

Only that Hoogle does not know any of these monadic helper functions.

Cheers,
Sebastian

[1]: http://www.curry-language.org/
[2]: unfortunately not yet in the mailing list archive (http://www.informatik.uni-kiel.de/~mh/curry/listarchive/ 
 Thread title: beautiful non-determinism)



--
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)



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


RE: [Haskell-cafe] powerSet = filterM (const [True, False]) ... is this obfuscated haskell?

2009-07-28 Thread Sittampalam, Ganesh
 perms = sortByM (const [True,False])

This doesn't seem right, since the comparison function is inconsistent
and moreover the results will depend on the sorting algorithm chosen.

Ganesh

=== 
 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


Re: [Haskell-cafe] powerSet = filterM (const [True, False]) ... is this obfuscated haskell?

2009-07-28 Thread Felipe Lessa
On Tue, Jul 28, 2009 at 10:58:53AM +0200, Sebastian Fischer wrote:
 tails = dropWhileM (const [True,False])

Actually this should be

tails = dropWhileM (const [False, True])

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


Re: [Haskell-cafe] ghci identifier listing question

2009-07-28 Thread Daniel van den Eijkel

Ah, thats great! And it shows the values (or part of if), too. Very nice.
Thank you,
Daniel


Jeff Wheeler schrieb:

On Mon, Jul 27, 2009 at 6:37 PM, Daniel van den Eijkeld...@gmx.net wrote:

  

Is it possible, to reach the (shadowed) values in any way?



I'm not sure about this, but . . .

  

Another question: Is it possible to show only those identifiers that are
defined during the interactive session? I only can list all identifiers
which start with a given prefix, but I would like to know if GHCi can show
me all identifiers defined in a given module or in the current session (by
pressing Tab or alike).



Yes, this will list the current bindings:

  

:show bindings



Jeff Wheeler
___
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: Proposal: TypeDirectedNameResolution

2009-07-28 Thread david48
 There are other possible language extension that may make qualification
 easier, Pascal's  with  statement comes to mind.

  http://freepascal.decenturl.com/with-statement-pascal

 In Haskell, this would work something like this:

  histogram xs =
      with Data.Map
          foldl' f empty xs
          where
              f m x = case lookup m x where
                         Just k  - insertWith x (+1) m

I like both that and TDNR. It would be cool that at least one of them
gets accepted in Haskell prime.

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


Re: [Haskell-cafe] lifting restrictions on defining instances

2009-07-28 Thread Tillmann Rendel

wren ng thornton wrote:

Thus, the forall keyword is serving as the type-level abstraction. 


What do you mean by type-level abstraction here?


I mean an abstraction, as in a lambda-abstraction (aka a 
lambda-expression), at the type level.



[...]


I'm not sure I follow what you mean. 


I mean that the forall keyword is *not* serving as the type-level 
abstraction.


There is a difference between abstraction (as in lambda abstraction) and 
the type of abstractions (as in function types). In pure type systems, 
we have two different binders for these different features:


  - lower-case lambda for abstraction (on all levels)
  - upper-case Pi for the type of abstractions (on all levels)

I find it highly confusing to say that forall denotes type-level 
abstraction, because it does not denote abstraction at all. It rather 
denotes the type of an abstraction, namely in Haskell, the type of 
abstracting over types in terms.



In other words, the following is not legal Haskell, and not how forall 
works in any polymorphic lambda calculus:



-- Just a type-level lambda
five :: (forall a. a) Int
five = 5

-- Making the term-level match the type exactly
five :: (forall a. a) Int
five = (/\a. 5::a) @Int


Note that (forall a . a) has kind *, so (forall a . a) Int is not even 
well-kinded, as ghci correctly determines:


   ghci -XRankNTypes
   :k (forall a. a)
  (forall a. a) :: *

   :k (forall a . a) Int
  interactive:1:0:
  Kind error: `forall a. a' is applied to too many type arguments

About syntax:

  (1) abstraction over terms in terms (to construct functions)
  (2) abstraction over types in terms (to construct polymorphic values)
  (3) abstraction over types in types (to construct type functions)


The syntax of #3 could also be conflated with the syntax of #2, for
the same reason: they are in different syntactic categories. I
pointed this out because the capital-lambda was the syntax others in
the thread were using. Also, it makes sense to me to have #2 and #3
(abstraction over types in _) paired together, rather than #1 and
#3 (abstraction over X in X). Pairing #2/#3 also gives term/type
symmetry as we have for other built-ins like [], (,), and - (though
the symmetry is imperfect for -).


I agree that this makes as much sense as my view.

However, I still argue that the existing type/kind symmetry for - 
should be reflected in a term/type symmetry for \. We already have:


  id x = x
  type Id x = x

  :t id
  id :: a - a

  :k Id
  Id :: * - *

And I think anonymous type-level abstraction should look like this:

  id' = \x - x
  type Id' = \x - x

  :t id'
  id' :: a - a

  :k Id'
  Id' :: * - *

I would use the upper-case lambda for kind-polymorphism on the type level.

  type Id'' = /\k - \t :: k - t
  :k Id'' :: forall k . k - k

  :k Id'' [*] :: * - *
  :k Id'' [*] Int = Int
  :k Id'' [forall k . k - k] Id'' [*] Int = Int

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


[Haskell-cafe] Need feedback on my Haskell code

2009-07-28 Thread CK Kashyap
Hi Everyone,
I managed to write up the line drawing function using the following links - 
http://www.cs.helsinki.fi/group/goa/mallinnus/lines/bresenh.html
http://rosettacode.org/wiki/Bresenham%27s_line_algorithm#Haskell

line :: Point - Point - [Point]
line (xa,ya) (xb,yb) = line' (x1,y1) (x2,y2) deltax deltay ystep isSteep 0
  where 
isSteep = abs (yb - ya)  abs (xb - xa)
(xa',ya',xb',yb') = if isSteep
  then (ya,xa,yb,xb)
  else (xa,ya,xb,yb)
(x1,y1,x2,y2) = if xa'  xb'
  then (xb',yb',xa',ya')
  else (xa',ya',xb',yb')
deltax = x2 - x1
deltay = abs (y2 - y1)
ystep = if y1  y2 then 1 else -1
  

line' :: Point - Point - Integer - Integer - Integer - Bool - Integer - 
[Point]
line' (x1,y1) (x2,y2) deltax deltay ystep isSteep error =
  if x1 == x2
  then if isSteep then [(y1,x1)] else [(x1,y1)]
  else
if isSteep
  then [(y1,x1)] ++ line' (newX,newY) (x2,y2) deltax deltay ystep isSteep 
newError 
  else [(x1,y1)] ++ line' (newX,newY) (x2,y2) deltax deltay ystep isSteep 
newError
where
  newX = x1 + 1
  tempError = error + deltay
  (newY, newError) = if (2*tempError) = deltax then 
(y1+ystep,tempError-deltax) else (y1,tempError)


Can someone please provide feedback on this? In terms of, how do I get more 
Haskell'ism into it.

Regards,
Kashyap



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


Re: [Haskell-cafe] Need feedback on my Haskell code

2009-07-28 Thread Neil Mitchell
Hi Kashyap,

My first suggestion would be to run HLint over the code
(http://community.haskell.org/~ndm/hlint) - that will spot a few easy
simplifications.

Thanks

Neil

On Tue, Jul 28, 2009 at 2:04 PM, CK Kashyapck_kash...@yahoo.com wrote:
 Hi Everyone,
 I managed to write up the line drawing function using the following links -
 http://www.cs.helsinki.fi/group/goa/mallinnus/lines/bresenh.html
 http://rosettacode.org/wiki/Bresenham%27s_line_algorithm#Haskell

 line :: Point - Point - [Point]
 line (xa,ya) (xb,yb) = line' (x1,y1) (x2,y2) deltax deltay ystep isSteep 0
   where
     isSteep = abs (yb - ya)  abs (xb - xa)
     (xa',ya',xb',yb') = if isSteep
   then (ya,xa,yb,xb)
   else (xa,ya,xb,yb)
     (x1,y1,x2,y2) = if xa'  xb'
   then (xb',yb',xa',ya')
   else (xa',ya',xb',yb')
     deltax = x2 - x1
     deltay = abs (y2 - y1)
     ystep = if y1  y2 then 1 else -1


 line' :: Point - Point - Integer - Integer - Integer - Bool - Integer
 - [Point]
 line' (x1,y1) (x2,y2) deltax deltay ystep isSteep error =
   if x1 == x2
   then if isSteep then [(y1,x1)] else [(x1,y1)]
   else
     if isSteep
   then [(y1,x1)] ++ line' (newX,newY) (x2,y2) deltax deltay ystep
 isSteep newError
   else [(x1,y1)] ++ line' (newX,newY) (x2,y2) deltax deltay ystep
 isSteep newError
     where
   newX = x1 + 1
   tempError = error + deltay
   (newY, newError) = if (2*tempError) = deltax then
 (y1+ystep,tempError-deltax) else (y1,tempError)


 Can someone please provide feedback on this? In terms of, how do I get more
 Haskell'ism into it.

 Regards,
 Kashyap


 ___
 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] Need feedback on my Haskell code

2009-07-28 Thread CK Kashyap
Thanks Neil,
That helped. Now the code looks better - I still feel a little bad about the 
way I repeat calls to line' though - I was thinking of using a partially 
applied function with (newX,newY) as the last parameter - but that'll make the 
code less readable.

line :: Point - Point - [Point]
line (xa,ya) (xb,yb) = line' (x1,y1) (x2,y2) deltax deltay ystep isSteep 0
  where
isSteep = abs (yb - ya)  abs (xb - xa)
(xa',ya',xb',yb') = if isSteep
  then (ya,xa,yb,xb)
  else (xa,ya,xb,yb)
(x1,y1,x2,y2) = if xa'  xb'
  then (xb',yb',xa',ya')
  else (xa',ya',xb',yb')
deltax = x2 - x1
deltay = abs (y2 - y1)
ystep = if y1  y2 then 1 else -1


line' (x1, y1) (x2, y2) deltax deltay ystep isSteep error
  | x1 == x2 = if isSteep then [(y1, x1)] else [(x1, y1)]
  | isSteep =
(y1, x1) :
  line' (newX, newY) (x2, y2) deltax deltay ystep isSteep newError
  | otherwise =
(x1, y1) :
  line' (newX, newY) (x2, y2) deltax deltay ystep isSteep newError
  where newX = x1 + 1
tempError = error + deltay
(newY, newError)
  = if (2 * tempError) = deltax then
  (y1 + ystep, tempError - deltax) else (y1, tempError)

Regards,
Kashyap





From: Neil Mitchell ndmitch...@gmail.com
To: CK Kashyap ck_kash...@yahoo.com
Cc: haskell-cafe@haskell.org
Sent: Tuesday, July 28, 2009 6:44:58 PM
Subject: Re: [Haskell-cafe] Need feedback on my Haskell code

Hi Kashyap,

My first suggestion would be to run HLint over the code
(http://community.haskell.org/~ndm/hlint) - that will spot a few easy
simplifications.

Thanks

Neil

On Tue, Jul 28, 2009 at 2:04 PM, CK Kashyapck_kash...@yahoo.com wrote:
 Hi Everyone,
 I managed to write up the line drawing function using the following links -
 http://www.cs.helsinki.fi/group/goa/mallinnus/lines/bresenh.html
 http://rosettacode.org/wiki/Bresenham%27s_line_algorithm#Haskell

 line :: Point - Point - [Point]
 line (xa,ya) (xb,yb) = line' (x1,y1) (x2,y2) deltax deltay ystep isSteep 0
   where
 isSteep = abs (yb - ya)  abs (xb - xa)
 (xa',ya',xb',yb') = if isSteep
   then (ya,xa,yb,xb)
   else (xa,ya,xb,yb)
 (x1,y1,x2,y2) = if xa'  xb'
   then (xb',yb',xa',ya')
   else (xa',ya',xb',yb')
 deltax = x2 - x1
 deltay = abs (y2 - y1)
 ystep = if y1  y2 then 1 else -1


 line' :: Point - Point - Integer - Integer - Integer - Bool - Integer
 - [Point]
 line' (x1,y1) (x2,y2) deltax deltay ystep isSteep error =
   if x1 == x2
   then if isSteep then [(y1,x1)] else [(x1,y1)]
   else
 if isSteep
   then [(y1,x1)] ++ line' (newX,newY) (x2,y2) deltax deltay ystep
 isSteep newError
   else [(x1,y1)] ++ line' (newX,newY) (x2,y2) deltax deltay ystep
 isSteep newError
 where
   newX = x1 + 1
   tempError = error + deltay
   (newY, newError) = if (2*tempError) = deltax then
 (y1+ystep,tempError-deltax) else (y1,tempError)


 Can someone please provide feedback on this? In terms of, how do I get more
 Haskell'ism into it.

 Regards,
 Kashyap


 ___
 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] Need feedback on my Haskell code

2009-07-28 Thread Chaddaï Fouché
On Tue, Jul 28, 2009 at 3:04 PM, CK Kashyapck_kash...@yahoo.com wrote:
 Hi Everyone,
 I managed to write up the line drawing function using the following links -
 http://www.cs.helsinki.fi/group/goa/mallinnus/lines/bresenh.html
 http://rosettacode.org/wiki/Bresenham%27s_line_algorithm#Haskell


I tried to simplify your function a little bit :

line :: Point - Point - [Point]
line pa@(xa,ya) pb@(xb,yb) = map maySwitch . unfoldr go $ (x1,y1,0)
  where
steep = abs (yb - ya)  abs (xb - xa)
maySwitch = if steep then (\(x,y) - (y,x)) else id
[(x1,y1),(x2,y2)] = sort [maySwitch pa, maySwitch pb]
deltax = x2 - x1
deltay = abs (y2 - y1)
ystep = if y1  y2 then 1 else -1
go (xTemp, yTemp, error)
| xTemp  x2 = Nothing
| otherwise  = Just ((xTemp, yTemp), (xTemp + 1, newY, newError))
where
  tempError = error + deltay
  (newY, newError) = if (2*tempError) = deltax
 then (yTemp+ystep,tempError-deltax)
 else (yTemp,tempError)

I think it will be a bit better, tell me what you think ?

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


Re: [Haskell-cafe] powerSet = filterM (const [True, False]) ... is this obfuscated haskell?

2009-07-28 Thread Sebastian Fischer


On Jul 28, 2009, at 11:06 AM, Sittampalam, Ganesh wrote:


perms = sortByM (const [True,False])


This doesn't seem right, since the comparison function is inconsistent


I was also wary about this point, e.g. QuickSort depends on  
transitivity.



and moreover the results will depend on the sorting algorithm chosen.


Is it only that different sorting algorithms enumerate all  
permutations in different orders or is there a sorting algorithm, such  
that the above definition does not enumerate all permutations?


Here is some shirt-sleeved reasoning:

Every sorting algorithm :: [Int] - [Int] that actually sorts can  
describe every possible permutation (if there is a permutation that  
cannot be realised by the sorting algorithm then there is an input  
list that cannot be sorted). Hence, if this sorting algorithm is  
`sortBy p` for some predicate p then there are possible decisions of p  
to produce every possible permutation. If p makes *every* decision non- 
deterministically then certainly the specific decisions necessary for  
any specific permutation are also made.


Hence, perm as defined above can yield a list that contains all  
permutations of the input (at least once) regardless of the sorting  
algorithm.


Where is the hitch?

Sebastian


--
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)



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


RE: [Haskell-cafe] powerSet = filterM (const [True, False]) ... is this obfuscated haskell?

2009-07-28 Thread Sittampalam, Ganesh
Sebastian Fischer wrote:
 On Jul 28, 2009, at 11:06 AM, Sittampalam, Ganesh wrote:
 
 perms = sortByM (const [True,False])
 
 and moreover the results will depend on the sorting algorithm chosen.
 
 Is it only that different sorting algorithms enumerate all
 permutations in different orders or is there a sorting algorithm,
 such that the above definition does not enumerate all permutations?  
 
[..]
 Hence, perm as defined above can yield a list that contains all
 permutations of the input (at least once) regardless of the sorting
 algorithm.  
 
 Where is the hitch?

The at least once bit - unless your non-determinism is based on set
rather than bag semantics, it's wrong to duplicate results.

Ganesh

=== 
 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


Re: [Haskell-cafe] Need feedback on my Haskell code

2009-07-28 Thread Felipe Lessa
Small tips:

- Use swap and avoid those if's.
- [a] ++ b  is the same as  a : b.
- Factor out the first point that is always there.
- Factor out line' arguments that don't change with the recursion.

Untested:

 swap :: Bool - (a,a) - (a,a)
 swap False = id
 swap True  = \(x,y) - (y,x)

 line :: Point - Point - [Point]
 line (xa,ya) (xb,yb) = line' p1 p2 deltax deltay ystep isSteep 0
   where
 isSteep = abs (yb - ya)  abs (xb - xa)
 (p1,p2) = let a = swap isSteep (xa,ya)
   b = swap isSteep (xb,yb)
   in swap (fst a  fst b) (a, b)
 ((x1,y1),(x2,y2)) = (p1,p2)
 deltax = x2 - x1
 deltay = abs (y2 - y1)
 ystep  = if y1  y2 then 1 else -1


 line' :: Point - Point - Integer - Integer - Integer - Bool - Integer 
 - [Point]
 line' p1 (x2,_) deltax deltay ystep isSteep = go p1
   where
 go (x1,y1) error = swap isSteep (x1,y1) : rest
 where
   rest = if x1 == x2 then [] else go (newX,newY) newError
   newX = x1 + 1
   tempError = error + deltay
   (newY, newError) = if (2*tempError) = deltax
  then (y1+ystep,tempError-deltax) else 
 (y1,tempError)


But now that we got here, you may inline line' and avoid swap
isSteep.  I've also changed some names to more pleasant one (for
me, at least :).  Untested as well:

 swap :: Bool - (a,a) - (a,a)
 swap False = id
 swap True  = \(x,y) - (y,x)

 line :: Point - Point - [Point]
 line (xa,ya) (xb,yb) = go (x1,y1) 0
   where
 ((x1,y1),(x2,y2)) = let a = adjust (xa,ya)
 b = adjust (xb,yb)
 in swap (fst a  fst b) (a, b)
 adjust = swap $ abs (yb - ya)  abs (xb - xa)
 deltax = x2 - x1
 deltay = abs (y2 - y1)
 ystep  = if y1  y2 then 1 else -1

 go (x,y) error =
 let error'  = error + deltay
 (yd,ed) = if 2*tempError = deltax then (ystep,deltax) else (0,0)
 in adjust (x,y) : if x == x2 then [] else go (x+1,y+yd) (error' - ed)

HTH,

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


[Haskell-cafe] Adding a field to a data record

2009-07-28 Thread Henry Laxen
Dear Group,

It seems to me this should be easy, but I can't quite figure out
how to do it without a lot of typing.  Here is the question:

Suppose you have a data type like:
Data Foo = Foo { a :: Int, b :: Int, 
   ... many other fields ... 
 y :: Int } deriving (Eq, Read, Show, Typeable, Data)

Now I would like to add a field z :: Int to the end of Foo.  If
I have a ton of data out on disk, which I wrote with, say
writeFile a.data (show foo) -- where foo is a [Foo] say 1000
long, I would like to get a new a.data file which has a new
z::Int field.

So far the only way I can think of is to make a new Data Foo1,
which includes the z::Int, read in a.data as a list of Foo,
write a function like:

fooTofoo1 :: Foo - Foo1
fooTofoo1 xx = Foo1 {a = a xx, ... y = y xx, z = 1}

then write the file back out, and perhaps use emacs to
query-replace all the Foo1's back to Foo's, add the z::Int field
back into Foo, and read it back.

Please tell me there is a better way.  Thanks in advance.
Best wishes, 
Henry Laxen

PS: 
I have read syb1, and syb2 a couple of times now, but so far
haven't been able to connect it with this kind of problem.




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


Re: [Haskell-cafe] Adding a field to a data record

2009-07-28 Thread Malcolm Wallace

and perhaps use emacs to
query-replace all the Foo1's back to Foo's


At least this bit can be avoided easily enough, by using
module qualification during the conversion process.

module Original (Foo(..)) where
data Foo = Foo { ... y :: Int } deriving ...

module New (Foo(..)) where
data Foo = Foo { ... y, z :: Int } deriving ...

module Convert where
import Original as Old
import New as New
newFoo :: Old.Foo - New.Foo
newFoo old{..} = New.Foo { a=a, b=b, ... z=1 }

Finally rename module New.

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


Re: [Haskell-cafe] Re: cabal: : openFile: does not exist (No such file or directory)

2009-07-28 Thread Thomas Hartman
did you verify parsec-2.1.0.1 exports

Text.Parsec.Language

?

This might be a parsec 2 versus parsec 3 issue

ghc-pkg describe parsec-2.1.0.1

should tell you the answer to that.



2009/7/27 Job Vranish jvran...@gmail.com:
 I tried updating to ghc-6.10.4 and have exactly the same error.
 Also ghc doesn't seem to be able to find any of the haskell platform
 packages, even though it ghc-pkg finds them just fine.

 For example (trimmed for brevity):

 ghc-pkg list
 /usr/local/lib/ghc-6.10.4/./package.conf:
     Cabal-1.6.0.3,
 ...
     parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1,
 ...

 ghci -v readModel.hs
 GHCi, version 6.10.4: http://www.haskell.org/ghc/  :? for help
 Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2 booted by
 GHC version 6.8.2
 Using package config file: /usr/local/lib/ghc-6.10.4/./package.conf
 ...

 readModel.hs:9:7:
     Could not find module `Text.Parsec.Language':
   locations searched:
     Text/Parsec/Language.hs
     Text/Parsec/Language.lhs
 Failed, modules loaded: none.
 ...


 ghc-pkg finds parsec, but ghci can't find it.

 And if I do a cabal -v3 update I get a:
 cabal: 3: openFile: does not exist (No such file or directory)

 Anybody figured it out?

 - Job Vranish

 On Fri, Jul 17, 2009 at 11:17 AM, Thomas Hartman tphya...@gmail.com wrote:

 cabal -v3 update

 will give you a more verbose version of what is going wrong.

 cabal --help

 regrettably, cabal --help doesn't tell you this but there is always
 the man page I suppose.

 2009/7/16 Tony Hannan tonyhann...@gmail.com:
  Hello,
 
  I'm on Ubuntu 8.10.
  I installed ghc 6.10.4 (from binary package:
  ghc-6.10.4-i386-unknown-linux-n.tar.bz2).
  I installed haskell-platform-2009.2.0.1 (from source package:
  haskell-platform-2009.2.0.1.tar.gz). It contains cabal-install-0.6.2.
 
  Then when I run cabal update, I get the following error:
  cabal:  : openFile: does not exist (No such file or directory)
 
  Any ideas?
 
  Thanks,
  Tony
 
  ___
  Libraries mailing list
  librar...@haskell.org
  http://www.haskell.org/mailman/listinfo/libraries
 
 
 ___
 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: Adding a field to a data record

2009-07-28 Thread Henry Laxen
Malcolm Wallace Malcolm.Wallace at cs.york.ac.uk writes:

 
  and perhaps use emacs to
  query-replace all the Foo1's back to Foo's
 
 At least this bit can be avoided easily enough, by using
 module qualification during the conversion process.
 
  module Original (Foo(..)) where
  data Foo = Foo { ... y :: Int } deriving ...
 
  module New (Foo(..)) where
  data Foo = Foo { ... y, z :: Int } deriving ...
 
  module Convert where
  import Original as Old
  import New as New
  newFoo :: Old.Foo - New.Foo
  newFoo old{..} = New.Foo { a=a, b=b, ... z=1 }
 
 Finally rename module New.
 
 Regards,
  Malcolm
 

Thanks Malcolm, yes, that keeps me out of emacs, but the part I would really
like to avoid is writing the New.Foo { a=a, b=b, ... z=1 } part, where the field
names are many, long, and varied.  Yes, I could cut and paste, but I'm hoping
for a better way.  Thanks.
Best wishes,
Henry Laxen


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


Re: [Haskell-cafe] Re: Adding a field to a data record

2009-07-28 Thread Jason Dagit
On Tue, Jul 28, 2009 at 7:47 AM, Henry Laxen nadine.and.he...@pobox.comwrote:

 Malcolm Wallace Malcolm.Wallace at cs.york.ac.uk writes:

 
   and perhaps use emacs to
   query-replace all the Foo1's back to Foo's
 
  At least this bit can be avoided easily enough, by using
  module qualification during the conversion process.
 
   module Original (Foo(..)) where
   data Foo = Foo { ... y :: Int } deriving ...
 
   module New (Foo(..)) where
   data Foo = Foo { ... y, z :: Int } deriving ...
 
   module Convert where
   import Original as Old
   import New as New
   newFoo :: Old.Foo - New.Foo
   newFoo old{..} = New.Foo { a=a, b=b, ... z=1 }
 
  Finally rename module New.
 
  Regards,
   Malcolm
 

 Thanks Malcolm, yes, that keeps me out of emacs, but the part I would
 really
 like to avoid is writing the New.Foo { a=a, b=b, ... z=1 } part, where the
 field
 names are many, long, and varied.  Yes, I could cut and paste, but I'm
 hoping
 for a better way.  Thanks.


I guess you could define:
type UpgradeFoo = (Foo, Int)

And then write the conversion code as a zip.  upgradeFoo foos = zip foos
[1..]

instance Show UpgradeFoo where ...

And then use the module trick to switch the code around?

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


[Haskell-cafe] Re: Adding a field to a data record

2009-07-28 Thread Maurí­cio CA

Suppose you have a data type like:
Data Foo = Foo { a :: Int, b :: Int, 
   ... many other fields ... 
 y :: Int } deriving (Eq, Read, Show, Typeable, Data)


Now I would like to add a field z :: Int to the end of Foo.  If
I have a ton of data out on disk, which I wrote with, say
writeFile a.data (show foo) -- where foo is a [Foo] say 1000
long, I would like to get a new a.data file which has a new
z::Int field.


This seems to depend on what you want to accomplish. Is
your goal just to rewrite this whole file? If it is, the
idea of just adding a field to Foo would be enough. You
could then add that 'z' field in your file using 'sed' (or,
as you said, emacs) and then read it back.

In general, however, if you want to deal with this kind
of translation of text to data, what you really want is to
take some time to learn something like Parsec.

http://www.haskell.org/ghc/docs/latest/html/libraries/parsec/Text-ParserCombinators-Parsec.html


So far the only way I can think of is to make a new Data Foo1,
which includes the z::Int, read in a.data as a list of Foo,
write a function like:

fooTofoo1 :: Foo - Foo1
fooTofoo1 xx = Foo1 {a = a xx, ... y = y xx, z = 1}


Note that this would not work exactly like that. 'a' is
a field of Foo, and that means it's a function like

a :: Foo - Int

So, you can't use it as a field of Foo1, as that would
imply

a :: Foo1 - Int

Best,
Maurício

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


Re: [Haskell-cafe] Re: Adding a field to a data record

2009-07-28 Thread Malcolm Wallace

the part I would really like to avoid is writing the
New.Foo { a=a, b=b, ... z=1 } part, where the field
names are many, long, and varied.


OK, here is another hack-ish trick, since I notice your data is stored  
on disk as text, using show.  I assume you are using something like  
Read to retrieve it.  Well, how about using a real parser instead?   
The parser during conversion can be slightly more lax, automatically  
adding in the extra field.


For instance, using polyparse's Text.Parse, and DrIFT to derive the  
appropriate Parse instance for your datatype:


module Foo where
data Foo = Foo { a :: Int
   , b :: Bool
   , c :: Maybe Foo }
  {-! derive : Parse !-}

DrIFT gives you this instance:

{-* Generated by DrIFT : Look, but Don't Touch. *-}
instance Parse Foo where
parse = constructors
[ ( Foo
  , return Foo `discard` isWord { `apply` field a
   `discard` isWord , `apply` field b
   `discard` isWord , `apply` field c
   `discard` isWord }
  )
]

Let's say the field 'b' is new, and your existing data does not have  
it.  So just take the parser generated by DrIFT and make a small  
modification:


{-* Generated by DrIFT but modified by hand for conversion  
purposes *-}

instance Parse Foo where
parse = constructors
[ ( Foo
  , return Foo `discard` isWord { `apply` field a
   `apply` return True -- this field does not yet exist in 
data
   `discard` isWord , `apply` field c
   `discard` isWord }
  )
]

Then do the obvious thing: parse the old data, immediately write it  
out again, and then throw away the modified parser in favour of the  
pure generated one.


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


Re: [Haskell-cafe] Need feedback on my Haskell code

2009-07-28 Thread CK Kashyap
Thank you very much Jedai ... this looks much more concise and does not contain 
the repetitions that I had. I'd need to go over it more to understand it better.
I'll ping you if I have any questions about this.

Regards,
Kashyap





From: Chaddaï Fouché chaddai.fou...@gmail.com
To: CK Kashyap ck_kash...@yahoo.com
Cc: haskell-cafe@haskell.org
Sent: Tuesday, July 28, 2009 7:10:38 PM
Subject: Re: [Haskell-cafe] Need feedback on my Haskell code

On Tue, Jul 28, 2009 at 3:04 PM, CK Kashyapck_kash...@yahoo.com wrote:
 Hi Everyone,
 I managed to write up the line drawing function using the following links -
 http://www.cs.helsinki.fi/group/goa/mallinnus/lines/bresenh.html
 http://rosettacode.org/wiki/Bresenham%27s_line_algorithm#Haskell


I tried to simplify your function a little bit :

line :: Point - Point - [Point]
line pa@(xa,ya) pb@(xb,yb) = map maySwitch . unfoldr go $ (x1,y1,0)
  where
steep = abs (yb - ya)  abs (xb - xa)
maySwitch = if steep then (\(x,y) - (y,x)) else id
[(x1,y1),(x2,y2)] = sort [maySwitch pa, maySwitch pb]
deltax = x2 - x1
deltay = abs (y2 - y1)
ystep = if y1  y2 then 1 else -1
go (xTemp, yTemp, error)
| xTemp  x2 = Nothing
| otherwise  = Just ((xTemp, yTemp), (xTemp + 1, newY, newError))
where
  tempError = error + deltay
  (newY, newError) = if (2*tempError) = deltax
 then (yTemp+ystep,tempError-deltax)
 else (yTemp,tempError)

I think it will be a bit better, tell me what you think ?

-- 
Jedaï



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


Re: [Haskell-cafe] Re: Adding a field to a data record

2009-07-28 Thread Iavor Diatchki
Hello,
you may also find the package pretty-show
(http://hackage.haskell.org/package/pretty-show) useful.  It contains
code to convert automatically derived instances of Show into an
explicit data structure, which you can then manipulate (e.g., by
adding the extra field), and then render back to text.
-Iavor


On Tue, Jul 28, 2009 at 6:07 PM, Malcolm
Wallacemalcolm.wall...@cs.york.ac.uk wrote:
 the part I would really like to avoid is writing the
 New.Foo { a=a, b=b, ... z=1 } part, where the field
 names are many, long, and varied.

 OK, here is another hack-ish trick, since I notice your data is stored on
 disk as text, using show.  I assume you are using something like Read to
 retrieve it.  Well, how about using a real parser instead?  The parser
 during conversion can be slightly more lax, automatically adding in the
 extra field.

 For instance, using polyparse's Text.Parse, and DrIFT to derive the
 appropriate Parse instance for your datatype:

    module Foo where
    data Foo = Foo { a :: Int
                   , b :: Bool
                   , c :: Maybe Foo }
      {-! derive : Parse !-}

 DrIFT gives you this instance:

    {-* Generated by DrIFT : Look, but Don't Touch. *-}
    instance Parse Foo where
        parse = constructors
            [ ( Foo
              , return Foo `discard` isWord { `apply` field a
                       `discard` isWord , `apply` field b
                       `discard` isWord , `apply` field c
                       `discard` isWord }
              )
            ]

 Let's say the field 'b' is new, and your existing data does not have it.  So
 just take the parser generated by DrIFT and make a small modification:

    {-* Generated by DrIFT but modified by hand for conversion purposes *-}
    instance Parse Foo where
        parse = constructors
            [ ( Foo
              , return Foo `discard` isWord { `apply` field a
                       `apply` return True -- this field does not yet exist
 in data
                       `discard` isWord , `apply` field c
                       `discard` isWord }
              )
            ]

 Then do the obvious thing: parse the old data, immediately write it out
 again, and then throw away the modified parser in favour of the pure
 generated one.

 Regards,
    Malcolm
 ___
 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: Proposal: TypeDirectedNameResolution

2009-07-28 Thread Ryan Ingram
On Tue, Jul 28, 2009 at 1:41 AM, Heinrich
Apfelmusapfel...@quantentunnel.de wrote:
 While I do agree that qualified names are annoying at times, I think
 that type directed name disambiguation is a Pandora's box.

I see where you are going, but I'm not sure I agree.  Let me give an
example from another language with this kind of resolution: C++.  From
a purely practical point of view, function overloading in C++ does
what I want almost all the time.  And when it doesn't do what I want,
it's always been immediately obvious, and it's a sign that my design
is flawed.

But those cases where it does what I want have been incredibly useful.

 Furthermore, we already have a mechanism for type based disambiguation,
 namely good old type classes. For instance, the qualifications required
 when importing  Data.Map  are actually a sign that we are lacking proper
 container type classes à la Edison.

Perhaps.  I think containers is a great example of why you want TDNR.
Many containers have *almost* the same interface, but not quite.
After all, if the interface was the same, you would just find the most
efficient container for that interface and call it a day.

So unless you want to go the direction of putting every single
container-related function in its own typeclass, I don't think you'll
be able to come up with one container interface to rule them all.

To be fair, I'm not against the idea of putting each function in its
own typeclass.  For work along these lines, see the many better
numeric hierarchy attempts.  But I'd also need support for class
aliases or something similar so that defining common subsets of those
classes would work easily.

Along those lines, what about being able to elide class names when
they can be unambiguously determined from the functions defined?

instance _ [] where
fmap = map
pure x = [x]
fs * xs = [ f x | f - fs, x - xs ]
return x = [x]
m = f = concatMap f m

This would define Functor, Applicative, and Monad for [].

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


Re: [Haskell-cafe] powerSet = filterM (const [True, False]) ... is this obfuscated haskell?

2009-07-28 Thread Ryan Ingram
On Tue, Jul 28, 2009 at 6:47 AM, Sebastian
Fischers...@informatik.uni-kiel.de wrote:
 perms = sortByM (const [True,False])
 Hence, perm as defined above can yield a list that contains all permutations
 of the input (at least once) regardless of the sorting algorithm.

 Where is the hitch?

The algorithm might diverge when given a non-transitive comparison
operator.  On Spore we had a bug where a NaN got into a list of floats
we were sorting and our quicksort corrupted the heap because  isn't
transitive on lists with NaNs.

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


Re: [Haskell-cafe] Re: Proposal: TypeDirectedNameResolution

2009-07-28 Thread Colin Paul Adams
 Ryan == Ryan Ingram ryani.s...@gmail.com writes:

Ryan Along those lines, what about being able to elide class
Ryan names when they can be unambiguously determined from the
Ryan functions defined?

Ryan instance _ [] where fmap = map pure x = [x] fs * xs = [ f
Ryan x | f - fs, x - xs ] return x = [x] m = f = concatMap f
Ryan m

Ryan This would define Functor, Applicative, and Monad for [].

What happens if I define a class Foo with a method named fmap? If this
were in scope then Functor would no longer be defined for [].

Could this situation cause a problem?
-- 
Colin Adams
Preston Lancashire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Deepest polymorphic functor

2009-07-28 Thread Eduard Sergeev

I was wondering if it is possible to somehow change deep f_map from
http://okmij.org/ftp/Haskell/deepest-functor.lhs article in a such a way
that it would work not only for monotypes like in the provided example:

test1 = f_map (+1) [[[1::Int,2,3]]]

But for polymorphic types as well (e.g. behaves like simple map) so the
following line would compile as well:

test1 = f_map (+1) [[[1,2,3]]]

?

-- 
View this message in context: 
http://www.nabble.com/Deepest-polymorphic-functor-tp24709303p24709303.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] lifting restrictions on defining instances

2009-07-28 Thread wren ng thornton

Tillmann Rendel wrote:

wren ng thornton wrote:

Thus, the forall keyword is serving as the type-level abstraction. 


What do you mean by type-level abstraction here?


I mean an abstraction, as in a lambda-abstraction (aka a 
lambda-expression), at the type level.



[...]


I'm not sure I follow what you mean. 


I mean that the forall keyword is *not* serving as the type-level 
abstraction.


There is a difference between abstraction (as in lambda abstraction) and 
the type of abstractions (as in function types). In pure type systems, 
we have two different binders for these different features:


  - lower-case lambda for abstraction (on all levels)
  - upper-case Pi for the type of abstractions (on all levels)

I find it highly confusing to say that forall denotes type-level 
abstraction, because it does not denote abstraction at all. It rather 
denotes the type of an abstraction, namely in Haskell, the type of 
abstracting over types in terms.


I view these as different sides of the same coin. There are two 
different senses of the forall keyword. There's the implicit Rank-1 
quantifier, and then there's the Rank-N quantifier for polymorphic 
components. Your intuition is relying on the latter, whereas mine is 
relying on the former. The difference is similar to the difference 
between morphisms vs exponential objects in CCCs. We often find it 
convenient to elide the conversions between them, but they are in fact 
quite different. And if, at the term layer, functions can be silently 
lifted to/lowered from closures, then why not also at the type layer? 
While it is important to keep the ideas distinct, in practice we've 
found great utility in conflating the two faces of the coin.


Why can't the type of abstractions be an abstraction of types? This is 
not currently the case in GHC, as you point out, but that does not 
demonstrate that the idea is unsound. This distributive transformation 
is used routinely in Conal Elliott's typeclass morphisms[1], Ralf 
Hinze's polyidiomatic lambda calculus[2], in HOAS (if you squint), and 
many other places where poly*ism spans multiple layers of the tower of 
interpretation. The symmetry between forall and /\ in System F is simply 
too great to write off without investigation.




In any case, I think this discussion has veered far afield from the 
intent of my original footnote, which was simply to point out that the 
capital-lambda binder already has a canonical usage in System F (so we 
should not co-op it for type abstractions, without express intention). I 
have little invested in the current discussion, and the Cafe list 
doesn't really seem like the best venue to pursue it. If you have 
references you think would enlighten me, I'd happily pursue them. 
Otherwise, I think the best color for the bikeshed is purple :)



[1] http://conal.net/blog/tag/type-class-morphism/
[2] http://www.comlab.ox.ac.uk/ralf.hinze/WG2.8//26/slides/ralf.pdf

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


Re: [Haskell-cafe] Re: Proposal: TypeDirectedNameResolution

2009-07-28 Thread Richard O'Keefe


On Jul 29, 2009, at 5:05 AM, Ryan Ingram wrote:

I see where you are going, but I'm not sure I agree.  Let me give an
example from another language with this kind of resolution: C++.


Right.  That settles it:  TDNR is a bad idea.
Half fun and full earnest.

I'm a fan of overloading as done in Ada, but the way
C++ does it has always struck me as a mix of under-useful
and over-complex, and my experience with it in practice
has not been that marvellous.  (C++ has far too many
types that are _sort of_ compatible, but only sort of.)

Interestingly, I've found that when I've thought I've wanted
overloading in Haskell, what I've _really_ wanted is
typeclasses, because they give me
 - far more confidence that my code is correct
 - far more _leverage_; typeful programming is amazing.



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


Re: [Haskell-cafe] Re: Proposal: TypeDirectedNameResolution

2009-07-28 Thread Dan Doel
On Tuesday 28 July 2009 8:27:53 pm Richard O'Keefe wrote:
 Right.  That settles it:  TDNR is a bad idea.
 Half fun and full earnest.

 I'm a fan of overloading as done in Ada, but the way
 C++ does it has always struck me as a mix of under-useful
 and over-complex, and my experience with it in practice
 has not been that marvellous.  (C++ has far too many
 types that are _sort of_ compatible, but only sort of.)

Amusingly enough, one of the major items going into C++0x was concepts, which 
are an effort to add type class-alike restrictions to C++'s current completely 
ad-hoc overloading. They were only recently dropped due to disagreements about 
certain details (I think I read that people couldn't agree whether programmers 
should be forced to declare the analogue of class instances, or whether the 
compiler should figure it out, but I haven't paid close attention, so that may 
be inaccurate).

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


[Haskell-cafe] runProcess does not care about hSetBuffering?

2009-07-28 Thread Magicloud Magiclouds
Hi,
  Code like:
(or_, ow_) - createPipe
or - fdToHandle or_
ow - fdToHandle ow_
hSetBuffering ow LineBuffering
hSetBuffering or LineBuffering
h - runProcess cmd [] Nothing Nothing Nothing (Just ow) Nothing
  In the cmd process, the ow is not LineBuffering
-- 
竹密岂妨流水过
山高哪阻野云飞
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] runProcess does not care about hSetBuffering?

2009-07-28 Thread Brandon S. Allbery KF8NH

On Jul 28, 2009, at 21:14 , Magicloud Magiclouds wrote:

(or_, ow_) - createPipe
or - fdToHandle or_
ow - fdToHandle ow_
hSetBuffering ow LineBuffering
hSetBuffering or LineBuffering
h - runProcess cmd [] Nothing Nothing Nothing (Just ow) Nothing
 In the cmd process, the ow is not LineBuffering


Buffering is not an attribute of a filehandle, but of the I/O  
library.  There is no way for you to tell cmd how you want it to  
buffer, unless it has an option to do so (cat -u, tcpdump -l, etc.),  
although you can hint by using a pty instead of a pipe:  many programs  
will switch to line buffering in that case, some will go unbuffered;  
usually, a pipe, FIFO, or ordinary file will be block buffered.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




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


[Haskell-cafe] Hugs used in circuit simulations code

2009-07-28 Thread Fernan Bolando
Hi all

thanks to everyone that reviewed my code.

The good news
1. I happy to say that it has become useful enough for me to use it in
some matlab type caluculations. includes transient and dc op
2. The simple pivtoing code I added into the DSP Lu appears to be
useable for this application.

The bad news
1. If you dont use some strategy in simplifying circuits and use the
simulator only, it would take a considerable amount of time to
converge.
A simple 10x10 non linear matrix will take 13 minutes. In a high-end
circuit simulator this would have taken less than a second.

What is everybodies expereience in speed difference between C and
interpreted haskell? I am hoping to achieve at least 10x an equivalent
C code.
So if a 10x10 matrix takes 1 second for C I want it to take 10seconds for hugs.

regards
fernan


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


Re: [Haskell-cafe] Deepest polymorphic functor

2009-07-28 Thread Ryan Ingram
What would this do with

  instance Num a = Num [a]

in scope?

On Tue, Jul 28, 2009 at 3:51 PM, Eduard Sergeeveduard.serg...@gmail.com wrote:

 I was wondering if it is possible to somehow change deep f_map from
 http://okmij.org/ftp/Haskell/deepest-functor.lhs article in a such a way
 that it would work not only for monotypes like in the provided example:

 test1 = f_map (+1) [[[1::Int,2,3]]]

 But for polymorphic types as well (e.g. behaves like simple map) so the
 following line would compile as well:

 test1 = f_map (+1) [[[1,2,3]]]

 ?

 --
 View this message in context: 
 http://www.nabble.com/Deepest-polymorphic-functor-tp24709303p24709303.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] Hugs used in circuit simulations code

2009-07-28 Thread Daniel Fischer
Am Mittwoch 29 Juli 2009 03:32:20 schrieb Fernan Bolando:
 What is everybodies expereience in speed difference between C and
 interpreted haskell?

That depends on what you do, unsurprisingly. But usually it's huge. A factor of 
several 
hundred is not uncommon, but 10-100 is the normal range (in my limited 
experience, I 
almost always compile).

 I am hoping to achieve at least 10x an equivalent C code.

Then you should definitely *not* run interpreted code, but compile it.
With compiled code, I usually have a factor of less than 10, mostly 2-4, 
sometimes even 
better. But some things take longer in Haskell.

 So if a 10x10 matrix takes 1 second for C I want it to take 10seconds for
 hugs.

Execution speed is not one of hugs' strongest points, so I'd be surprised.
I recommend you get a GHC.


 regards
 fernan

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


Re: [Haskell-cafe] Hugs used in circuit simulations code

2009-07-28 Thread Don Stewart
daniel.is.fischer:
 Am Mittwoch 29 Juli 2009 03:32:20 schrieb Fernan Bolando:
  What is everybodies expereience in speed difference between C and
  interpreted haskell?

Why are you using hugs?

Hugs is slower than GHCi, which is around 30x slower on average than
GHC, (measured a couple of years ago).

Please use ghc -O2 if you care about performance!

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


Re: [Haskell-cafe] Hugs used in circuit simulations code

2009-07-28 Thread Jason Dagit
On Tue, Jul 28, 2009 at 6:32 PM, Fernan Bolando fernanbola...@mailc.netwrote:

 Hi all

 thanks to everyone that reviewed my code.

 The good news
 1. I happy to say that it has become useful enough for me to use it in
 some matlab type caluculations. includes transient and dc op
 2. The simple pivtoing code I added into the DSP Lu appears to be
 useable for this application.

 The bad news
 1. If you dont use some strategy in simplifying circuits and use the
 simulator only, it would take a considerable amount of time to
 converge.
 A simple 10x10 non linear matrix will take 13 minutes. In a high-end
 circuit simulator this would have taken less than a second.

 What is everybodies expereience in speed difference between C and
 interpreted haskell? I am hoping to achieve at least 10x an equivalent
 C code.
 So if a 10x10 matrix takes 1 second for C I want it to take 10seconds for
 hugs.


Use GHC's profiler.  Figure out why and where the code is slow and then you
can do something about it:
http://book.realworldhaskell.org/read/profiling-and-optimization.html

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