Fame/Famix statically typed

> On Nov 24, 2016, at 9:48 AM, Nicolas Anquetil <[hidden email]> wrote:
>
>
> Why is Fame (and Famix) statically typed?
>
> It always seemed strange to me in the Smalltalk context.
>
> Do we really use/need this property?
>
> (Because sometimes, it really sucks)
>
> nicolas
>
>
> --
> Nicolas Anquetil -- MCF (HDR)
> Project-Team RMod
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

> Hi,
>
> We chose to have it statically typed because we are also generating the meta-model for other languages. But, it is true that it is less ideal in some edge cases.
>
> We can think about removing this constraint, but the generation part is a relevant use case that we should take into account. That is why I believe that having a model organized around Traits would be suitable.
>
> What do you think?
>
> Cheers,
> Doru
>
>
>> On Nov 24, 2016, at 9:48 AM, Nicolas Anquetil <[hidden email]> wrote:
>>
>>
>> Why is Fame (and Famix) statically typed?
>>
>> It always seemed strange to me in the Smalltalk context.
>>
>> Do we really use/need this property?
>>
>> (Because sometimes, it really sucks)
>>
>> nicolas
>>
>>
>> --
>> Nicolas Anquetil -- MCF (HDR)
>> Project-Team RMod
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
> --
> www.tudorgirba.com
> www.feenk.com
>
> "From an abstract enough point of view, any two things are similar."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

> On Nov 26, 2016, at 9:58 AM, stepharo <[hidden email]> wrote:
>
> Hi
>
> What we will try to do with Pavel, alain, anne and me (probably nicolas) in contact with Peter starting january is the following
>
> Define another metametamodel (trying to use Pharo + Slot for relationships + invariant = Pharom)
> - this metameta should be able to have different syntaxes
> OpenPonk, Express, Pharo
> - This metameta should does not need types :) sorry I did not get at all the remark of guillaume
> And in particular there is a difference between a static type and a concrete type systems.
>
>
> Take Famix 3 -> Famix3NG and break it appart to get composable pieces
> and use Pharom to describe FamixNG
>
> We are open to discussions but to a certain extent.
>
> Then we will work on optimise for space.
> In addition we will do a call to collect all the points that should be improve in Moose.
>
> We will
> collect
> prioritze
> and tackle them
>
>
> Stef

> Hi,
>
> As I mentioned at ESUG, I am really happy to see this effort, and I will  
> support it. Modeling is an important piece in Moose, and being more  
> flexible at creating new models is a significant added value given that  
> Moose. Please keep me in the loop.
>
> I am particularly interested in the object model of the meta-meta-model,  
> and in the mapping to the Pharo classes that contain the implementation  
> of the meta-model. I believe a Traits-based model would work well (I  
> will try to list my ideas of how this could work later).
>
> Using Slots is definitely something we already should have done in Fame,  
> and I think it will work very well at least on the implementation level  
> of the meta-model.
>
> About syntaxes, I have less predilection for those, but I understand why  
> they can be appealing. I believe that we should first favor Pharo, and  
> only afterwards other DSLs. For example, if we insist of having the  
> meta-model code separately, I believe that we should be able to produce  
> the meta-description also through a fluent API (so, the fluent API is  
> one of the syntaxes). Still, if we express the meta-model separately  
> from the meta-model implementation, the question is remains about how we  
> do the mapping.

>
> Cheers,
> Doru
>
>
>> On Nov 26, 2016, at 9:58 AM, stepharo <[hidden email]> wrote:
>>
>> Hi
>>
>> What we will try to do with Pavel, alain, anne and me (probably  
>> nicolas) in contact with Peter starting january is the following
>>
>> Define another metametamodel (trying to use Pharo + Slot for  
>> relationships + invariant = Pharom)
>> - this metameta should be able to have different syntaxes
>> OpenPonk, Express, Pharo
>> - This metameta should does not need types :) sorry I did not get at  
>> all the remark of guillaume
>> And in particular there is a difference between a static type and a  
>> concrete type systems.
>>
>>
>> Take Famix 3 -> Famix3NG and break it appart to get composable pieces
>> and use Pharom to describe FamixNG
>>
>> We are open to discussions but to a certain extent.
>>
>> Then we will work on optimise for space.
>> In addition we will do a call to collect all the points that should be  
>> improve in Moose.
>>
>> We will
>> collect
>> prioritze
>> and tackle them
>>
>>
>> Stef
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Yesterday is a fact.
>  Tomorrow is a possibility.
>  Today is a challenge."
>
>
>
>

