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 :-( >>>> and http://pypi.python.org/pypi/modgrammar >>> >>> >>> - Cannot handle left recursion (BLOCKER) >> >> >> Hm, thanks for pointing out. I tried to check that yesterday and I >> still cannot find the information in their docs (at least direct >> searching for "recursion" doesn't work for me). > > > http://packages.python.org/modgrammar/tutorial.html#left-recursion > > Last paragraph of the section. Oh, thank you. > 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. >> I wanted to say that if "integrate" and "limit" belong to different >> classes of symbols, then, should the lexer encounter "intgrate", it >> wouldn't be able to correctly classify it as "integrate". > > > Hmmm... that usually doesn't end well. You never know whether a particular > misspelling was intentional or not. > > E.g. is "limits" a misspelled keyword, or a free variable because he's doing > some first-order logic on interval arithmetic (where he might be > manipulating sets of limits, i.e. upper/lower bounds). Yeah, I see. > 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. > That doesn't mean that this kind of advice is always valid, but you need to > know what you're doing and why those approaches failed, to avoid falling to > the same traps that have been known for over half a century now. Yes, sure, I see. >> I was thinking about the situation when the user intuitively enters >> some text which includes elements of a natural language (like "find" >> and "the" in "find the limit sin(x)/x when x goes to 0"). In this >> case the user thinks that all words are meaningless, but, for the >> application, "find" and "the" bear no meaning. > > Well, it's really hard to write a parser that does this kind of stuff well > enough to be worth it. I see. > I do not know of a single project that successfully implemented such a > thing, but about several that failed abysmally. > > You're trying to get a DWIM thing implemented. > See http://catb.org/jargon/html/D/DWIM.html . Oh, what a vivid example; thank you :-) > 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. > 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. Sergiu -- 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.
