On Wed, 8 Dec 2004 19:27:56 +0100, Gour
<[EMAIL PROTECTED]> wrote:
> > Three of us also have a very rough start on a hands-on, practical
> > introduction to Haskell aimed at the experienced imperative programmer.
>
> This is *very* important - bringing new people from the imperative (I do not
> me
John Goerzen ([EMAIL PROTECTED]) wrote:
> I think the two main things to do that would be:
>
> 1. Write Haskell code that has a wide appeal (example: darcs)
Agree. One individual wrote an application of the (very) general interest
'educating' programmers about Haskell's adequacy as a general pr
On Wed, 8 Dec 2004, Duncan Coutts wrote:
> I use HashTable like so:
>
> import Data.HashTable (HashTable)
> import qualified Data.HashTable as HashTable
If you give a generic name for the type, you can leave out the first
'import' and can stick completely to qualified identifiers, like
HashTabl
On Wed, 2004-12-08 at 17:04 +0100, Henning Thielemann wrote:
> On Wed, 8 Dec 2004, Duncan Coutts wrote:
>
> > There are actually several options here, you can import modules only
> > qualified, then every value from that module needs to be qualified. Some
> > modules are designed to be used this w
I'm appreciating the feedback. I discovered where I was going wrong.
The library I was using allowed me to import a module, which in turn
allowed me to use functions from other modules. So even though I could
use func directly I couldn't use B.func because I hadn't explicitly
imported B.
I find
On Wed, 2004-12-08 at 07:58 -0700, [EMAIL PROTECTED] wrote:
> I've got a general new person type question.
>
> I understand that I can hide a function in a module that I am importing
> if it conflicts with another identical function name.
>
> But if the situation arises that I would like to use t
[EMAIL PROTECTED] wrote:
I've got a general new person type question.
I understand that I can hide a function in a module that I am importing
if it conflicts with another identical function name.
But if the situation arises that I would like to use two identically
named functions from two differen
On Wed, 8 Dec 2004 [EMAIL PROTECTED] wrote:
> But if the situation arises that I would like to use two identically
> named functions from two different modules is there anyway for me to
> specify that I want to use the function from module A rather then the
> function from module B.
A.func
B.fu
I've got a general new person type question.
I understand that I can hide a function in a module that I am importing
if it conflicts with another identical function name.
But if the situation arises that I would like to use two identically
named functions from two different modules is there any
> Is it possible and senseful for a compiler to extract common
> sub-expressions? Naively I think that for a given tree of an
> expression it is efficiently possible to find all common sub-trees.
> Referential transparency would assure that equal expressions have the
> same value, so they can be re
On Wed, 8 Dec 2004, Daniel Fischer wrote:
> Am Mittwoch, 8. Dezember 2004 10:22 schrieben Sie:
> > On Tue, Dec 07, 2004 at 06:44:33PM +0100, Daniel Fischer wrote:
> > > ms :: [Integer] -> [Integer]
> > > ms as = zipWith (+) (zipWith (*) as (1:ms as)) (0:1:ms as)
> >
> > This version seems to be f
Your suggestion amounts to giving the programmer more control over the
ABI compared to the current extreme options:
(a) -O0,ABI == API
(b) -O[12], ABI == entire implementation + ABI of dependencies
in addition, the ABI includes the version of GHC that compiled the code.
Providing an option
On Wed, Dec 08, 2004 at 11:11:44AM +, Keean Schupke wrote:
> You can also do this in a way that statically guarantees the property...
>
> First you need to lift the numeric argument to the type level... This is
> harder for a double than an integer, but not impossible... First convert
> the do
Am Mittwoch, 8. Dezember 2004 10:22 schrieben Sie:
> On Tue, Dec 07, 2004 at 06:44:33PM +0100, Daniel Fischer wrote:
> > ms :: [Integer] -> [Integer]
> > ms as = zipWith (+) (zipWith (*) as (1:ms as)) (0:1:ms as)
>
> This version seems to be faster, but I don't know if it addresses your
> concern:
You can also do this in a way that statically guarantees the property...
First you need to lift the numeric argument to the type level... This is
harder
for a double than an integer, but not impossible... First convert the
double to
a pair of Integers (an infintite precision rational number)... T
mattr wrote:
Haskell is still a very dynamic language - there is still much room for
it to grow and improve. In that sense, it is still young.
Perl and Python and Ruby have hit middle age - no more growing, just
more bulk accumulating around the middle.
Or in Perl's case, a seriously ambitious
Daniel Fischer wrote:
Hi,
I have recently come across the curious phenomenon that ghci is sometimes much
slower than hugs.
[...]
ms as = zipWith (+) (zipWith (*) as (1:ms as)) (0:1:ms as)
Hugs has(**) a specific optimisation for the case where the left hand
side of the declaration occurs as a su
On Tue, Dec 07, 2004 at 06:44:33PM +0100, Daniel Fischer wrote:
>
> ms :: [Integer] -> [Integer]
> ms as = zipWith (+) (zipWith (*) as (1:ms as)) (0:1:ms as)
This version seems to be faster, but I don't know if it addresses your
concern:
ms as = let l = zipWith (+) (zipWith (*) as (1:l)) (0:1
Steven Huwig wrote:
On Dec 6, 2004, at 11:05 PM, Tom Pledger wrote:
import Data.Char(isSpace)
import Data.List(groupBy)
(op `on` f) x y = f x `op` f y
wordsAndSpaces = groupBy ((==) `on` isSpace)
`on` is a handy little function in this instance.
Does it have a technical name?
Perhaps
19 matches
Mail list logo
