[Grace-core] Other things that we might want to change

[James Noble]

On 8/02/2015, at 18:57 pm, Andrew P. Black <black at cs.pdx.edu> wrote:

> Since Michael has started revisiting some of the language details that we decided long ago,

we're all working through the spec in our various ways.

> I though that I would add a few more to the list of things to reconsider:

fair enough - but first: comments! 

> 	• The\smost\srecently\sdecided\swas\sto\suse\s\s\sfor\snon-breaking\sspace\sin\sa\sstring\sconstructor.\s\s\sHaving\sgiven\sthis\ssome\smore\sthought,\sit\sseems\sto\sme\sthat \_ would\_be\_a\_lot\_more\_readable.\_This\_paragraph\_should\_illustrate\_why.

:-)

> 	• Tim Sheard and I wrote the grammar-rules for binary operators yesterday.  
> 	• Tim’s comment was that it is precedence itself that is confusing, and if we are after simplicity, we should get rid of it.  

yep. this is Self's design, adopted by Pyret. 

my combinator grammar handled this in two stages
with traditional stratified encoding for + -, * / 
and then a particularly evil little rule to capture "same operator".
Nothing like an assignment in the middle of a rule! 
Perhaps it's easier if that isn't handled in the grammar.


def addExpression = rule { rep1sep(multExpression, addOp) }
def multExpression = rule { rep1sep(prefixExpression, multOp) }

def opExpression = rule {    // this complex rule ensures two different otherOps have no precedence
  var otherOperator 
  addExpression ~ opt(ws) ~
    opt( guard(otherOp, { s -> otherOperator:= s; true }) ~
        rep1sep(addExpression ~ opt(ws),
           guard(otherOp, { s -> s == otherOperator })
        )
    )
  } 


> 	• When I was rewriting minigrace’s identifier resolution pass, it became clear to me that I don’t understand the syntax of patterns.  In particular, I could not predict when identifiers in a method request with arguments were defining or applied occurrences.  

fair enough.
You may need context (are the identifiers already defined) but I don't think you should. 

J