| Re: [epsilon-dev] epsilon-dev Digest, Vol 46, Issue 2 |
Hi all, I agree with Antonio’s comments, and just to add a thought: if we are to go down the path of importing modules, would it be sensible to execute it lazily, so only when the actual import is “used”? This would be whenever the import is referenced by its alias. The output could simply be whatever the output of executeImpl() is, so for EVL it’s Set<UnsatisfiedConstraint>, for EOL it’s whatever the last return statement is, for ECL the MatchTrace, EPL the PatternMatchModel etc. However if an explicit execute(“fileA.epl”) is used then we execute eagerly. Thanks, Sina From: Garcia-Dominguez, Antonio Hi all, Adding to this, what would be the expected behaviour if we import a module that executes EVL/EPL modules? Some comments below: On Mon, 2018-12-10 at 12:47 +0000, Horacio Hoyos Rodriguez wrote: > As with Sina’s work on lambdas, I think this built-in variables makes the > language look clumsy and these additions an after thought. Harsh! :-) It is true that a dedicated statement would be friendlier towards automated checks, syntax highlighting/outlining and autocompletion in the future. > I would prefer something that is closer to the EOL syntax: import “<path>” as > <var>. If the import statement semantics are been too disrupted, I would > prefer adding a new import keyword for this special "executable in the pre” > imports, like Antonio suggested, but perhaps keywords that both reflect the > notion of execution and the appearance of a new model (the trace): > > load A from execute “fileA.epl” > > execute “fileA.epl” as A I like #2 better, it's more natural to read. We may want to have some provisions for passing arguments, by the way. Also, I assume that these can only happen at the top level (so nobody tries to do an 'execute' from inside an operation). > Or to make the source language explicit (note that explicit engine > specification allows for arbitrary file extensions too) > > model A = execute[‘patternMatch’, ‘file.epl' ] > model B = execute[‘validate’, ‘file.myfile' ] I'm not a big fan of this odd passing-arguments-between-brackets notation, it breaks the style that we have followed elsewhere in Epsilon. Kind regards, Antonio > > On 10 Dec 2018, at 12:31, Dimitris Kolovos <dimitris.kolovos@xxxxxxxxxx> > > wrote: > > > > Hi Antonio, > > > > On Mon, 10 Dec 2018 at 12:25, Garcia-Dominguez, Antonio < > > a.garcia-dominguez@xxxxxxxxxxx> wrote: > > > 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. > > > > Cheers, > > Dimitris > > > > > Kind regards, > > > Antonio > > > > > > -- > > > Sent from Hiri > > > > > > On 2018-12-10 12:00:22+00:00 Dimitris Kolovos wrote: > > > > Hi everyone, > > > > 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 > > > > Cheers, > > > > Dimitris > > > > > > > > On Mon, 10 Dec 2018 at 11:06, Antonio Garcia-Dominguez < > > > > agarcdomi@xxxxxxxxx> wrote: > > > > > 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). > > > > > Kind regards, > > > > > Antonio > > > > > > > > > > On Mon, 10 Dec 2018 at 10:52, Sina Madani <sinadoom@xxxxxxxxxxxxxx> > > > > > wrote: > > > > > > 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 > > > > > > > > > > > > From: Horacio Hoyos > > > > > > Sent: 10 December 2018 10:29 > > > > > > To: Epislon Project developer discussions > > > > > > Subject: Re: [epsilon-dev] epsilon-dev Digest, Vol 46, Issue 2 > > > > > > 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). > > > > > > Cheers, > > > > > > > > > > > > > On 9 Dec 2018, at 21:58, Beatriz Sanchez <basp91@xxxxxxxxx> wrote: > > > > > > > > > > > > > > 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: > > > > > > > > > > > > > > —————————— > > > > > > > import “file.epl” as “P” > > > > > > > > > > > > > > rule AB2C > > > > > > > transform ab : P!AB > > > > > > > to c : C { ...} > > > > > > > —————————— > > > > > > > > > > > > > > it could identify that is an EPL through the extension and > > > > > > > therefore accept the alias. > > > > > > > > > > > > > > Regards, > > > > > > > Beatriz Sánchez > > > > > > > > > > > > > > > On Dec 7, 2018, at 5:00 PM, epsilon-dev-request@xxxxxxxxxxx wrot > > > > > > > > e: > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > Arcanefoam > > > > > > > > > > > > https://bitbucket.org/arcanefoam/ > > > > > > https://github.com/arcanefoam > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > > > > > -- > > > > > Antonio Garcia-Dominguez > > > > > _______________________________________________ > > > > > 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 > > > > > > -- > > 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 > > > Dr. Horacio Hoyos Rodriguez > Research Associate > Computer Science Department > |