Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Details on builtin language #153

Closed
enikao opened this issue Aug 4, 2023 · 0 comments
Closed

Details on builtin language #153

enikao opened this issue Aug 4, 2023 · 0 comments

Comments

@enikao
Copy link
Contributor

enikao commented Aug 4, 2023

Are builtins part of regular models or always assumed present?

When we export a model to a file (as we are doing in several scenarios) do we export the builtin primitives as well? Or do we leave them out and is any tool reading the file assumed to know them?

Pro part of export:

  • Self-contained JSON file
    BUT: It's hard to make sense of the json content without specific LW knowledge

Pro always present:

  • Part of installation with special, stable ids
  • Versioned

Decision: We assume builtins are always present.

Do we declare builtins as language dependency?

If my language A uses anything of language B, A needs to depend on B.
If A uses anything of built-in, does it need to depend on Builtin?

Pro:

  • Uniform handling of all language dependencies

Con:

  • Every language (transitively) depends on Builtin. In Metamodel dependencies: explicit, transitive? #50, we decided we do not need to declare transitive language dependencies.
  • Any new language would need to declare the dependency before we can set e.g. a builtin property type

Decision: Don't need to declare

Do we declare builtins as used language?

Assume a JSON file that contains the M2 of language A. A refers to builtin entities like Node or String.
In the used languages section (#76), do we mention builtins?

Pro:

  • As builtins are used in M3, any M2 will probably instantiate builtins entities.
    Thus, builtins is a used language.
    NOTE: M1 JSON files might not have builtins as used language, e.g. if they don't contain any instance of INamed.
    But, if they do (e.g. my language defines Person implements INamed, and my M1 contains an instance of Person), we do use builtins.
  • If my language B does not depend on builtin types, because I declare my SpecialSting and SpecialNumber types, I don't want to import builtins.

Con:

  • It's impossible to define a language without using builtins, so we can assume it to always be used.

Decision: builtins are handled like any other language on serialization level, i.e. MUST be listed as used language if instantiated anywhere in the serialization chunk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant