Hi Dimitris/Antonio, I think this is a great idea, though my opinion is perhaps biased as it is the same approach I would use for the LambdaFactory to avoid keywords. I think it makes sense to have some sort of object like System or Epsilon as proposed for meta-level operations such as invoking other Epsilon programs or creating lambdas. Implementation-wise, we could keep the signature consistent (e.g. “Epsilon.validate(...)”) but the actual Epsilon object in the FrameStack can be extended to provide additional functionality for each language, e.g. in the case of EGL it could provide a façade for TemplateFactory. So we would have something like: EOLMetaContributor - validate
- patternMatch
- ..etc.
- Lambda creation operations?
EGLMetaContributor extends EOLMetaContributor - executeTemplate(String templateName, Map<String, ?> variables)
Thanks, Sina Hi Antonio, Hi Dimitris,
I like this idea, but how would you make this extensible? Would the Epsilon built-in variable take in new operations that would be contributed by the various Epsilon languages?
Possibly; I haven't worked out the best way to implement this but I'm sure we can agree on an extensible implementation. BTW, wouldn't it make sense for validate(...) to ask for a trace model name as well?
Yes - this was just a minimal example. We can be flexible on signatures. On 2018-12-10 12:00:22+00:00 Dimitris Kolovos wrote: Thank you for your insightful responses! Taking Antonio's idea a bit further I'm now wondering if it'd make sense to introduce a new built-in variable with appropriate methods instead of new keywords e.g. Epsilon.patternMatch("foo.epl", "P"); // Pattern matches currently loaded models using foo.epl and exports the result as an in-memory model named P in the module's model repository Epsilon.validate("foo.evl"); // Validates currently loaded models using foo.evl Hi all, I do like #3 with Betty's idea the best as it could open things up to better integration of other E*L languages (e.g. EVL), while not requiring too many changes to existing grammars. However, it's still a bit odd as importing AFAIK just brought up a collection of operations from an EOL file, rather than compute some intermediate model. We are overloading the import keyword here quite a bit. I would generalise Dimitris' original #3 to something like "execute" or "launch", and allow other types of E*L modules to be run and reused as temporary in-memory models (EVL, ECL). Hi all, I also agree with Betty and Horacio, though primarily because I’m not sure how EPL would be integrated with regards to its implementation and effect on the execution engines of the Epsilon languages, given that EPL is by far the most complex of all. I’m also slightly confused as to what would be the output of executing EPL patterns within other Epsilon languages. If it is a PatternMatchModel, then would this model need to be persisted or kept in memory? If so how would it be referenced within the program? If there is no output then presumably only the “onmatch” / “nomatch” / “do” blocks are used to perform post-processing. However in this case we would somehow need the EPL program to be aware of its context (that is, being a “child” of another Epsilon program) so that it can make use of operations and variables declared in the parent. In this case, it would be the EPL program which imports the EOL? I think that by using the third approach we can retain all semantics and features of EPL, though if we require the user to create a new EPL file then are we really integrating EPL into the language or providing more convenient plumbing for using and invoking it? If implementation was a non-issue, perhaps the first one would be ideal from the user’s standpoint as it integrates directly into the existing language constructs, but I suspect this will be the most difficult to implement. Though I can see the value in all Epsilon languages. In EVL for example the ConstraintContext could be defined by a pattern as opposed to getAllOfKind(). There is also obvious utility in ECL’s “compare” block. Thanks, Sina Hi all, My vote also goes towards the 3rd approach with Betty’s idea. #1 Changes ETL too much, making a complex rule based + pattern based transformation language. #2 Seems more powerful (I can see the benefit of validation of patterns) but gives EOL (a “general purpose” modelling language) too specific purpose #3 Keeps EPL as an independent language, and workflows that use the EPL result outside Epsilon scripts still work. The import with the “as” keyword provides a way to let the user identify the match model by any name (thus not forcing it to be P). Further, the same approach can be used to allow more easy reuse of ECL results too. Even more so, we could create a new “EVL” model that stores the unsatisfied constraints in a more “model like” structure and those could be reused too (e.g. to execute some transformation rules when certain constraints are violated). Hi Dimitris, How about a modification to the third approach where instead of using a new keyword “pattern” we reuse the import but add an alias to the imported pattern: rule AB2C
transform ab : P!AB
to c : C { ...} it could identify that is an EPL through the extension and therefore accept the alias. Send epsilon-dev mailing list submissions to
epsilon-dev@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://www.eclipse.org/mailman/listinfo/epsilon-dev
or, via email, send a message with subject or body 'help' to
epsilon-dev-request@xxxxxxxxxxx
You can reach the person managing the list at
epsilon-dev-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of epsilon-dev digest..."
Today's Topics:
1. Support for patterns in Epsilon languages (Dimitris Kolovos)
----------------------------------------------------------------------
Message: 1
Date: Thu, 6 Dec 2018 22:09:06 +0000
From: Dimitris Kolovos <dimitris.kolovos@xxxxxxxxxx>
To: Epsilon Project developer discussions <epsilon-dev@xxxxxxxxxxx>
Subject: [epsilon-dev] Support for patterns in Epsilon languages
Message-ID:
<CAEs3cJgR_AKwveWXEJf2UhpdVUMCpOH5rD71L6XY7R=++BTnaQ@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"
Hi everyone,
I've been thinking about how to provide better support for (EPL)
patterns within other Epsilon languages for a while now. Currently, if
e.g. an ETL transformation needs to make use of patterns, we need to
encode the latter in an EPL program and then use ANT to run the EPL
program, export pattern matches as a "model" and then use that model
in ETL. I'm considering three alternatives.
The first one is to adapt the syntax of ETL, EGX etc. to directly
accommodate patterns so that we can have rules like the following:
rule AB2C
transform
a : A from: A.all
b : B from: a.b
to c : C { ... }
The second option is to move support for patterns to EolModule so that
all Epsilon programs can also contain patterns, in which case the
transformation would be written as follows:
pattern AB
a: A from: A.all
b: B from: a.b { ... }
rule AB2C
transform ab : P!AB
to c : C { ...}
The third option is to introduce a new keyword to all Epsilon
languages through which we can invoke EPL e.g.
patterns "AB.epl";
rule AB2C
transform ab : P!AB
to c : C { ...}
The main advantage of the first approach is that the syntax will be
more natural since it supports "unnamed" patterns while the main
argument for the second approach is that it should be much more
straightforward to implement. However both of these would potentially
break backwards compatibility as they add all the keywords of EPL to
existing languages. The third approach only needs one keyword
("patterns"), but it feels a bit clunky.
Any thoughts?
Cheers,
Dimitris
--
Dimitris Kolovos
Professor of Software Engineering
Department of Computer Science
University of York
http://www.cs.york.ac.uk/~dkolovos
EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm
------------------------------
_______________________________________________
epsilon-dev mailing list
epsilon-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/epsilon-dev
End of epsilon-dev Digest, Vol 46, Issue 2
******************************************
 _______________________________________________
epsilon-dev mailing list
epsilon-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/epsilon-dev
_______________________________________________
epsilon-dev mailing list
epsilon-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/epsilon-dev
-- _______________________________________________
epsilon-dev mailing list
epsilon-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/epsilon-dev
--
--
Dimitris Kolovos
Professor of Software Engineering
Department of Computer Science
University of York
http://www.cs.york.ac.uk/~dkolovos
EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm |
