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

Rename reifyType and reifiedType operators for better understandability #1801

Open
jurgenvinju opened this issue Jun 1, 2023 · 1 comment

Comments

@jurgenvinju
Copy link
Member

jurgenvinju commented Jun 1, 2023

Describe the bug

These two expression operators are confusing and their (static) semantics is sometimes unclear:

  • # Type
  • type(Symbol symbol,map[Symbol,Production] definitions)

This is their grammar rules in Rascal.rsc:

syntax Expression
	= ...
	| reifiedType    : "type" "(" Expression symbol "," Expression definitions ")"  
        ...
	| reifyType      : "#" Type type !>> "[" !selector

The enhancement proposal is to:

  • change their name in the syntax definition
  • fix all impacted source code in Rascal and Java downstream
  • also rename the operators in the documentation

We might start by only the documentation, but eventually we should fix the implementation names as well.

The renaming:

syntax Expression
	= ...
	| typeValue    : "type" "(" Expression symbol "," Expression definitions ")"  
        ...
	| typeLiteral   : "#" Type type !>> "[" !selector

and corresponding changes in the definition of Pattern.

The rationale is clear in itself:

  • type(Symbol,map[...]) is indeed a value representation of all Rascal types based on Symbol and Production, completely dynamic and so the static type is type[value]
  • and #Type is a special literal type version of the above, where the user gets the Symbol value representation for free and the type can be statically asserted to be as concrete as type[Type] for every #Type.
@jurgenvinju
Copy link
Member Author

IOW, the word "reify" does not carry as much meaning as one might expect ;-) "value" and "type" and "types as values" makes more sense IMHO. @PaulKlint @tvdstorm wdyt?

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