Haskell or Python!
Jason Stokes
Sunil Hadap wrote in message <38994478...@cui.unige.ch>...
>I am confused which is better language for the purpose. Here are more
>specific questions
>
>- Can Haskell be used as interpreted language so that the animator
> can code interactively in the animation software
Yes. There's an implementation called "HUGS" which is interpreted.
>- Is Haskell matured to provide good support to libraries such as I/O
> GUI, network like Python
Haskell does have a socket and a GUI library, but they're very limited.
Haskell is very weak on library support. Haskell is especially weak on IO,
being a pure functional language. Haskell is designed mainly to be of
interest in the language research community.
>- Can I use traditional OO concepts in Haskell though it is Functional
Yes. Haskell is fully object oriented.
>- Is it dynamically typed. I mean can I get full information of type
>and
> its constituents (members) dynamically.
No. Haskell is a statically typed language with no introspective features.
>- Is it a good idea to mix Python and Haskell
It's certainly possible. For example: implement the hardcore numerical
stuff in Haskell, and the GUI stuff in Python. Both have COM bindings and C
language interfaces, so could be persuaded to talk to each other.
If functional programming is your thing, impure functional languages like
Lisp or Erlang or Clean are real options. However much I like Haskell's
design I can't see it being useful for general purpose development.
Neel Krishnaswami
> Sunil Hadap wrote in message <38994478...@cui.unige.ch>...
> >
>
> Yes. Haskell is fully object oriented.
Is this true? Haskell has overloading, but its type system doesn't
support subtyping, and overloaded methods are chosen at compile time
rather than based on the runtime type. Instead, you use pattern
matching to replace what subtyping and runtime method selection give
you in OO languages.
It's all very slick, but it doesn't feel very OO to me. Haskell is
just put together in a different (but not worse) way.
Neel
Andrew Bromage
Sunil Hadap <Sunil...@cui.unige.ch> writes:
>I am developing an animation system. I was almost convinced that
>Python will be the embedded scripting language for the purpose, till I
>was introduced to Haskell.
Haskell (as of Haskell 98, anyway) has a limitation of its type system
in that it does not allow heterogeneous containers. For example, you
might have a type class Object which is the class to which all geometric
primitives belong:
class Object a where
-- insert methods here --
instance Object Polygon where
-- methods defined for polygons --
instance Object NURBS where
-- methods defined for NURBS --
or whatever. You can now create a list (lazy stream?) of Polygons,
but you can't make one of Objects. To do this, Haskell would need
existential qualtification of types, which is on the wish list,
but not yet implemented.
I think that this problem more than anything else may rule out Haskell
(at the moment, anyway) as your scripting language of choice, but I
could be wrong. Your application may not need this.
>I am confused which is better language for the purpose. Here are more
>specific questions
>- Can Haskell be used as interpreted language so that the animator
> can code interactively in the animation software
Hugs is a Haskell interpreter which may suit your needs:
>- Is Haskell matured to provide good support to libraries such as I/O
> GUI, network like Python
I/O is there. The GUI is a debatable point. The Haskell standard does
not directly support any particular GUI model, there are a number of
bindings which may help:
HOpenGL is a binding to OpenGL and GLUT:
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne/haskell_libs/HOpenGL.html
TclHaskell is a binding to Tcl:
http://www.dcs.gla.ac.uk/~meurig/TclHaskell/
Fudgets is a toolkit which links directly to X:
http://www.cs.chalmers.se/ComputingScience/Research/Functional/Fudgets/
Haggis is one of those too, but requires a concurrent implementation
of Haskell to work correctly:
http://www.dcs.gla.ac.uk/fp/software/haggis/
As you can see, some degree of support is there
>- Can I use traditional OO concepts in Haskell though it is Functional
Let's see...
- Encapsulation: Yes. Type classes are your friends. Note
that there is no support for attributes, but who needs
them when you have access methods?
- Abstraction: Yes. Modules are your friends.
- Inheritance: Yes, sort of. Inherited type classes do most
of it, but see the note above on heterogeneous
containers which may bite you.
- Object identity: Tricky but not insurmountable. Equality
(==) in Haskell means _structural_ equality, not object
identity, so if two objects are distinct, you have to
explicitly make them distinct.
>- Is it dynamically typed.
No, it's strongly statically typed.
> I mean can I get full information of type and
> its constituents (members) dynamically.
That's a different question. :-) You're asking if Haskell supports
run-time type information.
The answer is "no", because it would break parametric polymorphism. If
you could peek inside a polymorphic variable, it wouldn't be truly
polymorphic.
The long answer is that you can fake it. Make a type class which has
methods which peer inside the type and make everything use that.
>- Is it a good idea to mix Python and Haskell
Haskell does speak COM, so there's one possibility. I don't think
that it speaks CORBA yet. See also:
http://www.dcs.gla.ac.uk/fp/software/hdirect/
You have to understand that Haskell was not designed as a scripting
language, but as an application programming language. You also have
to understand that lazy functional languages haven't been around as
long as traditional Von Neumann languages, so they have to understand
how well-understood features fit into the new framework before it gets
into the language.
For further info, see comp.lang.functional.
For an interesting piece of research which may or may not have anything
to do with your project, see:
http://www.research.microsoft.com/~conal/Fran/
Cheers,
Andrew Bromage
Ralf Muschall
> >- Can Haskell be used as interpreted language so that the animator
> > can code interactively in the animation software
> Yes. There's an implementation called "HUGS" which is interpreted.
Yes or no, depending on what Sunil wants exactly.
It is impossible [1] to add a function (or variable) definition
at the interactive prompt, since this would violate the
functionality. But you can type metacommands (beginning with
a colon) to (re)load the source file, and evaluate expressions
interactively (which might cause the animations to move).
> >- Is Haskell matured to provide good support to libraries such as I/O
> > GUI, network like Python
> Haskell is especially weak on IO,
> being a pure functional language. Haskell is designed mainly to be of
The first line (non-IO-part deleted) may be true, but the second
line is IMHO not the reason.
Haskell is rather young, and the population hacking it is not the
one who needs Tkinter, PIL and NumPy everyday.
OTOH, the IO system is well adapted to scan and parse hairy stuff
(there are XML libraries and Haskell compilers in Haskell).
> >- Is it dynamically typed. I mean can I get full information of type
> >and
> > its constituents (members) dynamically.
In the interpreter, you can switch on an option which shows
you the type of every evaluated expression together with the
value. The program itself has (AFAIK) no access to this
information. It is neither needed nor available (AFAIK) at
runtime in compiled programs.
[1] Strictly spoken, this is untrue: One might "load the source file"
/dev/tty :-)
Ralf
Andrew Bromage
Jason Stokes <js...@bluedog.apana.org.au> wrote:
>> Yes. Haskell is fully object oriented.
ne...@brick.cswv.com (Neel Krishnaswami) writes:
>Is this true? Haskell has overloading, but its type system doesn't
>support subtyping,
Its type class system allows subclassing, which gives you the same thing.
Well, it gives you interface inheritance which, when you think about it,
is all that CORBA and the like gives you too.
>and overloaded methods are chosen at compile time
>rather than based on the runtime type.
Existential types would fix that problem by generating the virtual
method table at compile time for each existentially quantified type.
The benefit is that you would only pay for the vtable it where you
actually use it. As I mentioned in a previous post, existentially
quantified types are a proposed addition to the language.
>Instead, you use pattern
>matching to replace what subtyping and runtime method selection give
>you in OO languages.
That's one possible implementation, but it doesn't give you separate
compilation, since there is no way to extend an algebraic type with more
alternatives without recompiling.
Cheers,
Andrew Bromage