Re: [Haskell-cafe] Python?

2005-05-11 Thread Samuel Bronson
On 11/05/05, Jerzy Karczmarczuk <[EMAIL PROTECTED]> wrote:
> Michael Vanier comments my defense of Matlab:
> 
> >>I used objects, and even a lot of functional
> >>constructs. I don't see any reason to call it a creeping horror.
> >>It is quite homogeneous and simple, and is decently interfaced.
> >>
> >>
> >>
> >
> >It's incredibly inconsistent.  To cite just one example, the syntax is
> >geared towards the notion that "everything is a two-dimensional matrices of
> >double-precision floating point numbers".  If you want to have a
> >three-dimensional array, you can do that, but the syntax is not going to be
> >nearly as elegant, because matlab's array syntax doesn't scale at all.
> >
> Come on...
> Matlab has cells and the full object-oriented layer nowadays. There
> are short ints, strings, complex numbers, etc. The extensibility is
> good. The overall consistency is reasonable.

I had to use it a bit for a class and it was *PURE PAIN* beyond the
simplest of things.

> Syntax for 3D arrays?
> Give me one single language where this is natural and immediate.

Numerical Python! Yes, the syntax is Python's, but the syntax doesn't
really do much of anything unless you use it with Numeric. Anyway, the
syntax is quite uniform and general. You can use it for any number of
dimensions (including 0!).

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


Re: [Haskell-cafe] Re: Haskell-Cafe Digest, Vol 21, Issue 27

2005-05-11 Thread Samuel Bronson
On 11/05/05, Stijn De Saeger <[EMAIL PROTECTED]> wrote:
> Quinn Dunkan <[EMAIL PROTECTED]> wrote :
> 
> > ... It is very natural to
> > write in a somewhat functional style, especially in regards to
> > sequence processing: higher order functions and listcomps provide the
> > processing and its built in generators and iterator protocol provide
> > some of the benefits of laziness.  Its elementary pattern matching
> > encourages you to return as many values from a function as you need
> > and use zip() (another haskell steal) to iterate over parallel
> > sequences (all pattern matches are irrefutable, though).
> 
> I'm confused... Python has pattern matching ?

Well, we usually call it unpacking. You can only do it on sequences
(maybe just tuples?), it looks like this:

(x, y) = (1, 2)

or this:

x, y = 1, 2

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


Re: [Haskell-cafe] resolving missing class instances @ compile time

2005-05-12 Thread Samuel Bronson
On 12/05/05, Greg Buchholz <[EMAIL PROTECTED]> wrote:
> Bernard Pope wrote:
> >
> > Perhaps this section of the report might help:
> >
> > >From Section "4.3.2 Instance Declarations" in the Haskell Report:
> >
> >http://www.haskell.org/onlinereport/decls.html#instance-decls
> >
> > "If no binding is given for some class method then the corresponding
> > default class method in the class declaration is used (if present); if
> > such a default does not exist then the class method of this instance is
> > bound to undefined and no compile-time error results."
> 
> I may be missing the big picture, but why is this behavior more
> desirable than failing with an error at compile time?

Aren't the warnings just about as usefull as failures? Anyway, you
could always use the -Werrror flag for ghc...

In any case, I would not like to have to implement an entire typeclass
at once... it would interfere with incremental development.

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


Re: [Haskell-cafe] resolving missing class instances @ compile time

2005-05-12 Thread Samuel Bronson
On 12/05/05, Greg Buchholz <[EMAIL PROTECTED]> wrote:
> Samuel Bronson wrote:
> > Aren't the warnings just about as usefull as failures? Anyway, you
> > could always use the -Werrror flag for ghc...
> >
> > In any case, I would not like to have to implement an entire typeclass
> > at once... it would interfere with incremental development.
> 
> Hmm.  I guess I'm doing a terrible job of asking my question.  I
> don't want to implement the entire typeclass either.  Just the part that
> my program actually uses.  Why can't the fact that my program uses an
> unimplemented instance of a class be statically determined?  Is there a
> theoretical reason it can't be done?  Is it more convienient for
> compiler/specification writers this way?  Is it just because that's the
> way its always been done?

After thinking about it for a while, I'm positive it would be a LOT of
work to get that to work in general, if it is even possible. Even
getting it to work in only specific, limited cases (such as within a
module) would probably not be easy, since it is such an indirect kind
of thing. It probably wouldn't be all that usefull anyway, either.

In general, though, I think they don't implement stuff like this
unless someone specifically wants to *use* it.

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


Re: [Haskell-cafe] resolving missing class instances @ compile time

2005-05-12 Thread Samuel Bronson
On 12/05/05, Greg Buchholz <[EMAIL PROTECTED]> wrote:
> Samuel Bronson wrote:
> > After thinking about it for a while, I'm positive it would be a LOT of
> > work to get that to work in general, if it is even possible. Even
> > getting it to work in only specific, limited cases (such as within a
> > module) would probably not be easy, since it is such an indirect kind
> > of thing. It probably wouldn't be all that usefull anyway, either.
> 
> (This is my last time, I promise).  Why?  Here's my thought process.
> Let's say I a have a program like...
> 
> main = print $ (foo 42)
> 
> ...(that's the whole thing).  The compiler parses it, determines that
> "foo" is a function being applied to "42" and tries to look up "foo" in
> the symbol table.  That fails because there is no function "foo".  Why
> is it any different if foo is part of some type class?  We must know
> where to look for "foo" since we know the type of "foo" from its
> arguments and return value (it passed the type checker after all).

Well, it would have to know that foo was being applied to 42 at
whatever type it was being applied at (Might be Int), and it would
also have to know that the instance declaration for foo's typeclass at
that type did bind foo. Now this might not sound so bad, but consider
the case where you call a function bar :: Foo a => a -> String, which
is not part of the typeclass but is defined in another module. Then
GHC would have to know which methods of Foo were implemented at
whatever type the value you applied bar to had, and which methods bar
actually called. The former may not be hard, but the latter would
require functions with typeclass constraints on their types to be
annotated in the interface file with what typeclass methods they
called. Does that sound hard yet?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] resolving missing class instances @ compile time

2005-05-12 Thread Samuel Bronson
On 12/05/05, Greg Buchholz <[EMAIL PROTECTED]> wrote:
> Samuel Bronson wrote:
> > The former may not be hard, but the latter would require functions
> > with typeclass constraints on their types to be annotated in the
> > interface file with what typeclass methods they called. Does that
> > sound hard yet?
> 
> Compared to writing the rest of the compiler?  No.  I've never
> written a Haskell compiler, but I'd say it sounds like it might be a
> tedious book-keeping problem though.

Most of the rest of the compiler is already written, though ;-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Unexported functions are evil

2005-05-16 Thread Samuel Bronson
On 15/05/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

> Taking this to an illogcial extreme, why don't we allow pointer arithmetic
> in Haskell, but require people to import "Prelude.C" first, so that people
> who enjoy playing with fire can do it?  After all, we use it under the
> covers...

Isn't this called Foreign.Ptr?

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


[Haskell-cafe] working Edison, a couple of collection modules, and typing troubles

2005-05-25 Thread Samuel Bronson
Whatever happened to Edison? I want to play with it and the one in the
HFL cvs repository won't build for me (and uses flat names).

I was trying my hand at writing some collection classes myself and I
can't figure out a good typing for map that will let me make Map an
instance of my Collection class...

I'm attaching what I have so far.

I don't much like the head of Mapping.

I expect oleg will have some crazy type-system trick up his sleeve.

