Better support for concrete values

[PaulKlint]

Overall goal: provide better support for concrete values:

• make ordinary lists and concrete lists as similar as possible.
• allow matching of syntax trees with both concrete and abstract patterns.
• allow field selection on values for non-terminal types.
• allow subscription of concrete lists (that indexes the actual elements and skips layout). The current implementation in the interpreter is incorrect: it does not discriminate between layout/non-lyout elements in the list.

The compiler does not support any of the above yet.

The type checker needs to:

• introduce the constructor in a syntax rule as an abstract constructor
• allow field selection on concrete values
• allow subscription on concrete lists.

[mahills]

I am now doing the first two, although I haven't done much to test the second. I need to look at the code and maybe refactor a bit, though, I added support for creating and using the constructors in with the existing constructor support code, but this means there are now more cases and probably a bit more duplication as well.

[PaulKlint]

@mahills sounds fantastic to me! Thanks a lot. I will started testing immediately.

[PaulKlint]

I have now implemented field selection on concrete values and that works fine. Subscription is not yet behaving as it should. Consider:

module experiments::Compiler::Examples::ConcreteTerms

import ParseTree;
layout Whitespace = [\ ]*;
lexical IntegerLiteral = [0-9]+; 
lexical Identifier = [a-z]+;

syntax Exp 
  = IntegerLiteral  
  | Identifier        
  | bracket "(" Exp ")"     
  > left Exp "*" Exp        
  > left Exp "+" Exp  
  | Exp "==" Exp      
  ;

syntax Stat 
   = Identifier ":=" Exp
   | "if" Exp cond "then" {Stat ";"}* thenPart "else" {Stat ";"}* elsePart "fi"
   ;

value main(list[value] args){
  e = [Exp] "x + 1";
  s1 = [Stat] "a := 2 * 3";
  s2 = [Stat] "b := 4 + 5";

  s3 = (Stat) `if <Exp e> then <Stat s1>;<Stat s2> else <Stat s1> fi`;

  return s3.thenPart[0];   <=== problem
}

gives

error("Expressions of type {Stat ;}* cannot be subscripted",|rascal:///experiments/Compiler/Examples/ConcreteTerms.rsc|(649,14,<29,9>,<29,23>))

[mahills]

I'll try to get this added over the next couple of days.

[PaulKlint]

This one still seems to be open, I still get the above error message.

[mahills]

Ah, my "next couple of days" apparently didn't work out quite as expected :(

I'll take a look -- I'm assuming subscripts ignore layout, like the constructors do?

[swatbot]

Yes, I think also subscripts should ignore layout.

On Mon, Jan 13, 2014 at 12:37 AM, mahills notifications@github.com wrote:

Ah, my "next couple of days" apparently didn't work out quite as expected
:(

I'll take a look -- I'm assuming subscripts ignore layout, like the
constructors do?

—

Reply to this email directly or view it on GitHubhttps://github.com//issues/451#issuecomment-32138233
.

Jurgen Vinju

• Centrum Wiskunde & Informatica - SWAT

• INRIA Lille - ATEAMS

• Universiteit van Amsterdam

  www: http://jurgen.vinju.org, http://www.rascal-mpl.org,
  http://twitter.com/jurgenvinju
  skype: jurgen.vinju

[PaulKlint]

Indeed!

[mahills]

Just to verify, the correct behavior should be:

• for concrete lists, subscripting should act like it does for normal lists, e.g., if we have A* and a match like <A* x> then we could have x[0], x[1], etc to get the first, second, etc A
• for concrete non-iter terms, subscripting should act like it does for nodes or tuples, e.g., if we have a definition of a conditional in variable s, then s[0] is the guard, s[1] the then branch, and s[2] the else branch

Is this all correct?

[swatbot]

Yes, and all results are of type Tree, necessarily—
Jurgen J. Vinju
CWI SWAT
INRIA Lille
UvA master software engineering
http://jurgen.vinju.org

On Tue, Jan 14, 2014 at 1:35 AM, mahills notifications@github.com wrote:

Just to verify, the correct behavior should be:

• for concrete lists, subscripting should act like it does for normal lists, e.g., if we have A* and a match like <A* x> then we could have x[0], x[1], etc to get the first, second, etc A

• for concrete non-iter terms, subscripting should act like it does for nodes or tuples, e.g., if we have a definition of a conditional in variable s, then s[0] is the guard, s[1] the then branch, and s[2] the else branch
  Is this all correct?

  Reply to this email directly or view it on GitHub:
  Better support for concrete values #451 (comment)

[PaulKlint]

@mahills, here is my take on this:

• Indeed: for concrete lists, subscripting should act like it does for normal lists, e.g., if we have A* and a match like <A* x> then we could have x[0], x[1], etc to get the first, second, etc A. and the type of the result of x[0] etc. should be A
• for concrete non-iter terms, subscripting should act like it does for nodes or tuples, e.g., if we have a definition of a conditional in variable s, then s[0] is the guard, s[1] the then branch, and s[2] the else branch. And here it is unavoidable that the inferred type of the result is of type Tree (although its actually type will be more precise).

[jurgenvinju]

A yes! We can be more precise with lists. Cool.—
Jurgen J. Vinju
CWI SWAT
INRIA Lille
UvA master software engineering
http://jurgen.vinju.org

On Tue, Jan 14, 2014 at 8:44 AM, Paul Klint notifications@github.com
wrote:

@mahills, here is my take on this:

• Indeed: for concrete lists, subscripting should act like it does for normal lists, e.g., if we have A* and a match like <A* x> then we could have x[0], x[1], etc to get the first, second, etc A. and the type of the result of x[0] etc. should be A

* for concrete non-iter terms, subscripting should act like it does for nodes or tuples, e.g., if we have a definition of a conditional in variable s, then s[0] is the guard, s[1] the then branch, and s[2] the else branch. And here it is unavoidable that the inferred type of the result is of type Tree (although its actually type will be more precise).

Reply to this email directly or view it on GitHub:
#451 (comment)