Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Design question: resolving dependency between Ecore and builtin types
Design question: resolving dependency between Ecore and builtin types [message #1858631] Wed, 12 April 2023 15:35 Go to next message
Simon Cockx is currently offline Simon CockxFriend
Messages: 69
Registered: October 2021
Member
I'm modelling a language with expressions and types such as `int` and `date`. Note that these types are built-in, i.e., users cannot add additional types.

These types have two representations:
1. In the language itself:
basic type int
record type date {
  day: int
  month: int
  year: int
}

... which are represented as `BasicType` and `RecordType` classes in the ecore, e.g.,
interface Type {
    String name
}
class BasicType extends Type { }
class RecordType extends Type {
    contains RecordFeature[] features
}
class RecordFeature {
    String name
    refers Type type
}

The idea is that these types are automatically made available as a "standard library".

2. In the Java code:
public class RType {}

public class RBasicType extends RType {
  public static BasicType INT = new BasicType("int");
  ...
}

public class RRecordType extends RType {
  public static RRecordType DATE = new RRecordType("date");
  ...
}


The language supports these expressions:
- date construction, e.g.,
{ day: 12, month: 4, year: 2023 }

- feature projection, e.g.,
myDate.month


When performing type inference, I have a rule that says "for a date construction, return `RRecordType.DATE`" and a rule that says "for a feature projection, return the type of the feature you're projecting to".

Problem: while computing the scope of a feature projection, I can compute the type of the expression I'm projecting on, but then I need some way of accessing the Ecore features of that type. For example, consider the following expression:
{ day: 12, month: 4, year: 2023 }.month

I first infer that the type of the receiving expression is `RRecordType.DATE`. Then I would like to return a list of the Ecore features of the corresponding `RecordType`, but I'm not sure how.


One thing I considered is adding a reference to `RecordType` to the class `RRecordType`, but then I cannot instantiate the static field `RRecordType.DATE` anymore, which I need when performing type inference.

Are there languages with a similar problem that came up with a solution for this? Any suggestions?

[Updated on: Fri, 21 April 2023 09:53]

Report message to a moderator

Re: Design question: resolving dependency between Ecore and builtin types [message #1858640 is a reply to message #1858631] Thu, 13 April 2023 08:15 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14735
Registered: July 2009
Senior Member
am not sure about the "ecore" feature thing here.
do you mean ecore::EAttribute?


Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Day Job: https://www.everest-systems.com
Re: Design question: resolving dependency between Ecore and builtin types [message #1858782 is a reply to message #1858640] Fri, 21 April 2023 10:00 Go to previous message
Simon Cockx is currently offline Simon CockxFriend
Messages: 69
Registered: October 2021
Member
With "feature", I refer to the concept of something you can project to (e.g., in Java, everything after a dot). For my DSL, that includes the fields of a record type.

With "ecore feature", I mean the representation of a feature in the Ecore. For my DSL, record features are represented by the Ecore class "RecordFeature".

Basically, my scope provider necessitates that the type system knows about the Ecore. I'm not sure how to implement that cleanly though - currently my types are constructed statically, without knowledge of Ecore.
Previous Topic:Auto format Xtext textual model
Next Topic:Syntactic predicates and proposal provider execution time
Goto Forum:
  


Current Time: Fri Dec 06 12:10:32 GMT 2024

Powered by FUDForum. Page generated in 0.02032 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top