Struct objects

[ACassimiro]

Introducing struct creation and usage. Structs can be created with or without its inner variable assignments. For example:

struct Pair{i: u32, j: u32 }
[...]
//Within a function
let _pair = ::structs::Pair {
     i: 1_u32,
     j: 2_u32
};
// or
let _pair = ::structs::Pair {
     1_u32,
     2_u32
};

[virgil-serbanuta]

This does not follow the Rust reference (see the link at line 544). We should not follow it precisely when it helps us, but could you document the changes (a TODO would probably be enough)? Also, whenever possible, could you try to preserve the sort names in the Rust reference?

Some more precise questions:

1. Why did you use a TypePath instead of a PathInExpression here? If a TypePath is easier to implement, it's probably fine, since we don't plan to use generics in this way.
2. Does the LiteralExpressionList thing below actually work in Rust? By looking at this page, I'm not sure how: https://doc.rust-lang.org/reference/expressions/struct-expr.html . If it does not work in Rust, do we need it?
3. Does it help if you use LiteralExpression in StructExprField / StructFieldAssignment instead of Expression? The same question for LiteralExpressionList - you may be able to use TupleElementsNoEndComma here, which can be transformed to ExpressionList. I'm asking this because, if you use Expression/ExpressionList instead, you may have easier ways to evaluate expressions.

[ACassimiro]

1. For the TypePath, I'm having issues converting a PathExpression into a TypePath, so I decided to use it directly in the construction. If you think the effort is valid, I can take some time to continue digging into it.
2. and 3. In the first implementation, I focused on implementing a syntax that would work for the specific case I was trying to handle on our tests. I ended up not correcting the syntax once the test was correctly executed, so I reimplemented the syntax to become closer to the reference implementation. Please notice that, even in this updated syntax, a few of the approaches that we use to initialize structs are not yet supported, and we're using a TypePath where a PathInExpression should be.

[virgil-serbanuta]

s/variable/field/, perhaps?

[virgil-serbanuta]

Why is this an owise rule?

[ACassimiro]

Testing it without the [owise] always caused tests to reach a stuck state. My understanding is that there is a certain degree of ambiguity between this rule and the rule right below it, and when the second one should be applied to finish the parsing of the struct declaration, it would apply the first, leading the K cell to a state where it could not be rewritten further.

[virgil-serbanuta]

Ah, now I understand what happens... I was misreading the rule below. You may try to replace it with

rule structParser(_Name:TypePath, .StructFields) => .K

and then you will probably not need an owise rule here.

[virgil-serbanuta]

Do you need the "Structs" sort?

[ACassimiro]

I've just noticed it is not necessary. Will remove it.

[virgil-serbanuta]

Could you either match the reference, or add some TODOs where the implementation is different? Here you're missing WhereClause?, which is fine since we don't need it. Something similar applies to "StructField" below.

[virgil-serbanuta]

Ah, now I understand what happens... I was misreading the rule below. You may try to replace it with

rule structParser(_Name:TypePath, .StructFields) => .K

and then you will probably not need an owise rule here.

[virgil-serbanuta]

Probably it's a good idea to not implement this, since we are short on time, but, for the future, probably the better way of implementing this is something like this:

syntax KItem ::= fromStructExpressionWithLiteralsBuildFieldsMap(TypePath, StructBases, List)  [strict(2), result(ValueWithPtr)]

rule isValueWithPtr(.StructBases) => true
rule isValueWithPtr(E:Expression Es:StructBases) => isValueWithPtr(E) andBool isValueWithPtr(Es)

rule E:Expression Es:StructBases => E ~> E Es  [heat, result(ValueWithPtr)]
rule E:Expression ~> _:Expression Es:StructBases => E Es  [cool, result(ValueWithPtr)]

rule E:Expression Es:StructBases => Es ~> E Es requires isValueWithPtr(E)  [heat, result(ValueWithPtr)]
rule Es:StructBases ~> E:Expression _:StructBases => E Es requires isValueWithPtr(E)  [cool, result(ValueWithPtr)]

rule fromStructExpressionWithLiteralsBuildFieldsMap(I, RL, FieldNameList) => almostAStruct(I, pairFieldsWithValues(RL, FieldNameList, .Map))
rule almostAStruct(I, M:Map) => struct(I, M)

syntax MapOrError ::= pairFieldsWithValues(StructBases, List, .Map)  [function, total]
rule pairFieldsWithValues(.StructBases, .List, M:Map) => M
rule pairFieldsWithValues(???) => ???
...

Something similar applies to fromStructExpressionWithAssignmentsBuildFieldsMap.

[virgil-serbanuta]

I think that there is at most one StructBase here. It's fine to keep it as-is, but add a "//TODO: Not implemented properly". I think that you can also have StructExprFields , StructBase and StructExprFields , here. Again, we don't need them, but you should add the TODO. Also, StructBase below is actually ".. Expression". You should probably not change it, but you should add a TODO.