msp-strath / Mary

Mary is the successor of Marx, a content delivery and assessment engine based on markdown and git

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

infix arithmetic/logical operators

pigworker opened this issue · comments

We could do with some basic infix gadgetry for arithmetic, numerical comparison, and Boolean logic. I'm struggling with my conscience as to the representation of Boolean values. Do we overload 0 and 1? Do we do the Lisp classic [] and 't? The former, I think.

This is mostly a parser hacking job.

Interesting questions for the future involve whether we let the punters define infix things. For the moment, we just hardwire enough stuff to build the sorts of formulae we use in marking.

So we have '0 and '1 for Boolean values, in order to be clear about which things guard, liIke in #44.

I've added a datatype to the parser called Forbidden which is a bounded ordered enumeration whose least element is NoProb, meaning everything's cool.

For the moment, I don't propose to allow users to define infix operators, which means we just have to sort our own business out, rather than constructing a framework for negotiation.

Each operator needs to tell us when it is forbidden and how much it forbids to its right.

Now, here's a question: how do we represent the resulting parse tree. Do we just represent e1 + e2 as a variable with illegal name + applied to (e1,e2)? Is there any reason to be more subtle? I guess that while we keep an iron grip on infix powers, we can do whatever we like.

If we were to translate + to the corresponding named primitive then users would be able to dynamically redefine the associated primitive and thus hijack the infix notation.

I guess we would then need a translation from each symbol to alphabetical text used as a suffix to prim.

I'm going to move the stuff about operators and precedence from Shonkier.Parser to Shonkier.Syntax as it's clear that Shonkier.Pretty also needs to know about it.

I think we're done on this one, as of yesterday's slog.