Re: [Haskell-cafe] Python?
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
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
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
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
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
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
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
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
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
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?
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
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
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
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