> On Nov 26, 2016, at 2:02 PM, stepharo <[hidden email]> wrote:
>
> Hi doru
>
>> Hi,
>>
>> As I mentioned at ESUG, I am really happy to see this effort, and I will support it. Modeling is an important piece in Moose, and being more flexible at creating new models is a significant added value given that Moose. Please keep me in the loop.
>>
>> I am particularly interested in the object model of the meta-meta-model, and in the mapping to the Pharo classes that contain the implementation of the meta-model. I believe a Traits-based model would work well (I will try to list my ideas of how this could work later).
>>
>> Using Slots is definitely something we already should have done in Fame, and I think it will work very well at least on the implementation level of the meta-model.
>>
>> About syntaxes, I have less predilection for those, but I understand why they can be appealing. I believe that we should first favor Pharo, and only afterwards other DSLs. For example, if we insist of having the meta-model code separately, I believe that we should be able to produce the meta-description also through a fluent API (so, the fluent API is one of the syntaxes). Still, if we express the meta-model separately from the meta-model implementation, the question is remains about how we do the mapping.
>
> I kind of agree. Now I do not want to people feel that we still their ideas and that
> they get stuck with their syntaxes.

>> About types, I also disagree with the comment from Guillaume :). One place where types can be relevant is when producing interfaces for editing objects, but I think that that does not have to be the main driver of the design of the new meta-meta-model. The only thing that I think is important when it comes to types is to allow us to reproduce the basic meta-model implementation in other languages that do rely on rigid static types. For example, right now, Fame generates the relations implementation using this information.
>
> Yes there is a difference between saying
>
> - the type of "to" of this relation is Container
>
> - the type of to of this relation is the class of the object that will be the to of the relation
> based on the instantiation of the relation.
> It is like anchor-type. you may want to say
> this variable is the same type as this one or the same type as whaeveter.
> and not hardcode the type once for all.

>>
>> Cheers,
>> Doru
>>
>>
>>> On Nov 26, 2016, at 9:58 AM, stepharo <[hidden email]> wrote:
>>>
>>> Hi
>>>
>>> What we will try to do with Pavel, alain, anne and me (probably nicolas) in contact with Peter starting january is the following
>>>
>>> Define another metametamodel (trying to use Pharo + Slot for relationships + invariant = Pharom)
>>> - this metameta should be able to have different syntaxes
>>> OpenPonk, Express, Pharo
>>> - This metameta should does not need types :) sorry I did not get at all the remark of guillaume
>>> And in particular there is a difference between a static type and a concrete type systems.
>>>
>>>
>>> Take Famix 3 -> Famix3NG and break it appart to get composable pieces
>>> and use Pharom to describe FamixNG
>>>
>>> We are open to discussions but to a certain extent.
>>>
>>> Then we will work on optimise for space.
>>> In addition we will do a call to collect all the points that should be improve in Moose.
>>>
>>> We will
>>> collect
>>> prioritze
>>> and tackle them
>>>
>>>
>>> Stef
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Yesterday is a fact.
>> Tomorrow is a possibility.
>> Today is a challenge."
>>
>>
>>
>>
>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/

> Hi,
>
>> On Nov 26, 2016, at 2:02 PM, stepharo <[hidden email]> wrote:
>>
>> Hi doru
>>
>>> Hi,
>>>
>>> As I mentioned at ESUG, I am really happy to see this effort, and I  
>>> will support it. Modeling is an important piece in Moose, and being  
>>> more flexible at creating new models is a significant added value  
>>> given that Moose. Please keep me in the loop.
>>>
>>> I am particularly interested in the object model of the  
>>> meta-meta-model, and in the mapping to the Pharo classes that contain  
>>> the implementation of the meta-model. I believe a Traits-based model  
>>> would work well (I will try to list my ideas of how this could work  
>>> later).
>>>
>>> Using Slots is definitely something we already should have done in  
>>> Fame, and I think it will work very well at least on the  
>>> implementation level of the meta-model.
>>>
>>> About syntaxes, I have less predilection for those, but I understand  
>>> why they can be appealing. I believe that we should first favor Pharo,  
>>> and only afterwards other DSLs. For example, if we insist of having  
>>> the meta-model code separately, I believe that we should be able to  
>>> produce the meta-description also through a fluent API (so, the fluent  
>>> API is one of the syntaxes). Still, if we express the meta-model  
>>> separately from the meta-model implementation, the question is remains  
>>> about how we do the mapping.
>>
>> I kind of agree. Now I do not want to people feel that we still their  
>> ideas and that
>> they get stuck with their syntaxes.
>
> I think I am missing a part of the picture. What do you mean by  
> “stealing"?

