Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epsilon-dev] epsilon-dev Digest, Vol 46, Issue 2
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 wrote:

 

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
******************************************

 

https://bowtie.mailbutler.io/tracking/hit/18f9b332-5ef3-4d52-a036-ef356a517a34/03133689-d1ee-4cf4-b853-aefff07a2b55/t.gif_______________________________________________
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


--
Antonio Garcia-Dominguez

Back to the top