-- Thankful-in-advance-ly yrs, Sam
{-# OPTIONS_GHC -fglasgow-exts #-}

module Data.Collection where

import qualified List

class Collection c v | c -> v where
-- Query
null :: c -> Bool
size :: c -> Int

null = (0 ==) . size
size = List.length . toList

-- Construction 
empty :: c 
singleton :: v -> c

empty   = fromList []
singleton v = fromList [v]

-- Manipulation
insert :: v -> c -> c

-- Conversion
toList   :: c -> [v]
fromList :: [v] -> c

fromList = List.foldl (flip insert) empty

fromCollection :: (Collection c1 v, Collection c2 v) => c1 -> c2
fromCollection = fromList . toList

{-# OPTIONS_GHC -fglasgow-exts #-}

module Data.Mapping where

import Prelude hiding (lookup,map,filter,foldr,foldl,null)

import qualified Data.Mapas M
import qualified Data.IntMap as IM
import qualified Data.List   as List

import Data.Collection

class Collection (d e) (k, e) => Mapping d k e | d -> k where
-- * Query
lookup  :: (Monad m) => k -> d e -> m e

instance Ord k => Collection (M.Map k e) (k, e) where
null  = M.null
size  = M.size

empty = M.empty
singleton = uncurry M.singleton
insert= uncurry M.insert

toList= M.toList
fromList  = M.fromList

instance Ord k => Mapping (M.Map k) k e where
lookup= M.lookup

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


Re: [Haskell-cafe] working Edison, a couple of collection modules, and typing troubles

2005-05-25 Thread Samuel Bronson
On 25/05/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> G'day all.
> 
> Quoting Samuel Bronson <[EMAIL PROTECTED]>:
> 
> > Whatever happened to Edison?
> 
> It's in the process of being cabalised, but sadly I'm a little short of
> tuits at the moment.

Would this process involve hierarchicalization?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: working Edison, a couple of collection modules, and typing troubles

2005-05-26 Thread Samuel Bronson
On 26/05/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 
> Samuel Bronson wrote:
> 
> > I was trying my hand at writing some collection classes myself and I
> > can't figure out a good typing for map that will let me make Map an
> > instance of my Collection class...
> > I don't much like the head of Mapping.
> 
> How about the following:
> 
> > class Collection (d k e) (k, e) => Mapping d k e where
> > -- * Query
> > lookup  :: (Monad m) => k -> d k e -> m e
> >
> > instance Ord k => Collection (M.Map k e) (k, e) where
> > null  = M.null
> > empty = M.empty
> > 
> >
> > instance Ord k => Mapping M.Map k e where
> > lookup= M.lookup
> 
> A higher-ranked type constructor gets rid of functional
> dependencies. The drawback of course is trying to use something like
> Integer as a mapping from Int to Bool. We have to declare a wrapper

This also doesn't seem like it would work very well with making an
instance for IntMap.
I guess I can't have everything.

What do you suggest that I do for map? What sort of class should it be
in? I'd like it to be able to do (a -> b) -> [a] -> [b] and such... I
had been thinking of having ((k, e) -> (k', e')) -> Map k e -> Map k'
e', but now it occurs to me that changing key types doesn't make any
sense.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Python?

2005-05-27 Thread Samuel Bronson
On 27/05/05, John Goerzen <[EMAIL PROTECTED]> wrote:
> Yes, but actually much of that is slated for removal from the Python
> language in future versions.  See
> 
> http://www.python.org/peps/pep-3000.html

I still can't believe that Guido will get away with this...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] foldl and space problems

2005-06-09 Thread Samuel Bronson
On 06/06/05, Gracjan Polak <[EMAIL PROTECTED]> wrote:
 
> Question: is there any way to see what is holding my source list? I did
> try to guess, but without results as of now:(
> 
> How do I debug and/or reason about such situation?

I heard that NHC has excellent heap profiling support, maybe it would
be able to help?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Looking for lost library

2005-06-09 Thread Samuel Bronson
On 05/06/05, Dean Herington <[EMAIL PROTECTED]> wrote:
> I believe you're describing:
> http://portal.acm.org/citation.cfm?doid=581478.581482 .

I don't suppose you know of any place to get it *free*?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Hackage accounts and real names

2010-04-05 Thread Possibily not Samuel Bronson after all?
Gwern Branwen  gmail.com> writes:

> It must've been put in place in the past year or two; I've never made
> any bones about using a pseudonym, and I had no trouble getting a
> Hackage account back when it was starting up.

It may have helped that you appear to be using a pseudonym somewhat less
obviously pseudonymous than "Pseudonym"?

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