[Haskell-cafe] Re:

[Martin Sulzmann]

On Wed, Oct 14, 2009 at 7:33 AM,  wrote:

>
> Martin Sulzmann wrote:
> > "Undecidable" instances means that there exists a program for which
> there's
> > an infinite reduction sequence.
>
> I believe this may be too strong of a statement. There exists patently
> terminating type families that still require undecidable
> instances in GHC.


Sorry, I wasn't precise enough.

I didn't mean to say that *every* program which requires "undecidable"
instance won't terminate.

Rather, take any of the properties which imply decidability. Then,
there *exists* a program which satisfies the negated property and this
program won't terminate.

As you show, for specific cases we can argue that "undecidable" instances
are decidable. You can even argue that the Add/Mult example is decidable,
assuming we never generate loopy type constraints.

-Martin


> Here is an example:
>
> > {-# LANGUAGE TypeFamilies #-}
> >
> > type family I x :: *
> > type instance I x = x
> >
> > type family B x :: *
> > type instance B x = I x
>
>
> GHC 6.8.3 complaints:
>Application is no smaller than the instance head
>  in the type family application: I x
>(Use -fallow-undecidable-instances to permit this)
>In the type synonym instance declaration for `B'
>
> But there cannot possibly be any diverging reduction sequence here, can it?
> The type family I is the identity, and the type family B is its
> alias. There is no recursion. The fact that type families are open is
> not relevant here: our type families I and B are effectively closed,
> because one cannot define any more instance for I and B (or risk
> overlap, which is rightfully not supported for type families).
>
> The reason GHC complains is because it checks termination
> instance-by-instance. To see the termination in the above program, one
> should consider instances I and B together. Then we will see that I
> does not refer to B, so there are no loops. But this global
> termination check -- for a set of instances -- is beyond the
> abilities of GHC. This is arguably the right decision: after all, GHCi
> is not a full-blown theorem prover.
>
> Thus there are perfectly decidable type programs that require
> undecidable instances. Indeed, there is no reason to be afraid of that
> extension.
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Amazing

[Stefan Monnier]

> So IMO static typing is good, but it's only with functional programming that
> it really shines.

You can go one step further: if you start using dependent types, you'll
see that it gets yet harder to get your program to type-check, and once
it does, you don't even bother to run it since it's so blindingly
obvious that it's correct.


Stefan

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

[Haskell-cafe] Re: StableFunPtr?

[Neal Alexander]

Maurí­cio wrote:

Hi,

I've seen that if I'm going to leave a pointer
to data in the hands of foreign code, I should
use StablePtr so that the value it points to
doesn't change.

However, we also usually give FunPtr to foreign
code, like when registering callbacks, but I
can't found any kind of "StableFunPtr".

Are all FunPtrs stable?

Thanks,
Maurício


You can also use StablePtr for callbacks (forkOS uses it).

I'm not sure what the difference is between the two in that case though.

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

[Haskell-cafe] Re: StableFunPtr?

[Neal Alexander]

Maurí­cio wrote:

Hi,

I've seen that if I'm going to leave a pointer
to data in the hands of foreign code, I should
use StablePtr so that the value it points to
doesn't change.

However, we also usually give FunPtr to foreign
code, like when registering callbacks, but I
can't found any kind of "StableFunPtr".

Are all FunPtrs stable?

Thanks,
Maurício


You can also use StablePtr for callbacks (forkOS uses it).

I'm not sure what the difference is between the two in that case though.

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

[Haskell-cafe] Re: Zippers

[Heinrich Apfelmus]

Cristiano Paris wrote:
> 
> I'm trying to catch the connection between delimited continuations and
> zippers so I wrote a (kinda) zipper interface to a simple tree
> structure. Here's the code:
> 
> ---
> module Main where
> 
> import Data.Maybe
> 
> data Tree a = Leaf a | Fork (Tree a) (Tree a) deriving Show
> 
> tree = Fork (Fork (Leaf 1) (Leaf 2)) (Fork (Leaf 3) (Fork (Leaf 4) (Leaf 5)))
> 
> data ZContext a = ZContext { moveUp:: Maybe (ZContext a),
>  moveLeft  :: Maybe (ZContext a),
>  moveRight :: Maybe (ZContext a),
>  this :: Maybe a }
> 
> initZ t = doInitZ Nothing t
>   where
> doInitZ c (Leaf a) = ZContext c Nothing Nothing $ Just a
> doInitZ c t@(Fork l r) = ZContext c (Just $ doInitZ s l)
> (Just $ doInitZ s r)
> Nothing
>  where s = Just $ doInitZ c t
> ---
> 
> You access the tree in the following way (session from ghci):
> 
> *Main> this $ fromJust . moveLeft $ fromJust . moveLeft $ initZ tree
> 
> I read Haskell book's Chapter about Zippers on Wikibooks and I think I
> understood the underlying concept even if the implementation still
> seems to me a bit arbitrary (i.e. different implementation can be
> provided even if the proposed one is neat thinking of
> differentiation).
> 
> Hence, I decided to go experimenting myself and came up with the above
> solution. I know that the interface to a tree having values only on
> leaves is pointless as the main advantage of using a Zipper is to get
> O(1) performance on updating but I wanted to keep it as simple as
> possible.
> 
> So, can you provide some comments on that implementation? Thank you
> all, as usual!

The unusual thing about your implementation is probably that you're
tying a knot by making both  moveUp  and  moveLeft  record fields. This
reminds me of

  Weaving a web. Ralf Hinze and Johan Jeuring. 2001.
  http://www.informatik.uni-bonn.de/~ralf/publications/TheWeb.ps.gz


The problem with knot-tying / sharing is of course that they are tricky
to update. What about the crucial function

  update :: ZContext a -> Maybe a -> ZContext a

that changes the data at a leaf? I think that with your current
approach, you'd have to regenerate the whole context which pretty much
defeats the purpose of a zipper.


Regards,
apfelmus

--
http://apfelmus.nfshost.com

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

[Haskell-cafe] Re: Zippers

[Heinrich Apfelmus]

Cristiano Paris wrote:
> Ryan Ingram wrote:
>> ...
>> Here is the problem with your "update":
>>
>> tree = Fork (Leaf 1) (Leaf 2)
>> ztree = initZ tree
>>
>> test = fromJust $ do
>>z1 <- moveLeft ztree
>>let z2 = update z1 3
>>z3 <- moveUp z2
>>z4 <- moveLeft z3
>>this z4
>>
>> I'd expect "test" to equal 3, but I believe with your code that it
>> still equals 1.  As apfelmus said, update needs to completely
>> re-construct the zipper structure with the tied knot, which defeats
>> the purpose of using a zipper in the first place.
> 
> I got it. I dont't know what your expression "tied knot" is referring
> to but I got the point.

In  doInitZ , you're basically using the  s  itself to define the
moveLeft  and  moveRight  fields of  s . You could as well write it as

  initZ t = doInitZ Nothing t
  where
  doInitZ c (Leaf a) = ZContext c Nothing Nothing $ Just a
  doInitZ c t@(Fork l r) = s
   where s = ZContext c (Just $ doInitZ (Just s) l)
(Just $ doInitZ (Just s) r)
Nothing

Such self-reference is usually called "tying the knot", see also

  http://www.haskell.org/haskellwiki/Tying_the_Knot


Regards,
apfelmus

--
http://apfelmus.nfshost.com

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

[Haskell-cafe] Re: MPI

[FFT]

On Wed, Mar 4, 2009 at 5:03 PM, FFT  wrote:
> Are MPI bindings still the best way of using Haskell on Beowulf
> clusters? It's my feeling that the bindings stagnated, or are they
> just very mature?

What's the story with distributed memory multiprocessing? Are Haskell
programmers uninterested in it, or are things other than MPI used with
it?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Zippers

[Heinrich Apfelmus]

Cristiano Paris wrote:
> Heinrich Apfelmus wrote:
>> ...
>> Such self-reference is usually called "tying the knot", see also
>>
>>  http://www.haskell.org/haskellwiki/Tying_the_Knot
> 
> I didn't know. Would you call this "Tying the knot" as well?
> 
> http://yi-editor.blogspot.com/2008/12/prototypes-encoding-oo-style.html

Yes, or rather, I would call it "untying the knot". ;)


Regards,
apfelmus

--
http://apfelmus.nfshost.com

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

[Haskell-cafe] Re: .editrc

[Ben Franksen]

brad clawsie wrote:
> does anyone have a .editrc they can provide that allows ghci to be used
> on freebsd?
> 
> i'm not looking for anything fancy, just backspace not being broken etc

You could try to cabal install ghci-haskeline and see if that works better.

Cheers
Ben

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

[Haskell-cafe] Re: Matrices

[Patrick Perry]

Hi Cetin,

This is probably the easiest way:

> (m - es)^2/es
listMatrix (2,2)  
[0.6163270413689804,0.600918865334756,0.33217626255600896,0.3238718559921087 
]


This will create 2 temporary arrays.  Alternatively,

> let res = listMatrix (shape m) [ (o-e)^2 / e | o <- colElems m | e  
<- colElems es ] where colElems = concatMap elems . cols

> res
listMatrix (2,2)  
[0.6163270413689804,0.600918865334756,0.33217626255600896,0.3238718559921087 
]


In a later version of the library, "colElems" will probably be built- 
in.  This version has the disadvantage that it doesn't use BLAS calls.


If you *really* want to get tricky and eliminate temporary arrays:

> runSTMatrix $ do
res <- newCopyMatrix m
subMatrix res es
modifyWith (^2) res
divMatrix res es
return res


Now, to get the sum:

> sumAbs $ vectorFromMatrix res
1.8732940252518542

or

> sum $ elems res
1.8732940252518542

The first version will usually be more efficient, since it calls the  
BLAS1 function "dasum".



Patrick

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

[Haskell-cafe] Re: gcd

[Achim Schneider]

Steve  wrote:

> "It is useful to define gcd(0, 0) = 0 and lcm(0, 0) = 0 because then
> the natural numbers become a complete distributive lattice with gcd
> as meet and lcm as join operation. This extension of the definition
> is also compatible with the generalization for commutative rings
> given below."
> 
Ouch. Speak of mathematicians annoying programmers by claiming that 0
isn't divisible by any of [1..], and further implying that 0 is bigger
than all of those, not to mention justifying all that with long words.

Damn them buggers.

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.


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

[Haskell-cafe] Re: gcd

[Achim Schneider]

Nathan Bloomfield  wrote:

> The "greatest" in gcd is not w.r.t. the canonical ordering on the
> naturals; rather w.r.t. the partial order given by the divides
> relation.
>
This, to defend myself, was not how it was explained in high school.

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.


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

[Haskell-cafe] Re: Tests

[John Goerzen]

Guenther Schmidt wrote:
> let me first of all thank you for providing the HDBC package. Haskell 
> would be a much, much less usefull language without a working database 
> interface. I could certainly not have written the app in  Haskell 
> without it and in any other language I know writing this app would have 
> been much more difficult.

Thanks!  I'm glad you found it (and Real World Haskell) helpful.

> The problem is what's in the database.
> 
> You'd think there'd be a "Günni" in the database, right?
> 
> Wrong!
> 
> At least this is where your library and Sqlite disagree. Sqlite with any 
> GUI client doesn't show a "Günni", it shows a "G!$%§$§%nni". So do MS 
> Access and MySql btw.

And now that is REALLY weird, because I can't duplicate it here.

I wrote this little Haskell program:

import Database.HDBC
import Database.HDBC.Sqlite3

main = do dbh <- connectSqlite3 "foo.db"
  run dbh "CREATE TABLE foo (bar text)" []
  run dbh "INSERT INTO foo VALUES (?)" [toSql "Günther"]
  run dbh "INSERT INTO foo VALUES (?)" [toSql "2-G\252nther"]
  commit dbh
  disconnect dbh

And when I inspect foo.db with the sqlite3 command-line tool:

/tmp$ sqlite3 foo.db
SQLite version 3.5.9
Enter ".help" for instructions
sqlite> select * from foo;
Günther
2-Günther

Exactly correct, as expected.

I can read it back correctly from Haskell, too:

import Database.HDBC
import Database.HDBC.Sqlite3
import qualified System.IO.UTF8 as U

main = do dbh <- connectSqlite3 "foo.db"
  results <- quickQuery' dbh "SELECT * from foo" []
  mapM_ ((print :: String -> IO ()) . fromSql . head) results
  mapM_ (U.putStrLn . fromSql . head) results
  disconnect dbh

and when I run this:

/tmp$ ./foo3a
"G\252nther"
"2-G\252nther"
Günther
2-Günther

I wonder if there is something weird about your environment: non-unicode
terminals, databases, editors, or something?

For me, it Just Works as it should.



> 
> For now I managed to rollback the UTF8 code in the HDBC-2.1 and got my 
> app to work as needed.
> 
> I hope you find this info useful, thanks once more
> 
> Günther
> 
> 

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

[Haskell-cafe] RE: iota

[Paul Keir]

That is quite spectacular. I revised my knowledge of sequence

with a little function, akin to "sequence [xs1,xs2]":

 

seq2 xs1 xs2 = do x1 <- xs1

x2 <- xs2

return [x1,x2]

 

> seq2 [0,1] [0,1,2]

> [[0,0],[0,1],[0,2],[1,0],[1,1],[1,2]]

 

I like your point-free style too; and that's a nice use of pred.

 

Many thanks,

Paul

 

The iota function you're looking for can be a whole lot simpler if you
know about monads (list monad in particular) and sequence. For lists,
sequence has the following behaviour:

 

sequence [xs1,xs2, ... xsn] =

   [[x1,x2, ... , xn] | x1 <- xs1, x2 <- xs2, ... , xn <- xsn]

 

 

Using this, you can reduce your iota function to a powerful one-liner:

 

iota = sequence . map (enumFromTo 0 . pred)

 

 

Kind regards,

 

Raynor Vliegendhart

 

 

From: Paul Keir 
Sent: 01 June 2009 10:01
To: haskell-cafe@haskell.org
Subject: iota

 

Hi all,

 

I was looking for an APL-style "iota" function for array indices. I
noticed

"range" from Data.Ix which, with a zero for the lower bound (here
(0,0)),

gives the values I need:

 

> let (a,b) = (2,3)

> index ((0,0),(a-1,b-1))

> [(0,0),(0,1),(0,2),(1,0),(1,1),(1,2)]

 

However, I need the results as a list of lists rather than a list of
tuples; and

my input is a list of integral values. I ended up writing the following
function

instead. The function isn't long, but longer than I first expected. Did
I miss a

simpler approach?

 

iota :: (Integral a) => [a] -> [[a]]

iota is = let count = product is

   tups = zip (tail $ scanr (*) 1 is) is

   buildRepList (r,i) = genericTake count $ cycle $

   [0..i-1]
>>= genericReplicate r

   lists = map buildRepList tups

 in transpose lists

 

> length $ iota [2,3,4]

> 24

 

Thanks,

Paul

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

[Haskell-cafe] Re: hackage.haskell.org

[Simon Marlow]

David Waern wrote:


I'd like to set up a Trac for Haddock on hackage.haskell.org. Who should I
contact?


Let's hold off on this for now.  I don't think Haddock warrants a full Trac of 
its own just yet, the overheads of managing a Trac are pretty high compared to 
editing the text file called "TODO" in the root of the Haddock source tree :-)


Cheers,
Simon

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

[Haskell-cafe] Re: hackage.haskell.org

[David Waern]

> David Waern wrote:
>
>> I'd like to set up a Trac for Haddock on hackage.haskell.org. Who should
>> I
>> contact?
>
> Let's hold off on this for now.  I don't think Haddock warrants a full
> Trac of
> its own just yet, the overheads of managing a Trac are pretty high
> compared to
> editing the text file called "TODO" in the root of the Haddock source tree
> :-)

What do you think of the Google bug tracker? Neil and I created a project
for Haddock at http://code.google.com/p/haddock/

I'd like to pre-release haddock.ghc and it would be nice to have some
place for users to report bugs.

/David

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

[Haskell-cafe] Re: hackage.haskell.org

[Simon Marlow]

Neil Mitchell wrote:

> Let's hold off on this for now.  I don't think Haddock warrants a full
> Trac of
> its own just yet, the overheads of managing a Trac are pretty high
> compared to
> editing the text file called "TODO" in the root of the Haddock 
source tree

> :-)

What do you think of the Google bug tracker? Neil and I created a project
for Haddock at http://code.google.com/p/haddock/


For reference, it took well under a minute for me to create a new
Google Code project, and is unlikely to need maintenance ever.

Google rules!


I'm thinking of the overheads of using a web app to manage a bug database as 
opposed to a text file + darcs + email.  Google code is certainly good, but it 
isn't going to beat the low-tech tools in terms of simplicity and speed.  What's 
more, we'll have to populate it with all the existing known bugs, or keep bugs 
in two places.  And can you extract the metadata from google code when you want 
to move to Trac or something else?


I'm mainly worried that I'll have yet another place to go looking for bugs.

David - if you want to set up a Google bug tracker for haddock.ghc then by all 
means go ahead, but my vote would be to keep it simple, at least until we really 
need the extra functionality.


Cheers,
Simon

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

[Haskell-cafe] Re: Mathematica

[Rene de Visser]

> How difficult would it be to implement Mathematica in Haskell?

Why don't you use axiom? It already has several 100 of years man effort put 
into it.

Or for dynamically type package you could use Maxima.

Both are free.

Rene.




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

[Haskell-cafe] Re: Mathematica

[Chung-chieh Shan]

Andrew Coppin <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in 
gmane.comp.lang.haskell.cafe:
> The absurdly efficient number crunching is obviously not implementable 
> in Haskell - or indeed virtually any language except assembly. [...]
> The pretty user interface is obviously not implementable in Haskell. [...]
> It seems it would 
> be a fairly difficult task to implement the pattern matching engine 
> properly.

Why?

-- 
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
2007-05-15 International Conscientious Objection Day http://wri-irg.org/

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

[Haskell-cafe] Re: quiry

[Stephane Bortzmeyer]

On Wed, May 16, 2007 at 06:34:53PM +0530,
 ashutosh dimri <[EMAIL PROTECTED]> wrote 
 a message of 34 lines which said:

> how to convert a hexadecimal into base 10 integer using haskell . I
> have written a code but its not working for large values , please
> help

Not showing the code you wrote will not help. Please read the
instructions first:

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

[Haskell-cafe] Re: Editor

[apfelmus]

Jules Bean wrote:
> Michael T. Richter wrote:
>>1. A real GUI environment that takes into account some of the HID
>>   advances made in the past 30 years.  (Emacs and Vim don't count,
>>   in other words.)
> 
> Both emacs and vim take into account many of the HID advances made in
> the past 30 years.

I can't know whether that's the case, but the fact that virtually all
commands are invoked with the keyboard clashes with HID research reported at

   http://www.asktog.com/TOI/toi06KeyboardVMouse1.html

It adresses the question whether selecting commands in menus with the
mouse or accessing them via keyboard shortcuts is faster. The answer is:

 "* Test subjects consistently report that keyboarding is faster than
mousing.
  * The stopwatch consistently proves mousing is faster than
keyboarding."

Regards,
apfelmus

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

[Haskell-cafe] Re: Editor

[apfelmus]

Jules Bean wrote:
> apfelmus wrote:
>> I can't know whether that's the case, but the fact that virtually all
>> commands are invoked with the keyboard clashes with HID research
>> reported at
>>
>>http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
>>
>> It adresses the question whether selecting commands in menus with the
>> mouse or accessing them via keyboard shortcuts is faster. The answer is:
>>
>>  "* Test subjects consistently report that keyboarding is faster than
>> mousing.
>>   * The stopwatch consistently proves mousing is faster than
>> keyboarding."
> 
> 
> The research there is reported as hearsay, it is not referenced
> research, so I can't check their methods.

Well, hearsay is probably not the right word but the selection of tasks
on which the conclusions are based is indeed vital yet missing. In

   http://www.asktog.com/SunWorldColumns/S02KeyboardVMouse3.html

, he reports on an actual experiment in response to a comment. It can be
debated (no use of "advanced" cursor positioning like M-f or M-b?), but
for the task at hand (replace all '|' by 'e' in a text by hand) the
mouse seems superior. Of course, a find/replace command performs much
better, so a keybinding for that would be worth it because it makes the
computer perform the task.

But in any case, this research can easily be reproduced at home! Of
course, nobody (include me) does :)

> Despite the implicit claim that my brain must be lying to me and causing
> amnesia I'm unaware of, I would dispute the claims there. I suspect
> there might well be a large body of users (even 'most') for which it's
> true. However 'most' people are not fast typists.

(I think "amnesia" is not a good choice of words. It's more like the
well-known effect from a quotation of A. Einstein "Put your hand on a
hot stove for a minute, and it seems like an hour. Sit with a pretty
girl for an hour, and it seems like a minute. THAT'S relativity.")

> I'm sure that I can quite reliably hit the command editor keybindings I
> use many, many times faster than if I had to select them from a menu.

Note that the claimed time-consuming part is not to actually press the
keybinding, but to chose and remember which one to press.

Being sure and verified experimentally are two different things. The
question cannot be decided by arguments or by stating opions, only the
stopwatch can answer it. In a sense, the basic statement is that the
human's internal stopwatch is unreliable.

Regards,
apfelmus

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

[Haskell-cafe] Re: Editor

[Ashley Yakeley]

Michael T. Richter wrote:
I have a dream.  It's not a little dream.  It's a big dream.  I have a 
dream that someday I can find a UNIX/Linux text editor for Haskell 
hacking (and possibly two or three hundred other programming languages, 
although that's optional) that can give me all of the following:


   1. A real GUI environment that takes into account some of the HID
  advances made in the past 30 years.  (Emacs and Vim don't count,
  in other words.)


I don't suppose you're familiar with the Dylan programming language, or 
more to the point, have looked at the IDE that Apple included in their 
original implementation of the language (around 1993 or so)? 
Characteristic of Apple of that time, the UI was both highly innovative 
and a joy to use. It was based around "browsers", where each browser had 
a "subject" (such as a project, module, definition etc.) and an "aspect" 
(such as "contents of", "errors in", "references to", "direct methods 
of" etc.). Browsers could be linked so that the selection in one browser 
became the subject in another. This made it very easy to navigate your 
project.


All code was stored in a database rather than as text files, and 
individual code definitions were separate objects in the browsers rather 
than pieces of text in a big file.


Info w/ screenshots: 

Needless to say, this goes in rather the opposite UI direction to the 
"Ctrl-M Ctrl-Meta-Z  :edit qx" approach to editors that some people 
prefer.


Dylan's not a bad language, and there are open source implementations 
available for Gnu/Linux. But if you want to check out Apple's IDE, 
you'll really need a 68K Mac, as the PPC version is very buggy and I 
don't think the 68K version will run in PPC.


--
Ashley Yakeley
Seattle, WA

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

[Haskell-cafe] Re: Editor

[apfelmus]

Ketil Malde wrote:
> On Tue, 2007-05-22 at 10:19 +0200, apfelmus wrote:
> 
>> http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
>>
>> It adresses the question whether selecting commands in menus with the
>> mouse or accessing them via keyboard shortcuts is faster. The answer is:
>>
>>  "* Test subjects consistently report that keyboarding is faster than
>> mousing.
>>   * The stopwatch consistently proves mousing is faster than
>> keyboarding."
> 
> Interesting!  I did a quick test doing search and replace using the
> keyboard and the menus in Emacs.  It takes me about six seconds with the
> keyboard, and closer to ten using the menus.  (The first time, it took
> thirty as I spent time to locate the correct menu options :-)
> 
> But I agree with the report that using the mouse *feels* a lot slower. 
> Quoting the report: "It takes two seconds to decide upon which
> special-function key to press. Deciding among abstract symbols is a
> high-level cognitive function."
> I'm not so sure I agree, using the mouse feels way more abrupt and
> intrusive.

The question is whether the stopwatch feels the same way :)

> I can do M-x repl TAB str TAB foo RET bar RET with my eyes
> closed¹, but to use the mouse, I need to locate the mouse with my hand,
> locate the mouse cursor, locate the menu, etc etc.

Note that "locate the menu" is indeed something may take more time than
it should. Traditionally, Mac OS features a single menu bar at the top
of the screen as opposed to Windows or GNOME. This is a consious design
choice whose rationale is explained at

   http://www.asktog.com/columns/022DesignedToGiveFitts.html

In short, Fitt's Law says that the amount of time to navigate to a
target on screen depends logarithmically on the ratio (size of target /
distance to target). Now, a menu bar at the top of the screen has
effectively infinite target size, you can just throw your mouse pointer
to the top of the screen and be assured that it hits the top edge = the
target. This is much faster than targetting a small menu attached to a
window. And it has the additional side effect that the task "locate the
mouse pointer" can be partially omitted because only the horizontal
position matters if you're going to throw the pointer to the top of the
screen anyway.

Regards,
apfelmus

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

[Haskell-cafe] Re: Memoization

[apfelmus]

Mark Engelberg wrote:
> I'd like to write a memoization utility.  Ideally, it would look
> something like this:
> 
> memoize :: (a->b) -> (a->b)
> 
> memoize f gives you back a function that maintains a cache of
> previously computed values, so that subsequent calls with the same
> input will be faster.

Note that due to parametricity, any function of this type is necessarily
either id or _|_. In other words, there are only two functions of type

  ∀a∀b. (a->b) -> (a->b)

That's because the functions has to work for all types a and b in the
same way, i.e. it may not even inspect how the given types a or b look
like. You need type classes to get a reasonable type for the function
you want

  memoize :: Memoizable a => (a->b) -> (a->b)


Now, how to implement something like this? Of course, one needs a finite
map that stores values b for keys of type a. It turns out that such a
map can be constructed recursively based on the structure of a:

  Map ()b  := b
  Map (Either a a') b  := (Map a b, Map a' b)
  Map (a,a')b  := Map a (Map a' b)

Here,  Map a b  is the type of a finite map from keys a to values b. Its
construction is based on the following laws for functions

() -> b  =~=  b
  (a + a') -> b  =~=  (a -> b) x (a' -> b) -- = case analysis
  (a x a') -> b  =~=  a -> (a' -> b)   -- = currying

For further and detailed explanations, see

  R. Hinze. Memo functions, polytypically!
  http://www.informatik.uni-bonn.de/~ralf/publications.html#P11

and

  R. Hinze. Generalizing generalized tries.
  http://www.informatik.uni-bonn.de/~ralf/publications.html#J4


Regards,
apfelmus

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

[Haskell-cafe] Re: Memoization

[apfelmus]

Andrew Coppin wrote:
>>> OOC, can anybody tell me what ∀ actually means anyway?

http://en.wikipedia.org/wiki/Universal_quantification
http://en.wikipedia.org/wiki/System_F

> I do recall that GHC has some weird extension called "existential
> quantification"

http://haskell.org/haskellwiki/Existential_types
http://en.wikibooks.org/wiki/Haskell/Existentially_quantified_types

Regards,
apfelmus

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

[Haskell-cafe] Re: Memoization

[Simon Marlow]

Rodrigo Queiro wrote:
sorear pointed me to this paper a while ago: 
http://citeseer.ist.psu.edu/peytonjones99stretching.html


I never tried any of the code in the end, but it will probably be useful?


An implementation of that memo table scheme can be found here:

http://darcs.haskell.org/testsuite/tests/ghc-regress/lib/should_run/Memo.lhs

It's probably too slow for general use, though.  You might find it useful if 
your keys are huge (or infinite) and comparing them directly is impractical.


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

[Haskell-cafe] Re: Hardware

[Jon Fairbairn]

Andrew Coppin <[EMAIL PROTECTED]> writes:

> OK, so... If you were going to forget everything we humans
> know about digital computer design - the von Neuman
> architecture, the fetch/decode/execute loop, the whole
> shooting match - and design a computer *explicitly* for the
> purpose of executing Haskell programs... what would it look
> like?

Back in the eighties (I don't remeber exactly when), Thomas
Clarke, Stuart Wray and I got together to think this through
(we had the possiblity of funding to make something).  We
had lots of ideas, but after much arguing back and forth the
conclusion we reached was that anything we could do would
either be slower than mainstream hardware or would be
overtaken by it in a very short space of time.  I'm not sure
that the conclusion still holds because conventional
architectures are approaching an impasse, but there's a lot
of force left in the arguments: most of the improvements I
can think of also benefit imperative languages, so if
they're worthwhile they'll happen anyway.

One of the things that is different now is the availability
of parallelism, but the mainstream is working pretty hard on
that. There's an opportunity there, in that functional
languages have some nice properties when it comes to
parallel execution, but to make an impact we'd have to get
on with it pretty sharpish.


-- 
Jón Fairbairn [EMAIL PROTECTED]

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

[Haskell-cafe] Re: Hardware

[Jon Fairbairn]

"Claus Reinke" <[EMAIL PROTECTED]> writes:

> > either be slower than mainstream hardware or would be
> > overtaken by it in a very short space of time.
> 
> i'd like to underline the last of these two points, and i'm
> impressed that you came to that conclusion as early as the
> eighties.

Well, Stuart and I had just been working on TIM, and Thomas
Clarke was one of the folk who built SKIM, so we had a fair
bit of relevant experience between us.  It must have been
between 1986 (when we'd finished TIM) and 1989 (when I got
ill).

> unlike earlier designs, the hardware only leaned toward
> functional, rather than being specific to it (mostly RISC,
> with large register files organised as very fast stack
> windows for a small number of stacks),

We had that sort of thing in mind -- my first implementation
of TIM was on an ARM, so I knew something of what RISC had
to offer.

> and numbers from the hand-configured prototype suggested
> that it would be about twice as fast as contemporary
> standard hardware. which was great, until it became clear
> that, in the time it would have taken to go from that
> prototype to production, the next generation of that
> standard hardware would have been on the market, also
> twice as fast (with the next next generation already on
> its way)..

Yup, that's what we figured (we knew the ARM guys too, and
knowing the rate at which they worked probably helped us see
things quite clearly :-).

> the suggestion that the mainstream might be running out of
> steam along one particular dimension is interesting, but
> in my naive view, there is still the difference between
> any one-shot research project and a snapshot in a
> development pipeline of great momentum

Yes. I think the best bet is to get hold of prototypes and
research fp implementations for them; my TIM implementation
of Ponder must have been the first fp language on ARM, and
the process of doing that probably informed much of the
detailed design of TIM. Doing an fp implementatio for a huge
number of cores strikes me as an exciting avenue.


-- 
Jón Fairbairn [EMAIL PROTECTED]

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

[Haskell-cafe] Re: Hardware

[Jon Fairbairn]

"Neil Davies" <[EMAIL PROTECTED]> writes:

> Bulat
> 
> That was done to death as well in the '80s - data flow architectures
> where the execution was data-availability driven. The issue becomes
> one of getting the most of the available silicon area. Unfortunately
> with very small amounts of computation per work unit you:
>a) spend a lot of time/area making the matching decision - the what
> to do next
>b) the basic sequential blocks of code are too small - can't
> efficiently pipeline
> 
> Locality is essential for performance. It is needed to hide all the
> (relatively large) latencies in fetching things.
> 
> If anyone wants to build the new style of functional programming
> execution hardware, it is those issues that need to be sorted.

Yes indeed, though a lot has changed (and a lot stayed the
same) in hardware since then.  There may be greater
possibilities for integrating garbage collection in the
memory, for example, and there's always the possibility that
someone will come up with a new and radically different way
of spreading a functional programme across multiple CPU
cores.

-- 
Jón Fairbairn [EMAIL PROTECTED]


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

[Haskell-cafe] Re: Hardware

[Al Falloon]

Bulat Ziganshin wrote:

it seems that now we move right into this direction with GPUs


I was just thinking that GPUs might make a good target for a reduction 
language like Haskell. They are hugely parallel, and they have the 
commercial momentum to keep them current. It also occurred to me that 
the cell processor (in the Playstation 3) might also be a good target 
considering its explicitly parallel architecture.


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

[Haskell-cafe] Re: IDE?

[Ashley Yakeley]

[EMAIL PROTECTED] wrote:


Any help to find an IDE that comes closest to these features would be much
appreciated.


There's a short list at , but I 
don't think any are all that close. I'd like to see a good IDE for 
Haskell, but it's a lot of work.


Ideally it would use the .cabal file as its "project file", so that one 
could take any Cabal project and double-click on the .cabal file to open 
the project in the IDE. Also I think we could borrow some ideas from 
Apple's Dylan IDE

.

--
Ashley Yakeley

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

[Haskell-cafe] Re: IDE?

[Jean-Philippe Bernardy]

Claus Reinke  talk21.com> writes:

> This was followed by Ermacs, a concurrent
> Emacs clone written completely in Erlang. Ermacs
> is fairly complete – it has major modes for
> Erlang and Scheme programming, a built-in Erlang
> shell, and support for efficiently editing large
> files. However, once the core editor was complete,
> it was obvious that GNU Emacs has an incredibly
> large set of wonderful features, and that extending
> Ermacs to include “enough” of them was
> completely out of the question.
> The lessons learned from Ermacs lead to Distel,..
> 
> how is Yi going to avoid that trap?

Here's the plan for world domination:

* Many features are going to be written/replicated as haskell libraries anyway,
for usage as independent libraries.
* Make sure gluing code is relatively easy

I frankly suspect that haskell is a lot more powerful than erlang, and therefore
it will be way easier to write code for Yi than Ermacs. 

For example, Ben Moseley has written a rudimentary Dired mode for Yi in about a
week (I think), with no prior knowledge of Yi. The module is now 347 lines long
(including blanks and comments)

Also, I suspect haskell will become more popular than erlang, and the
contributions to the respective editor of choice proportional.


Cheers,
JP.



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

[Haskell-cafe] Re: Collections

[apfelmus]

Thomas Conway wrote:
> In particular, I find my self wanting to use a priority queue for
> N-way sorted merge, which you can do with Data.Map: (compiles, so
> clearly works even though I have not tested it. ;-) )
> 
> import Data.List as List
> import Data.Map as Map
> 
> merge :: Ord t => [[t]] -> [t]
> merge lists = merge' $ Map.fromList $ concatMap makePair lists
>where
>makePair [] = []
>makePair (x:xs) = [(x,xs)]
> 
> merge' heap
>| Map.null heap = []
>| otherwise = x:(merge' $ removeEqual x $ reinsert xs heap')
>where
>((x,xs), heap') = deleteFindMin heap
> 
> reinsert [] heap = heap
> reinsert (x:xs) heap = Map.insert x xs heap
> 
> removeEqual x heap
>| Map.null heap = heap
>| x /= y= heap
>| otherwise = removeEqual x $ reinsert ys heap'
>where
>((y,ys), heap') = deleteFindMin heap

Eh, why not a simple mergesort that also deletes duplicates?

-- the nested lists must be sorted: map sort xs == xs
  mergesort :: Ord a => [[a]] -> [a]
  mergesort []  = []
  mergesort xs  = foldtree1 merge xs

  foldtree1 :: (a -> a -> a) -> [a] -> a
  foldtree1 f [x] = x
  foldtree1 f xs  = foldtree1 f $ pairs xs
 where
 pairs []= []
 pairs [x]   = [x]
 pairs (x:x':xs) = f x x' : pairs xs

  merge :: Ord a => [a] -> [a] -> [a]
  merge [] ys = ys
  merge xs [] = xs
  merge xs'@(x:xs) ys'@(y:ys)
  | x  < y= x:merge xs  ys'
  | x == y=   merge xs  ys'
  | otherwise = y:merge xs' ys

The function 'foldtree1' folds the elements of the list as if they where
in a binary tree:

  foldrtree1 f [1,2,3,4,5,6,7,8]
 ==>
  ((1 `f` 2) `f` (3 `f` 4)) `f` ((5 `f` 6) `f` (7 `f` 8))

and with f = merge, this serves as heap (although a very implicit one).
The hole mergesort will take

  O(n*log (length xs)) where n = length (concat xs)

time. Moreover, this variant of mergesort happens to generate elements
as soon as they are available, i.e.

 head . mergesort  is  O(n)

See also

 http://article.gmane.org/gmane.comp.lang.haskell.general/15010


> The other thing I have found myself doing often is using splitLookup
> followed by union, though what I really want is "join" being the dual
> of split - i.e. requiring all the keys in the rhs to be greater than
> the keys in the lhs. My own AVL tree implementation has this operation
> which is O(log n), which is rather better than union's O(n log n).

2-3-Finger trees support efficient splits and concatenations:

  http://www.soi.city.ac.uk/~ross/papers/FingerTree.html

In fact, you can build a plethora of data structures from them.

Regards,
apfelmus

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

[Haskell-cafe] Re: Collections

[apfelmus]

Thomas Conway wrote:
> On 6/22/07, Duncan Coutts <[EMAIL PROTECTED]> wrote:
>> You might find that lazy IO is helpful in this case. The primitive that
>> implements lazy IO is unsafeInterleaveIO :: IO a -> IO a
> 
> Personally, unsafeInterleaveIO is so horribly evil, that even just
> having typed the name, I'll have to put the keyboard through the
> dishwasher (see http://www.coudal.com/keywasher.php).

:D :D
Finally someone who fully understands the true meaning of the prefix
"unsafe"  ;)

>> Note that using a Map will probably not help since it needs to
>> read all the keys to be able to construct it so that'd pull
>> in all the data from disk.
>
> Well, in the case I'm dealing with, the map can contain the current
> key from each postings vector, and the closure for reading the
> remainder of the vector. E.g. Map Key ([IO (Maybe Key)]).

In any case, you have to store as many keys as you have lists to sort,
but lazy mergesort will not hold on more than (length xs + 1) keys in
memory at a single moment in time and only force one new key per
retrieval. No lingering intermediate lists :)

In this situation, unsafeInterleaveIO is an easy way to carry this
behavior over to the IO-case:

 type Reader t = IO (Maybe t)
 type Writer t = t -> IO ()

 readList :: Reader t -> IO [t]
 readList m = unsafeInterleaveIO $ do
mx <- m
case mx of
   Just x  -> liftM (x:) $ readList m
   Nothing -> return []

 mergesortIO :: Ord t => [Reader t] -> Writer t -> IO ()
 mergesortIO xs f = do
ys <- mapM readList xs
mapM_ f $ mergesort ys

Here, readList creates only as many list elements as you demand,
similarly to getContents. Of course, it has the same problem as
getContents, namely that you can accidentally close the file before
having read all data. But this is applies to any on-demand approach be
it with IO or without.

Also, you can make the heap in mergesort explicit and obtain something
similar to your current approach with Data.Map. The observation is that
while mergesort does create a heap, its shape does not change and is
determined solely by (length xs).

-- convenient invariant:
--   the smaller element comes from the left child
  data Ord b => Heap m b = Leaf m b | Branch b (Tree a b) (Tree a b)

-- smart constructor
  branch :: Ord b => Tree m b -> Tree m b -> Tree m b
  branch x y
  | gx <= gy  = Branch gx x y
  | otherwise = Branch gy y x
  where
  (gx,gy) = (getMin x, getMin y)

-- fromList is the only way to "insert" elements into a heap
  fromList :: Ord b => [(m,b)] -> Heap m b
  fromList = foldtree1 branch . map (uncurry Leaf)

  getMin :: Heap m b -> b
  getMin (Leaf _ b)  = b
  getMin (Branch b _ _ ) = b

  deleteMin :: Heap (Reader b) b -> IO (Maybe (Heap (Reader b) b))
  deleteMin (Leaf m _) = m >>= return . fmap (Leaf m)
  deleteMin (Branch _ x y) = do
mx' <- deleteMin x
return . Just $ case mx' of
   Just x' -> branch x' y
   Nothing -> y

  mergesortIO :: Ord t => [Reader t] -> Writer t -> IO ()
  mergesortIO xs f = ...

> Also, I need to support concurrent querying and updates,
> and trying to manage the locking is quite hard enough as it is,
> without trying to keep track of which postings vectors have closures
> pointing to them!

I guess you have considered Software Transactional Memory for atomic
operations?
   http://research.microsoft.com/~simonpj/papers/stm/index.htm

Also, write-once-read-many data structures (like lazy evaluation uses
them all the time) are probably very easy to get locked correctly.


Regards,
apfelmus

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

[Haskell-cafe] Re: Lambdabot

[Daniel Fischer]

I can partially answer my questions.
Removing also Seen does away with the ByteString.index error.
Must check the code to see why.

Two more concrete questions
a) how do I gracefully leave lambdabot?
ctrl-C or killing it from another shell are the only ways out I found so far.
b) what does lambdabot expect in the fptools directory?

Cheers,
Daniel

Am Freitag, 22. Juni 2007 20:10 schrieb ich:
> Greetings,
> lambdabot segfaulted when installing
> Fact
> Haddock
> Quote
> Source
> Todo
> Where
>
> What's special about them?
> I.e., why did they cause a segfault and the others not?
>
> And, how could I build a lambdabot _with_ them (though I'm not sure, I'll
> actually want them, but I might).
>
> Without these, I now have an apparently working lambdabot, well, not
> properly working.
> First time I started it, all seemed well, but from then on:
> $ ./lambdabot
> Initialising plugins ..sending message to
> bogus server: IrcMessage {msgServer = "freenode", msgLBName =
> "urk!", msgPrefix = "", msgCommand = "NAMES", msgParams =
> [""]}
> ... done.
> Main: caught (and ignoring) IRCRaised Data.ByteString.index: index too
> large: 0, length = 0
> lambdabot> > 3+7
> Main: caught (and ignoring) IRCRaised Data.ByteString.index: index too
> large: 0, length = 0
>  10
> lambdabot>
>
> The bogus message thing also appeared the first time, I hope this is meant
> to be so.
> But what about the ByteString.index exception?
> Where might that come from?
> How to get rid of it?
>
> Finally, is there a tutorial/manual for using lambdabot?
>
> Thanks for any help,
> Daniel

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

[Haskell-cafe] Re: Collections

[apfelmus]

Andrew Coppin wrote:
> Lennart Augustsson wrote:
>> If you don't run into graphs you are either solving very peculiar
>> problems, or you don't recognize them when you see them.  They are
>> everywhere.
> 
> I see lots of *trees*, but no general graphs. (As in, *data* structures
> having cycles in them. My *code* is often cyclic...)

So what does a compiler do to typecheck it? It represents your code as a
graph and calculates strongly connected components.

Regards,
apfelmus

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

[Haskell-cafe] Re: Collections

[apfelmus]

Andrew Coppin wrote:
> apfelmus wrote:
>> Andrew Coppin wrote:
>>  
>>> I see lots of *trees*, but no general graphs. (As in, *data* structures
>>> having cycles in them. My *code* is often cyclic...)
>>> 
>>
>> So what does a compiler do to typecheck it? It represents your code as a
>> graph and calculates strongly connected components.
>>   
> 
> That's quite true - but *I* am not writing a compiler, am I? ;-)

Oh well. You may insist that you won't encounter graphs in your problems
and I recommend to delete all symbolic links (aka "aliases") from your
file system to that end.

Regards,
apfelmus

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

[Haskell-cafe] Re: Reinvention

[Jon Fairbairn]

Andrew Coppin <[EMAIL PROTECTED]> writes:

> I seem to be forever writing code that looks like this:
> 
> decode :: String -> (SKI,String)
> decode (c:cs) = case c of
>   'S' -> (S,cs)
>   'K' -> (K,cs)
>   'I' -> (I,cs)
>   '*' -> let (e0,cs0) = decode cs; (e1,cs1) = decode cs1 in (e0 :@: e1, cs1)

This looks like parsing to me.

-- 
Jón Fairbairn [EMAIL PROTECTED]

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

[Haskell-cafe] Re: filterFirst

[apfelmus]

Alexteslin wrote:
> filterAlpha :: (a -> Bool) -> [a] -> [a]
> filterAlpha f [] = []
> filterAlpha f (x:xs)
>   |f x= x : filterAlpha xs
>   |otherwise  = filterAlpha xs
> 
> 
> and i am getting this error message:
> 
> Type error in application
> Expression :filterAlpha xs
> Type: [b]
> Dous not match : a -> Bool

  filterAlpha :: (a -> Bool) -> [a] -> [a]
  filterAlpha f [] = []
  filterAlpha f (x:xs)
 | f x   = x : filterAlpha f xs
 | otherwise = filterAlpha f xs

filterAlpha  has two parameters. The first parameter is a function (a ->
Bool), the second is a list [a]. The error message complains that  xs ,
which you actidentially gave as first parameter, is a list [a] and not a
function (a -> Bool).

Regards,
apfelmus

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

[Haskell-cafe] Re: Backpatching

[ChrisK]

Thomas Conway wrote:
> One of the things that gets messy is that in lots of places you can
> put either a thing or a reference to a thing (i.e. the name of a thing
> defined elsewhere). For example, consider the production:
> 
> NamedNumber ::= identifier "(" SignedNumber ")"
>   | identifier "(" DefinedValue ")"
> 

I like solving this with either a (WriterT Parser) or using the Parsec state to
lazily access the final mapping.  Here is a working Toy example where 'finalMap'
is used during the parsing.  Parsec was a bit too strict with the return of
'parseVal' so I had to use a (data Box) to make it lazy:


> import Text.ParserCombinators.Parsec
> 
> import Data.Maybe
> import qualified Data.Map as M
> 
> data Box a = Box {unBox :: a}
> 
> input = unlines $
>   [ "name(ref)"
>   , "ref=7"
>   ]
> 
> data Toy = Toy String Int deriving (Show)
> 
> myParse s = toys where
>   result = runParser parser M.empty "Title" s
>   toys = either Left (Right . fst) result
> 
>   lookupRef r = Box (finalMap M.! r)
> where finalMap = either undefined snd result
> 
>   parser = do
> maybeToyList <- many parseLine
> defMap <- getState
> return (catMaybes maybeToyList,defMap)
> 
>   parseLine = try parseToy <|> parseDef <|> (char '\n' >> return Nothing)
> 
>   parseToy = do
> name <- many1 letter
> val <- between (char '(') (char ')') (try parseVal <|> parseRef)
> return (Just (Toy name (unBox val)))
> 
>   parseVal = do 
> s <- many1 digit
> return (Box (read s))
> 
>   parseRef = do
> s <- many1 letter
> return (lookupRef s)
> 
>   parseDef = do
> s <- many1 letter
> char '='
> v <- parseVal
> defMap <- getState
> let defMap' = M.insert s (unBox v) defMap
> setState $! defMap'
> return Nothing


When I run it in ghci I get:

> *Main> myParse input
> Right [Toy "name" 7]

Cheers,
  Chris

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

[Haskell-cafe] Re: Ideas

[John MacFarlane]

+++ Andrew Coppin [Aug 25 07 12:50 ]:
> How easy would it be to make / would anybody care / has somebody already 
> made ... in Haskell?
> 
> - A wiki program. (Ditto.)

I wrote a simple wiki using HAppS and pandoc.  See demonstration #15
on the pandoc web page:

http://sophos.berkeley.edu/macfarlane/pandoc/examples.html

It's by no means a finished product, but might serve as a good base
if you decide to work on a wiki.

John

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

[Haskell-cafe] Re: Ideas

[John MacFarlane]

> may i ask you what did you had in mind as an application when you started
> that ?

This was just recreational programming: I wanted to see what writing a
web application in Haskell would be like. I think it would be great to
have a fully featured wiki program in Haskell, but I don't have time to
do it myself. Your idea sounds very interesting. Feel free to extend
pandocwiki if that works for you; it's GPL.

John

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

[Haskell-cafe] Re: Ideas

[Luc TAESCH]

thanks John for replying...

when building , i cannot find the lcs mentionned in the cabal file not
on hasckage nor on goggle.
could you help?
( your papers on philosophy looks quite serious .. impressive you are
in haskell too ..  math backgroud ? logics ?)


2007/8/26, John MacFarlane <[EMAIL PROTECTED]>:
> > may i ask you what did you had in mind as an application when you started
> > that ?
>
> This was just recreational programming: I wanted to see what writing a
> web application in Haskell would be like. I think it would be great to
> have a fully featured wiki program in Haskell, but I don't have time to
> do it myself. Your idea sounds very interesting. Feel free to extend
> pandocwiki if that works for you; it's GPL.
>
> John
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Ideas

[John MacFarlane]

lcs can be found at http://urchin.earth.li/darcs/igloo/lcs/

+++ Luc TAESCH [Aug 26 07 23:45 ]:
> when building , i cannot find the lcs mentionned in the cabal file not
> on hasckage nor on goggle.
> could you help?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: foreach

[Henning Thielemann]

On Wed, 13 Sep 2006, Bulat Ziganshin wrote:

> Wednesday, September 13, 2006, 1:12:35 PM, you wrote:
> 
> > Adding sugar or using Template Haskell for such a simple task is a bit
> > unreasonable. I think Tim should use mapM a little bit and then he will
> > probably need no longer a special syntax.
> 
> i disagree. lack of good syntax makes imperative programming in
> Haskell less convenient. i want to have such syntax in order to make
> Haskell great imperative language:
> 
> sum <- new 0
> arr <- new Array[1..3]
> for i in [1..3] do
>   sum += i
>   arr[i] := sum
> for i in [1..3] while arr[i]<2 do
>   print arr[i]

let arr = scanl1 (+) [1..3]
in  mapM_ print (takeWhile (<2) arr)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: foreach

[apfelmus]

Bulat Ziganshin wrote:

> because REAL code is somewhat larger than examples. try to rewrite the
> following:
> 
>   directory_blocks  <-  (`mapM` splitBy (opt_group_dir command) 
> files_to_archive)
> ( \filesInOneDirectory -> do
>   datablocks  <-  (`mapM` splitToSolidBlocks filesInOneDirectory)
> ( \filesInOneDataBlock -> do 
> [...]

This particular snippet contains too many undefined identifiers to be
rewritten effectively, but I'm very sure that the whole program can be
restructured to great effect.

Maybe by designing a "binary-block"-combinator language which calculates
padding bytes and length headers automatically and fiddles out
scheduling for fast writing to a pipe, something like that. Eventually,
a binary parser combinator library which can read single bit flags and
things is a must here. It may even be possible to combine the two
providing a bijection between abstract file tree, "tar"-ed blocks and
compressed binary file. Separate your concerns, ban IO as much as
possible and any function that takes more than 15 lines is a wart.

I admit that real world applications are not a good exercise to practice
functional programming, but once acquired, advanced functional tactics
prove very powerful. An example might be WASH/CGI which successfully
abstracts session state over HTTP, a problem where Perl-Scripts are
doomed and all kind of imperative buzz like JavaBeans and so on have
been invented but somewhat fail to solve it for non-trivial cases.

Regards,
afpelmus

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

[Haskell-cafe] Re: foreach

[Benjamin Franksen]

Brandon Moore wrote:
> Couldn't '\' delimit a subexpression, as parentheses do? Would there be
> any ambiguity in accepting code like State \s -> (s, s) instead of
> requiring State $ \s -> (s, s), or taking
> 
> main = do
> args <- getArgs
> foreach args \arg -> do
> foreach [1..3] \n -> do
> putStrLn ((show n) ++ ") " ++ arg
> 
> It would be a bit odd to have a kind of grouping the always starts
> explicitly and ends implicitly, but other than that it seems pretty
> handy, harmless, and natural (I know I've tried to write this sort of
> thing often enough)

Sounds like an extremely good idea to me.

Ben

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

[Haskell-cafe] Re: MonadList?

[Ashley Yakeley]

Michael Shulman wrote:


This is because (ErrorT e []) inherits its
instance of MonadPlus from Error, not from [].  (Is there a reason for
this, or is it just assumed that this is the more frequently desired
behavior?)


It's a flaw in MonadPlus, since it allows two different behaviours and 
really should be two different classes. See 
.


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

[Haskell-cafe] Re: MonadList?

[Michael Shulman]

On 9/19/06, Ashley Yakeley <[EMAIL PROTECTED]> wrote:

It's a flaw in MonadPlus, since it allows two different behaviours and
really should be two different classes. See
.


Ah, excellent.  So it sounds like at least in Haskell prime, I'll
probably be able to use MonadPlus to do what I want, because MaybeT
and ErrorT will be instances of MonadOr instead.

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

[Haskell-cafe] Re: MonadList?

[Ashley Yakeley]

Michael Shulman wrote:

Ah, excellent.  So it sounds like at least in Haskell prime, I'll
probably be able to use MonadPlus to do what I want, because MaybeT
and ErrorT will be instances of MonadOr instead.


I'm not sure if this is part of Haskell Prime, though.

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

[Haskell-cafe] Re: Haskore

[Jón Fairbairn]

"David Curran" <[EMAIL PROTECTED]> writes:

> Hi
> I have been trying to learn haskell (tip over the vending machine)

Tipping over a vending machine is a real world effect, so
you'll have to use the IO Monad.

-- 
Jón Fairbairn [EMAIL PROTECTED]

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

[Haskell-cafe] Re: Greetings

[Paul Johnson]

I've done some stuff with maybe 50k rows at a time.  A few bits and pieces:

1: I've used HSQL 
(http://sourceforge.net/project/showfiles.php?group_id=65248) to talk to 
ODBC databases.  Works fine, but possibly a bit slowly.  I'm not sure 
where the delay is: it might just be the network I was running it over.  
One gotcha: the field function takes a field name, but its not random 
access.  Access the fields in query order or it crashes.


2: For large data sets laziness is your friend.  When reading files 
"getContents" presents an entire file as a list, but its really 
evaluated lazily.  This is implemented using unsafeInterleaveIO.  I've 
never used this, but in theory you should be able to set up a query that 
returns the entire database as a list and then step through it using 
lazy evaluation in the same way.


3: You don't say whether these algorithms are just row-by-row algorithms 
or whether there is something more sophisticated going on.  Either way, 
try to make things into lists and then apply map, fold and filter 
operations.  Its much more declarative and high level when you do it 
that way.


Let us know how you get on.

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

[Haskell-cafe] Re: casting

[Thomas Conway]

On 10/9/06, I wrote:

So, can anyone suggest how I can achieve my goal?


And how many milliolegs of type hackery will it take? ;-)

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

[Haskell-cafe] Re: Data.List.join

[Stefan Holdermans]

Samuel wrote:


But wait! There is also a join in Control.Monad!


Josef replied:


Good point. But I don't really see that as a problem. Don't you think
the two 'join's can co-exist?


I do think it's a problem, for list are also monads. Instantiating  
the monadic join with [] we'd wind up with both


  join :: [[a]] -> [a]

and

  join :: [a] -> [[a]] -> [a]

which to me seems just a little too confusing.

Cheers,

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

[Haskell-cafe] Re: Class

[Slavomir Kaslev]

Err, sorry for the meaningless mail subject. Should be 'Newbie class
problem' or something like that.

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

[Haskell-cafe] Re: Versioning

[Joachim Durchholz]

Neil Mitchell schrieb:

You seem to be describing SYB and not knowing it:
http://homepages.cwi.nl/~ralf/syb1/

That basically does exactly what you've requested, in terms of
traversing all items when only one matters.


Yup, that's exactly what I was looking for. Actually I had seen it a 
while ago, but didn't remember it now. Thanks.


One thing that might become a problem is that the "Scrap your 
boilerplate" approach seems to work only in GHC.
There's nothing wrong with GHC, but it sounds like I'm committing to a 
specific compiler right from the start. I'd like to keep the number of 
choices as high as possible... and besides, if the compiler gives me an 
error message, or the generated code does unexpected things, I'd like to 
have the possibility to cross-check with a different compiler.


So have other compilers picked up SYB support yet?

It might be not feasible though. The papers mention that you can't 
serialize (well, actually unserialize) function values with it. For the 
envisioned update-through-marshalling process, this would prevent me 
from ever using function values in data that needs to be persistent, and 
that's quite a harsh restriction.



That said, serialisation is still a hard problem - think long and
hard before picking a data format.


What would be the problems of choosing the wrong one?


With Yhc.Core I used Drift to derve Binary instances, keep a version
tag, and if the version tags mismatch refuse to load the data.


Links?

Regards,
Jo

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

[Haskell-cafe] Re: Versioning

[Joachim Durchholz]

Ross Paterson schrieb:
It might be not feasible though. The papers mention that you can't 
serialize (well, actually unserialize) function values with it. For the 
envisioned update-through-marshalling process, this would prevent me 
from ever using function values in data that needs to be persistent, and 
that's quite a harsh restriction.


That's hard to avoid, unless you have a data representation of the
functions you're interested in.


I could encode functions by their name. I don't think that would scale 
to a large application with multiple developers, but it's not this kind 
of project anyway.
I'd be reluctant to accept that way if it means adding boilerplate code 
for every function that might ever be serialized. Since I'm planning to 
serialize an entire application, I fear that I'd need that boilerplate 
code for 90% of all functions, so even a single line of boilerplate 
might be too much.


Regards,
Jo

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

[Haskell-cafe] Re: Versioning

[Joachim Durchholz]

Robert Dockins schrieb:


Let me just say here that what you are attempting to do sounds very 
difficult.  As I understand, you want to be able to serialize an entire 
application at some (predetermined / arbitrary?) point, change some of 
its code and/or data structures, de-serialize and run the thing 
afterwards.


Right.

Though it's not too far out of the ordinary. Haskell being a rather 
orthogonal language, I had hoped that I can "simply serialize" any data 
structure.


> Doing something like this without explicit language support

is going to be hard, especially in a fairly static language like Haskell.


Exactly.
I was intrigued when I found that libraries can do quite a lot 
serialization in Haskell - that gives Haskell an excellent rating in 
what could be called "aspect-orientedness".

It doesn't help to serialize functions values or thunks, though.

I would think Smalltalk, Erlang, or something from the Lisp/Scheme 
family would be more suitable for this sort of work (caveat, I have 
little experience with any of these languages). 


Erlang is actually on my list of potential alternatives. It has 
different advantages than Haskell, though, and right now, I'm willing to 
try Haskell.



Also, take a look here (http://lambda-the-ultimate.org/node/526) for
some related discussion.


I'm not sure whether that relates to my project. I let network 
connections be handled by Apache and FastCGI, so I'm leaving out a whole 
lot of library issues that hit that reported project really hard.


Regards,
Jo

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

[Haskell-cafe] Re: Versioning

[Joachim Durchholz]

Simon Peyton-Jones schrieb:

| One thing that might become a problem is that the "Scrap your
| boilerplate" approach seems to work only in GHC.

I don't think so. Other compilers might not support "deriving Data",
but you can always write the instance by hand.


How much boilerplate would be needed in that case?
As far as I understood the web site, it would be around a line of code 
per data type, independently of the number of HOFs that need to iterate 
over the data structures - is that correct?


I understand that Drift is a kind of preprocessor / code generator. 
Could it be used to generate the necessary boilerplate?


Regards,
Jo

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

[Haskell-cafe] Re: HaskellForge?

[John Goerzen]

On 2007-01-07, Imam Tashdid ul Alam <[EMAIL PROTECTED]> wrote:
> is it a good idea to have HaskellForge?
>
> Ruby, Lua and some other languages have already
> adopted GForge, and I must say, those sites look
> *impressive*!!!

Have you looked at trac?  I'm using it for about a dozen projects over
on http://software.complete.org/.

For instance, http://software.complete.org/missingh

I looked at Savane and GForge, and both looks like they were overkill
for what I wanted.  They are both very invasive on the host system,
requiring user accounts to be setup, hosts entries added, DNS control,
all sorts of Apache tweaks, etc.  You really need a dedicated OS install
for them.  And neither really seemed to be all that featureful, either.
Wikis weren't a standard part of either, and forums were a deprecated
part of one.  The one thing they have over GForge is mailing list
integration, but I just point people to haskell-cafe anyway.

Plus: only trac has integration with darcs.

It took some time to get trac setup and working the way I want to, with
the right plugins, but once done, it's been happy.

-- John


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

[Haskell-cafe] Re: Currying

[Stephane Bortzmeyer]

On Thu, Jan 18, 2007 at 11:00:26AM +0100,
 [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote 
 a message of 15 lines which said:

> what is so great about "currying"?

The name is very cool.
 
> What are its uses, apart from letting one define functions with less
> parentheses?  

Partial applications.

http://fr.wikipedia.org/wiki/Curryfication

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

[Haskell-cafe] Re: Currying

[Johan Grönqvist]

[EMAIL PROTECTED] skrev:

Hello,

what is so great about "currying"?

What are its uses, apart from letting one define functions with less
parentheses?


Letting one apply them with less extra characters:

add x y = x + y
map (add 2) [1..5]

instead of
add (x,y) = x + y
let add2 y = add(2,y) in map add2 [1..5] end

(The last might not technically be partial application, but it serves 
the same purpose without using currying.)


I believe it makes code shorter and more readable, but I do not believe 
it gives more power.


/ johan

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

[Haskell-cafe] Re: DevRandom

[Yitzchak Gale]

It's short, so I'll post it here.
Any comments?

Thanks,
-Yitz

module DevRandom where

import System.IO
import System.IO.Error
import Foreign.Marshal.Alloc
import Foreign.Storable
import Foreign.Ptr

data BlockingMode = Blocking | NonBlocking
 deriving (Eq, Show)

-- Read data from the system random device.
-- Return Nothing if there is currently not
-- enough entropy in the system random device.
devRandom :: Storable a => IO (Maybe a)
devRandom = readDev "/dev/random" NonBlocking

-- Read data from the system random device.
-- If necessary, wait until there is
-- enough entropy in the system random device.
devRandomWait :: Storable a => IO a
devRandomWait = readDev dev Blocking >>= maybe (devRandomError dev) return
 where
   dev = "/dev/random"

-- Read data from the system random device.
-- If there is currently not enough entropy
-- in the system random device, use a lower
-- quality source of randomness instead.
devURandom :: Storable a => IO a
devURandom = readDev dev NonBlocking >>= maybe (devRandomError dev) return
 where
   dev = "/dev/urandom"

readDev :: Storable a => FilePath -> BlockingMode -> IO (Maybe a)
readDev dev mode = do
   h <- openFile dev ReadMode
   hSetBuffering h NoBuffering
   alloca $ getMaybe h undefined
 where
   getMaybe :: Storable a => Handle -> a -> Ptr a -> IO (Maybe a)
   getMaybe h undef ptr = do
 let size = sizeOf undef
 n <- case mode of
Blocking-> hGetBufh ptr size
NonBlocking -> hGetBufNonBlocking h ptr size
 if n < size
   then return Nothing
   else peek ptr >>= return . Just

devRandomError :: FilePath -> IO a
devRandomError p = ioError $ mkIOError illegalOperationErrorType
 "Unable to read from the system random device" Nothing (Just p)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Network.CGI.Compat.pwrapper

[Gracjan Polak]

Bjorn Bringert  cs.chalmers.se> writes:
> 
> > Another question is: how do I do equivalent functionality without  
> > pwrapper?
> 
> You can roll you own web server if you want something very simple. If  
> you don't want to do that, there is a version of Simon Marlow's  
> Haskell Web Server with CGI support [1]. You could also get the  
> original HWS [2] and merge it with your program. You might also be  
> interested In HAppS [3].

Haskell Web Server seems to be the closest match. I don't want fully 
functional web server. I need more low level thing, as I need to set 
this up as a testing environment for some other (browser like) application. 
So I need a way to trigger (atrificial) errors, like protocol errors, garbage 
and broken connections.

Thanks for the response.

Is there a description what is a *CGI* protocol? 

-- 
Gracjan


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

[Haskell-cafe] Re: Network.CGI.Compat.pwrapper

[Gracjan Polak]

Bjorn Bringert  cs.chalmers.se> writes:
> >
> > Is there a description what is a *CGI* protocol?
> 
> Here you go: http://hoohoo.ncsa.uiuc.edu/cgi/interface.html
> 

I should be more clear: what kind of data does pwrapper expect? Somewhere in the
middle it needs two handles: one to write and one to read which seem to be
equivalent to stdin/stdout. But what about environment? How is it transfered, as
someone ale pointed out pwrapper runs on different machine?

-- 
Gracjan




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

[Haskell-cafe] Re: process

[h .]

I have in mind something as connections via pipes to the chils's stdin, stdout 
and stderr, but the stream library just supports internal pipes, and posix 
require Unix. By this means it's not possible to request, receive and than 
respond,... with the process. Does there exist an alternative way?

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

[Haskell-cafe] Re: process

[h .]

Donald Bruce Stewart  cse.unsw.edu.au> writes:
> I usually use System.Process for this kind of thing.
> 
> http://haskell.org/ghc/docs/latest/html/libraries/base/System-Process.html
> 

As I wrote in "process":
[...]
As long as there is no need to put some input after having received some output 
it is no problem
[...]
module Main where
import System.Process
import System.IO

main :: IO ()
main = do
putStrLn "Running proc9..."
(inp,out,err,pid) <- runInteractiveProcess "prog1" [] Nothing Nothing
hSetBuffering inp LineBuffering
hSetBuffering out LineBuffering
hSetBuffering err LineBuffering
hPutStrLn inp "1"
a <- hGetLine out
hPutStrLn inp a
a <- hGetLine out
waitForProcess pid
putStrLn a
[...]


If it basically works, what goes wrong in my programm?


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

[Haskell-cafe] Re: process

[h .]

Jules Bean  jellybean.co.uk> writes:
> Well that depends entirely what your program is supposed to do.
> 
> Your email doesn't tell us (a) what your program was supposed to do or 
> (b) what goes wrong. Therefore we are forced to guess!
> 
> The following slight variation of your program works fine for me. I 
> don't have anything called 'prog1' on my system, so I used 'bc' which is 
> a calculator program standard on unixes, which works by line-by-line 
> interaction. I varied your program just a tiny bit to get some 
> interesting output:
> 
> module Main where
> import System.Process
> import System.IO
> 
> main :: IO ()
> main = do
> putStrLn "Running BC"
> (inp,out,err,pid) <- runInteractiveProcess "bc" [] Nothing Nothing
> hSetBuffering inp LineBuffering
> hSetBuffering out LineBuffering
> hSetBuffering err LineBuffering
> hPutStrLn inp "1+3"
> a <- hGetLine out
> hPutStrLn inp a
> a <- hGetLine out
> hPutStrLn inp "quit"
> waitForProcess pid
> putStrLn a
> 
> This program asks 'bc' to calculate "1+3".  The reply is stored in 'a'. 
> Then the program sends 'a' back to bc, effectively asking bc to 
> calculate "4". Since the "4" evaluates just to "4", 'a' gets the value 
> "4" once more.
> 
> Then I have to send "quit" to bc. That is the command that "bc" 
> interprets as an instruction to quit; without that command, 
> 'waitForProcess pid' will wait forever (it's waiting for bc to quit).
> 
> Finally my program outputs "4" the result of the last calculation.
> 
> Is this close to what you're trying to do?
> 
> Jules
> 

Thanks, but I still puzzle over the same problem.
I wrote the following lines to test exactely your code:

module Main where
main :: IO ()
main = f
  where
  f = do
a <- getLine
if a == "quit" then return () else putStrLn a >> f

running the program in the console works without any problems ("1+3" is the 
result :) ), but with runInteractiveProcess I do not get any output 
except "Running BC", and every IO action after the first hPutStrLn inp "1+3" is 
never reached (the program hang-up there - no error is thrown) - thats my 
problem...

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

[Haskell-cafe] Re: process

[h .]

Albert Y. C. Lai  vex.net> writes:

> 
> h. wrote:
> > module Main where
> > main :: IO ()
> > main = f
> >   where
> >   f = do
> > a <- getLine
> > if a == "quit" then return () else putStrLn a >> f
> 
> This one also needs to switch to line buffering. Add/Change:
> 
> import System.IO(stdout, hSetBuffering, BufferMode(LineBuffering))
> main = hSetBuffering stdout LineBuffering >> f
> 


Thanks a lot, now it does work!
This means just the proc1 program has to be changed and everything will work 
properly (hopefully - at least the haskell part works :) ).


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

[Haskell-cafe] Re: LDFLAGS

[Simon Marlow]

[EMAIL PROTECTED] wrote:

I have built ghc-6.6 twice for 64-bit OpenBSD 4.0 with
LDFLAGS=-L/usr/local/lib set as an environmental variable.  Both
times the built ghc did not find -lgmp until I modified
lib/ghc-6.6/package.conf by adding "-L/usr/local/lib" to ldOptions.
What do I set in order to have ldOptions set properly at the
conclusion of make;make install?


See this bug:

http://hackage.haskell.org/trac/ghc/ticket/957

Hopefully it should be fixed for 6.6.1.

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

[Haskell-cafe] Re: toClockTime

[Jón Fairbairn]

"Jeremy Shaw" <[EMAIL PROTECTED]> writes:
> Try using Data.Time instead -- it was written by a self-professed time
> nerd, and probably works correctly. It was added in GHC 6.6 and
> largely supercedes System.Time.

Curiously, Hoogle doesn't seem to have it indexed yet -- I
was looking for it just the other day and didn't find it.
I'm glad it's there in 6.6

-- 
Jón Fairbairn [EMAIL PROTECTED]
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2006-09-13)

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

[Haskell-cafe] Re: fix

[Pete Kazmier]

"Matthew Brecknell" <[EMAIL PROTECTED]> writes:

> As others have pointed out, fix is polymorphic, so "a" can stand for any
> type, including "(b -> c)". Removing redundant parentheses, this means
> fix can directly specialise to:
>
>> fix :: ((b -> c) -> b -> c) -> b -> c

I understand now.  I think part of my problem was that I was trying to
grasp one too many new things all at once.  This makes perfect sense.

Thanks,
Pete

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

[Haskell-cafe] Re: Ropes

[apfelmus]

Rafael Gustavo da Cunha Pereira Pinto wrote:
> I am doing the ICFPC07 task right now, to learn Haskell and tried to use the
> Sequence, but the final code is too damn slow (a few iterations per
> minute!).
> 
> The DNA needs only 2 operations: head (or take) and concat.
> 
> I am thinking in using ropes for the DNA and sequences for all the rest
> (patterns, templates and RNA).

I have been told that you could pretty much literally implement the algorithms
from the problem specification with  Seq  from  Data.Sequence  and achieve
acceptable speed (IIRC ~ one minute for generating a whole picture).

Are you sure that there is no unintentional bug in your implementation that
slows things down?


Regards,
apfelmus

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

[Haskell-cafe] Re: Ropes

[Rafael Gustavo da Cunha Pereira Pinto]

I have been told that you could pretty much literally implement the
> algorithms
> from the problem specification with  Seq  from  Data.Sequence  and achieve
> acceptable speed (IIRC ~ one minute for generating a whole picture).
>

Yes, it is straightforward to implement the algorithm when using sequences.



>
> Are you sure that there is no unintentional bug in your implementation that
> slows things down?
>

The test cases on the problem definition all worked, but they touch very
little of the code.

I added some "trace" calls, but could not see any trouble. I also did some
runs "by hand" and it  seemed ok.

If only Gödel was wrong... :-)


-- 
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.



-- 
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: System.Process

[Matti Niemenmaa]

Timothy Goddard wrote:
> On Tue, 30 Sep 2008 08:49:44 Andrew Coppin wrote:
>> Before anybody remarks that "words" will do this, consider the "echo" 
> command, which treats whitespace meaningfully.)
> 
> [EMAIL PROTECTED]:~/$ echo foo  barbaz
> foo bar baz
> 
> Echo doesn't receive special treatment. It joins its arguments with spaces.

D:\>echo foo  barbaz
foo  barbaz

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

[Haskell-cafe] Re: System.Process

[Simon Marlow]

Andrew Coppin wrote:

Anyway, the point I'm trying to get to is... would it be hard for 
however maintains this library to add a little more flexibility in what 
it can do please?


In the new System.Process, that comes with GHC 6.10.1:

Prelude System.Process> createProcess (shell "echo $FOO"){ env = Just 
[("FOO","BAR")] }

Prelude System.Process> BAR

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

[Haskell-cafe] Re: System.Process

[Andrew Coppin]

Simon Marlow wrote:

Andrew Coppin wrote:

Anyway, the point I'm trying to get to is... would it be hard for 
however maintains this library to add a little more flexibility in 
what it can do please?


In the new System.Process, that comes with GHC 6.10.1:

Prelude System.Process> createProcess (shell "echo $FOO"){ env = Just 
[("FOO","BAR")] }

Prelude System.Process> BAR


Ah, cool. So it's already in hand then...

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

[Haskell-cafe] Re: [] vs [()]

[Benjamin L . Russell]

On Fri, 10 Oct 2008 00:24:08 -0400, John Dorsey <[EMAIL PROTECTED]>
wrote:

>> dmehrtash:
>> >What is the difference between empty list [] and list with one unit
>> >element [()]?
>> 
>> Prelude> length []
>> 0
>> Prelude> length [()]
>> 1
>
>Also, they differ in type.
>
>[()] is a list of unit elements, and happens to contain exactly one
>of them.
>
>[] is a (polymorphic) list of any kind of element, and happens not to
>contain any of them.

Prelude> :type []
[] :: [a]
Prelude> :type [()]
[()] :: [()]

In fact, [()] contains an empty tuple, called a "unit" (see "4 Notes
and tips" of "Constructor - HaskellWiki" at
http://www.haskell.org/haskellwiki/Constructor), whereas [] is just an
empty list.

-- Benjamin L. Russell

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

[Haskell-cafe] Re: [] vs [()]

[Jon Fairbairn]

"Daryoush Mehrtash" <[EMAIL PROTECTED]> writes:

> What is the difference between empty list [] and list with one unit
> element [()]?


   Prelude> :m + Data.List
   Prelude Data.List> []\\[()]
   []

or, for completeness, the difference between a list with one
unit element and the empty list:

   Prelude Data.List> [()]\\[]
   [()]

:-P

-- 
Jón Fairbairn [EMAIL PROTECTED]


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

[Haskell-cafe] Re: [] vs [()]

[Mauricio]

What is the difference between empty list [] and list with one unit 
element [()]?





Or, yet:

():[()] --is legal
10:[()] --is not

One list can contain elements of a
single type. Since the type of () is
() (element constructors  and types
are allowed to have the same name),
a list of type [()] can only contain
elements of type (), i.e., ()s. Try
this is ghci:

:t [()]
:t [(),(),(),()]

Best,
Maurício

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

[Haskell-cafe] Re: Crash!

[Achim Schneider]

Andrew Coppin <[EMAIL PROTECTED]> wrote:

> Well what do you know? I have actually managed to write a pure
> Haskell program that generates an actual access violation when run!
> o_O
> 
Did you already make a decision on the colour of the frame? I think I
would pick blue.

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.

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

[Haskell-cafe] Re: OOPer?

[Maurí­cio]

(...)

GHC says that the type of the result of 'function' is both determined by
the "rigid type" from MyClass and  the "rigid type" from MyData. But why
can't both be the same?


are you OOPer? :)



What is an OOPer?

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

[Haskell-cafe] Re: Cabal

[mail]

Don Stewart <[EMAIL PROTECTED]> writes:
>
> I'm a fan of gitit, and its 46 dependencies, that install via
> cabal-install. Pretty awesome.
>

gitit's 46 dependencies convinced me to install cabal-install, and now I
couldn't be happier!

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

[Haskell-cafe] Re: Data.List.Split

[Matti Niemenmaa]

Adam Vogt wrote:
> * On Saturday, December 13 2008, Gianfranco Alongi wrote:
>> I have actually been thinking about a similar thing, but on the "group" 
>> subject.
>> One can actually group things in many ways, such as groupBy (==) , so
>> that groupBy (==) [1,2,1,2] should give
>> [[1,1],[2,2]]. Of course other ideas are possible.
> 
> That result happens with:
> 
>> sortedGroups = group . sort
> 
> That composition is pretty, unlike those splitting functions. I don't know 
> if manually fusing sort and group helps performance at all though.

Sorting requires an Ord instance, though. Here's a relatively simple but slow
way which doesn't:

fullGroupBy :: (a -> a -> Bool) -> [a] -> [[a]]
fullGroupBy rel xs = map (\a -> filter (rel a) xs) (nubBy rel xs)

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

[Haskell-cafe] Re: OpenAL

[Paul Langevin]

>Does the example code at
>http://articles.bluishcoder.co.nz/Haskell/OpenAL work for anyone? 

sorry for the delay, Brian :

I can hear the two sounds one after the other (I wish I knew how to hear them 
at the same time).
However, I've got a strange error message from ALSA :
"
alsa_blitbuffer: Could not write audio data to sound device: File descriptor in 
bad state
mixer: pcm.c:2644: snd_pcm_areas_copy: Assertion 'dst_areas' failed.
"

(mixer is the name of the executable (because I thought...))

OpenAL version : 1.3
ALC version : 1.0
AL version : 1.1
Ghc version : 6.6
_
Téléphonez gratuitement à tous vos proches avec Windows Live Messenger  !  
Téléchargez-le maintenant ! 
http://www.windowslive.fr/messenger/1.asp___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Haddock

[David Waern]

Hi everyone,

I received this question from Lennart Augustsson (via Simon M) and
thought I'd send out an inquiry to the Haskell community in general
(Lennart, I hope you don't mind):

Lennart writes:
> We have some local patches for haddock that extends the <>
> syntax so you can put TeX formulae in the documentation.
> It looks like, <>, but I'd like to extend it so
> you can process the string with any command.
>
> Are you interested in folding this into the main branch?

So the question is about extending the Haddock markup language.

When modifying the language we should think about the tension between
familiarity, presentation features (pictures, math, whatever) and
visual portability across different mediums (HTML, ghci, IDE tooltips,
etc). And here I should say that Haddock already supports pictures
using the << url >> syntax.

IMHO, adding <> for TeX math is fine, because:

  - math in documentation is often useful
  - if you're going to write math, you need a format, even when the
medium is plain text as in ghci.
  - TeX formulae seem to be relatively widely used and understood.

As for running arbitrary commands, I think we are opening up to a lot
of unfamiliar syntax. I'd like to hear what everyone thinks about
that.

There was also a thread about Haddock markup on haskell-cafe@ about a
year ago, which originated with the interesting idea of using Markdown
(or a Pandoc-extended version of it) instead of the current language:

  http://www.mail-archive.com/haskell-cafe@haskell.org/msg38054.html

I think the original idea there is pretty nice, but let's first focus
on the current markup language in order to answer Lennart's question.
That thread contains some useful opinions on this matter, also.

So, any comments? :)

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

[Haskell-cafe] Re : OpenAL

[Paul Langevin]

For those who follow, I finally  find the way to mix (simpler than I thought)

import Sound.ALUT

playSound :: IO ()
playSound = withProgNameAndArgs runALUT $ \ _ _ -> do
↠ buffer1 <- createBuffer $ Sine 440 0 1
↠ buffer2 <- createBuffer $ HelloWorld
↠ [source1,source2] <- genObjectNames 2
↠ buffer source1 $= Just buffer1
↠ buffer source2 $= Just buffer2
↠ play [source1,source2]
↠ sleep 2
↠ return ()

main = playSound

(sorry if unicode if ugly, I don't know what to do with spaces)


_
Téléphonez gratuitement à tous vos proches avec Windows Live Messenger  !  
Téléchargez-le maintenant ! 
http://www.windowslive.fr/messenger/1.asp___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: OpenAL

[Paul Langevin]

> AL lib: alSource.c:2291: alcDestroyContext(): 1 Source(s) NOT deleted

Brian, have you tried

currentContext $= Nothing

before closing the device ?

It works for me now : no message from ALSA (and still the sounds)



_
Téléphonez gratuitement à tous vos proches avec Windows Live Messenger  !  
Téléchargez-le maintenant ! 
http://www.windowslive.fr/messenger/1.asp___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re : OpenAL

[Paul Langevin]

by the way, a mean to get it done without error is to not use 
runALUTUsingCurrentContext :

import Sound.ALUT

playSound :: IO ()
playSound = withProgNameAndArgs runALUT $ \ _ _ -> do
buffer1 <- createBuffer $ Sine 440 0 1
buffer2 <- createBuffer HelloWorld
[source] <- genOjectNames 1
queueBuffers source [buffer1,buffer2]
play [source]
sleep 2
return ()

main = playSound


I'm not sure if haskell-cafe will take spaces into account. If not, only 7 
lines should be tabulated after do. 

Does anyone know how to mix buffers ?


_
Vous voulez savoir ce que vous pouvez faire avec le nouveau Windows Live ? 
Lancez-vous !
http://www.microsoft.com/windows/windowslive/default.aspx___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Math.Statistics

[ok]

There are a number of interesting issues raised by mbeddoe's  
Math.Statistics.


0.  Coding issues.

Why use foldr1 (*) instead of product?

covm xs =  split' (length xs) cs
  where
cs = [ cov a b | a <- xs, b <- xs]
split' n = unfoldr (\y -> if null y then Nothing
  else Just $ splitAt n y)

seems a rather odd way to write

covm xs = [[cov a b | b <- xs] | a <- xs]

which in turn is a bit wasteful because the matrix must be
symmetric.

I believe the author may have misunderstood "numerically stable".
The obvious (sum xs)/(fromIntegral $ length $ xs) is fine for
the mean, and the obvious two-pass algorithm for the variance is
fine.  The tricky algorithms are needed for incremental one-pass
calculation.

1.  How do you decide how general to make things?

mean, hmean: Floating a
But only + and / are needed, so Fractional a is enough.
gmean: Floating a
You need + and /, so fair enough.
median: Floating a, Ord a
High median and low median (not provided) need only Ord a.
Standard median needs + and /, so fair enough.
modes: Ord a
Right.
range: Num a, Ord a
But range needs only Ord a.
avgdev: Floating a
Right.
pvar, var, stddev, skew, kurtosis, cov, covm: Floating a
How should one define the variance of a collection of complex
numbers?  I'm not at all sure that it makes sense.  If I were
dealing with complex numbers, I might treat them as 2-vectors,
in which case the "standard deviation" would be a 2x2 matrix,
not a complex number.  I suspect that these should require
Floating a, Ord a.  For skew this is quite certain: one looks
for "positive" or "negative" skew, and this makes no sense for
complex numbers.
   iqr: type not specified but appears to be :: [a] -> [a]
This is certainly the wrong type as the inter-quartile range
is supposed to be a NUMBER, not a sequence.  You have to use
comparisons and subtraction, so
iqr :: Num a, Ord a => [a] -> a

2. Statistics

This is an odd bunch of things; mostly things that are dangerous to
use.  A collection of the techniques from "Applications, Basics,  
and

Computing" by Hoaglin and Velleman (and was there someone else?
memory fails me) would be nice.  A few basic robust measures like
- median absolute deviation
- trimmed mean
- Winsorized standard deviation
- percentage bend correlation
might be nice.

3.  How laziness could help.

Suppose you ask for the mean, standard deviation, and skewness of
a bunch of numbers using this library.  Calculating the standard
deviation will recalculate the mean.  Calculating the skewness
will recalculate the standard deviation, which will recalculate the
mean.

Robust statistics, like the trimmed mean, often want to sort the
data.  And you don't want to keep on sorting the data over and over
again.

This is a case where Haskell's laziness really shines: it translates
into direct practical gains for simple code.

data (Floating a, Ord a)
  => Simple_Continuous_Variate a
   = SCV [a] Int a a (Array Int a)

list_to_variate xs = SCV xs n m s o
  where n = length xs
m = sum xs / fromIntegral n
s = sum [(x - m)^2 | x <- xs] / fromIntegral (n - 1)
o = listArray (1,n) (sort xs)

vLength (SCV _ n _ _ _) = n
vMean   (SCV _ _ m _ _) = m
vSd (SCV _ _ _ s _) = s
vMin(SCV _ _ _ _ a) = a ! 1
vMax(SCV _ n _ _ a) = a ! n
vRange   scv= vMax scv - vMin scv
vMedian (SCV _ n _ _ a)
  | odd n   = a ! ((n+1)`div`2)
  | even n  = ((a ! l) + (a ! u))/2
  where l = n `div` 2
u = n - l
.

The wonderful thing about this is that there are no bangs in SCV, so
the various pieces of information don't get evaluated until they are
needed, and then don't get evaluated *again*.  For example, vRange
will cause the sorted array to be built at most once.  Trimmed mean
is very little harder to write than vMedian.

Esoteric uses of lazy evaluation abound, but this one makes sense  
even to

an old number-crunching programmer.  I once built something like this in
C, but boy, it was a pain.

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

[Haskell-cafe] Re: Math.Statistics

[ChrisK]

ok wrote:
> There are a number of interesting issues raised by mbeddoe's
> Math.Statistics.
> 
> data (Floating a, Ord a)
>   => Simple_Continuous_Variate a
>= SCV [a] Int a a (Array Int a)
> 
> list_to_variate xs = SCV xs n m s o
>   where n = length xs
> m = sum xs / fromIntegral n
> s = sum [(x - m)^2 | x <- xs] / fromIntegral (n - 1)
> o = listArray (1,n) (sort xs)
> 
> vLength (SCV _ n _ _ _) = n
> vMean   (SCV _ _ m _ _) = m
> vSd (SCV _ _ _ s _) = s
> vMin(SCV _ _ _ _ a) = a ! 1
> vMax(SCV _ n _ _ a) = a ! n
> vRange   scv= vMax scv - vMin scv
> vMedian (SCV _ n _ _ a)
>   | odd n   = a ! ((n+1)`div`2)
>   | even n  = ((a ! l) + (a ! u))/2
>   where l = n `div` 2
> u = n - l
> .

Math.Statistics eats many good names. I would also suggest offering a type class
interface.  Then you could operate on various containers besides a list:

-- A class for extracting a summary number from a type.
-- None of these make much sense without Ord.
-- I could imagine using (+) and `div` so why require (/)?
class (Ord b) => SingleStat a b | a -> b where
   samples :: a -> Integer  -- lump in with SingleStat
   mean :: a -> b
   var :: a -> b
   stddev :: a -> b
   moment :: Int -> a -> b
   range :: a -> b
   min :: a -> b
   max :: a -> b
   median :: a -> b

instance SingleStat [Integer] Integer where ...
instance SingleStat [Double] Double where ...
instance (Ix i) => SingleStat (Array i Double) Double where ...
instance SingleStat (Simple_Continuous_Variate a) where ...

-- And then I could make interesting things like Histogram,
-- where the data is Int's but the statistics are Doubles:

newtype Histogram = Histogram (Map Int Int)
instance SingleStat Histogram Double where ...

Cheers,
  Chris

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

[Haskell-cafe] Re: Math.Statistics

[apfelmus]

ok wrote:


I believe the author may have misunderstood "numerically stable".
The obvious (sum xs)/(fromIntegral $ length $ xs) is fine for
the mean,


That's probably my fault, out of ignorance. Do you know a good online 
resource about numeric stability? (I don't have the Knuth at home. 
Didn't he say something about the mean formula? Or was it the standard 
derivation?).


Regards,
apfelmus

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

[Haskell-cafe] Re: pi

[ChrisK]

[EMAIL PROTECTED] wrote:
> Yitzchak Gale writes:
>> Dan Piponi wrote:
>>> The reusability of Num varies inversely with how many
>>> assumptions you make about it.
>>
>> A default implementation of pi would only increase usability,
>> not decrease it.
> 
> Suppose I believe you. (Actually, I am afraid, I have doubts.)
> Can you provide some examples of this "increased usability"?
> If possible, with a *relevant* context, which shows that PI should belong
> by default to the class Floating (whatever we mean by that...)
> Somehow I do not only think that the default implementation would be good
> for nothing, but that putting PI into Floating as a class member, serves
> nobody.

Putting 'pi' in the same class as the trigonometric functions is good design.

> I would be happy to learn that I am mistaken, but if it is just
> to save 5 seconds of a person who wants to pass smoothly between floating
> numbers of single and double precision...
> Jerzy Karczmarczuk

Moving smoothly from single to double precision was much of the motivation to
invent a mechanism like type classes in the first place.

There are two things in Floating, the power function (**) [ and sqrt ] and the
transcendental functions (trig functions,exp and log, and constant pi).

Floating could be spit into two classes, one for the power and one for the
transcendental functions.  And I would bet that some of the custom mathematical
prelude replacements do this.

If you do not want 'pi' in a class named Floating then you have to move all the
transcendental stuff with it.

If you do not want 'pi' in any class, then you cannot reasonably put any of the
transcendental functions in a class.  This would really degrade the API.

-- 
Chris

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

[Haskell-cafe] Re: pi

[jerzy . karczmarczuk]

ChrisK writes:


Putting 'pi' in the same class as the trigonometric functions is good design.


If you wish so... But:
Look, this is just a numeric constant.
Would you like to have e, the Euler's constant, etc., as well, polluting
the name space? What for?


Moving smoothly from single to double precision was much of the motivation to
invent a mechanism like type classes in the first place.


Pardon?
I think I remember the time when type classes have been introduced. The
motivation you mention is not very visible, if at all... Actually, the
numerical hierarchy was - as the French would say - "bricolée" with plenty
of common sense, but without a decent methodology... The type classes is
a splendid invention, much beyond any numerics.
Besides, most people who *really* need FlP numerics use only the most
precise available, the "single precision" stuff is becoming obsolete.


There are two things in Floating, the power function (**) [ and sqrt ] and the
transcendental functions (trig functions,exp and log, and constant pi).

Floating could be spit into two classes, one for the power and one for the
transcendental functions.


The power is an abomination for a mathematician. With rational exponent it
may generate algebraic numbers, with any real - transcendental... The
splitting should be more aggressive. It would be good to have *integer*
powers, whose existence is subsumed by the multiplicative s.group structure.
But the Haskell standard insists that the exponent must belong to the same
type as the base...


If you do not want 'pi' in a class named Floating then you have to move all the
transcendental stuff with it.


I would survive without moving anything anywhere, I assure you.


If you do not want 'pi' in any class, then you cannot reasonably put any of the
transcendental functions in a class.  This would really degrade the API.


What??
But it is just a numerical constant, no need to put it into a class, and
nothing to do with the type_classing of related functions. "e" is not
std. defined, and it doesn't kill people who use exponentials.

Jerzy Karczmarczuk

PS. One of the US Army folklore slogans say: "if it's ain't broken, don't
fix it." I would say: if what you need is one good exemplar, don't overload
it.

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

[Haskell-cafe] Re: pi

[Aaron Denney]

On 2007-10-10, [EMAIL PROTECTED] wrote:
> ChrisK writes: 
>
>> Putting 'pi' in the same class as the trigonometric functions is good design.
>
> If you wish so... But:
> Look, this is just a numeric constant.
> Would you like to have e, the Euler's constant, etc., as well, polluting
> the name space? What for? 

It's there in the form (exp 1), after all.  Yeah, you can get pi from
(log i), but the multi-valuedness is annoying.  Not an issue with exp.

> The power is an abomination for a mathematician. With rational exponent it
> may generate algebraic numbers, with any real - transcendental... The
> splitting should be more aggressive. It would be good to have *integer*
> powers, whose existence is subsumed by the multiplicative s.group structure.
> But the Haskell standard insists that the exponent must belong to the same
> type as the base... 

Yes, this is an issue.  I wish there were a serious plan for reworking
the numeric hierarchy for Haskell', but no one seems to interested.
I've thought about writing something up, but with it not entirely clear
what subset of MPTCs, FunDeps, and ATs will be in, that makes a design
a bit trickier.

class Exponential a where
(^) :: (Integral b) => a -> b -> a

> What??
> But it is just a numerical constant, no need to put it into a class, and
> nothing to do with the type_classing of related functions. "e" is not
> std. defined, and it doesn't kill people who use exponentials. 

As I said above, it effectively is.  And, after all, 1, 2, 3, are
constants of the typeclass Integral a => a, 
and 0.0, 1.348, 2.579, 3.7, etc. are in Floating a => a.
So why not pi?

-- 
Aaron Denney
-><-

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

[Haskell-cafe] Re: pi

[Aaron Denney]

On 2007-10-10, [EMAIL PROTECTED] wrote:
> Oh yes, everybody in the world uses in ONE program several overloaded
> versions of pi, of the sine function, etc.

They don't have to be in the same program for overloaded versions to be
semantically useful.  They're not strictly necessary, but so?
Having different programs use compatible conventions really is a win.

> How often *you* needed simultaneously overloaded pi and trigs in such a way
> that a default could help you? Answer sincerely (if you wish to answer at
> all...) 

Oh, just about never.   But the defaults are the issue, not the
simultaneously overloaded pi and trig functions.

-- 
Aaron Denney
-><-

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

[Haskell-cafe] Re: pi

[jerzy . karczmarczuk]

David Roundy: 


jerzy.karczmarczuk:



The power is an abomination for a mathematician. With rational exponent it
may generate algebraic numbers, with any real - transcendental... The
splitting should be more aggressive. It would be good to have *integer*
powers, whose existence is subsumed by the multiplicative s.group structure.
But the Haskell standard insists that the exponent must belong to the same
type as the base...


I suppose you're unfamiliar with the (^) operator, which does what you
describe?


Sorry for being imprecise. I know (^), certainly, I wanted to suggest that
the power should THEN belong to Num; if a multiplication is defined, surely
the integer power as well, although this is somewhat delicate, since (*)
defines a semi-group. That's why (^) for negative exponent, yells.
And that's why we have also (^^) for Fractionals, which calls recip for
the negative exponent. 


... Where is the abomination here?


Having THREE different power operators, one as a class member, others as
normal functions. Do you think this is methodologically sane? 


===
Other message: 


Would you also prefer to eliminate sqrt and log? We've been using these
functions for years (in other languages)... I think it's quite sensible, 
for instance, that passing a negative number as the first argument of 
(**) with the second argument non-integer leads to a NaN.


As you wish. But, since this is an overloaded class member, making it
sensitive to the exponent being integer or not, is awkward. And perhaps
I would *like* to see the result being complex, non NaN?
Oh, you will say that it would break the typing. NaN also does it, in
a sense. And this suggests that the type a->a->a is perhaps a wrong choice.
Of course, this implies a similar criticism of log and sqrt...
(One of my friends embeds the results of his functions in a generalization
of Maybe [with different Nothings for different disasters], and a numerical
result, if available, is always sound.) 


I am not sure whether Henning's ideas convince me entirely, and his
statement "In mathematical notation we don't respect types" seems to be
perhaps too strong (unless 'notation' means just the notation, which
doesn't "respect anything"), but the relation between mathematical domains
and the type system should one day be sanitized. 

Jerzy Karczmarczuk 



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

[Haskell-cafe] Re: pi

[Aaron Denney]

On 2007-10-11, Jonathan Cast <[EMAIL PROTECTED]> wrote:
> Yes.  I am very eager to criticize your wording.  To wit, I'm still
> failing to understand what your position is.  Is it fair to say that
> your answer to my question, why pi has no default implementation, is `in
> fact, pi shouldn't be a method of Floating anyway'?

That was how I was reading him.

> Btw: I am arguing that I (still) don't understand why the line
>
> pi = acos (-1)
>
> or something like it doesn't appear at an appropriate point in the
> Standard Prelude, given that the line
>
> pi :: a
>
> appears nearby said point.  I am eager to be enlightened.  But I haven't
> been, yet.

You would have to ask the committee.  But I think it's a bad idea to
have such a default (or 4 * atan 1, or ...) because of calculational
issues.  It's not a useful default, except for toy uses.  Yeah, it works
"fine" for float and double on hardware with FPUs.  But I want to be
told that I haven't implemented it, rather than it getting a really
awful default.  Most of the defaulting in other classes are minor
wrappers, such as converting between (<=) and compare, not actual
algorithmic implementations, which can pull in strongly less efficient
implementations.

-- 
Aaron Denney
-><-

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

[Haskell-cafe] Re: do

[ChrisK]

[EMAIL PROTECTED] wrote:
> Peter Verswyvelen writes about non-monadic IO, unique "external worlds":
>> But... isn't this what the Haskell compiler & runtime do internally
>> when IO monads are executed? Passing the RealWorld "singleton" from
>> "action" to "action"? 

In GHC, yes.

> 
> I never looked into any Haskell compiler. Chalmers, or York, don't
> remember,
> used continuations, this seems a bit different from the Clean approach, but
> I don't really know the gory details.
>> To me, no real difference exists between IO monads and Clean's uniques
>> types; it's just a different approach to tackle the same problem. 
> 
> Yes, *different approach*. So, there *are* differences. Compilers, anyway,
> are special applications. I wanted to see - responding to Brandon - a
> "normal" Haskell program, which does IO without monads, that't all.

> The problem is then when you hide something, you hide. It is possible to
> superpose a kind of monadic framework on unique worlds, files, etc. in
> Clean, but the reverse operation goes beyond my horizons.

> Some examples, anybody?
> Jerzy Karczmarczuk

I don't have examples, but I can show you where the gory details are hiding:

The Haskell 98 standard specifies the API for input/output to be using the IO
monad.  If you want to use Haskell 98 to do input/output without the IO monad
then you will find that you cannot do so. I see three ways to go around 
Haskell98.

Common caveat: The thing that using the provided IO monad does is provide a
standard way of sequencing two input/output operations.   Once you avoid that
sequencing then you indeterminism unless you provide your own sequencing 
manually.

The first, which you may decide does not really count, is using
"unsafePerformIO" or "unsafeInterleaveIO" and avoiding the sequencing provided
by the IO monad.  This still does nothing to tell you about the gory details.

As a cheat: If you use the FFI addendum then you can access all the impure c
input/output functions and lie about their type so that are not in IO.  Then you
could manually manage their sequencing and control everything.  This comes
closer to understanding how the standard IO operations are implemented in the
gory details.

For the GHC implementation of Haskell it is possible to go inside the IO monad
and operate using the same gory details that GHC uses.  This is probably what
you want to see, but note that it is not the only compiler or the only way to do
this.

The details are in the source at
http://darcs.haskell.org/ghc-6.6/packages/base/GHC/
in IOBase.lhs and IO.hs and so on...

>From IOBase.lhs I see that GHC uses a newtype around a function of type
State b -> (State b, a) to represent IO a.
The State b is actually an unboxed type "State# RealWorld".  The tuple is
likewise an unboxed "(# , #)" tuple.

> newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #))
> 
> unIO :: IO a -> (State# RealWorld -> (# State# RealWorld, a #))
> unIO (IO a) = a

Also in IOBase.lhs this is made into a Functor and, inevitably, a monad:

> instance  Functor IO where
>fmap f x = x >>= (return . f)
> 
> instance  Monad IO  where
> {-# INLINE return #-}
> {-# INLINE (>>)   #-}
> {-# INLINE (>>=)  #-}
> m >> k  =  m >>= \ _ -> k
> return x  = returnIO x
> 
> m >>= k = bindIO m k
> fail s= failIO s

> returnIO :: a -> IO a
> returnIO x = IO (\ s -> (# s, x #))

> bindIO :: IO a -> (a -> IO b) -> IO b
> bindIO (IO m) k = IO ( \ s ->
>   case m s of 
> (# new_s, a #) -> unIO (k a) new_s
>   )

> failIO :: String -> IO a
> failIO s = ioError (userError s)
>
> -- | Raise an 'IOError' in the 'IO' monad.
> ioError :: IOError -> IO a 
> ioError   =  ioException
>
> ioException   :: IOException -> IO a
> ioException err =  IO $ raiseIO# (IOException err)
> 

Where raiseIO# is from GHC.Prim
http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-Prim.html
http://darcs.haskell.org/ghc/compiler/prelude/primops.txt.pp

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