Please find below the latest draft of the MSE format
There is a new mse element, annotations, which can be used twofold
(1) To structure mse files into multiple documents. For example an mse file may contain an @mse header document and both a @metamodel and @model document, or even multiple @version1 @version2 ... documents. The only reserved annotation would be @mse for the leading header document.
So a valid document could eg look like this
@mse ((MSE.File (metamodel 'http://moose.unibe.ch/spec/famix/3.0') (model '@model')) @model ((FAMIX.Package (id: 1) (name 'LAN') (classes (FAMIX.Class ... ... ... ))))
(2) Annotations for elements. Attribute names may start with an @ to indicate an attribute not conforming to the metamodel, for example the longDesc of a Moose measurement, or the category of a Moose meny entry would use this feature. But also the variable indexed slots of Magritte elements.
(MA.Element (name 'ABC') (attr 0.5 0.75 -1 0.2) (@1 'foo') (@2 'bar') (@3 nil) (@4 'qux'))
Also there are two new primitives
- Nil - Datetime
Nil is not to be confused with unset values, which may have a default value different from nil
(... absent = default value (attr ) = default value (attr nil) = nil value (attr "..some..") = some value ...)
Similar to SAX, there is a ParserClient interface for reading MSE documents using callbacks. This interface allows an application to register for MSE document parsing. The sequence of callbacks is limited to the following protocol
MAIN := beginFile ( annotation* beginDocument ELEM* endDocument )* endFile ELEM := beginElement serial? (beginAttribute ( primitive | reference | ELEM )* endAttribute) endElement
which is based on this grammer and tokens
root := fragment | file fragment := elementNode file := document* document := annotation* "(" elementNode* ")" annotation := AT_NAME elementNode := "(" elementName serial? attributeNode* ")" elementName := NAME attributeNode := "(" attributeName valueNode* ")" attributeName := NAME | AT_NAME valueNode := primitive | id-reference | reference | elementNode primitive := STRING | NUMBER | BOOLEAN | DATE | NIL serial := "(" "id:" INTEGER ")" id-reference := "(" "idref:" INTEGER ")" reference := "(" "ref:" NAME ")"
Breaks input-stream into tokens. Accepts the following grammar
Tokens
Open ::= "(" Close ::= ")" AtName ::= "@" ( Letter | Digit )+ Keyword ::= "id:" | "idref:" | "ref:" Name ::= Letter ( Letter | Digit )* ( "." ( Letter | Digit )+ )* String ::= ( "'" [ˆ']* "'" )+ Boolean ::= "true" | "false" Nil ::= "nil" Date ::= Digit{4} "-" Digit{2} "-" Digit{2} ( "," Digit{2} ":" Digit{2} ":" Digit{2} ) Number ::= "-"? Digit+ ( "." Digit+ )? ( "e" ( "-"? Digit+ ))?
Terminals
Digit ::= [0-9] Letter ::= [a-zA-Z_]
Whitespace
Whitespace ::= Space Tab ecetera... Comment ::= """ [ˆ"] """
----
What do you think? AA
On 8 Dec 2007, at 0:17 , Adrian Kuhn wrote:
root := fragment | file fragment := elementNode file := document* document := annotation* "(" elementNode* ")" annotation := AT_NAME
Me again, this should have been
root := fragment | document | file file := "@mse" document ( documentName document )* documentName := AT_NAME document := "(" elementNode* ")" fragment := elementNode
AA
On 8 déc. 07, at 00:17, Adrian Kuhn wrote:
Please find below the latest draft of the MSE format
There is a new mse element, annotations, which can be used twofold
(1) To structure mse files into multiple documents.
do we want that? because we will have to uniquely identify the metamodel associated with a model? How do we distinguish versions? because there is a number in the tag?
For example an mse file may contain an @mse header document and both a @metamodel and @model document, or even multiple @version1 @version2 ... documents. The only reserved annotation would be @mse for the leading header document.
So a valid document could eg look like this
@mse ((MSE.File (metamodel 'http://moose.unibe.ch/spec/famix/3.0') (model '@model'))
we had something similar in CDIF and never used it for validation :)
@model ((FAMIX.Package (id: 1) (name 'LAN') (classes (FAMIX.Class ... ... ... ))))
(2) Annotations for elements. Attribute names may start with an @ to indicate an attribute not conforming to the metamodel, for example the longDesc of a Moose measurement, or the category of a Moose meny entry would use this feature. But also the variable indexed slots of Magritte elements.
(MA.Element (name 'ABC') (attr 0.5 0.75 -1 0.2) (@1 'foo') (@2 'bar') (@3 nil) (@4 'qux'))
Also there are two new primitives
- Nil
- Datetime
Nil is not to be confused with unset values, which may have a default value different from nil
I see.
(... absent = default value (attr ) = default value (attr nil) = nil value (attr "..some..") = some value ...)
ok above defaultValue means nil in Smalltalk?
Similar to SAX, there is a ParserClient interface for reading MSE documents using callbacks. This interface allows an application to register for MSE document parsing.
cool
The sequence of callbacks is limited to the following protocol
MAIN := beginFile ( annotation* beginDocument ELEM* endDocument )* endFile ELEM := beginElement serial? (beginAttribute ( primitive | reference | ELEM )* endAttribute) endElement
which is based on this grammer and tokens
root := fragment | file fragment := elementNode file := document* document := annotation* "(" elementNode* ")" annotation := AT_NAME elementNode := "(" elementName serial? attributeNode* ")" elementName := NAME attributeNode := "(" attributeName valueNode* ")" attributeName := NAME | AT_NAME valueNode := primitive | id-reference | reference | elementNode primitive := STRING | NUMBER | BOOLEAN | DATE | NIL serial := "(" "id:" INTEGER ")" id-reference := "(" "idref:" INTEGER ")" reference := "(" "ref:" NAME ")"
Breaks input-stream into tokens. Accepts the following grammar
Tokens
Open ::= "(" Close ::= ")" AtName ::= "@" ( Letter | Digit )+ Keyword ::= "id:" | "idref:" | "ref:" Name ::= Letter ( Letter | Digit )* ( "." ( Letter | Digit )
- )* String ::= ( "'" [ˆ']* "'" )+ Boolean ::= "true" | "false" Nil ::= "nil" Date ::= Digit{4} "-" Digit{2} "-" Digit{2} ( "," Digit{2}
":" Digit{2} ":" Digit{2} ) Number ::= "-"? Digit+ ( "." Digit+ )? ( "e" ( "-"? Digit+ ))?
Terminals
Digit ::= [0-9] Letter ::= [a-zA-Z_]
Whitespace
Whitespace ::= Space Tab ecetera... Comment ::= """ [ˆ"] """
What do you think? AA
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
(1) To structure mse files into multiple documents.
do we want that? because we will have to uniquely identify the metamodel associated with a model? How do we distinguish versions? because there is a number in the tag?
I am not sure what exactly was meant in this part. The title seems to say something different from the body. Me and Doru have had a small discussion about external files (what I understand from the title) and loading in files which you might need at some point to reference to types etc outside the scope of files. In order for this to work, idref:-s need to be consistent in some way. So we thought of something like: (MSE.File (filename: "....") (id: "...")) which allows you then to ref over files (idref: <fileid>.<objectid>) or local refs: (idref: <objectid>). This is similar to how imports are handled in Python. In order to fix diamond-shaped loadings etc, the absolute filename has to be used inside readers instead of <fileid> to distinguish objects.
@mse ((MSE.File (metamodel 'http://moose.unibe.ch/spec/famix/3.0') (model '@model'))
we had something similar in CDIF and never used it for validation :)
It would be handy however... this would allow us to generate code in case the classes belonging to it are not there yet :)
(... absent = default value (attr ) = default value (attr nil) = nil value (attr "..some..") = some value ...)
ok above defaultValue means nil in Smalltalk?
Default value in smalltalk means what the class puts as default value in "initialize" I guess. This would be the smalltalk variant of what I am currently doing in Python.
Toon
On 8 Dec 2007, at 14:54 , Toon Verwaest wrote:
(... absent = default value (attr ) = default value (attr nil) = nil value (attr "..some..") = some value ...)
ok above defaultValue means nil in Smalltalk?
Default value in smalltalk means what the class puts as default value in "initialize" I guess. This would be the smalltalk variant of what I am currently doing in Python.
Default value for booleans is false and for numbers it is 0, see FM3 (draft) spec.
Currently FM3 does not allow other default, question is if we really need that, as we have no usecase yet. @Lukas, how is it in Magritte? Defaults for primitve attributes are straight forward, whereas default values for other attributes lead into the whole meta-behavior mess...
AA
Currently FM3 does not allow other default, question is if we really need that, as we have no usecase yet. @Lukas, how is it in Magritte? Defaults for primitve attributes are straight forward, whereas default values for other attributes lead into the whole meta-behavior mess...
I would default values to be class-defined... For boolean = False is ok for our purpose with Famix (that's then also where it came from, me noticing that there were too many false's in the text), but this is not really a good solution for all situations. Lukas already told me that his default value for some booleans where true. I really think that (since for the files itself it doesn't really matter) it would be better to have some "default" tag in fm3-specified documents, so you can customize. (equivalent is the body of the initialize)
Currently FM3 does not allow other default, question is if we really need that, as we have no usecase yet. @Lukas, how is it in Magritte?
In Magritte default values are nil by default, also for numbers and booleans. Attributes can have a different default value. As Toon explained I have examples where the default value for a boolean is true or the one for a number is 17 ;-)
Cheers, Lukas
Hi,
The main use case in Magritte for the nil initial value is that you want to distinguish between something that is specifically set and something that is not. The same use case we would have for distinguishing between the case when a parser could not say about a class that it isAbstract and another case when it could say that it is not.
The other use case is when we could not compute some metric for some reason.
I think, these are good use cases.
On the other hand, I do not like that a Boolean can have 3 values because this hinders later on the queries and proliferates guard conditions (which is a pain). So, if we take this road, then I would like to have an ExtendedBoolean and an ExtendedNumber that deal with the special cases.
But, somehow I would rather go for the simplest case when we do not allow such undecided values, because this puts more pressure on the parsers to produce better results.
Doru
On Dec 8, 2007, at 5:03 PM, Lukas Renggli wrote:
Currently FM3 does not allow other default, question is if we really need that, as we have no usecase yet. @Lukas, how is it in Magritte?
In Magritte default values are nil by default, also for numbers and booleans. Attributes can have a different default value. As Toon explained I have examples where the default value for a boolean is true or the one for a number is 17 ;-)
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"It's not what we do that matters most, it's how we do it."
I shoud say that I do not really understand the goal of what you are doing. Using Famix for code generation? representing parser results? I have the impression that when you have a boolean and the parser give you nil then you know that this is not the value but unknown. May be this is what you do not like doru (I got confused). But the isKnown was the solution to this problem at that ancient time :)
Stef
Hi,
The main use case in Magritte for the nil initial value is that you want to distinguish between something that is specifically set and something that is not. The same use case we would have for distinguishing between the case when a parser could not say about a class that it isAbstract and another case when it could say that it is not.
The other use case is when we could not compute some metric for some reason.
I think, these are good use cases.
On the other hand, I do not like that a Boolean can have 3 values because this hinders later on the queries and proliferates guard conditions (which is a pain). So, if we take this road, then I would like to have an ExtendedBoolean and an ExtendedNumber that deal with the special cases.
But, somehow I would rather go for the simplest case when we do not allow such undecided values, because this puts more pressure on the parsers to produce better results.
Doru
On Dec 8, 2007, at 5:03 PM, Lukas Renggli wrote:
Currently FM3 does not allow other default, question is if we really need that, as we have no usecase yet. @Lukas, how is it in Magritte?
In Magritte default values are nil by default, also for numbers and booleans. Attributes can have a different default value. As Toon explained I have examples where the default value for a boolean is true or the one for a number is 17 ;-)
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"It's not what we do that matters most, it's how we do it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Stéphane Ducasse wrote:
I shoud say that I do not really understand the goal of what you are doing. Using Famix for code generation? representing parser results? I have the impression that when you have a boolean and the parser give you nil then you know that this is not the value but unknown. May be this is what you do not like doru (I got confused). But the isKnown was the solution to this problem at that ancient time :)
Stef
Mmmmh... I can't say that I really like the "isKnown" solution.
The idea of our talk (at least my side) is that if default values -are- primitive values; we might as well include them in the FAMIX.fm3.mse specification. This would allow code generation in different platforms to actually write the correct initialization for those values. And then famix-files would be allowed to omit values which are the default ones. As we saw for famix specified in fm3 where we specified default values (Adrian got a bit mixed up and reused these default values also for other metamodels); this shortens the length of some files quite a lot. (and reduces the time needed for parsing and initializing obviously...)
Toon
On 10 déc. 07, at 11:19, Toon Verwaest wrote:
Stéphane Ducasse wrote:
I shoud say that I do not really understand the goal of what you are doing. Using Famix for code generation? representing parser results? I have the impression that when you have a boolean and the parser give you nil then you know that this is not the value but unknown. May be this is what you do not like doru (I got confused). But the isKnown was the solution to this problem at that ancient time :)
Stef
Mmmmh... I can't say that I really like the "isKnown" solution.
without a metamodel it was good enough.
The idea of our talk (at least my side) is that if default values - are- primitive values; we might as well include them in the FAMIX.fm3.mse specification.
But how can you make sure that these default values are the same in all the languages. Is it the importer that will do the mapping? I did that in CDIF converting idiot -TRUE- into true and this is boring and slowing everything. So mse will be slower or mse will favor a language (if this is Smalltalk this is ok too).
now if the default value is a boolean, will I get true or nil if in the model it was not set?
This would allow code generation in different platforms to actually write the correct initialization for those values.
I know I did that in 2000 for the DomainGenerator we never used. But this was fun to do that just to learn that old MOF way of representing relationship was crap and created overly complex queries for code generation.
And then famix-files would be allowed to omit values which are the default ones. As we saw for famix specified in fm3 where we specified default values (Adrian got a bit mixed up and reused these default values also for other metamodels); this shortens the length of some files quite a lot. (and reduces the time needed for parsing and initializing obviously...)
Toon _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
But how can you make sure that these default values are the same in all the languages.
This is equivalent to how all primitive values are set. If you have an attribute and you want to give it a value; you always need to translate the text in a way so that the language interpreting it understands it. "preferring a language" is not really relevant since you will probably always read it as a token first and then change tokens into actual values. The standard way of writing parsers.
Is it the importer that will do the mapping? I did that in CDIF converting idiot -TRUE- into true and this is boring and slowing everything.
As said before; this does -not- slow -anything- down. You always have to do that. If you write "true" in your workspace in Visualworks or whatever you use; you also have to read and parse this. It's not because it looks like the language does this automagically that your smalltalk does not read and parse it anyway.
So mse will be slower or mse will favor a language (if this is Smalltalk this is ok too).
So this is an invalid argument. See above.
now if the default value is a boolean, will I get true or nil if in the model it was not set?
If no default is specified, this will be the default "unset" value of the language in question. In python this will be None, in java this will be null or 0 for int or false for boolean. For ...... and smalltalk this will be nil.
This would allow code generation in different platforms to actually write the correct initialization for those values.
I know I did that in 2000 for the DomainGenerator we never used. But this was fun to do that just to learn that old MOF way of representing relationship was crap and created overly complex queries for code generation.
Adrian implemented a code generator for FM3, I just finished doing the same in python, I also already have an mse-reader + writer in scheme; next week I will implement this in Smalltalk; and we use this to generate the FAMIX3.0 code so that they automatically support opposites with One/Many(for the one->one->many->many relations). Now we are working on a draft of the specification of MSE and FM3 in cooperation with Lukas.
FAME implementations available (for java and python) at: https://www.iam.unibe.ch/scg/svn_repos/Sources/Famix
cheers, Toon
FAME implementations available (for java and python) at: https://www.iam.unibe.ch/scg/svn_repos/Sources/Famix
The MSE implementation for Squeak, that also features a Magritte plug-in, is available at: http://source.lukas-renggli.ch/mse
Lukas
Hi lukas,
do you parse mse? or generate it because I did a mse exporter to save all the version of seaside last year.
MCHttpRepository location: 'http://www.squeaksource.com/MSE' user: '' password: ''
did you rewrite everything? Which version of mse are you supporting? I wrote that code for the first version of mse and know I do not understand anything.
Stef
FAME implementations available (for java and python) at: https://www.iam.unibe.ch/scg/svn_repos/Sources/Famix
The MSE implementation for Squeak, that also features a Magritte plug-in, is available at: http://source.lukas-renggli.ch/mse
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Stef,
Your code was about generating the MSE for FAMIX entities.
Lukas' implementation is about having an import/export for any objects based on meta-descriptions (like the one in VW). For example, he can use the Magritte descriptions.
One of the goals was to build a format for storing Pier in text files, so with this occasion we reused a bit the effort :).
Cheers, Doru
On Dec 11, 2007, at 2:23 PM, Stéphane Ducasse wrote:
Hi lukas,
do you parse mse? or generate it because I did a mse exporter to save all the version of seaside last year.
MCHttpRepository location: 'http://www.squeaksource.com/MSE' user: '' password: ''
did you rewrite everything? Which version of mse are you supporting? I wrote that code for the first version of mse and know I do not understand anything.
Stef
FAME implementations available (for java and python) at: https://www.iam.unibe.ch/scg/svn_repos/Sources/Famix
The MSE implementation for Squeak, that also features a Magritte plug-in, is available at: http://source.lukas-renggli.ch/mse
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"Obvious things are difficult to teach."
I see.
I could not check the code because I had no internet access in a bad room with no plug during the complete day.
Stef
On 11 déc. 07, at 19:10, Tudor Girba wrote:
Hi Stef,
Your code was about generating the MSE for FAMIX entities.
Lukas' implementation is about having an import/export for any objects based on meta-descriptions (like the one in VW). For example, he can use the Magritte descriptions.
cool I'm interested since I did a stupid exporting based on magritte for my comix app but I was too lazy to do the rest.
I was planning to use Sixx but the xml part was pushing me away
One of the goals was to build a format for storing Pier in text files, so with this occasion we reused a bit the effort :).
E x c e l l e n t
Stef
Cheers, Doru
On Dec 11, 2007, at 2:23 PM, Stéphane Ducasse wrote:
Hi lukas,
do you parse mse? or generate it because I did a mse exporter to save all the version of seaside last year.
MCHttpRepository location: 'http://www.squeaksource.com/MSE' user: '' password: ''
did you rewrite everything? Which version of mse are you supporting? I wrote that code for the first version of mse and know I do not understand anything.
Stef
FAME implementations available (for java and python) at: https://www.iam.unibe.ch/scg/svn_repos/Sources/Famix
The MSE implementation for Squeak, that also features a Magritte plug-in, is available at: http://source.lukas-renggli.ch/mse
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"Obvious things are difficult to teach."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Stef,
Your code was about generating the MSE for FAMIX entities.
Lukas' implementation is about having an import/export for any objects based on meta-descriptions (like the one in VW). For example, he can use the Magritte descriptions.
One of the goals was to build a format for storing Pier in text files, so with this occasion we reused a bit the effort :).
Cheers, Doru
On Dec 11, 2007, at 2:23 PM, Stéphane Ducasse wrote:
Hi lukas,
do you parse mse? or generate it because I did a mse exporter to save all the version of seaside last year.
MCHttpRepository location: 'http://www.squeaksource.com/MSE' user: '' password: ''
did you rewrite everything? Which version of mse are you supporting? I wrote that code for the first version of mse and know I do not understand anything.
Stef
FAME implementations available (for java and python) at: https://www.iam.unibe.ch/scg/svn_repos/Sources/Famix
The MSE implementation for Squeak, that also features a Magritte plug-in, is available at: http://source.lukas-renggli.ch/mse
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"Obvious things are difficult to teach."
Hi Stef,
do you parse mse?
yes, both. I wrote a generic reader and a generic writer.
or generate it because I did a mse exporter to save all the version of seaside last year.
I know that code. The goal of my implementation is a bit different, it does not (necessarily) generate output to be consumed by FAMIX.
Which version of mse are you supporting?
I think the version from Monday, but frankly it is quite a mess with these versions lately. The parser is based on SmaCC so I can fairly quick adopt it, if necessary.
I wrote that code for the first version of mse and know I do not understand anything.
What? I don't get it ;-)
Let me explain what I did:
- I wrote a generic MSEParser. You give it a valid MSE string and it will return you a graph of Associations, OrderedCollection, and Dictionaries. That's the default and directly maps to the MSE structure. Obviously this is not really useful. Now it is possible to subclass MSEParser and override some hock methods that allow you to instantiate and build 'real' objects. How you instantiate and initialize your real objects is up to you or your meta-model. I've written such parsers for Magritte and for the Smalltalk object model.
- I wrote a generic MSEWriter. You give it a tree of objects and it writes everything out as a graph. Again the default implementation is totally stupid, but you can subclass it to tell the engine how to traverse your objects and what to serialize. I've done this for Magritte and the Smalltalk object model.
So for me this is merely a way to serialize objects (e.g. for Pier). This is not much different than what SIXX, JSON, or Hessian are already doing, except that I can combine it nicely with any read/write strategy. Of course it would also be possible to enable it to read/write FAMIX models, but I did not do that right now.
For example:
MSESmalltalkWriter write: 1 @ #( 'mse' 1.1 $a $a ) asOrderedCollection. '(Point (id: 1) (x 1) (y (OrderedCollection (id: 2) (array (Array (id: 3) (_var ''mse'' (Character (id: 4) (value 97)) (idref: 4)))) (firstIndex 1) (lastIndex 3))))'
Parsing back that string I get the same object as I wrote out.
Cheers, Lukas
But how can you make sure that these default values are the same in all the languages.
This is equivalent to how all primitive values are set. If you have an attribute and you want to give it a value; you always need to translate the text in a way so that the language interpreting it understands it. "preferring a language" is not really relevant since you will probably always read it as a token first and then change tokens into actual values. The standard way of writing parsers.
Thanks for the lesson. (Toon could you consider that even if I ask extremely naive (or looking naive) question I'm not totally brainwashed, at least I believe so let me with my dreams.)
Apparently this is no what I understood from the first mse format. Adrian's first implementation used a literal array representation just to avoid to do the -TRUE- to true kind of conversion. Adrian can you comment on that?
Is it the importer that will do the mapping? I did that in CDIF converting idiot -TRUE- into true and this is boring and slowing everything.
As said before; this does -not- slow -anything- down. You always have to do that. If you write "true" in your workspace in Visualworks or whatever you use; you also have to read and parse this. It's not because it looks like the language does this automagically that your smalltalk does not read and parse it anyway.
I do not think that this is right :) but again I'm probably really naive about compiler and parsers. At least when the Smalltalk parser parses a literal array, it creates literal objects at compile-time and you do not have to do another translation. You sound really strong on your claim. I would really like that you show me that we are not losing more time with the translation approach.
'#(true nil (x true true false))' versus '-TRUE- NIL (X -TRUE- -TRUE- -FALSE-)'
Because I faced that in CDIF. But since I could not change CDIF I had to live with that. I had the impression that mse format was just to avoid the verbosity of XML and also the translation of such information. Now this is not a problem if the importer of moose gets slow. I was just asking this question for curiosity.
So mse will be slower or mse will favor a language (if this is Smalltalk this is ok too).
So this is an invalid argument. See above.
now if the default value is a boolean, will I get true or nil if in the model it was not set?
If no default is specified, this will be the default "unset" value of the language in question. In python this will be None, in java this will be null or 0 for int or false for boolean. For ...... and smalltalk this will be nil.
This would allow code generation in different platforms to actually write the correct initialization for those values.
I know I did that in 2000 for the DomainGenerator we never used. But this was fun to do that just to learn that old MOF way of representing relationship was crap and created overly complex queries for code generation.
Adrian implemented a code generator for FM3, I just finished doing the same in python, I also already have an mse-reader + writer in scheme; next week I will implement this in Smalltalk; and we use this to generate the FAMIX3.0 code so that they automatically support opposites with One/Many(for the one->one->many->many relations). Now we are working on a draft of the specification of MSE and FM3 in cooperation with Lukas.
FAME implementations available (for java and python) at: https://www.iam.unibe.ch/scg/svn_repos/Sources/Famix
cheers, Toon _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 11 Dec 2007, at 17:27 , Stéphane Ducasse wrote:
Apparently this is no what I understood from the first mse format. Adrian's first implementation used a literal array representation just to avoid to do the -TRUE- to true kind of conversion. Adrian can you comment on that?
The first prototype re-used the Smalltalk parser, right. Now we use a custom scanner / parser as this is faster.
cheers, AA
Apparently this is no what I understood from the first mse format. Adrian's first implementation used a literal array representation just to avoid to do the -TRUE- to true kind of conversion. Adrian can you comment on that?
The first prototype re-used the Smalltalk parser, right. Now we use a custom scanner / parser as this is faster.
Just because I would like to know for Squeak potential speed. Why was the VW parser slower? what kind of optimizations did you use?
Stef
On 12 Dec 2007, at 9:34 , Stéphane Ducasse wrote:
Apparently this is no what I understood from the first mse format. Adrian's first implementation used a literal array representation just to avoid to do the -TRUE- to true kind of conversion. Adrian can you comment on that?
The first prototype re-used the Smalltalk parser, right. Now we use a custom scanner / parser as this is faster.
Just because I would like to know for Squeak potential speed. Why was the VW parser slower? what kind of optimizations did you use?
The intermediate literal array falls away, now its
Text -> Parser -> some logic -> model objects
using Smalltalk parser its
Text -> Parser -> intermediate array -> some logic -> model objects
I guess Lukas's parser is the fastest you can get
AA
On (12/12/07 21:01), Adrian Kuhn wrote:
From: Adrian Kuhn akuhn@gmx.ch To: Related to the development of Moose and other related tools moose-dev@iam.unibe.ch Subject: [Moose-dev] Re: MSE Format, latest draft Date: Wed, 12 Dec 2007 21:01:15 +0100
On 12 Dec 2007, at 9:34 , Stéphane Ducasse wrote:
Apparently this is no what I understood from the first mse format. Adrian's first implementation used a literal array representation just to avoid to do the -TRUE- to true kind of conversion. Adrian can you comment on that?
The first prototype re-used the Smalltalk parser, right. Now we use a custom scanner / parser as this is faster.
Just because I would like to know for Squeak potential speed. Why was the VW parser slower? what kind of optimizations did you use?
The intermediate literal array falls away, now its
Text -> Parser -> some logic -> model objects
using Smalltalk parser its
Text -> Parser -> intermediate array -> some logic -> model objects
I guess Lukas's parser is the fastest you can get
Unless you are "crazy" enough to do manual tweakings :D Which is not even sure to speed up the process anyway...
My question was can we reuse what you did to speed up the default Squeak Smalltalk parser. But I get that you speed up the mse one.
Stef
On 12 déc. 07, at 21:01, Adrian Kuhn wrote:
On 12 Dec 2007, at 9:34 , Stéphane Ducasse wrote:
Apparently this is no what I understood from the first mse format. Adrian's first implementation used a literal array representation just to avoid to do the -TRUE- to true kind of conversion. Adrian can you comment on that?
The first prototype re-used the Smalltalk parser, right. Now we use a custom scanner / parser as this is faster.
Just because I would like to know for Squeak potential speed. Why was the VW parser slower? what kind of optimizations did you use?
The intermediate literal array falls away, now its
Text -> Parser -> some logic -> model objects
using Smalltalk parser its
Text -> Parser -> intermediate array -> some logic -> model objects
I guess Lukas's parser is the fastest you can get
AA
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Apparently this is no what I understood from the first mse format. Adrian's first implementation used a literal array representation just to avoid to do the -TRUE- to true kind of conversion. Adrian can you comment on that?
The first prototype re-used the Smalltalk parser, right. Now we use a custom scanner / parser as this is faster.
ok if you have your dedicated scanner then this is different. I thought that you reused the one of Smalltalk. The original CDIF one used the one of Smalltalk since serge did not use Smacc.
Stef
Me too, I subclass from Scanner (see yourself Meta.MSEParser)
AA
On 13 Dec 2007, at 15:35 , Stéphane Ducasse wrote:
Apparently this is no what I understood from the first mse format. Adrian's first implementation used a literal array representation just to avoid to do the -TRUE- to true kind of conversion. Adrian can you comment on that?
The first prototype re-used the Smalltalk parser, right. Now we use a custom scanner / parser as this is faster.
ok if you have your dedicated scanner then this is different. I thought that you reused the one of Smalltalk. The original CDIF one used the one of Smalltalk since serge did not use Smacc.
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 11 Dec 2007, at 17:27 , Stéphane Ducasse wrote:
At least when the Smalltalk parser parses a literal array, it creates literal objects at compile-time and you do not have to do another translation.
It reads a string and then does string == "true" ifTrue: [ ^true ] same for nil false etc. No magic in there, Toon is right.
AA
Thanks for the lesson. (Toon could you consider that even if I ask extremely naive (or looking naive) question I'm not totally brainwashed, at least I believe so let me with my dreams.)
I did not mean to do no harm.
Apparently this is no what I understood from the first mse format. Adrian's first implementation used a literal array representation just to avoid to do the -TRUE- to true kind of conversion. Adrian can you comment on that?
So here... I guess this is just that ... the closer a syntax is to the syntax of the (mainly) used language itself; the easier it is to read and parse it. (Here easier refers to the amount of work for the programmer; not for the machine).
If you look at an MSE-file without any MSE-strings in it (since they are "smalltalk-optimized"); you could just open a scheme-evaluator and evaluate it as a list (by just putting a ' in front of it). Then scheme does all the parsing work for you since it just looks exactly the same as what normal scheme lists would look like. Numbers are read probably since scheme uses the same kind of numbers; names are scheme-symbols... and if you don't use '' inside a string to denote '; even strings are read properly like it should. However; true and false are read as symbols true and false instead of the boolean values. Whereas, if the booleans would be #t and #f in the fileformat; this would automatically yield the scheme-true and scheme-false after read-evalling the list. And here the same holds for Smalltalk I guess; if you put # in front of an mse-expression; it just looks like an Array. And smalltalk does all the "hard" work for you.
Actually; when I did my first scheme-mse-reader; I just did some basic string-translations on the document which changed true and false into #t and #f; and those strings ('[^']*')+ into things with """. Then I just read it as a list. In order to then "parse" it; I don't have to think about "tokens" etc etc; I just traverse a scheme-list in normal recursion.
I hope that this clarifies your question?
cheers, and now really of to bed :) Toon
Currently FM3 does not allow other default, question is if we really need that, as we have no usecase yet. @Lukas, how is it in Magritte?
In Magritte default values are nil by default, also for numbers and booleans. Attributes can have a different default value. As Toon explained I have examples where the default value for a boolean is true or the one for a number is 17 ;-)
Do you have non-primitive or non-constant, ie derived, default values?
In general, default values do not fit well into a meta-layer architecture, as a value of the model level is to be specified at the meta-level. A default value can be constant or derived and primitive or non-primitive, of these cases only constant primitive default values fit well with a meta-layer architecture.
All other cases require an expression written in a query language. Which is maybe better to be post-poned for a later release of FM3, we should first get the simple stuff right.
AA
In general, default values do not fit well into a meta-layer architecture, as a value of the model level is to be specified at the meta-level. A default value can be constant or derived and primitive or non-primitive, of these cases only constant primitive default values fit well with a meta-layer architecture.
For other cases we could currently just specify the same as what we do for derived but non-opposite attributes and the methods we generate for them. => raise NotImplementedError() #This is a stub-method. We want to give as much support for automation as possible, but where impossible to do without the current mse-suport; the programmer has to fill in the blanks in the generated code.
As far as I see default values declarations are only important for code generation. For all other cases; you just use what's in the "initialize" as default value.
I wouldn't immediately start providing support for other things by means of a query language; this would convert the fileformat MSE into a language of its own (which is then translatable to all the other languages which use MSE???) which is also not the purpose I guess.
I do not understand why you want to put a default value for languages where you cannot know it.
(... absent = default value (attr ) = default value (attr nil) = nil value (attr "..some..") = some value ...)
ok above defaultValue means nil in Smalltalk?
Default value in smalltalk means what the class puts as default value in "initialize" I guess. This would be the smalltalk variant of what I am currently doing in Python.
Default value for booleans is false and for numbers it is 0, see FM3 (draft) spec.
Currently FM3 does not allow other default, question is if we really need that, as we have no usecase yet. @Lukas, how is it in Magritte? Defaults for primitve attributes are straight forward, whereas default values for other attributes lead into the whole meta-behavior mess...
AA
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
The underlying question is aren;t you redoing yet another XMI XLink... stuff. and ow mcuh are you reusing from their design because may there is something to learn from their approach (besides dropping XML).
stef On 8 déc. 07, at 14:54, Toon Verwaest wrote:
(1) To structure mse files into multiple documents.
do we want that? because we will have to uniquely identify the metamodel associated with a model? How do we distinguish versions? because there is a number in the tag?
I am not sure what exactly was meant in this part. The title seems to say something different from the body. Me and Doru have had a small discussion about external files (what I understand from the title) and loading in files which you might need at some point to reference to types etc outside the scope of files. In order for this to work, idref:-s need to be consistent in some way. So we thought of something like: (MSE.File (filename: "....") (id: "...")) which allows you then to ref over files (idref: <fileid>.<objectid>) or local refs: (idref: <objectid>). This is similar to how imports are handled in Python. In order to fix diamond-shaped loadings etc, the absolute filename has to be used inside readers instead of <fileid> to distinguish objects.
@mse ((MSE.File (metamodel 'http://moose.unibe.ch/spec/famix/3.0') (model '@model'))
we had something similar in CDIF and never used it for validation :)
It would be handy however... this would allow us to generate code in case the classes belonging to it are not there yet :)
(... absent = default value (attr ) = default value (attr nil) = nil value (attr "..some..") = some value ...)
ok above defaultValue means nil in Smalltalk?
Default value in smalltalk means what the class puts as default value in "initialize" I guess. This would be the smalltalk variant of what I am currently doing in Python.
Toon _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Adrian Kuhn -
Lukas Renggli -
Stéphane Ducasse -
Toon Verwaest -
Toon Verwaest -
Tudor Girba