Am 17.03.2012 13:25, schrieb Sergiu Ivanov:
On Fri, Mar 16, 2012 at 12:58 AM, Joachim Durchholz<j...@durchholz.org> wrote:
Am 14.03.2012 14:15, schrieb Sergiu Ivanov:
I see. I thought the differences in syntax were not that influential.
Well, it's not just syntax. The way you express semantic actions can have a
deep impact.
It's alike the similarities and differences between C and Pascal: both are
statically-types, imperative language with little thought for modularity.
Still, you wouldn't want to rewrite programs from one language to the other,
not even as small ones as 500 lines.
Hm, the difference is actually much more fundamental than my
imagination would paint it to me :-(
Oh, but the difference between C and Pascal is far from fundamental!
If you want something fundamentally different, try Lisp. Or Haskell. Or
even APL :-)
The point here is that while a left-recursive and a right-recursive grammar
are equivalent in the set of inputs that they accept, they generate
different parse trees.
Yes, sure. Avoiding left-recursion is usually not that hard with
proper experience (at least I've always found it easy), but I see your
point.
Eliminating left recursion is indeed not difficult :-)
It's just that you'll have to postprocess the parse tree.
Which distributes the structural description of the parse tree over two
places, the syntax and the postprocessing code. I think that's a real
disadvantage that would need to be offset by some advantage elsewhere.
The standard advice to programming language designers is that this is One Of
Those Well-Intentioned Bad Ideas From The 50ies.
Other ideas like what were "make a programming language look like English"
(that gave us Cobol), or "put all good ideas into one language to give use
the One True Language That Has It All" (that gave us PL/I).
Hm, a very nice historical perspective. Although I'm trying hard to
avoid such Well-Intentioned Bad Ideas, I'm still producing them with
regularity.
"Experience is the sum of errors made."
;-)
The first rule for this kind of thing is: Don't guess what the problems are,
go out and watch what problems bite the users in reality. Then add some
(cautious) spell checking and other DWIM mechanisms, and iteratively correct
them until they do *far* more good than harm.
It's nothing that can be designed. You need to deal with what people
actually do (and, hence, it is probably too much work for the current size
of the SymPy community).
We could start that by adding some statistics code to SymPy: which functions
are used, what kinds of errors happen, where do they originate. Define a
mail address to send them to, write the tools to extract information from
the raw data.
Very very cool. Collecting anonymous user data should be very useful
in this regard.
Thanks :-)
Think about how to ask the user about whether collecting usage
data is okay for them (some might disagree, an NSA mathematician working
with SymPy on some secret research would most certainly disagree).
This could be gently offered as and opt-in feature, I think.
Just my thinking.
Don't expect an easy miracle though.
User input is multi-channel high-noise input, extracting useful signals
from that ain't easy.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
