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,

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

_______________________________________________
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


Back to the top