>
>
>>> About types, I also disagree with the comment from Guillaume :). One  
>>> place where types can be relevant is when producing interfaces for  
>>> editing objects, but I think that that does not have to be the main  
>>> driver of the design of the new meta-meta-model. The only thing that I  
>>> think is important when it comes to types is to allow us to reproduce  
>>> the basic meta-model implementation in other languages that do rely on  
>>> rigid static types. For example, right now, Fame generates the  
>>> relations implementation using this information.
>>
>> Yes there is a difference between saying
>>
>> - the type of "to" of this relation is Container
>>
>> - the type of to of this relation is the class of the object that will  
>> be the to of the relation
>> based on the instantiation of the relation.
>> It is like anchor-type. you may want to say
>> this variable is the same type as this one or the same type as  
>> whaeveter.
>> and not hardcode the type once for all.
>
> Exactly. For example, MultivalueLinks that model the bidirectional  
> relationships in Fame work at the Pharo level and they do not care about  
> type. The static information is actually only meaningful when we  
> generate code.
>
> Perhaps one option would be to have some sort of optional types for the  
> scenario in which someone would like to maintain these types. Or maybe  
> we find another solution.

>
>>> In any case, I do not necessarily have a predefined solution in my  
>>> head, but I do have requirements. And I would like to spend effort on  
>>> this at least at the level of feedback and prototyping.
>>
>> Ok we do not have either a predefined solution.
>> Now we do not want to focus on interexchange constraints more on  
>> empowering our infrastructure.
>
> That makes sense. That is why I said that I am interested to spend  
> effort :).
>
>
> Cheers,
> Doru
>
>
>
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>> On Nov 26, 2016, at 9:58 AM, stepharo <[hidden email]> wrote:
>>>>
>>>> Hi
>>>>
>>>> What we will try to do with Pavel, alain, anne and me (probably  
>>>> nicolas) in contact with Peter starting january is the following
>>>>
>>>> Define another metametamodel (trying to use Pharo + Slot for  
>>>> relationships + invariant = Pharom)
>>>> - this metameta should be able to have different syntaxes
>>>> OpenPonk, Express, Pharo
>>>> - This metameta should does not need types :) sorry I did not get  
>>>> at all the remark of guillaume
>>>> And in particular there is a difference between a static type and a  
>>>> concrete type systems.
>>>>
>>>>
>>>> Take Famix 3 -> Famix3NG and break it appart to get composable pieces
>>>> and use Pharom to describe FamixNG
>>>>
>>>> We are open to discussions but to a certain extent.
>>>>
>>>> Then we will work on optimise for space.
>>>> In addition we will do a call to collect all the points that should  
>>>> be improve in Moose.
>>>>
>>>> We will
>>>> collect
>>>> prioritze
>>>> and tackle them
>>>>
>>>>
>>>> Stef
>>>
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>>
>>> "Yesterday is a fact.
>>> Tomorrow is a possibility.
>>> Today is a challenge."
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Using Opera's mail client: http://www.opera.com/mail/
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "What we can governs what we wish."
>
>
>
>

> On Nov 26, 2016, at 3:17 PM, stepharo <[hidden email]> wrote:
>
> On Sat, 26 Nov 2016 14:32:16 +0100, Tudor Girba <[hidden email]> wrote:
>
>> Hi,
>>
>>> On Nov 26, 2016, at 2:02 PM, stepharo <[hidden email]> wrote:
>>>
>>> Hi doru
>>>
>>>> Hi,
>>>>
>>>> As I mentioned at ESUG, I am really happy to see this effort, and I will support it. Modeling is an important piece in Moose, and being more flexible at creating new models is a significant added value given that Moose. Please keep me in the loop.
>>>>
>>>> I am particularly interested in the object model of the meta-meta-model, and in the mapping to the Pharo classes that contain the implementation of the meta-model. I believe a Traits-based model would work well (I will try to list my ideas of how this could work later).
>>>>
>>>> Using Slots is definitely something we already should have done in Fame, and I think it will work very well at least on the implementation level of the meta-model.
>>>>
>>>> About syntaxes, I have less predilection for those, but I understand why they can be appealing. I believe that we should first favor Pharo, and only afterwards other DSLs. For example, if we insist of having the meta-model code separately, I believe that we should be able to produce the meta-description also through a fluent API (so, the fluent API is one of the syntaxes). Still, if we express the meta-model separately from the meta-model implementation, the question is remains about how we do the mapping.
>>>
>>> I kind of agree. Now I do not want to people feel that we still their ideas and that
>>> they get stuck with their syntaxes.
>>
>> I think I am missing a part of the picture. What do you mean by “stealing"?
>
> I mean that I would like a solution that openPonk and platypus can use
> and that we can share the same metameta and if they prefer their own syntax that they can use it.
> From a end-user perspective may be usig openPonk or express is nicer than pharo :)

>>>> About types, I also disagree with the comment from Guillaume :). One place where types can be relevant is when producing interfaces for editing objects, but I think that that does not have to be the main driver of the design of the new meta-meta-model. The only thing that I think is important when it comes to types is to allow us to reproduce the basic meta-model implementation in other languages that do rely on rigid static types. For example, right now, Fame generates the relations implementation using this information.
>>>
>>> Yes there is a difference between saying
>>>
>>> - the type of "to" of this relation is Container
>>>
>>> - the type of to of this relation is the class of the object that will be the to of the relation
>>> based on the instantiation of the relation.
>>> It is like anchor-type. you may want to say
>>> this variable is the same type as this one or the same type as whaeveter.
>>> and not hardcode the type once for all.
>>
>> Exactly. For example, MultivalueLinks that model the bidirectional relationships in Fame work at the Pharo level and they do not care about type. The static information is actually only meaningful when we generate code.
>>
>> Perhaps one option would be to have some sort of optional types for the scenario in which someone would like to maintain these types. Or maybe we find another solution.
>
> Yes this is the point or deduce the Type because we rarely want abstract types.
>
>
>
>>
>>>> In any case, I do not necessarily have a predefined solution in my head, but I do have requirements. And I would like to spend effort on this at least at the level of feedback and prototyping.
>>>
>>> Ok we do not have either a predefined solution.
>>> Now we do not want to focus on interexchange constraints more on empowering our infrastructure.
>>
>> That makes sense. That is why I said that I am interested to spend effort :).
>>
>>
>> Cheers,
>> Doru
>>
>>
>>
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>>> On Nov 26, 2016, at 9:58 AM, stepharo <[hidden email]> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> What we will try to do with Pavel, alain, anne and me (probably nicolas) in contact with Peter starting january is the following
>>>>>
>>>>> Define another metametamodel (trying to use Pharo + Slot for relationships + invariant = Pharom)
>>>>> - this metameta should be able to have different syntaxes
>>>>> OpenPonk, Express, Pharo
>>>>> - This metameta should does not need types :) sorry I did not get at all the remark of guillaume
>>>>> And in particular there is a difference between a static type and a concrete type systems.
>>>>>
>>>>>
>>>>> Take Famix 3 -> Famix3NG and break it appart to get composable pieces
>>>>> and use Pharom to describe FamixNG
>>>>>
>>>>> We are open to discussions but to a certain extent.
>>>>>
>>>>> Then we will work on optimise for space.
>>>>> In addition we will do a call to collect all the points that should be improve in Moose.
>>>>>
>>>>> We will
>>>>> collect
>>>>> prioritze
>>>>> and tackle them
>>>>>
>>>>>
>>>>> Stef
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>> www.feenk.com
>>>>
>>>> "Yesterday is a fact.
>>>> Tomorrow is a possibility.
>>>> Today is a challenge."
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Using Opera's mail client: http://www.opera.com/mail/
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "What we can governs what we wish."
>>
>>
>>
>>
>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/

> Aha. Yes, indeed :). I completely agree that we should aim to allow  
> people to use higher level editing tools. I just do not want to lose the  
> ability to keep the mapping to the Pharo level where the real logic is.
>
> A somewhat related parallel that spawns to mind is SmaCC vs PetitParser:
> - SmaCC is a DSL out of which the AST is being generated. One  
> consequence is that the AST nodes are not very smart. For example, there  
> are no specific traversals in the nodes. However, these traversals are  
> achieved through the generic query language which is indeed a nice thing  
> to have. It is possible to add these queries as extensions to the nodes  
> (I do that for some projects), but I did not see it happening too often.  
> Probably the main reason for it being the fact that when you change the  
> name of the AST node class, the extension gets lost.
> - PetitParser allows us to work using the same level of abstraction  
> which is very interesting. What you notice in this case is that the AST  
> trees tend to be smarter and grow their API over time. This is much  
> easier to manage given the integrated refactoring. However, at the same  
> time until now, PetitParser did not produce a generic query language.
>
> I think there are things to learn from both of these worlds. I do not  
> know if this parallel makes sense to you, but to me, the way I see  
> Platypus is more like SmaCC, while the way we work with FAMIX/Fame is  
> more like PetitParser with everything being integrated. Likely, we are  
> missing opportunities due to that focus, but we gain the liveness and  
> this ability of growing the API over time. I think the work on Chef was  
> a very nice thing that showed that we can actually get the best of both  
> worlds.
>
> Now, it would be definitely be very cool to have a way to integrate  
> Pharo logic inside another DSL because this would open the door for a  
> completely different community that we can both learn from and probably  
> offer tools to. Especially, given that now we could also offer a  
> debugger for those kinds of languages. And hopefully soon, we will also  
> offer editing options.
>
> I think this is exciting and definitely worth the investment.