Magnus Lycka wrote:
> [EMAIL PROTECTED] wrote:
> > Magnus Lycka wrote:
> >
> >>I don't really know Haskell, so I can't really compare it
> >>to Python. A smarter compiler can certainly infer types from
> >>the code and assemble several implementations of an
> >>algorithm, but unless I'm confused, this makes it difficult
> >>to do the kind of dynamic linking / late binding that we do in
> >>Python. How do you compile a dynamic library without locking
> >>library users to specific types?
> >
> > I don't know. I am learning Haskell(and Python too), long way to go
> > before I would get into the the usage you mentioned, if ever, be it
> > Haskell or Python.
>
> Huh? I must have expressed my thoughts badly. This is trivial to
> use in Python. You could for instance write a module like this:
>
> ### my_module.py ###
> import copy
>
> def sum(*args):
> result = copy.copy(args[0])
> for arg in args[1:]:
> result += arg
> return result
>
> ### end my_module.py ###
>
> Then you can do:
>
> >>> from my_module import sum
> >>> sum(1,2,3)
> 6
> >>> sum('a','b','c')
> 'abc'
> >>> sum([1,2,3],[4,4,4])
> [1, 2, 3, 4, 4, 4]
> >>>
>
> Assume that you didn't use Python, but rather something with
> static typing. How could you make a module such as my_module.py,
> which is capable of working with any type that supports some
> standard copy functionality and the +-operator?
Ah, I thought you were talking about DLL or some external library
stuff. In Haskell, it use a concept of type class. Conceptually similar
to the "duck typing" thing in python/ruby. You just delcare the data
type then add an implementation as an instance of a type class that
knows about +/- or copy. The inference engine then would do its work.
I would assume that even in python, there are different implement of
+/- and copy for different object types.
--
http://mail.python.org/mailman/listinfo/python-list
