metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mattf-horton <>
Subject [GitHub] metron issue #687: METRON-1090 Add Assignment to Stellar Language
Date Thu, 18 Jan 2018 19:52:05 GMT
Github user mattf-horton commented on the issue:
    As a professed language nut, when you mention the word "variable", I think "scope".  And
it seems to me that by placing the responsibility for variable assignment/update in the VariableResolver,
you've actually tied into a very natural definition of scope given the way MapVariableResolver
already works in association with a target dictionary or stack of dictionaries.
    A. I think you should explicitly discuss scope in the documentation.  There are several
scopes already being used in practice, and I think users need to understand how it all works
together, otherwise they will misunderstand and be bewildered.  I am, no doubt, a good example,
so dense that I have to ask the questions below :-) 
    B. I don't understand why you don't go ahead and enable update in MapVariableResolver,
since IIRC that's the resolver for essentially everything interesting that uses variables
in Stellar.
    C. Do I understand correctly from the patch, that variable assignment IS enabled in lambda
expressions?  Presumably the scope will be the same instance dictionary where the input variables
are stored, thus making them local, correct?  Can new variables be created as well as input
variables be updated?
    D. The following scopes come to mind, with associated need for clarification:
    - Lambdas save their input variables in their ephemeral instance context, initialized
by call syntax.
      - Comment: questions already asked above
    - The REPL used one global dict for scope of its variables, defined by ':='.  
      - Comment: If I understand correctly, when in the REPL, '=' and ':=' assignments will
go to the same global context dictionary, is that correct? 
    - Profilers, transformations, and several other xml-defined Stellar-using features, have
a persistent instance context, with variables initialized and updated via an xml syntax.
      - Comment: Apparently here we've specifically exclude assignment, even though this seems
to be where it's needed most.  Why is that?  The instance context seems ready-made for local


View raw message