Skip to content

Commit

Permalink
Swap the order of 'type-specifier' and 'array-subscripts'
Browse files Browse the repository at this point in the history 
This fixes the non-intuitive order when appending array dimensions in Modelica:
```
model ModelicaAppendDimensions
  type Arr = Real[3, 4];
  Arr[1, 2] x = fill(0.0, 1, 2, 3, 4); /* Note: (Real[k, l])[m, n] is not the same as Real[k, l, m, n]. */
end ModelicaAppendDimensions;
```

With the order swapped, we get this instead:
```
model NaturalAppendDimensions
  type Arr = [3, 4] Real;
  [1, 2] Arr x = fill(0.0, 1, 2, 3, 4); /* Note: [k, l]([m, n]Real) is the same as Real[k, l, m, n]. */
end NaturalAppendDimensions;
```
  • Loading branch information
@henrikt-ma
henrikt-ma committed Jan 7, 2020
1 parent 84c271b commit 4f01282
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions RationaleMCP/0031/grammar.md
View file
Expand Up @@ -104,7 +104,7 @@ end _F;
> _short-class-specifier_ →\
>   _IDENT_ **=**\
>   ( _base-prefix_? _type-specifier_ _array-subscripts_? _class-modification_?\
>   ( _base-prefix_? _array-subscripts_? _type-specifier_ _class-modification_?\
>   | **enumeration** `[(]` ( _enum-list_? | **:** ) `[)]`\
>   )\
>   _comment_
Expand Down Expand Up @@ -162,7 +162,7 @@ end _F;

## B24 Component**clause**
> _component-clause_ → _type-prefix_ _type-specifier_ _array-subscripts_? _component-list_
> _component-clause_ → _type-prefix_ _array-subscripts_? _type-specifier_ _component-list_
> _type-prefix_ →\
>   ( **flow** | **stream** )?\
Expand Down

6 comments on commit 4f01282

@gkurzbach
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having dimension before the type, the handling inside the compiler might be some kind of natural, but from the user point of view I find it unusual and somehow very ugly.

Especially, in your example, I think you made a mistake:

model ModelicaAppendDimensions
  type Arr = Real[3, 4];
  Arr[1, 2] x = fill(0.0, 1, 2, 3, 4); /* Note: (Real[k, l])[m, n] is not the same as Real[k, l, m, n]. */
end ModelicaAppendDimensions;

should be

model ModelicaAppendDimensions
  type Arr = Real[3, 4];
  Arr[1, 2] x = fill(0.0, 1, 2, 3, 4); /* Note: (Real[k, l])[m, n] is not the same as Real[m,n,k, l]. */
end ModelicaAppendDimensions;

And this is, what it makes the handling somehow unnatural.

@gkurzbach
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also making such changes, the syntax of Flat Modelica diverges from Modelica to much, without real benefit.

@HansOlsson
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also making such changes, the syntax of Flat Modelica diverges from Modelica to much, without real benefit.

I agree.

And regarding examples I believe it is more helpful to say what something is the same as - and not what it isn't.

@henrikt-ma
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gkurzbach, I think you missed the negation in the comment of ModelicaAppendDimensions (which is probably what @HansOlsson meant).

The examples show what is the same as what by giving a fill call with the resulting dimensions. In this way, the negative example (ModelicaAppendDimensions) shows that (Real[3, 4])[1, 2] is the same as Real[1, 2, 3, 4] — not Real[3, 4, 1, 2] as one may naively think. I don't think I've ever met a person that doesn't find this counter-intuitive, which is why I wanted to give fixing it a try.

The reason why I think this matters more for Modelica than some other popular languages is that one quite often encounters these nested arrays that have to be thought of as multidimensional, especially when creating modifiers.

Now that we've had some discussion around it, I'm expecting that we can decide what to do during tomorrow's meeting.

@gkurzbach
Copy link
Collaborator

@gkurzbach gkurzbach commented on 4f01282 Jan 9, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gkurzbach, I think you missed the negation in the comment of ModelicaAppendDimensions (which is probably what @HansOlsson meant).

Sorry for that, you are right.

The examples show what is the same as what by giving a fill call with the resulting dimensions. In this way, the negative example (ModelicaAppendDimensions) shows that (Real[3, 4])[1, 2] is the same as Real[1, 2, 3, 4] — not Real[3, 4, 1, 2] as one may naively think. I don't think I've ever met a person that doesn't find this counter-intuitive, which is why I wanted to give fixing it a try.

So I'm even more in favor of removing dimensions on types at all. Also, we are defining FlatModelica and dimensions on types introduce some kind of hierarchical structure, which is against the aim to have a flat language, e.g.:

type T1=Real[1];
type T2=T1[2];
type T3=T1[3,2]
type T4=T2[3];

Are T3 and T4 equivalent? To answer such questions, the compiler has to flatten the hierarchy of declarations and that's what we want to avoid in the language.

@olivleno
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Proposals:

  • Gerd: removing dimensions on type aliases at all. Have dimensions only on components.
  • Henrik: preserve the abstraction of an array as type, e.g.
type Point=Real[3];
type Omega=Real[3];
Point points[5,4];
Omega omega;
Real y13 = points[1,3][2];

in contrast to:

Real points[5,4,3];
Real omega[3];
Real y13 = points[1,3,2];

Using records to work around a lack of array type abstraction:

record Point
    Real[3] x;
end Point;

Point points[5,4];
Real y13 = points[1,3].x[2];
Real[3] x;

If we need of records of arrays anyways, then there is no relaxation in terms of complexity not supporting this abstraction.
To be revisited.

Next meeting Thursday Jan. 30, 9.00AM.

Please sign in to comment.