This looks nice. Some basic comments:
- Since you mention that Grim should be parsable by languages other
than Python, I would suggest specifying a formal grammar for it. If
you want to keep that grammar as a strict subset of Python's grammar,
including semantics around operator precedence, I think that's a good
idea.
- It seems like you only allow symbol names to be ASCII characters. I
think that's fine, since LaTeX does the same, although there are
certainly people who will want to write something like π instead of
pi. But a question that comes up is how to represent arbitrary
formatting for certain symbols. Does that have to be represented in
the printer somehow, or can it be put on the symbol name. And if the
former, how is that stored in the expression? Does it mean that any
symbol with custom printing has to be represented as a custom function
(non-atom, I guess you call it). For example, sometimes people will
use something like Symbol('x^0_1') or Symbol(r'\mathbf{x}') in SymPy
which prints as such. Another option is to explicitly disallow such
things by requiring them to be part of the semantics. So for instance,
a if you want to have a vector that prints in bold face you have to
represent it as a vector, like Vector(x) or something like that.
I know you state that Grim is not a typesetting system, and that's a
good thing to state. But in my experience people will want to use it
as one nonetheless.
- If I understand it correctly, Grim doesn't do any sort of semantic
type checking, allowing you to create formulas that are completely
nonsense. If that is not the case, I think you will need to add a type
system, which complicates things quite a bit (you'll probably want to
look to formal proof systems for inspiration).
Aaron Meurer
On Mon, Dec 16, 2019 at 12:00 PM Fredrik Johansson
<fredrik.johans...@gmail.com> wrote:
>
> Hi all,
>
> First off, congratulations to the SymPy community for version 1.5!
>
> I'm interested in feedback about the symbolic formula language I'm developing
> for Fungrim (http://fungrim.org/).
>
> I have a draft writeup about the language (now named Grim) here:
> http://fungrim.org/grim/
>
> It's still very much a work in progress and many aspects of the design could
> certainly be changed. A central constraint is that I'm trying to have
> constructs that work reasonably well both for representing symbolic
> expressions and for representing natural mathematical notation (sometimes
> these goals clash with each other).
>
> Here is a minimal start of a SymPy-Grim interface:
> https://github.com/fredrik-johansson/fungrim/blob/master/pygrim/sympy_interface.py
>
> Fredrik
>
> --
> 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 sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/c608241b-0f34-44ea-a616-64de84c063a1%40googlegroups.com.
--
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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2B42eOw7ayQ%3DP-s%3DjCsmmnEokSCawUw8fkrDea6ZX4pfQ%40mail.gmail.com.
