I am sorry that what I posted originally somehow didn't go through. It took me a while to write and touches on a number of things mentioned in the discussion. So let me try again.
I have a limited simple-minded brain for all of the various syntaxes and dialects. So one goal as briefly mentioned was to be able to write/use a common language for expressing CAS. The characteristics of this common language should be: - there a number of examples, tutorials, blogs, and books in that language - it is fairly complete in what it expresses, - it is popular and ergonomic, - i is well defined and documented One may quibble about the well-defined-ness of the Mathematica/Wolfram language. But overall I think that language fits the above criteria pretty well. I should say at the start, I have a bit of familiarity and experience with compilers. And no, I don't think this will be either easy, quick, or complete. And as with my other compiler <https://pypi.org/project/uncompyle6/> related <https://zshdb.readthedocs.io/en/latest/> projects <https://pypi.org/project/trepan3k/>, I am not counting on and don't expect to receive much help from others. (Of course, help is greatly welcome). In the lost post, I wrote about the problems of language drift in a programming language. This came up in the Python decompilers I've written and I have a handle on how to deal with the 20 or so different Python dialects of bytecode (if not Python language specifications). Although WRI is free to change its language specification at any time (and has), and do so even in an incompatible way, in practice, when a programming language is in widespread use, you can't really change it that quickly even if you want to. Think about how long Python 2 has been around long after Guido Rossum and Pythonistas have declared it dead. The same is true with Mathematica syntax. One thing that has changed since that decade-old discussion is the level of specification for Mathematica and tools for parsing Mathematics. Robert Jacobson wrote FoxySheep <https://github.com/rljacobson/FoxySheep>, and there is the Wolfram Language Specification Tools <https://wltools.github.io/LanguageSpec/>. Looking at that discussion there was a bit about parsing technology, so let me address that. I intend to use the last two links above as a guide and cull from them. As for the specific parser and parsing technology, I intend to use this very general J Earley parser <https://pypi.org/project/spark-parser/> that allows one use ambiguous grammars as input. I use it in my Python decompilers and know it well. Although there is much that could be improved in that parser (especially in its input format), it has some features <https://github.com/rocky/python-spark/blob/master/NEW-FEATURES.rst> that I am not aware of exist in other parser systems. But of course this is not just about parsing. I imagine that for each backend there will probably need to be a compatibility library for each backend (sage, Axiom/FriCAS, Macsyma, ...) And there can be an impedance mismatch in concepts between front-end language input and backend. But I have found that just because a problem is very difficult if not close to impossible to do well, that doesn't mean one shouldn't start and try. And along the way you'll understand the problem better if not also how better to deal with it. A program can be extremely useful even if it is flawed. That is definitely true with my Python decompilers. Another example I like to give here google translate. Sometimes you'll get a translation that is not just wrong but so funny that it can be and has been the subject of jokes. (And part of the problem can be the ambiguity of the language: you can't hang a man with a wooden leg - you have to use a rope) But overall, google translate is useful enough in everyday life that it continues to exist, be used and improved. All this said, I have no idea whether I'll undertake this or if I do how far I'll get. On Sat, Jul 4, 2020 at 9:44 AM kcrisman <kcris...@gmail.com> wrote: > > > >> I'm curious of any consideration has been giving for transpiling from one >> CAS syntax to another instead of or right before sage.repl.preparse(). >> > > I think that long ago some of that was suggested, but the problem is that > there are very nontrivial differences - it's not just a matter of changing > lowercase to uppercase or something, as you know. Here is one decade-old > discussion: https://groups.google.com/forum/#!topic/sage-devel/JLg-fJ4dJns > > Even translating a given Sage object to another program is nontrivial; a > recent example is https://trac.sagemath.org/ticket/12074 where we don't > even have close to the same name as Mathematica for the same (essentially) > proposed function. And that doesn't take into account things like actual > programming syntax. (Even trying to use Numpy or Sympy and Sage together > may lead to namespace clashes, or at least at some point in the past did.) > > That doesn't mean it isn't somehow feasible, but it does mean it's not > likely that other developers will be signing up to do it from scratch. See > https://groups.google.com/forum/#!searchin/sage-devel/mathematica$20syntax%7Csort:date/sage-devel/cjrsZfGkc-w/IoDiv9ZwNxoJ > for a different discussion about https://mathics.github.io which > apparently now uses Sympy as a backend. Anyway, if you have a proof of > concept already available, that would be very different, and I don't see > why we wouldn't be open to having this as some sort of preparsing option. > Good luck! > > -- > You received this message because you are subscribed to a topic in the > Google Groups "sage-devel" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sage-devel/z3XBhQOCh9E/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > sage-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/d4b01e0b-8e7b-42f8-bfbb-f05f6e894b1fo%40googlegroups.com > <https://groups.google.com/d/msgid/sage-devel/d4b01e0b-8e7b-42f8-bfbb-f05f6e894b1fo%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CANCp2gbLZ_QdAt6hVBO_zYedui0udV%2BnYofj5QTXBHL2E5rLMg%40mail.gmail.com.
