Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add full support to mathos library #4

Open
furesoft opened this issue Jan 17, 2016 · 6 comments
Open

add full support to mathos library #4

furesoft opened this issue Jan 17, 2016 · 6 comments
Milestone

Comments

@furesoft
Copy link

why not add an mathos parser instance that can handle all stuff of the mathos library

functions, variables, operators, etc.

@artemlos
Copy link
Member

@furesoft

this is actually a good idea. me and an @napen123 thought about this and focused our efforts on https://github.com/MathosProject/Mathos-Project/tree/master/RubyInt, a Ruby based interpreter that aims to make access to mathos library simple through Ruby.

what you mentioned is certainly possible but requires a large amount of time: either, we add all methods separately and think through how these methods should interact with each other OR we use reflection to try to achieve similar functionality as with any other .NET targeting language.

@napen123
Copy link
Member

I think it would be better to use things like reflection rather than adding all of the methods. Since the parser uses decimals for functions currently, it would be a little tricky to figure out a way for certain parts of mathos to be represented as decimals (like geometry).

@artemlos
Copy link
Member

A fun thing we could do is to attempt to write a scripting language and then enable core library related features. There seems to be many LL(1) parsers out there, for instance http://goldparser.org/news/index.htm or http://www.antlr.org/.

I.e. to be more specific:

  1. first, we construct a syntax that is more or less consistent.
  2. we use existing tools to generate the actual parser (the only thing we define is the grammar).
  3. code the actual functionality, i.e. accessing methods from mathos core library by reflection, etc.

@artemlos
Copy link
Member

the problem with the current parser is that there are very few token types (everything is treated as a string mostly). it would be better to expand the types of tokens and have a more systematic approach to interpret them. in the long run, we could also enable symbolic features such as derivation (it might sound complex, but given a tree of tokens and application of the chain rule, these things become easy, and, so do other things related to symbolic computations).

@napen123
Copy link
Member

I agree that we should expand the parser. Writing a scripting language also sounds like fun.

@artemlos
Copy link
Member

Just want to share our previous language design file: https://github.com/MathosProject/Docs/blob/master/languagedesign/Language%20Referencev3.pdf

I suppose the language should be functional (not purely functional though) and imperative

@napen123 napen123 added this to the Future milestone Jun 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants