10 Apr
2013
10 Apr
'13
10:54 a.m.
Doru, there is something in your mail configuration that is breaking the mail threads :)
On Apr 10, 2013, at 8:57 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
On Wed, Apr 10, 2013 at 8:36 AM, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr>
wrote:
thank you for you contribution.
I had a similar discussion with Damien Cassou (about traits).
First, it depends a lot on what you call a Trait.
Trait has only one meaning in programming languages, and it denotes a mechanism for
reuse. Multiple inheritance is also a mechanism for reuse. The difference lies in the
semantics of specifying and handling the reuse.
What I understood is that traits boil down to an inheritance mechanism where you can
specify how each property is inherited.
Typically, you don't specify anything ("normal inheritance") but when you
multiply inherit the same property from two super-class, you can rename one of the 2
property (aliasing) or reject it (restriction).
So from this point of view, yes we will use Traits because we also need to deal with name
collision in multiple inheritance.
Second we want to have attributes in the Famix concepts.
Again, as I understand, in Pharo, traits are currently stateless due to
compilation/optimization issue.
But Fame and Famix or not real programming languages. They need to be compiled to a
programming language which is compiled to a low level language.
Because the first "compilation" goes to a language with symbols (instead of
accessing attributes by their position), there does not seem to be any difficulty in
considering "statefull traits" in Fame/Famix.
Both methods and attributes would be treated the same (inheritance + possible
aliasing/restriction)
So in this sense, we can say that we will be using statefull traits.
Yes. And the way we can get around the current Pharo Trait implementation is by using
state dictionary, like we are doing now in MooseEntity.
But in the end, I am not too sure whether it makes sense to speak of Traits at this level
of abstraction.
It does.
We are currently aiming at multiple inheritance of both attributes+methods with the
aliasing/restriction mechanisms.
Is this traits?
No. we are aiming at composing meta-models and for that we need a language mechanism.
Hence, talking about the mechanism makes perfect sense. And we will use Traits because it
is the best on the market.
As for compiling Famix to programming languages, this is a very different story.
Currently the way it works is that we program things in Pharo, add the appropriate
pragmas to the Pharo methods, and then generate Famix from the Pharo classes.
What I would like to have is more top-down: we generate everything in Famix (will need a
bit of tooling here), and then we generate Pharo code automatically.
Done that way, the discussion about trait and inheritance can be eliminated because
actually, one can generate a flat set of Pharo classes where all inheritance has been
inlined.
In some sense, it is again similar to current implementation of Traits in Pharo where the
Traits methods are compiled inside the Pharo class.
So again it will be kind of using traits again.
I disagree. We keep a 1-to-1 mapping to Pharo. This is critical because we are using
Pharo as the execution language and we do not want to deal with two model abstractions. Of
course, we should also build tools, such as the MetaBrowser that make it easier for us to
handle the meta-descriptions, but in the end we want to keep a clear mapping to Pharo
code. This will save us a ton of trouble down the road.
Given that Traits are already supported in the execution language (Pharo), we can
directly use this 1-to-1 mapping without any problems. So, we will not rely on generation
at all. The same as it is now. And we put in place tests that check the
meta-descriptions.
Generation only looks cheap, but as soon as you want to manipulate anything at the lower
level, it becomes highly expensive. We managed to keep away from this and it payed off
until now. I insist on this point :).
As for Alain's work.
I have it on my disk, but did not have the time to look at it yet.
I think we should start from this one and see how we can support Fame-Traits in Java.
Doru
nicolas
On 04/09/2013 12:11 PM, Tudor Girba wrote:
Hi,
Thanks for taking the time to lay this out. I am certainly interested in participating. I
agree with most of it, except one thing: multiple inheritance.
As I said before, we should use Traits instead. There are only benefits from using
Traits:
- Traits are already supported by Pharo, making it easy to integrate meta-descriptions
with existing code due to the 1-to-1 mapping between meta-descriptions and code, and thus
benefits from tooling.
- Traits are better at dealing with conflicts.
- Java anyway does not have multiple inheritance, so choosing between Traits and multiple
inheritance has a similar impact.
- Traits can be used as types as well.
- Chef showed that we can nicely use Traits for navigation.
- And we already have a first version of a Traits extension to Fame (built by Alain
Plantec).
Cheers,
Doru
On Tue, Apr 9, 2013 at 11:44 AM, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr>
wrote:
Hi guys,
Food for thoughts.
It's a long one, but it is literally the result of years of thinking and discussing
Famix in our group.
This is still work in progress so that those who might want to participate have a chance
to do it before everything is already decided.
You can call it a vision for the next Famix (and Fame incidentally)
Although the goal of Famix is to be able to model systems in any language, the reality of
it is that it focuses very much on OO, and more precisely on ST and Java.
And even with only these two languages, it is already difficult.
Famix is the union of ST + Java which means unneeded complexity when you deal with only
one of the two.
Same happen when considering something outside the current scope.
For example something as a C function calling another C function is currently represented
as an invocation, which means it has a receiver (the object on which a message is sent,
useless in C) and also a collection of candidates (whereas in C function names must be
unique).
When working with different languages, mostly not OO, it started to annoy me, and I
wanted to see how we could redesign a new Famix so that:
- we have a bare core metamodel that is really language independent
- something that is easily extensible so that one does not have to redefine basic stuff
(what is a variable, a class, a method)
- no "hidden" associations as the declaredType of a FamixStructuralEntity
- it is completely model driven, which means we can regenerate all the code in Smalltalk,
Java and other languages from the metamodel. Having Fame (and thus Famix) in Java helped a
lot when I did VerveineJ. I can imagine having a C implementation of Fame could be nice to
reuse old parsers based on Bison+Flex :-)
I had two other requirements steming from the way I see metamodels: primarily as
conceptual representations of some domain. They should be as clear as possible about what
is meant by the concepts and their relationships, and also it should be as close as
possible from the human conception of the domain.
This implies:
- I want it to be typed. C and Java have types to guard the developer from making
mistakes, I want types to clarify the meaning of the concepts, like defining an ontology
- I want it to have multiple inheritance, with as little restrictions as possible
(typical multiple inheritance problems in programming languages) to try to be closer from
the abstract conception of the domain.
In short, we are looking for the Graal, nothing new here :-)
Now the question is how far we can push it and how close can we get?
Discussing we had the idea of a GenericEntity, probably equivalent to the current
FamixSourcedEntity.
We could have generic FunctionEntity, VariableEntity, ClassEntity inheriting from
GenericEntity; MethodEntity inheriting from FunctionEntity.
And all these only stating consensual things like a class defines methods, a function
defines variables.
Independent of that (meant to be used through multiple inheritance) we would have the
idea that there are ContainerEntity, BehavioredEntity, TypedEntity, maybe even
NamedEntity.
So that FunctionEntity (which is a GenericEntity) would also be a BehavioredEntity + a
NamedEntity.
Invocation would occur between two BehavioredEntity
And we could create new entities by combining all these things.
For example, a JavaMethodEntity would inherit from MethodEntity + TypedEntity +
ContainerEntity (may define classes)
A PascalProgram could be a GenericEntity+ContainerEntity (contains
functions)+BehavioredEntity
All this would be declarative in the new Famix and translated in some way by Fame into
different languages (lets concentrate on Pharo and Java for now).
In a first step, behaviour to be reused (like navigation between a ContainerEntity and
its members) could be stored directly in the metamodel for each target language and then
copied appropriately when generating actual code.
In a second step I also dream of using FAST (AST metamodeling, see
http://youtu.be/dRr3WHOD3x4) to model the behaviour abstractly and then generate the code
from that.
I believe this would introduce only two real changes to Moose: First Fame would have to
allow for multiple inheritance, second MooseChef would have to be re-designed to allow for
new queries (at least ContainerEntity, BehavioredEntity).
And of course, we would need to using it concretely to see whether it really helps
considering new languages
So this is about it.
If you have any idea or comment on this, we will be glad to here from you.
If you want to participate, we will be even gladder because we are not that many and it
is a lot of work.
nicolas
--
Nicolas Anquetil -- RMod research team (Inria)
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Nicolas Anquetil -- RMod research team (Inria)
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev