Am 07.10.2013 21:06, schrieb F. B.:
On Monday, October 7, 2013 8:28:04 PM UTC+2, Joachim Durchholz wrote:
Am 07.10.2013 20:07, schrieb F. B.:
I just had a look at the Julia project http://julialang.org/
Have a look at how they manage operator overloading:
I just did and shuddered.
Unrestrained multple dispatch runs into modularity issues. It's one of
those mistakes that language designers make over and over again, because
the base idea seems to simple and the use cases one can think of are so
straightforward, but they almost never consider the case what happens
when two independent developers have their work merged by a third.
Methods and operators in Python and C++ are not very different from Julia's
idea, it's just the way you write it: the first argument in Python is *self*,
you just have to write it inside the class declaration, while in Julia you
write it outside of it. The same is true for C++ methods, the only
difference is that in Julia you're free to write the methods everywhere,
but problems could be avoided by keeping the code clean.
The relevant point is that you have multipe parameters that you dispatch
on (or overload, the issues are the same).
That is a great idea, it would keep code clear and readable, and avoid
the
need of all those *if isinstance( ) ... elif isinstance( )*
There are better and more general ways to avoid that.
Unfortunately, neither Julia's approach nor the ones typically employed
in FPLs are available in Python.
A type dispatcher is a must for a CAS, in my opinion. It would keep things
easier.
Yes, but multiple dispatch is *so* not the way to go.
Unless all dispatch combinations are forced to be within the same module.
Multiple dispatch: modularity, unsurprising behaviour, unrestricted
ability to add new variants - pick any two.
By the way, the aim of Julia is to be both an interpreted language and a
fast compiled language, with speed of execution near to those of C. At
the
same time they want to keep perfect interaction with both Python and
C...
Sounds like they're too ambitious to succeed.
Well, it is not impossible nowadays. There is LLVM now.
LLVM solves quite a few challenges, but not these.
> and at the
same time allow perfect interaction with both Python and C, and reach
the
performance of C.
I doubt that you can have both easy interaction with dynamic languages
and raw performance. To the very least, you'll have to keep the number
of inter-language calls down, and that would impose design restrictions
on Sympy's code. Sympy already has a lot of restrictions to observe, I
doubt that that's going to be easy.
Well, I believe that you are looking back in time at traditional languages,
without realizing the power of a language specifically engineered for
scientific research.
I think I should stop in politeness here and just point out that you are
wrong in your belief.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.
