Issue 12214: Section Allocation: Wrong direction of the allocation (marte-ftf) Source: INRIA (Dr. Frederic Mallet, Frederic.Mallet(at)inria.fr) Nature: Revision Severity: Minor Summary: Wrong direction of the allocation: The MARTE allocation mechanism is directly inspired from SysML. SysML has chosen a convention contrary to UML and draws the arrow from the suppliers (usually a target) to the clients (usually a source). So as to be compatible MARTE has followed SysML with that convention. Now, the SysML RTF is considering that this triggers too many problems with tool vendors and thus considers using the same convention than UML. An alignment between SysML and MARTE is required as much as possible and MARTE FTF should then think through this issue and adopt the same convention than UML. Resolution: The only text that was wrong has been removed in the resolution for issue 11770. The new text in this resolution assumed that sources are referred as clients and targets are referred as suppliers. This resolution has no impact on any other section since the wrong "direction" was only in the vocabulary used (clients vs. suppliers) and the graphical notation was already correct. Revised Text: See resolution for issue 11770 for details. Actions taken: February 7, 2008: received issue February 17, 2010: closed issue Discussion: End of Annotations:===== te: Mon, 4 Feb 2008 10:42:55 -0500 (EST) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: issues@omg.org Subject: using $ in naming variables This editing issue affects many chapters. In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name. Throughout the document there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning. Examples are found in NFP (Fig 8.9) and many other chapters. These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement. In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca Subject: Issue 12209: using $ in naming variables (and variable calls) Date: Mon, 18 Feb 2008 17:32:55 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 12209: using $ in naming variables (and variable calls) thread-index: AchyS+m+70M/GUXFSlyzl5r5B+qIGA== From: "ESPINOZA Huascar 218344" To: X-OriginalArrivalTime: 18 Feb 2008 16:32:55.0324 (UTC) FILETIME=[E9F3C5C0:01C8724B] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m1IGXjg0006295 Hi all, Issue 12209 (see below) relates to using '$' not only in variable declaration but also in 'variable call expressions' has been uploaded in the MARTE FTF wiki. Source: Murray Woodside. http://www.omgwiki.org/marte/lib/exe/fetch.php?id=annex_b_wg&cache=cache&media=12209_closednochange_ballot1.doc I'd like to clarify that at this point we (Hauscar and Séb Demathieu) don't concur in a common resolution with Murray (you'll find the Murray' argumentation at the end of this email). However, I'm providing this initial resolution (closed no change) to open discussion in the mailing list. Please let me know you opinion. Regards, -- Huascar ESPINOZA, Ph.D. CEA Saclay DRT/DTSI/SOL/LISE 91191 GIF/YVETTE CEDEX Phone/Fax: +33 1 69 08 45 87 / 20 82 France ___ Disposition: Closed, no change OMG Issue No: 12209 Title: using $ in naming variables (and variable calls) Source: Carleton University (Dr. Murray Woodside, cmw@sce.carleton.ca) Summary: In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name. Throughout the document there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning. Examples are found in NFP (Fig 8.9) and many other chapters. These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement. In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples. Resolution: There are two kinds of VSL expressions related to variables: 'variable declaration' and 'variable call'. In VSL, we use '$' as a prefix only in the declaration notation, and in the 'call', we use only the name. We really need to make difference between both because VSL parsers need to make the difference. It's true that having a distinctive symbol for 'variable call' different than other 'names' in a VSL expression 'names', such as enumeration literals or PropertyCallExpression, would help to a fast awareness of VSL variable calls. However, some reasons would suggest avoiding such a modification: -Using only the name for both variables and property call expressions is also used by OCL, and there were not reported any issue related to confusing impressions for language users. -In MARTE, most of VSL variable expressions are used at "declaration" level, because in a regular NFP tuple, the value resulting from the evaluation of an expression or variable is specified in a dedicated slot ("value"). This means that VariableCallExpressions are mainly used in Algebraic (math, logical, conditional) expressions, where having a transparent syntax in terms of "parameters" either coming from a UML Property or VSL Variable origin is desirable to avoid complexity in VSL expressions. -Having simple and short expressions is a main concern in VSL to embed them in graphical models without charging models, and for easy learning of the language. For these reasons, we suggest to close this issue with no change. Disposition: Closed, no change Murray's counterposition: -----Message d'origine----- De : Murray Woodside [mailto:cmw@sce.carleton.ca] Envoyé : jeudi 14 février 2008 13:06 À : ESPINOZA Huascar 218344 Cc : Sébastien Demathieu Objet : Re: Issue 12209 - Use of '$' in variables Using a different name (with a prefix $) in the declaration is an uncomfortable solution for making the declaration distinct. Better would be to change the statement, for instance the declaration could have two == signs. Using a $ everywhere reminds a reader that this is a parameter, an NFP, rather than the name of an object. there are so many names in a ndesign, and parameters introduce many many more. I have found that remembering to use a different name in the declaration leads to constant errors. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) Subject: RE: Issue 12209: using $ in naming variables (and variable calls) Date: Mon, 18 Feb 2008 16:44:08 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 12209: using $ in naming variables (and variable calls) Thread-Index: AchyS+m+70M/GUXFSlyzl5r5B+qIGAAAZGKc From: "VanZandt, Lonnie" To: "ESPINOZA Huascar 218344" , Because the VSL is not any arbitrary opaque expression but is specified with a formal grammar, I concur that we do not want to require the $ token in the variable call expressions. Lonnie VanZandt Field Applications Engineer Denver, CO Artisan Software Tools mobile: 720 201-1349 desk: 303 482-2943 lonnie.vanzandt@artisansw.com -------------------------------------------------------------------------------- From: ESPINOZA Huascar 218344 [mailto:Huascar.ESPINOZA@cea.fr] Sent: Mon 2/18/2008 9:32 AM To: marte-ftf@omg.org Subject: Issue 12209: using $ in naming variables (and variable calls) Hi all, Issue 12209 (see below) relates to using '$' not only in variable declaration but also in 'variable call expressions' has been uploaded in the MARTE FTF wiki. Source: Murray Woodside. http://www.omgwiki.org/marte/lib/exe/fetch.php?id=annex_b_wg&cache=cache&media=12209_closednochange_ballot1.doc I'd like to clarify that at this point we (Hauscar and Séb Demathieu) don't concur in a common resolution with Murray (you'll find the Murray' argumentation at the end of this email). However, I'm providing this initial resolution (closed no change) to open discussion in the mailing list. Please let me know you opinion. Regards, -- Huascar ESPINOZA, Ph.D. CEA Saclay DRT/DTSI/SOL/LISE 91191 GIF/YVETTE CEDEX Phone/Fax: +33 1 69 08 45 87 / 20 82 France ___ Disposition: Closed, no change OMG Issue No: 12209 Title: using $ in naming variables (and variable calls) Source: Carleton University (Dr. Murray Woodside, cmw@sce.carleton.ca) Summary: In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name. Throughout the document there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning. Examples are found in NFP (Fig 8.9) and many other chapters. These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement. In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples. Resolution: There are two kinds of VSL expressions related to variables: 'variable declaration' and 'variable call'. In VSL, we use '$' as a prefix only in the declaration notation, and in the 'call', we use only the name. We really need to make difference between both because VSL parsers need to make the difference. It's true that having a distinctive symbol for 'variable call' different than other 'names' in a VSL expression 'names', such as enumeration literals or PropertyCallExpression, would help to a fast awareness of VSL variable calls. However, some reasons would suggest avoiding such a modification: -Using only the name for both variables and property call expressions is also used by OCL, and there were not reported any issue related to confusing impressions for language users. -In MARTE, most of VSL variable expressions are used at "declaration" level, because in a regular NFP tuple, the value resulting from the evaluation of an expression or variable is specified in a dedicated slot ("value"). This means that VariableCallExpressions are mainly used in Algebraic (math, logical, conditional) expressions, where having a transparent syntax in terms of "parameters" either coming from a UML Property or VSL Variable origin is desirable to avoid complexity in VSL expressions. -Having simple and short expressions is a main concern in VSL to embed them in graphical models without charging models, and for easy learning of the language. For these reasons, we suggest to close this issue with no change. Disposition: Closed, no change Murray's counterposition: -----Message d'origine----- De : Murray Woodside [mailto:cmw@sce.carleton.ca] Envoyé : jeudi 14 février 2008 13:06 À : ESPINOZA Huascar 218344 Cc : Sébastien Demathieu Objet : Re: Issue 12209 - Use of '$' in variables Using a different name (with a prefix $) in the declaration is an uncomfortable solution for making the declaration distinct. Better would be to change the statement, for instance the declaration could have two == signs. Using a $ everywhere reminds a reader that this is a parameter, an NFP, rather than the name of an object. there are so many names in a ndesign, and parameters introduce many many more. I have found that remembering to use a different name in the declaration leads to constant errors. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=i6pzhPXt5Ffl9oFunMaQXYOnbfn1PKupvbJNifhueQ0=; b=oHBPPSzxIj/U11/flhBMINHjTQ6KwQzFFH79hRv891KUUEmHHVDG3Z1pk+f1OlkpA81qGvhG0cMR7qhayyw6UqhVSASg3WjHUqlaD9iwTLT0b7QwTsgJC5UA9IaVraWNp90XVtBHOdhZcMmQxI+zk11pRqrSpulJbKC6D6nLErk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=QP+tAknI+BeOPmyas9uHbGLLwiwGGBXAEml+BATXpK4Y4m1hblMR0zNmwg0tVxqQv7ZsnRQx/hZkJ8Y8lXjvUZaapeTJ+SOn6w8cffSPHgBFF0yRJ+ImKpNRQofQpgZI7tVVti4zWcwOrG5fp7xCrzrv+SWnOr/Y/JD3U9X9JVo= Date: Mon, 18 Feb 2008 14:37:07 -0500 From: "Bran Selic" To: "ESPINOZA Huascar 218344" Subject: Re: Issue 12209: using $ in naming variables (and variable calls) Cc: marte-ftf@omg.org Well, I hate to be the one who goes against the flow, but, like Murray, I feel that a consistent use of the $ prefix was a good thing. I cannot see any justifiable technical reason for differentiating the name in a declaration versus its usage/invocation in expressions. So, my suggestion is either remove it from both places or keep it in both. (From what I recall, OCL does not use mixed forms for variables.) In favour of keeping the $ prefix is the fact that it makes it easy to visually spot the variables in an expression. That was the primary reason we chose to use in SPT. This was partly due to the fact that we did not have an "in" or "out" attribute associated with variables in SPT. The principle there was simple: any variables that did not have explicitly assigned values were automatically deemed output variables, while those that had values were "in" variables. Now, this may look like a weakness in the language, but I actually think that the explicit declaration of "in' and "out" has drawbacks, since it forces you to declare the type of analysis you are doing directly in the specification. OTOH, in practice, it is often the case that you want to play around with choosing which values you want to fix (i.e., input values) and which ones you want to compute. This allows various kinds of searches through the possibilities. You may want to fix one value and see what happens, and then, later, leave it as a dependent variable. I am not sure if this is possible in VSL, but if not, then we have lost something by forcing "in" and "out" to be declared in the variable declaration. I realize the latter is a separate topic from the original issue, but, perhaps, I am raising another one. Cheers...Bran On Feb 18, 2008 11:32 AM, ESPINOZA Huascar 218344 wrote: Hi all, Issue 12209 (see below) relates to using '$' not only in variable declaration but also in 'variable call expressions' has been uploaded in the MARTE FTF wiki. Source: Murray Woodside. http://www.omgwiki.org/marte/lib/exe/fetch.php?id=annex_b_wg&cache=cache&media=12209_closednochange_ballot1.doc I'd like to clarify that at this point we (Hauscar and Séb Demathieu) don't concur in a common resolution with Murray (you'll find the Murray' argumentation at the end of this email). However, I'm providing this initial resolution (closed no change) to open discussion in the mailing list. Please let me know you opinion. Regards, -- Huascar ESPINOZA, Ph.D. CEA Saclay DRT/DTSI/SOL/LISE 91191 GIF/YVETTE CEDEX Phone/Fax: +33 1 69 08 45 87 / 20 82 France ___ Disposition: Closed, no change OMG Issue No: 12209 Title: using $ in naming variables (and variable calls) Source: Carleton University (Dr. Murray Woodside, cmw@sce.carleton.ca) Summary: In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name. Throughout the document there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning. Examples are found in NFP (Fig 8.9) and many other chapters. These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement. In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples. Resolution: There are two kinds of VSL expressions related to variables: 'variable declaration' and 'variable call'. In VSL, we use '$' as a prefix only in the declaration notation, and in the 'call', we use only the name. We really need to make difference between both because VSL parsers need to make the difference. It's true that having a distinctive symbol for 'variable call' different than other 'names' in a VSL expression 'names', such as enumeration literals or PropertyCallExpression, would help to a fast awareness of VSL variable calls. However, some reasons would suggest avoiding such a modification: -Using only the name for both variables and property call expressions is also used by OCL, and there were not reported any issue related to confusing impressions for language users. -In MARTE, most of VSL variable expressions are used at "declaration" level, because in a regular NFP tuple, the value resulting from the evaluation of an expression or variable is specified in a dedicated slot ("value"). This means that VariableCallExpressions are mainly used in Algebraic (math, logical, conditional) expressions, where having a transparent syntax in terms of "parameters" either coming from a UML Property or VSL Variable origin is desirable to avoid complexity in VSL expressions. -Having simple and short expressions is a main concern in VSL to embed them in graphical models without charging models, and for easy learning of the language. For these reasons, we suggest to close this issue with no change. Disposition: Closed, no change Murray's counterposition: -----Message d'origine----- De : Murray Woodside [mailto:cmw@sce.carleton.ca] Envoyé : jeudi 14 février 2008 13:06 À : ESPINOZA Huascar 218344 Cc : Sébastien Demathieu Objet : Re: Issue 12209 - Use of '$' in variables Using a different name (with a prefix $) in the declaration is an uncomfortable solution for making the declaration distinct. Better would be to change the statement, for instance the declaration could have two == signs. Using a $ everywhere reminds a reader that this is a parameter, an NFP, rather than the name of an object. there are so many names in a ndesign, and parameters introduce many many more. I have found that remembering to use a different name in the declaration leads to constant errors. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) Subject: RE : Issue 12209: using $ in naming variable s (and variable calls) Date: Mon, 18 Feb 2008 20:54:55 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 12209: using $ in naming variables (and variable calls) thread-index: AchyZa6IYeeKhM7vT9OD6UGVz/WhgQAARWuZ From: "ESPINOZA Huascar 218344" To: "Bran Selic" Cc: X-OriginalArrivalTime: 18 Feb 2008 19:54:56.0891 (UTC) FILETIME=[22F81CB0:01C87268] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m1IJucSN016430 Thank you Bran. I'd like to clarify two points: -A parser needs to know whether a variable is being declared or used (called). Otherwise, the syntax will be ambiguous. OCL does so. To declare a variable, OCL uses "let " [nameVar: type = initExpr]. In VSL, "let " is replaced by $. -The in, out, and inout qualifiers for a variable declaration are optional. I agree with the usage scenario you mentionned as the general case. This is why this meta-attribute is optional. -->However, I just realized that there is a mistake in the grammar because it is not optional, while in the metamodel it is so. Let me evaluate a better resolution for this issue, while keeping language simplicity and the difference in both kinds of variable expressions (declaration and calls). Regards, Huascar ________________________________ De: Bran Selic [mailto:bran.selic@gmail.com] Date: lun. 18/02/2008 20:37 À: ESPINOZA Huascar 218344 Cc: marte-ftf@omg.org Objet : Re: Issue 12209: using $ in naming variables (and variable calls) Well, I hate to be the one who goes against the flow, but, like Murray, I feel that a consistent use of the $ prefix was a good thing. I cannot see any justifiable technical reason for differentiating the name in a declaration versus its usage/invocation in expressions. So, my suggestion is either remove it from both places or keep it in both. (From what I recall, OCL does not use mixed forms for variables.) In favour of keeping the $ prefix is the fact that it makes it easy to visually spot the variables in an expression. That was the primary reason we chose to use in SPT. This was partly due to the fact that we did not have an "in" or "out" attribute associated with variables in SPT. The principle there was simple: any variables that did not have explicitly assigned values were automatically deemed output variables, while those that had values were "in" variables. Now, this may look like a weakness in the language, but I actually think that the explicit declaration of "in' and "out" has drawbacks, since it forces you to declare the type of analysis you are doing directly in the specification. OTOH, in practice, it is often the case that you want to play around with choosing which values you want to fix (i.e., input values) and which ones you want to compute. This allows various kinds of searches through the possibilities. You may want to fix one value and see what happens, and then, later, leave it as a dependent variable. I am not sure if this is possible in VSL, but if not, then we have lost something by forcing "in" and "out" to be declared in the variable declaration. I realize the latter is a separate topic from the original issue, but, perhaps, I am raising another one. Cheers...Bran On Feb 18, 2008 11:32 AM, ESPINOZA Huascar 218344 wrote: Hi all, Issue 12209 (see below) relates to using '$' not only in variable declaration but also in 'variable call expressions' has been uploaded in the MARTE FTF wiki. Source: Murray Woodside. http://www.omgwiki.org/marte/lib/exe/fetch.php?id=annex_b_wg&cache=cache&media=12209_closednochange_ballot1.doc I'd like to clarify that at this point we (Hauscar and Séb Demathieu) don't concur in a common resolution with Murray (you'll find the Murray' argumentation at the end of this email). However, I'm providing this initial resolution (closed no change) to open discussion in the mailing list. Please let me know you opinion. Regards, -- Huascar ESPINOZA, Ph.D. CEA Saclay DRT/DTSI/SOL/LISE 91191 GIF/YVETTE CEDEX Phone/Fax: +33 1 69 08 45 87 / 20 82 France ___ Disposition: Closed, no change OMG Issue No: 12209 Title: using $ in naming variables (and variable calls) Source: Carleton University (Dr. Murray Woodside, cmw@sce.carleton.ca) Summary: In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name. Throughout the document there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning. Examples are found in NFP (Fig 8.9) and many other chapters. These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement. In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples. Resolution: There are two kinds of VSL expressions related to variables: 'variable declaration' and 'variable call'. In VSL, we use '$' as a prefix only in the declaration notation, and in the 'call', we use only the name. We really need to make difference between both because VSL parsers need to make the difference. It's true that having a distinctive symbol for 'variable call' different than other 'names' in a VSL expression 'names', such as enumeration literals or PropertyCallExpression, would help to a fast awareness of VSL variable calls. However, some reasons would suggest avoiding such a modification: -Using only the name for both variables and property call expressions is also used by OCL, and there were not reported any issue related to confusing impressions for language users. -In MARTE, most of VSL variable expressions are used at "declaration" level, because in a regular NFP tuple, the value resulting from the evaluation of an expression or variable is specified in a dedicated slot ("value"). This means that VariableCallExpressions are mainly used in Algebraic (math, logical, conditional) expressions, where having a transparent syntax in terms of "parameters" either coming from a UML Property or VSL Variable origin is desirable to avoid complexity in VSL expressions. -Having simple and short expressions is a main concern in VSL to embed them in graphical models without charging models, and for easy learning of the language. For these reasons, we suggest to close this issue with no change. Disposition: Closed, no change Murray's counterposition: -----Message d'origine----- De : Murray Woodside [mailto:cmw@sce.carleton.ca] Envoyé : jeudi 14 février 2008 13:06 À : ESPINOZA Huascar 218344 Cc : Sébastien Demathieu Objet : Re: Issue 12209 - Use of '$' in variables Using a different name (with a prefix $) in the declaration is an uncomfortable solution for making the declaration distinct. Better would be to change the statement, for instance the declaration could have two == signs. Using a $ everywhere reminds a reader that this is a parameter, an NFP, rather than the name of an object. there are so many names in a ndesign, and parameters introduce many many more. I have found that remembering to use a different name in the declaration leads to constant errors. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) Subject: RE : Issue 12209: using $ in naming variable s (and variable calls) Date: Mon, 18 Feb 2008 20:57:08 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 12209: using $ in naming variables (and variable calls) thread-index: AchyZa6IYeeKhM7vT9OD6UGVz/WhgQAARWuZAABrVVE= From: "ESPINOZA Huascar 218344" To: "Bran Selic" Cc: X-OriginalArrivalTime: 18 Feb 2008 19:59:03.0835 (UTC) FILETIME=[B628C6B0:01C87268] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m1IK03fM017175 It seems that there is a misundertanding (please correct me). You think that the '$' is part of the name? If so, I must clarify that the name is always the same. '$' is only a notation keyword. Huascar ________________________________ De: ESPINOZA Huascar 218344 Date: lun. 18/02/2008 20:54 À: Bran Selic Cc: marte-ftf@omg.org Objet : RE : Issue 12209: using $ in naming variables (and variable calls) Thank you Bran. I'd like to clarify two points: -A parser needs to know whether a variable is being declared or used (called). Otherwise, the syntax will be ambiguous. OCL does so. To declare a variable, OCL uses "let " [nameVar: type = initExpr]. In VSL, "let " is replaced by $. -The in, out, and inout qualifiers for a variable declaration are optional. I agree with the usage scenario you mentionned as the general case. This is why this meta-attribute is optional. -->However, I just realized that there is a mistake in the grammar because it is not optional, while in the metamodel it is so. Let me evaluate a better resolution for this issue, while keeping language simplicity and the difference in both kinds of variable expressions (declaration and calls). Regards, Huascar ________________________________ De: Bran Selic [mailto:bran.selic@gmail.com] Date: lun. 18/02/2008 20:37 À: ESPINOZA Huascar 218344 Cc: marte-ftf@omg.org Objet : Re: Issue 12209: using $ in naming variables (and variable calls) Well, I hate to be the one who goes against the flow, but, like Murray, I feel that a consistent use of the $ prefix was a good thing. I cannot see any justifiable technical reason for differentiating the name in a declaration versus its usage/invocation in expressions. So, my suggestion is either remove it from both places or keep it in both. (From what I recall, OCL does not use mixed forms for variables.) In favour of keeping the $ prefix is the fact that it makes it easy to visually spot the variables in an expression. That was the primary reason we chose to use in SPT. This was partly due to the fact that we did not have an "in" or "out" attribute associated with variables in SPT. The principle there was simple: any variables that did not have explicitly assigned values were automatically deemed output variables, while those that had values were "in" variables. Now, this may look like a weakness in the language, but I actually think that the explicit declaration of "in' and "out" has drawbacks, since it forces you to declare the type of analysis you are doing directly in the specification. OTOH, in practice, it is often the case that you want to play around with choosing which values you want to fix (i.e., input values) and which ones you want to compute. This allows various kinds of searches through the possibilities. You may want to fix one value and see what happens, and then, later, leave it as a dependent variable. I am not sure if this is possible in VSL, but if not, then we have lost something by forcing "in" and "out" to be declared in the variable declaration. I realize the latter is a separate topic from the original issue, but, perhaps, I am raising another one. Cheers...Bran On Feb 18, 2008 11:32 AM, ESPINOZA Huascar 218344 wrote: Hi all, Issue 12209 (see below) relates to using '$' not only in variable declaration but also in 'variable call expressions' has been uploaded in the MARTE FTF wiki. Source: Murray Woodside. http://www.omgwiki.org/marte/lib/exe/fetch.php?id=annex_b_wg&cache=cache&media=12209_closednochange_ballot1.doc I'd like to clarify that at this point we (Hauscar and Séb Demathieu) don't concur in a common resolution with Murray (you'll find the Murray' argumentation at the end of this email). However, I'm providing this initial resolution (closed no change) to open discussion in the mailing list. Please let me know you opinion. Regards, -- Huascar ESPINOZA, Ph.D. CEA Saclay DRT/DTSI/SOL/LISE 91191 GIF/YVETTE CEDEX Phone/Fax: +33 1 69 08 45 87 / 20 82 France ___ Disposition: Closed, no change OMG Issue No: 12209 Title: using $ in naming variables (and variable calls) Source: Carleton University (Dr. Murray Woodside, cmw@sce.carleton.ca) Summary: In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name. Throughout the document there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning. Examples are found in NFP (Fig 8.9) and many other chapters. These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement. In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples. Resolution: There are two kinds of VSL expressions related to variables: 'variable declaration' and 'variable call'. In VSL, we use '$' as a prefix only in the declaration notation, and in the 'call', we use only the name. We really need to make difference between both because VSL parsers need to make the difference. It's true that having a distinctive symbol for 'variable call' different than other 'names' in a VSL expression 'names', such as enumeration literals or PropertyCallExpression, would help to a fast awareness of VSL variable calls. However, some reasons would suggest avoiding such a modification: -Using only the name for both variables and property call expressions is also used by OCL, and there were not reported any issue related to confusing impressions for language users. -In MARTE, most of VSL variable expressions are used at "declaration" level, because in a regular NFP tuple, the value resulting from the evaluation of an expression or variable is specified in a dedicated slot ("value"). This means that VariableCallExpressions are mainly used in Algebraic (math, logical, conditional) expressions, where having a transparent syntax in terms of "parameters" either coming from a UML Property or VSL Variable origin is desirable to avoid complexity in VSL expressions. -Having simple and short expressions is a main concern in VSL to embed them in graphical models without charging models, and for easy learning of the language. For these reasons, we suggest to close this issue with no change. Disposition: Closed, no change Murray's counterposition: -----Message d'origine----- De : Murray Woodside [mailto:cmw@sce.carleton.ca] Envoyé : jeudi 14 février 2008 13:06 À : ESPINOZA Huascar 218344 Cc : Sébastien Demathieu Objet : Re: Issue 12209 - Use of '$' in variables Using a different name (with a prefix $) in the declaration is an uncomfortable solution for making the declaration distinct. Better would be to change the statement, for instance the declaration could have two == signs. Using a $ everywhere reminds a reader that this is a parameter, an NFP, rather than the name of an object. there are so many names in a ndesign, and parameters introduce many many more. I have found that remembering to use a different name in the declaration leads to constant errors. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; bh=ddb0cncGTAnKUU7qk1CvWSYplXEq5Sxtg6iInwpXLgQ=; b=VgyTBBf7tNBZwQYI7LDmxMehtTu3o5sBDQhXNCrxOSr2NLc9YGnogC7Dfq28BN35XsLnBqWjEqI7a6rPUIwYDL4n/caGdZDNblleWO4edi1Uhk01sNMf3hyGgmRw8RzK3jk2i6sbCSftJBa+aoueM9LGC9fZODWZGF9L26F2ul4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=TcxvxUGmbrnttAjtX1wgUnYU/ZWhR1KpMTRChjBdzFSxXm5Jl8KjOGAWZYAbAZZLb9cS1M+jvKCs3Gl+1PM5uyr+Zu/md1l36umDucnZLAMabtzKu5bDRIy7ADAvqXU1BjGS0ADUZlbvYqOKYOtN4axZ+5aCtvThYiu+FPybJMo= Date: Mon, 18 Feb 2008 21:11:16 -0500 From: "Bran Selic" To: "ESPINOZA Huascar 218344" Subject: Re: RE : Issue 12209: using $ in naming variables (and variable calls) Cc: marte-ftf@omg.org On Feb 18, 2008 2:54 PM, ESPINOZA Huascar 218344 wrote: Thank you Bran. I'd like to clarify two points: -A parser needs to know whether a variable is being declared or used (called). Otherwise, the syntax will be ambiguous. OCL does so. To declare a variable, OCL uses "let " [nameVar: type = initExpr]. In VSL, "let " is replaced by $. But, that is what declaration statements are for. I believe that something like "Let" (or "Var") is a better keyword for that purpose and more conventional than a "$" prefix. Cheers...Bran Subject: RE: RE : Issue 12209: using $ in naming variables (and variable calls) Date: Tue, 19 Feb 2008 09:39:04 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE : Issue 12209: using $ in naming variables (and variable calls) thread-index: AchynLqYCzeOE8gZRk6RfyjbwRza9QAMkp3A From: "ESPINOZA Huascar 218344" To: "Bran Selic" Cc: X-OriginalArrivalTime: 19 Feb 2008 08:39:04.0890 (UTC) FILETIME=[E28191A0:01C872D2] But Bran, I don.t believe you are saying that! Unquestionably, VSL is NOT a conventional language From that perspective, UML wouldn.t be conventional either. You forget that the Observation concept, being used &during a long time @now, uses exactly the same unconventional convention too . While observation declarations use a prefix (.&. for duration and .@. for time instant observation), at specification level only the name is used without distinction between duration or time instant call expressions. In fact, Observation is often understood by MARTE authors as a kind of variable, but with a particular semantics. Besides, please note that the variable use you and Murray have in mind, à la TVL, where variables are used to define a placeholder to analysis tool results are all .variable declarations. (it.s the first time you refer to those variables). That means that in those cases, the symbol .$. will be present. Or in other words, just imagine all those variables in your model with the .let . keyword polluting the graphical view $rgrd=.Regards. Huascar -------------------------------------------------------------------------------- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : mardi 19 février 2008 03:11 À : ESPINOZA Huascar 218344 Cc : marte-ftf@omg.org Objet : Re: RE : Issue 12209: using $ in naming variables (and variable calls) On Feb 18, 2008 2:54 PM, ESPINOZA Huascar 218344 wrote: Thank you Bran. I'd like to clarify two points: -A parser needs to know whether a variable is being declared or used (called). Otherwise, the syntax will be ambiguous. OCL does so. To declare a variable, OCL uses "let " [nameVar: type = initExpr]. In VSL, "let " is replaced by $. But, that is what declaration statements are for. I believe that something like "Let" (or "Var") is a better keyword for that purpose and more conventional than a "$" prefix. Cheers...Bran Date: Tue, 19 Feb 2008 11:17:55 +0100 From: Sébastien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: ESPINOZA Huascar 218344 , Bran Selic Cc: marte-ftf@omg.org Subject: Re: RE : Issue 12209: using $ in naming variables (and variable calls) Hello Huascar, Bran, First, I agree the direction of a variable should be optional, to allow a more declarative approach. We may need to raise an issue on that. I have no definitive opinion on the use of the $ symbol but there is an example I always use to illustrate how VSL variables work: consider a schedulable resource using fixed priority scheduling. If one wants to declare an output variable that represent the priority computed by an analysis tool, he writes : "fp (priority=out$locPrio:Integer)" as the value of the SchedulableResource.schedParam attribute. If we replace the "$" by a "let" / "var" construct, what would be the resulting expression here? Would it be still easy to parse? Thanks, Sébastien ESPINOZA Huascar 218344 a écrit : But Bran, I don.t believe you are saying that! Unquestionably, VSL is NOT a conventional language From that perspective, UML wouldn.t be conventional either. You forget that the Observation concept, being used &during a long time @now, uses exactly the same unconventional convention too . While observation declarations use a prefix (.&. for duration and .@. for time instant observation), at specification level only the name is used without distinction between duration or time instant call expressions. In fact, Observation is often understood by MARTE authors as a kind of variable, but with a particular semantics. Besides, please note that the variable use you and Murray have in mind, à la TVL, where variables are used to define a placeholder to analysis tool results are all .variable declarations. (it.s the first time you refer to those variables). That means that in those cases, the symbol .$. will be present. Or in other words, just imagine all those variables in your model with the .let . keyword polluting the graphical view $rgrd=.Regards. Huascar -------------------------------------------------------------------------------- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : mardi 19 février 2008 03:11 À : ESPINOZA Huascar 218344 Cc : marte-ftf@omg.org Objet : Re: RE : Issue 12209: using $ in naming variables (and variable calls) On Feb 18, 2008 2:54 PM, ESPINOZA Huascar 218344 wrote: Thank you Bran. I'd like to clarify two points: -A parser needs to know whether a variable is being declared or used (called). Otherwise, the syntax will be ambiguous. OCL does so. To declare a variable, OCL uses "let " [nameVar: type = initExpr]. In VSL, "let " is replaced by $. But, that is what declaration statements are for. I believe that something like "Let" (or "Var") is a better keyword for that purpose and more conventional than a "$" prefix. Cheers...Bran DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=7C4r3wdY0Avem+MjA6LAr8G5rd+G4/cVdY0Rq9c8PGg=; b=aEZMP+tCgQZs6BjwMzf+KNyADofoJSVgg/vAVyng53QqishkwnZRuFb84478VtBdXTNh1Gpc6k018NxilSpQXzrUHwGs1U32IbM0Nk1BUueztpK/s2gYtE1NVR4fHI6nul8CJNJJi5fMecAbSOzl9ErrEWwT3x/iRJnY/tMs8zk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=kZjjoCY6Son3slHq2W5hCOZI7pQigZzQOZaRjsOTSRX0NTav8nud2CYgcdzoPgr54Uec4Ogy+5j77enIwG7+J0ZdrFRq4sup14j9pcb9TBpoYHNCLrDsQs/zdkK/D9W3tnSLqi82OqxffyP/aev0lOJzb+hpf6wS7j/ov+SK50M= Date: Tue, 19 Feb 2008 06:43:20 -0500 From: "Bran Selic" To: "Sébastien Demathieu" Subject: Re: RE : Issue 12209: using $ in naming variables (and variable calls) Cc: "ESPINOZA Huascar 218344" , marte-ftf@omg.org Well, I was not advocating the use of in-line "let" declarations but as distinct statements -- the usual thing we have in most programming languages. The problem I see with the in-line variable declaration using $ signs is that they present a maintenance problem. For example, I may want to remove a statement in which the variable is declared without removing the variable. This means that I have to remember to re-declare it in a different statement. Also, when and where do I declare it? Can a variable appear in an expression before it is declared? (this requires a multipass parser). it just seems a lot simpler and cleaner and more conventional to have a separate variable declaration statement -- at least as an option (i.e., we can retain the "in-line" declaration form for those who prefer it). Cheers...Bran On Feb 19, 2008 5:17 AM, Sébastien Demathieu wrote: Hello Huascar, Bran, First, I agree the direction of a variable should be optional, to allow a more declarative approach. We may need to raise an issue on that. I have no definitive opinion on the use of the $ symbol but there is an example I always use to illustrate how VSL variables work: consider a schedulable resource using fixed priority scheduling. If one wants to declare an output variable that represent the priority computed by an analysis tool, he writes : "fp (priority=out$locPrio:Integer)" as the value of the SchedulableResource.schedParam attribute. If we replace the "$" by a "let" / "var" construct, what would be the resulting expression here? Would it be still easy to parse? Thanks, Sébastien ESPINOZA Huascar 218344 a écrit : But Bran, I don't believe you are saying that! Unquestionably, VSL is NOT a conventional language From that perspective, UML wouldn't be conventional either. You forget that the Observation concept, being used &during a long time @now, uses exactly the same unconventional convention too . While observation declarations use a prefix ('&' for duration and '@' for time instant observation), at specification level only the name is used without distinction between duration or time instant call expressions. In fact, Observation is often understood by MARTE authors as a kind of variable, but with a particular semantics. Besides, please note that the variable use you and Murray have in mind, à la TVL, where variables are used to define a placeholder to analysis tool results are all "variable declarations" (it's the first time you refer to those variables). That means that in those cases, the symbol "$" will be present. Or in other words, just imagine all those variables in your model with the "let " keyword polluting the graphical view $rgrd="Regards" Huascar -------------------------------------------------------------------------------- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : mardi 19 février 2008 03:11 À : ESPINOZA Huascar 218344 Cc : marte-ftf@omg.org Objet : Re: RE : Issue 12209: using $ in naming variables (and variable calls) On Feb 18, 2008 2:54 PM, ESPINOZA Huascar 218344 wrote: Thank you Bran. I'd like to clarify two points: -A parser needs to know whether a variable is being declared or used (called). Otherwise, the syntax will be ambiguous. OCL does so. To declare a variable, OCL uses "let " [nameVar: type = initExpr]. In VSL, "let " is replaced by $. But, that is what declaration statements are for. I believe that something like "Let" (or "Var") is a better keyword for that purpose and more conventional than a "$" prefix. Cheers...Bran Subject: RE: RE : Issue 12209: using $ in naming variables (and variable calls) Date: Tue, 19 Feb 2008 13:09:25 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE : Issue 12209: using $ in naming variables (and variable calls) thread-index: Achy7MpaHayNHT97Ql6C+OY6kEv+rgAAzmaw From: "GERARD Sebastien 166342" To: "Bran Selic" , Sébastien Demathieu Cc: "ESPINOZA Huascar 218344" , X-OriginalArrivalTime: 19 Feb 2008 12:09:26.0357 (UTC) FILETIME=[457C9850:01C872F0] One additional issue with inline declaration is how you determine a variable has been declared? It is ok in sequential program, but in a UML model, there is no a priori order in one model. I would also second the Bran.s proposition in order to make simpler its usage. -------------------------------------------------------------------------------- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : mardi 19 février 2008 12:43 À : Sébastien Demathieu Cc : ESPINOZA Huascar 218344; marte-ftf@omg.org Objet : Re: RE : Issue 12209: using $ in naming variables (and variable calls) Well, I was not advocating the use of in-line "let" declarations but as distinct statements -- the usual thing we have in most programming languages. The problem I see with the in-line variable declaration using $ signs is that they present a maintenance problem. For example, I may want to remove a statement in which the variable is declared without removing the variable. This means that I have to remember to re-declare it in a different statement. Also, when and where do I declare it? Can a variable appear in an expression before it is declared? (this requires a multipass parser). it just seems a lot simpler and cleaner and more conventional to have a separate variable declaration statement -- at least as an option (i.e., we can retain the "in-line" declaration form for those who prefer it). Cheers...Bran On Feb 19, 2008 5:17 AM, Sébastien Demathieu wrote: Hello Huascar, Bran, First, I agree the direction of a variable should be optional, to allow a more declarative approach. We may need to raise an issue on that. I have no definitive opinion on the use of the $ symbol but there is an example I always use to illustrate how VSL variables work: consider a schedulable resource using fixed priority scheduling. If one wants to declare an output variable that represent the priority computed by an analysis tool, he writes : "fp (priority=out$locPrio:Integer)" as the value of the SchedulableResource.schedParam attribute. If we replace the "$" by a "let" / "var" construct, what would be the resulting expression here? Would it be still easy to parse? Thanks, Sébastien ESPINOZA Huascar 218344 a écrit : But Bran, I don't believe you are saying that! Unquestionably, VSL is NOT a conventional language From that perspective, UML wouldn't be conventional either. You forget that the Observation concept, being used &during a long time @now, uses exactly the same unconventional convention too . While observation declarations use a prefix ('&' for duration and '@' for time instant observation), at specification level only the name is used without distinction between duration or time instant call expressions. In fact, Observation is often understood by MARTE authors as a kind of variable, but with a particular semantics. Besides, please note that the variable use you and Murray have in mind, à la TVL, where variables are used to define a placeholder to analysis tool results are all "variable declarations" (it's the first time you refer to those variables). That means that in those cases, the symbol "$" will be present. Or in other words, just imagine all those variables in your model with the "let " keyword polluting the graphical view $rgrd="Regards" Huascar -------------------------------------------------------------------------------- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : mardi 19 février 2008 03:11 À : ESPINOZA Huascar 218344 Cc : marte-ftf@omg.org Objet : Re: RE : Issue 12209: using $ in naming variables (and variable calls) On Feb 18, 2008 2:54 PM, ESPINOZA Huascar 218344 wrote: Thank you Bran. I'd like to clarify two points: -A parser needs to know whether a variable is being declared or used (called). Otherwise, the syntax will be ambiguous. OCL does so. To declare a variable, OCL uses "let " [nameVar: type = initExpr]. In VSL, "let " is replaced by $. But, that is what declaration statements are for. I believe that something like "Let" (or "Var") is a better keyword for that purpose and more conventional than a "$" prefix. Cheers...Bran Subject: RE: RE : Issue 12209: using $ in naming variables (and variable calls) Date: Tue, 19 Feb 2008 13:54:28 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE : Issue 12209: using $ in naming variables (and variable calls) thread-index: Achy7MpaHayNHT97Ql6C+OY6kEv+rgAAzmawAAEpeVA= From: "ESPINOZA Huascar 218344" To: "GERARD Sebastien 166342" , "Bran Selic" , Sébastien Demathieu Cc: X-OriginalArrivalTime: 19 Feb 2008 12:54:28.0837 (UTC) FILETIME=[904A5150:01C872F6] Hi, Let.s try to understand your point. The first aspect is that VSL does not support in-line variable declaration. This is a misunderstanding. We have a variable declaration statement and variable call expressions. The second aspect is that VSL, unlike TVL, proposes a mechanism to control the context (and namespace) of variables (see Section B.3.3.13 in the MARTE spec). The third point is that the consistence of expressions (declaration/calls) is a tool issue, that will work exactly as other OCL parsers work. It seems that a there is a misunderstanding. For instance, in the Seb Demathieu.s example, the right notation is: fp (priority= (expr=out$locPrio:Integer) Here, the variable is declared in a declaration statement within an expression. There is no such in-line variable declaration. If some value is evaluated for this expression, the notation would be: fp (priority= (value=24, expr=out$locPrio:Integer) Please let me know if this helps to clarify things. Regards, Huascar -------------------------------------------------------------------------------- De : GERARD Sebastien 166342 Envoyé : mardi 19 février 2008 13:09 À : 'Bran Selic'; Sébastien Demathieu Cc : ESPINOZA Huascar 218344; marte-ftf@omg.org Objet : RE: RE : Issue 12209: using $ in naming variables (and variable calls) One additional issue with inline declaration is how you determine a variable has been declared? It is ok in sequential program, but in a UML model, there is no a priori order in one model. I would also second the Bran.s proposition in order to make simpler its usage. -------------------------------------------------------------------------------- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : mardi 19 février 2008 12:43 À : Sébastien Demathieu Cc : ESPINOZA Huascar 218344; marte-ftf@omg.org Objet : Re: RE : Issue 12209: using $ in naming variables (and variable calls) Well, I was not advocating the use of in-line "let" declarations but as distinct statements -- the usual thing we have in most programming languages. The problem I see with the in-line variable declaration using $ signs is that they present a maintenance problem. For example, I may want to remove a statement in which the variable is declared without removing the variable. This means that I have to remember to re-declare it in a different statement. Also, when and where do I declare it? Can a variable appear in an expression before it is declared? (this requires a multipass parser). it just seems a lot simpler and cleaner and more conventional to have a separate variable declaration statement -- at least as an option (i.e., we can retain the "in-line" declaration form for those who prefer it). Cheers...Bran On Feb 19, 2008 5:17 AM, Sébastien Demathieu wrote: Hello Huascar, Bran, First, I agree the direction of a variable should be optional, to allow a more declarative approach. We may need to raise an issue on that. I have no definitive opinion on the use of the $ symbol but there is an example I always use to illustrate how VSL variables work: consider a schedulable resource using fixed priority scheduling. If one wants to declare an output variable that represent the priority computed by an analysis tool, he writes : "fp (priority=out$locPrio:Integer)" as the value of the SchedulableResource.schedParam attribute. If we replace the "$" by a "let" / "var" construct, what would be the resulting expression here? Would it be still easy to parse? Thanks, Sébastien ESPINOZA Huascar 218344 a écrit : But Bran, I don't believe you are saying that! Unquestionably, VSL is NOT a conventional language From that perspective, UML wouldn't be conventional either. You forget that the Observation concept, being used &during a long time @now, uses exactly the same unconventional convention too . While observation declarations use a prefix ('&' for duration and '@' for time instant observation), at specification level only the name is used without distinction between duration or time instant call expressions. In fact, Observation is often understood by MARTE authors as a kind of variable, but with a particular semantics. Besides, please note that the variable use you and Murray have in mind, à la TVL, where variables are used to define a placeholder to analysis tool results are all "variable declarations" (it's the first time you refer to those variables). That means that in those cases, the symbol "$" will be present. Or in other words, just imagine all those variables in your model with the "let " keyword polluting the graphical view $rgrd="Regards" Huascar -------------------------------------------------------------------------------- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : mardi 19 février 2008 03:11 À : ESPINOZA Huascar 218344 Cc : marte-ftf@omg.org Objet : Re: RE : Issue 12209: using $ in naming variables (and variable calls) On Feb 18, 2008 2:54 PM, ESPINOZA Huascar 218344 wrote: Thank you Bran. I'd like to clarify two points: -A parser needs to know whether a variable is being declared or used (called). Otherwise, the syntax will be ambiguous. OCL does so. To declare a variable, OCL uses "let " [nameVar: type = initExpr]. In VSL, "let " is replaced by $. But, that is what declaration statements are for. I believe that something like "Let" (or "Var") is a better keyword for that purpose and more conventional than a "$" prefix. Cheers...Bran Date: Sun, 24 Feb 2008 17:48:11 -0500 (EST) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: ESPINOZA Huascar 218344 Cc: Bran Selic , marte-ftf@omg.org Subject: Re: RE : Issue 12209: using $ in naming variable s (and variable calls) OK, it seems that the $ sign got highjacked to be used as a special signifier instead of designating a variable name, without ever being discussed. I think it would be better to use "let" to designate declarations, consistently with OCL, and keep the $ sign for NFPs. The way it is used now is obscure and confusing. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Mon, 18 Feb 2008, ESPINOZA Huascar 218344 wrote: It seems that there is a misundertanding (please correct me). You think that the '$' is part of the name? If so, I must clarify that the name is always the same. '$' is only a notation keyword. Huascar ________________________________ De: ESPINOZA Huascar 218344 Date: lun. 18/02/2008 20:54 À: Bran Selic Cc: marte-ftf@omg.org Objet : RE : Issue 12209: using $ in naming variables (and variable calls) Thank you Bran. I'd like to clarify two points: -A parser needs to know whether a variable is being declared or used (called). Otherwise, the syntax will be ambiguous. OCL does so. To declare a variable, OCL uses "let " [nameVar: type = initExpr]. In VSL, "let " is replaced by $. -The in, out, and inout qualifiers for a variable declaration are optional. I agree with the usage scenario you mentionned as the general case. This is why this meta-attribute is optional. -->However, I just realized that there is a mistake in the grammar because it is not optional, while in the metamodel it is so. Let me evaluate a better resolution for this issue, while keeping language simplicity and the difference in both kinds of variable expressions (declaration and calls). Regards, Huascar ________________________________ De: Bran Selic [mailto:bran.selic@gmail.com] Date: lun. 18/02/2008 20:37 À: ESPINOZA Huascar 218344 Cc: marte-ftf@omg.org Objet : Re: Issue 12209: using $ in naming variables (and variable calls) Well, I hate to be the one who goes against the flow, but, like Murray, I feel that a consistent use of the $ prefix was a good thing. I cannot see any justifiable technical reason for differentiating the name in a declaration versus its usage/invocation in expressions. So, my suggestion is either remove it from both places or keep it in both. (From what I recall, OCL does not use mixed forms for variables.) In favour of keeping the $ prefix is the fact that it makes it easy to visually spot the variables in an expression. That was the primary reason we chose to use in SPT. This was partly due to the fact that we did not have an "in" or "out" attribute associated with variables in SPT. The principle there was simple: any variables that did not have explicitly assigned values were automatically deemed output variables, while those that had values were "in" variables. Now, this may look like a weakness in the language, but I actually think that the explicit declaration of "in' and "out" has drawbacks, since it forces you to declare the type of analysis you are doing directly in the specification. OTOH, in practice, it is often the case that you want to play around with choosing which values you want to fix (i.e., input values) and which ones you want to compute. This allows various kinds of searches through the possibilities. You may want to fix one value and see what happens, and then, later, leave it as a dependent variable. I am not sure if this is possible in VSL, but if not, then we have lost something by forcing "in" and "out" to be declared in the variable declaration. I realize the latter is a separate topic from the original issue, but, perhaps, I am raising another one. Cheers...Bran On Feb 18, 2008 11:32 AM, ESPINOZA Huascar 218344 wrote: Hi all, Issue 12209 (see below) relates to using '$' not only in variable declaration but also in 'variable call expressions' has been uploaded in the MARTE FTF wiki. Source: Murray Woodside. http://www.omgwiki.org/marte/lib/exe/fetch.php?id=annex_b_wg&cache=cache&media=12209_closednochange_ballot1.doc I'd like to clarify that at this point we (Hauscar and Séb Demathieu) don't concur in a common resolution with Murray (you'll find the Murray' argumentation at the end of this email). However, I'm providing this initial resolution (closed no change) to open discussion in the mailing list. Please let me know you opinion. Regards, -- Huascar ESPINOZA, Ph.D. CEA Saclay DRT/DTSI/SOL/LISE 91191 GIF/YVETTE CEDEX Phone/Fax: +33 1 69 08 45 87 / 20 82 France ___ Disposition: Closed, no change OMG Issue No: 12209 Title: using $ in naming variables (and variable calls) Source: Carleton University (Dr. Murray Woodside, cmw@sce.carleton.ca) Summary: In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name. Throughout the document there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning. Examples are found in NFP (Fig 8.9) and many other chapters. These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement. In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples. Resolution: There are two kinds of VSL expressions related to variables: 'variable declaration' and 'variable call'. In VSL, we use '$' as a prefix only in the declaration notation, and in the 'call', we use only the name. We really need to make difference between both because VSL parsers need to make the difference. It's true that having a distinctive symbol for 'variable call' different than other 'names' in a VSL expression 'names', such as enumeration literals or PropertyCallExpression, would help to a fast awareness of VSL variable calls. However, some reasons would suggest avoiding such a modification: -Using only the name for both variables and property call expressions is also used by OCL, and there were not reported any issue related to confusing impressions for language users. -In MARTE, most of VSL variable expressions are used at "declaration" level, because in a regular NFP tuple, the value resulting from the evaluation of an expression or variable is specified in a dedicated slot ("value"). This means that VariableCallExpressions are mainly used in Algebraic (math, logical, conditional) expressions, where having a transparent syntax in terms of "parameters" either coming from a UML Property or VSL Variable origin is desirable to avoid complexity in VSL expressions. -Having simple and short expressions is a main concern in VSL to embed them in graphical models without charging models, and for easy learning of the language. For these reasons, we suggest to close this issue with no change. Disposition: Closed, no change Murray's counterposition: -----Message d'origine----- De : Murray Woodside [mailto:cmw@sce.carleton.ca] Envoyé : jeudi 14 février 2008 13:06 À : ESPINOZA Huascar 218344 Cc : Sébastien Demathieu Objet : Re: Issue 12209 - Use of '$' in variables Using a different name (with a prefix $) in the declaration is an uncomfortable solution for making the declaration distinct. Better would be to change the statement, for instance the declaration could have two == signs. Using a $ everywhere reminds a reader that this is a parameter, an NFP, rather than the name of an object. there are so many names in a ndesign, and parameters introduce many many more. I have found that remembering to use a different name in the declaration leads to constant errors. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) Subject: RE: RE : Issue 12209: using $ in naming variables (and variable calls) Date: Mon, 25 Feb 2008 10:21:11 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE : Issue 12209: using $ in naming variables (and variable calls) thread-index: Ach3f3hHf4AonQe+Q6irKoVFV5lbPQAC3Mmw From: "ESPINOZA Huascar 218344" To: "Bran Selic" , Cc: X-OriginalArrivalTime: 25 Feb 2008 09:21:12.0150 (UTC) FILETIME=[C3595760:01C8778F] Hi Bran and Murray, We agree on the idea that having a .$. prefix in names makes easier to identify variables. We should agree also that declaring variables is necessary in order facilitate debug. Indeed, TVL (as Perl, its origin) does use .inline variable declaration.. This means that we were able to have a .tagged value.: clockRate = ($clock_rate, .ns.) .without a previous declaration of $clock_rate. We also agree that this cause that it would be hard to debug a mistake like: adjustedClockRate = (1.4 * $clockrate, .ns.) where $clockrate (instead of $clock_rate) is understood as a new variable. For this reason, we force in VSL to declare variables. Up to this point, we seem agree. Now, if we follow your proposal, we will have: clockRate = (let $clock_rate, .ns.) (djustedClockRate = (1.4 * $clockrate, .ns.) where $clockrate will be easily detected as a bug. ;;; against the current VSL mechanism that would result in: clockRate = ($clock_rate, .ns.) . adjustedClockRate = (1.4 * clockrate, .ns.) where $clock_rate is the declaration, and clockrate (instead of clock_rate) will be also detected as a bug. à If all this is OK (and clear?), we would like to still hear your opinion. Personally, I preferred the current VSL approach because it was more compact, and was exactly as UML Observation notation works (so, I don.t believe that it is obscure and confusing). But I.m open to your proposal. I.d like to hear the opinion of the others as well. Rgrd, Huascar -------------------------------------------------------------------------------- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : lundi 25 février 2008 08:24 À : cmw@sce.carleton.ca Cc : ESPINOZA Huascar 218344; marte-ftf@omg.org Objet : Re: RE : Issue 12209: using $ in naming variables (and variable calls) I was thinking along the same lines as Murray. I prefer the use of a keyword as opposed to a key symbol for statements. (The original idea of $ signs in TVL was twofold: to identify variables and also to make them easier to spot when looking at expressions.) Cheers...Bran On 2/24/08, Murray Woodside wrote: OK, it seems that the $ sign got highjacked to be used as a special signifier instead of designating a variable name, without ever being discussed. I think it would be better to use "let" to designate declarations, consistently with OCL, and keep the $ sign for NFPs. The way it is used now is obscure and confusing. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Mon, 18 Feb 2008, ESPINOZA Huascar 218344 wrote: > It seems that there is a misundertanding (please correct me). You think that the '$' is part of the name? If so, I must clarify that the name is always the same. '$' is only a notation keyword. > Huascar > > ________________________________ > > De: ESPINOZA Huascar 218344 > Date: lun. 18/02/2008 20:54 > À: Bran Selic > Cc: marte-ftf@omg.org > Objet : RE : Issue 12209: using $ in naming variables (and variable calls) > > > Thank you Bran. > > I'd like to clarify two points: > > -A parser needs to know whether a variable is being declared or used (called). Otherwise, the syntax will be ambiguous. OCL does so. To declare a variable, OCL uses "let " [nameVar: type = initExpr]. In VSL, "let " is replaced by $. > -The in, out, and inout qualifiers for a variable declaration are optional. I agree with the usage scenario you mentionned as the general case. This is why this meta-attribute is optional. > -->However, I just realized that there is a mistake in the grammar because it is not optional, while in the metamodel it is so. > > Let me evaluate a better resolution for this issue, while keeping language simplicity and the difference in both kinds of variable expressions (declaration and calls). > > Regards, > Huascar > > ________________________________ > > De: Bran Selic [mailto:bran.selic@gmail.com] > Date: lun. 18/02/2008 20:37 > À: ESPINOZA Huascar 218344 > Cc: marte-ftf@omg.org > Objet : Re: Issue 12209: using $ in naming variables (and variable calls) > > > Well, I hate to be the one who goes against the flow, but, like Murray, I feel that a consistent use of the $ prefix was a good thing. I cannot see any justifiable technical reason for differentiating the name in a declaration versus its usage/invocation in expressions. So, my suggestion is either remove it from both places or keep it in both. (From what I recall, OCL does not use mixed forms for variables.) > > In favour of keeping the $ prefix is the fact that it makes it easy to visually spot the variables in an expression. That was the primary reason we chose to use in SPT. This was partly due to the fact that we did not have an "in" or "out" attribute associated with variables in SPT. The principle there was simple: any variables that did not have explicitly assigned values were automatically deemed output variables, while those that had values were "in" variables. > > Now, this may look like a weakness in the language, but I actually think that the explicit declaration of "in' and "out" has drawbacks, since it forces you to declare the type of analysis you are doing directly in the specification. OTOH, in practice, it is often the case that you want to play around with choosing which values you want to fix (i.e., input values) and which ones you want to compute. This allows various kinds of searches through the possibilities. You may want to fix one value and see what happens, and then, later, leave it as a dependent variable. I am not sure if this is possible in VSL, but if not, then we have lost something by forcing "in" and "out" to be declared in the variable declaration. > > I realize the latter is a separate topic from the original issue, but, perhaps, I am raising another one. > > Cheers...Bran > > > On Feb 18, 2008 11:32 AM, ESPINOZA Huascar 218344 wrote: > > > Hi all, > > Issue 12209 (see below) relates to using '$' not only in variable declaration but also in 'variable call expressions' has been uploaded in the MARTE FTF wiki. Source: Murray Woodside. > > http://www.omgwiki.org/marte/lib/exe/fetch.php?id=annex_b_wg&cache=cache&media=12209_closednochange_ballot1.doc > > I'd like to clarify that at this point we (Hauscar and Séb Demathieu) don't concur in a common resolution with Murray (you'll find the Murray' argumentation at the end of this email). However, I'm providing this initial resolution (closed no change) to open discussion in the mailing list. > > Please let me know you opinion. > > Regards, > > -- > Huascar ESPINOZA, Ph.D. > CEA Saclay > DRT/DTSI/SOL/LISE > 91191 GIF/YVETTE CEDEX > Phone/Fax: +33 1 69 08 45 87 / 20 82 > France > > ___ > Disposition: Closed, no change > OMG Issue No: 12209 > Title: using $ in naming variables (and variable calls) > Source: > Carleton University (Dr. Murray Woodside, cmw@sce.carleton.ca) > > Summary: > In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name. > > Throughout the document there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning. > Examples are found in NFP (Fig 8.9) and many other chapters. > > These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement. > > In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples. > > Resolution: > There are two kinds of VSL expressions related to variables: 'variable declaration' and 'variable call'. In VSL, we use '$' as a prefix only in the declaration notation, and in the 'call', we use only the name. We really need to make difference between both because VSL parsers need to make the difference. > > It's true that having a distinctive symbol for 'variable call' different than other 'names' in a VSL expression 'names', such as enumeration literals or PropertyCallExpression, would help to a fast awareness of VSL variable calls. > However, some reasons would suggest avoiding such a modification: > > -Using only the name for both variables and property call expressions is also used by OCL, and there were not reported any issue related to confusing impressions for language users. > > -In MARTE, most of VSL variable expressions are used at "declaration" level, because in a regular NFP tuple, the value resulting from the evaluation of an expression or variable is specified in a dedicated slot ("value"). This means that VariableCallExpressions are mainly used in Algebraic (math, logical, conditional) expressions, where having a transparent syntax in terms of "parameters" either coming from a UML Property or VSL Variable origin is desirable to avoid complexity in VSL expressions. > > -Having simple and short expressions is a main concern in VSL to embed them in graphical models without charging models, and for easy learning of the language. > > For these reasons, we suggest to close this issue with no change. > > Disposition: Closed, no change > > > > Murray's counterposition: > > -----Message d'origine----- > De : Murray Woodside [mailto:cmw@sce.carleton.ca] > Envoyé : jeudi 14 février 2008 13:06 > À : ESPINOZA Huascar 218344 > Cc : Sébastien Demathieu > Objet : Re: Issue 12209 - Use of '$' in variables > > Using a different name (with a prefix $) in the declaration is an > uncomfortable solution for making the declaration distinct. Better would > be to change the statement, for instance the declaration could have two == > signs. > > Using a $ everywhere reminds a reader > that this is a parameter, an NFP, rather than the name of an object. there > are so many names in a ndesign, and parameters introduce many many more. > > I have found that remembering to use a different name in the declaration > leads to constant errors. > > Murray Woodside > > Distinguished Research Professor > Dept of Systems and Computer Engineering, > Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. > (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca > (http://www.sce.carleton.ca/faculty/woodside.html) > > > > > > > > > > Date: Mon, 25 Feb 2008 09:46:48 -0500 (EST) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: ESPINOZA Huascar 218344 Cc: Bran Selic , marte-ftf@omg.org Subject: RE: RE : Issue 12209: using $ in naming variables (and variable calls) Huascar, your new proposal looks good to me. I dont think the observation notation is a good one to follow. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Mon, 25 Feb 2008, ESPINOZA Huascar 218344 wrote: Hi Bran and Murray, We agree on the idea that having a '$' prefix in names makes easier to identify variables. We should agree also that declaring variables is necessary in order facilitate debug. Indeed, TVL (as Perl, its origin) does use "inline variable declaration". This means that we were able to have a "tagged value": clockRate = ($clock_rate, 'ns') ...without a previous declaration of $clock_rate. We also agree that this cause that it would be hard to debug a mistake like: adjustedClockRate = (1.4 * $clockrate, 'ns') where $clockrate (instead of $clock_rate) is understood as a new variable. For this reason, we force in VSL to declare variables. Up to this point, we seem agree. Now, if we follow your proposal, we will have: clockRate = (let $clock_rate, 'ns') ... adjustedClockRate = (1.4 * $clockrate, 'ns') where $clockrate will be easily detected as a bug. ;;; against the current VSL mechanism that would result in: clockRate = ($clock_rate, 'ns') ... adjustedClockRate = (1.4 * clockrate, 'ns') where $clock_rate is the declaration, and clockrate (instead of clock_rate) will be also detected as a bug. --> If all this is OK (and clear?), we would like to still hear your opinion. Personally, I preferred the current VSL approach because it was more compact, and was exactly as UML Observation notation works (so, I don't believe that it is obscure and confusing). But I'm open to your proposal. I'd like to hear the opinion of the others as well. Rgrd, Huascar ________________________________ De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : lundi 25 février 2008 08:24 À : cmw@sce.carleton.ca Cc : ESPINOZA Huascar 218344; marte-ftf@omg.org Objet : Re: RE : Issue 12209: using $ in naming variables (and variable calls) I was thinking along the same lines as Murray. I prefer the use of a keyword as opposed to a key symbol for statements. (The original idea of $ signs in TVL was twofold: to identify variables and also to make them easier to spot when looking at expressions.) Cheers...Bran On 2/24/08, Murray Woodside wrote: OK, it seems that the $ sign got highjacked to be used as a special signifier instead of designating a variable name, without ever being discussed. I think it would be better to use "let" to designate declarations, consistently with OCL, and keep the $ sign for NFPs. The way it is used now is obscure and confusing. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Mon, 18 Feb 2008, ESPINOZA Huascar 218344 wrote: It seems that there is a misundertanding (please correct me). You think that the '$' is part of the name? If so, I must clarify that the name is always the same. '$' is only a notation keyword. Huascar ________________________________ De: ESPINOZA Huascar 218344 Date: lun. 18/02/2008 20:54 À: Bran Selic Cc: marte-ftf@omg.org Objet : RE : Issue 12209: using $ in naming variables (and variable calls) Thank you Bran. I'd like to clarify two points: -A parser needs to know whether a variable is being declared or used (called). Otherwise, the syntax will be ambiguous. OCL does so. To declare a variable, OCL uses "let " [nameVar: type = initExpr]. In VSL, "let " is replaced by $. -The in, out, and inout qualifiers for a variable declaration are optional. I agree with the usage scenario you mentionned as the general case. This is why this meta-attribute is optional. -->However, I just realized that there is a mistake in the grammar because it is not optional, while in the metamodel it is so. Let me evaluate a better resolution for this issue, while keeping language simplicity and the difference in both kinds of variable expressions (declaration and calls). Regards, Huascar ________________________________ De: Bran Selic [mailto:bran.selic@gmail.com] Date: lun. 18/02/2008 20:37 À: ESPINOZA Huascar 218344 Cc: marte-ftf@omg.org Objet : Re: Issue 12209: using $ in naming variables (and variable calls) Well, I hate to be the one who goes against the flow, but, like Murray, I feel that a consistent use of the $ prefix was a good thing. I cannot see any justifiable technical reason for differentiating the name in a declaration versus its usage/invocation in expressions. So, my suggestion is either remove it from both places or keep it in both. (From what I recall, OCL does not use mixed forms for variables.) In favour of keeping the $ prefix is the fact that it makes it easy to visually spot the variables in an expression. That was the primary reason we chose to use in SPT. This was partly due to the fact that we did not have an "in" or "out" attribute associated with variables in SPT. The principle there was simple: any variables that did not have explicitly assigned values were automatically deemed output variables, while those that had values were "in" variables. Now, this may look like a weakness in the language, but I actually think that the explicit declaration of "in' and "out" has drawbacks, since it forces you to declare the type of analysis you are doing directly in the specification. OTOH, in practice, it is often the case that you want to play around with choosing which values you want to fix (i.e., input values) and which ones you want to compute. This allows various kinds of searches through the possibilities. You may want to fix one value and see what happens, and then, later, leave it as a dependent variable. I am not sure if this is possible in VSL, but if not, then we have lost something by forcing "in" and "out" to be declared in the variable declaration. I realize the latter is a separate topic from the original issue, but, perhaps, I am raising another one. Cheers...Bran On Feb 18, 2008 11:32 AM, ESPINOZA Huascar 218344 wrote: Hi all, Issue 12209 (see below) relates to using '$' not only in variable declaration but also in 'variable call expressions' has been uploaded in the MARTE FTF wiki. Source: Murray Woodside. http://www.omgwiki.org/marte/lib/exe/fetch.php?id=annex_b_wg&cache=cache&media=12209_closednochange_ballot1.doc I'd like to clarify that at this point we (Hauscar and Séb Demathieu) don't concur in a common resolution with Murray (you'll find the Murray' argumentation at the end of this email). However, I'm providing this initial resolution (closed no change) to open discussion in the mailing list. Please let me know you opinion. Regards, -- Huascar ESPINOZA, Ph.D. CEA Saclay DRT/DTSI/SOL/LISE 91191 GIF/YVETTE CEDEX Phone/Fax: +33 1 69 08 45 87 / 20 82 France ___ Disposition: Closed, no change OMG Issue No: 12209 Title: using $ in naming variables (and variable calls) Source: Carleton University (Dr. Murray Woodside, cmw@sce.carleton.ca) Summary: In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name. Throughout the document there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning. Examples are found in NFP (Fig 8.9) and many other chapters. These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement. In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples. Resolution: There are two kinds of VSL expressions related to variables: 'variable declaration' and 'variable call'. In VSL, we use '$' as a prefix only in the declaration notation, and in the 'call', we use only the name. We really need to make difference between both because VSL parsers need to make the difference. It's true that having a distinctive symbol for 'variable call' different than other 'names' in a VSL expression 'names', such as enumeration literals or PropertyCallExpression, would help to a fast awareness of VSL variable calls. However, some reasons would suggest avoiding such a modification: -Using only the name for both variables and property call expressions is also used by OCL, and there were not reported any issue related to confusing impressions for language users. -In MARTE, most of VSL variable expressions are used at "declaration" level, because in a regular NFP tuple, the value resulting from the evaluation of an expression or variable is specified in a dedicated slot ("value"). This means that VariableCallExpressions are mainly used in Algebraic (math, logical, conditional) expressions, where having a transparent syntax in terms of "parameters" either coming from a UML Property or VSL Variable origin is desirable to avoid complexity in VSL expressions. -Having simple and short expressions is a main concern in VSL to embed them in graphical models without charging models, and for easy learning of the language. For these reasons, we suggest to close this issue with no change. Disposition: Closed, no change Murray's counterposition: -----Message d'origine----- De : Murray Woodside [mailto:cmw@sce.carleton.ca] Envoyé : jeudi 14 février 2008 13:06 À : ESPINOZA Huascar 218344 Cc : Sébastien Demathieu Objet : Re: Issue 12209 - Use of '$' in variables Using a different name (with a prefix $) in the declaration is an uncomfortable solution for making the declaration distinct. Better would be to change the statement, for instance the declaration could have two == signs. Using a $ everywhere reminds a reader that this is a parameter, an NFP, rather than the name of an object. there are so many names in a ndesign, and parameters introduce many many more. I have found that remembering to use a different name in the declaration leads to constant errors. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) From: "VanZandt, Lonnie" Date: Mon, 25 Feb 2008 15:21:03 -0000 Subject: RE: RE : Issue 12209: using $ in naming variables (and variable calls) Thread-Topic: RE : Issue 12209: using $ in naming variables (and variable calls) Thread-Index: Ach3owtoTpiZD36tRoyVKUOB/eaPtAAHeVm6 To: , "Bran Selic" Cc: "ESPINOZA Huascar 218344" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m1PG6o5l003537 I thought the primary purpose of the $ was to indicate 'volatility' (as in C) of the variable. I think the use of 'let' etc as an assignment operator can be dropped if one is willing to give up an insistence on using = as both an equivalence operator and as an assignment operator. Let = represent equivalence and let := be assignment and let let out of the grammar. You can still use inline assignment (if you must) by having operator:= return a lvalue so that the expression being assigned can be conditionally tested afterwards. (I grew up with Pascal...) -----Original Message----- From: "Bran Selic" Sent: 25 February 2008 07:24 To: "cmw@sce.carleton.ca" Cc: "ESPINOZA Huascar 218344" , "marte-ftf@omg.org" Subject: Re: RE : Issue 12209: using $ in naming variables (and variable calls) I was thinking along the same lines as Murray. I prefer the use of a keyword as opposed to a key symbol for statements. (The original idea of $ signs in TVL was twofold: to identify variables and also to make them easier to spot when looking at expressions.) Cheers...Bran On 2/24/08, Murray Woodside wrote: OK, it seems that the $ sign got highjacked to be used as a special signifier instead of designating a variable name, without ever being discussed. I think it would be better to use "let" to designate declarations, consistently with OCL, and keep the $ sign for NFPs. The way it is used now is obscure and confusing. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Mon, 18 Feb 2008, ESPINOZA Huascar 218344 wrote: > It seems that there is a misundertanding (please correct me). You think that the '$' is part of the name? If so, I must clarify that the name is always the same. '$' is only a notation keyword. > Huascar > > ________________________________ > > De: ESPINOZA Huascar 218344 > Date: lun. 18/02/2008 20:54 > Ã.: Bran Selic > Cc: marte-ftf@omg.org > Objet : RE : Issue 12209: using $ in naming variables (and variable calls) > > > Thank you Bran. > > I'd like to clarify two points: > > -A parser needs to know whether a variable is being declared or used (called). Otherwise, the syntax will be ambiguous. OCL does so. To declare a variable, OCL uses "let " [nameVar: type = initExpr]. In VSL, "let " is replaced by $. > -The in, out, and inout qualifiers for a variable declaration are optional. I agree with the usage scenario you mentionned as the general case. This is why this meta-attribute is optional. > -->However, I just realized that there is a mistake in the grammar because it is not optional, while in the metamodel it is so. > > Let me evaluate a better resolution for this issue, while keeping language simplicity and the difference in both kinds of variable expressions (declaration and calls). > > Regards, > Huascar > > ________________________________ > > De: Bran Selic [mailto:bran.selic@gmail.com] > Date: lun. 18/02/2008 20:37 > Ã.: ESPINOZA Huascar 218344 > Cc: marte-ftf@omg.org > Objet : Re: Issue 12209: using $ in naming variables (and variable calls) > > > Well, I hate to be the one who goes against the flow, but, like Murray, I feel that a consistent use of the $ prefix was a good thing. I cannot see any justifiable technical reason for differentiating the name in a declaration versus its usage/invocation in expressions. So, my suggestion is either remove it from both places or keep it in both. (From what I recall, OCL does not use mixed forms for variables.) > > In favour of keeping the $ prefix is the fact that it makes it easy to visually spot the variables in an expression. That was the primary reason we chose to use in SPT. This was partly due to the fact that we did not have an "in" or "out" attribute associated with variables in SPT. The principle there was simple: any variables that did not have explicitly assigned values were automatically deemed output variables, while those that had values were "in" variables. > > Now, this may look like a weakness in the language, but I actually think that the explicit declaration of "in' and "out" has drawbacks, since it forces you to declare the type of analysis you are doing directly in the specification. OTOH, in practice, it is often the case that you want to play around with choosing which values you want to fix (i.e., input values) and which ones you want to compute. This allows various kinds of searches through the possibilities. You may want to fix one value and see what happens, and then, later, leave it as a dependent variable. I am not sure if this is possible in VSL, but if not, then we have lost something by forcing "in" and "out" to be declared in the variable declaration. > > I realize the latter is a separate topic from the original issue, but, perhaps, I am raising another one. > > Cheers...Bran > > > On Feb 18, 2008 11:32 AM, ESPINOZA Huascar 218344 wrote: > > > Hi all, > > Issue 12209 (see below) relates to using '$' not only in variable declaration but also in 'variable call expressions' has been uploaded in the MARTE FTF wiki. Source: Murray Woodside. > > http://www.omgwiki.org/marte/lib/exe/fetch.php?id=annex_b_wg&cache=cache &media=12209_closednochange_ballot1.doc > > I'd like to clarify that at this point we (Hauscar and Séb Demathieu) don't concur in a common resolution with Murray (you'll find the Murray' argumentation at the end of this email). However, I'm providing this initial resolution (closed no change) to open discussion in the mailing list. > > Please let me know you opinion. > > Regards, > > -- > Huascar ESPINOZA, Ph.D. > CEA Saclay > DRT/DTSI/SOL/LISE > 91191 GIF/YVETTE CEDEX > Phone/Fax: +33 1 69 08 45 87 / 20 82 > France > > ___ > Disposition: Closed, no change > OMG Issue No: 12209 > Title: using $ in naming variables (and variable calls) > Source: > Carleton University (Dr. Murray Woodside, cmw@sce.carleton.ca) > > Summary: > In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name. > > Throughout the document there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning. > Examples are found in NFP (Fig 8.9) and many other chapters. > > These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement. > > In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples. > > Resolution: > There are two kinds of VSL expressions related to variables: 'variable declaration' and 'variable call'. In VSL, we use '$' as a prefix only in the declaration notation, and in the 'call', we use only the name. We really need to make difference between both because VSL parsers need to make the difference. > > It's true that having a distinctive symbol for 'variable call' different than other 'names' in a VSL expression 'names', such as enumeration literals or PropertyCallExpression, would help to a fast awareness of VSL variable calls. > However, some reasons would suggest avoiding such a modification: > > -Using only the name for both variables and property call expressions is also used by OCL, and there were not reported any issue related to confusing impressions for language users. > > -In MARTE, most of VSL variable expressions are used at "declaration" level, because in a regular NFP tuple, the value resulting from the evaluation of an expression or variable is specified in a dedicated slot ("value"). This means that VariableCallExpressions are mainly used in Algebraic (math, logical, conditional) expressions, where having a transparent syntax in terms of "parameters" either coming from a UML Property or VSL Variable origin is desirable to avoid complexity in VSL expressions. > > -Having simple and short expressions is a main concern in VSL to embed them in graphical models without charging models, and for easy learning of the language. > > For these reasons, we suggest to close this issue with no change. > > Disposition: Closed, no change > > > > Murray's counterposition: > > -----Message d'origine----- > De : Murray Woodside [mailto:cmw@sce.carleton.ca] > Envoyé : jeudi 14 février 2008 13:06 > Ã. : ESPINOZA Huascar 218344 > Cc : Sébastien Demathieu > Objet : Re: Issue 12209 - Use of '$' in variables > > Using a different name (with a prefix $) in the declaration is an > uncomfortable solution for making the declaration distinct. Better would > be to change the statement, for instance the declaration could have two == > signs. > > Using a $ everywhere reminds a reader > that this is a parameter, an NFP, rather than the name of an object. there > are so many names in a ndesign, and parameters introduce many many more. > > I have found that remembering to use a different name in the declaration > leads to constant errors. > > Murray Woodside > > Distinguished Research Professor > Dept of Systems and Computer Engineering, > Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. > (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca > (http://www.sce.carleton.ca/faculty/woodside.html) > > > > > > > > > > Date: Mon, 25 Feb 2008 10:33:26 -0500 (EST) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: "VanZandt, Lonnie" Cc: Bran Selic , ESPINOZA Huascar 218344 , marte-ftf@omg.org Subject: RE: RE : Issue 12209: using $ in naming variables (and variable calls) No, the $ was to indicate a quantitative variable as opposed to an object or method. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Mon, 25 Feb 2008, VanZandt, Lonnie wrote: I thought the primary purpose of the $ was to indicate 'volatility' (as in C) of the variable. I think the use of 'let' etc as an assignment operator can be dropped if one is willing to give up an insistence on using = as both an equivalence operator and as an assignment operator. Let = represent equivalence and let := be assignment and let let out of the grammar. You can still use inline assignment (if you must) by having operator:= return a lvalue so that the expression being assigned can be conditionally tested afterwards. (I grew up with Pascal...) -----Original Message----- From: "Bran Selic" Sent: 25 February 2008 07:24 To: "cmw@sce.carleton.ca" Cc: "ESPINOZA Huascar 218344" , "marte-ftf@omg.org" Subject: Re: RE : Issue 12209: using $ in naming variables (and variable calls) I was thinking along the same lines as Murray. I prefer the use of a keyword as opposed to a key symbol for statements. (The original idea of $ signs in TVL was twofold: to identify variables and also to make them easier to spot when looking at expressions.) Cheers...Bran On 2/24/08, Murray Woodside wrote: OK, it seems that the $ sign got highjacked to be used as a special signifier instead of designating a variable name, without ever being discussed. I think it would be better to use "let" to designate declarations, consistently with OCL, and keep the $ sign for NFPs. The way it is used now is obscure and confusing. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Mon, 18 Feb 2008, ESPINOZA Huascar 218344 wrote: > It seems that there is a misundertanding (please correct me). You think that the '$' is part of the name? If so, I must clarify that the name is always the same. '$' is only a notation keyword. > Huascar > > ________________________________ > > De: ESPINOZA Huascar 218344 > Date: lun. 18/02/2008 20:54 > Ã.: Bran Selic > Cc: marte-ftf@omg.org > Objet : RE : Issue 12209: using $ in naming variables (and variable calls) > > > Thank you Bran. > > I'd like to clarify two points: > > -A parser needs to know whether a variable is being declared or used (called). Otherwise, the syntax will be ambiguous. OCL does so. To declare a variable, OCL uses "let " [nameVar: type = initExpr]. In VSL, "let " is replaced by $. > -The in, out, and inout qualifiers for a variable declaration are optional. I agree with the usage scenario you mentionned as the general case. This is why this meta-attribute is optional. > -->However, I just realized that there is a mistake in the grammar because it is not optional, while in the metamodel it is so. > > Let me evaluate a better resolution for this issue, while keeping language simplicity and the difference in both kinds of variable expressions (declaration and calls). > > Regards, > Huascar > > ________________________________ > > De: Bran Selic [mailto:bran.selic@gmail.com] > Date: lun. 18/02/2008 20:37 > Ã.: ESPINOZA Huascar 218344 > Cc: marte-ftf@omg.org > Objet : Re: Issue 12209: using $ in naming variables (and variable calls) > > > Well, I hate to be the one who goes against the flow, but, like Murray, I feel that a consistent use of the $ prefix was a good thing. I cannot see any justifiable technical reason for differentiating the name in a declaration versus its usage/invocation in expressions. So, my suggestion is either remove it from both places or keep it in both. (From what I recall, OCL does not use mixed forms for variables.) > > In favour of keeping the $ prefix is the fact that it makes it easy to visually spot the variables in an expression. That was the primary reason we chose to use in SPT. This was partly due to the fact that we did not have an "in" or "out" attribute associated with variables in SPT. The principle there was simple: any variables that did not have explicitly assigned values were automatically deemed output variables, while those that had values were "in" variables. > > Now, this may look like a weakness in the language, but I actually think that the explicit declaration of "in' and "out" has drawbacks, since it forces you to declare the type of analysis you are doing directly in the specification. OTOH, in practice, it is often the case that you want to play around with choosing which values you want to fix (i.e., input values) and which ones you want to compute. This allows various kinds of searches through the possibilities. You may want to fix one value and see what happens, and then, later, leave it as a dependent variable. I am not sure if this is possible in VSL, but if not, then we have lost something by forcing "in" and "out" to be declared in the variable declaration. > > I realize the latter is a separate topic from the original issue, but, perhaps, I am raising another one. > > Cheers...Bran > > > On Feb 18, 2008 11:32 AM, ESPINOZA Huascar 218344 wrote: > > > Hi all, > > Issue 12209 (see below) relates to using '$' not only in variable declaration but also in 'variable call expressions' has been uploaded in the MARTE FTF wiki. Source: Murray Woodside. > > http://www.omgwiki.org/marte/lib/exe/fetch.php?id=annex_b_wg&cache=cache &media=12209_closednochange_ballot1.doc > > I'd like to clarify that at this point we (Hauscar and Séb Demathieu) don't concur in a common resolution with Murray (you'll find the Murray' argumentation at the end of this email). However, I'm providing this initial resolution (closed no change) to open discussion in the mailing list. > > Please let me know you opinion. > > Regards, > > -- > Huascar ESPINOZA, Ph.D. > CEA Saclay > DRT/DTSI/SOL/LISE > 91191 GIF/YVETTE CEDEX > Phone/Fax: +33 1 69 08 45 87 / 20 82 > France > > ___ > Disposition: Closed, no change > OMG Issue No: 12209 > Title: using $ in naming variables (and variable calls) > Source: > Carleton University (Dr. Murray Woodside, cmw@sce.carleton.ca) > > Summary: > In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name. > > Throughout the document there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning. > Examples are found in NFP (Fig 8.9) and many other chapters. > > These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement. > > In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples. > > Resolution: > There are two kinds of VSL expressions related to variables: 'variable declaration' and 'variable call'. In VSL, we use '$' as a prefix only in the declaration notation, and in the 'call', we use only the name. We really need to make difference between both because VSL parsers need to make the difference. > > It's true that having a distinctive symbol for 'variable call' different than other 'names' in a VSL expression 'names', such as enumeration literals or PropertyCallExpression, would help to a fast awareness of VSL variable calls. > However, some reasons would suggest avoiding such a modification: > > -Using only the name for both variables and property call expressions is also used by OCL, and there were not reported any issue related to confusing impressions for language users. > > -In MARTE, most of VSL variable expressions are used at "declaration" level, because in a regular NFP tuple, the value resulting from the evaluation of an expression or variable is specified in a dedicated slot ("value"). This means that VariableCallExpressions are mainly used in Algebraic (math, logical, conditional) expressions, where having a transparent syntax in terms of "parameters" either coming from a UML Property or VSL Variable origin is desirable to avoid complexity in VSL expressions. > > -Having simple and short expressions is a main concern in VSL to embed them in graphical models without charging models, and for easy learning of the language. > > For these reasons, we suggest to close this issue with no change. > > Disposition: Closed, no change > > > > Murray's counterposition: > > -----Message d'origine----- > De : Murray Woodside [mailto:cmw@sce.carleton.ca] > Envoyé : jeudi 14 février 2008 13:06 > Ã. : ESPINOZA Huascar 218344 > Cc : Sébastien Demathieu > Objet : Re: Issue 12209 - Use of '$' in variables > > Using a different name (with a prefix $) in the declaration is an > uncomfortable solution for making the declaration distinct. Better would > be to change the statement, for instance the declaration could have two == > signs. > > Using a $ everywhere reminds a reader > that this is a parameter, an NFP, rather than the name of an object. there > are so many names in a ndesign, and parameters introduce many many more. > > I have found that remembering to use a different name in the declaration > leads to constant errors. > > Murray Woodside > > Distinguished Research Professor > Dept of Systems and Computer Engineering, > Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. > (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca Subject: RE: RE : Issue 12209: using $ in naming variables (and variable calls) Date: Thu, 28 Feb 2008 21:29:57 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE : Issue 12209: using $ in naming variables (and variable calls) Thread-Index: Ach3owtoTpiZD36tRoyVKUOB/eaPtACq7KMc From: "VanZandt, Lonnie" To: "Bran Selic" , Cc: "ESPINOZA Huascar 218344" , Having stumbled through the BNF and some Antlr rules for VSL, I think I see that the "$" token only appears in variable declaration statements (which can appear inlined in other VSL expressions). The usage is limited to (sub)statements of the form: [in|out|inout]? $ varname [ : namespaced_typename ] [ = initializing VSL expression ]. For example: in $foo : bar = ( 3, us ) A reason why a token of any form is needed within that statement at all is because the direction qualifier, typifier, and initializer are all optional and the VSL grammar supports another statement atom which is an enum literal reference. Without the $ token, the parser can't disambiguate these two statements: // declare but don't qualify, typify, nor initialize a new variable foo // refer to the globally-scoped bar enum literal bar Of course, constraining the variable declaration statement so that they would have to indicate a direction, provide a type, or explicitly initialize it would all be enough to prevent the ambiguity. That is, an isolated identifier non-namespace-qualified identifier could only be an enum literal. I prefer the $ approach (e.g. $foo = (3, us) ) to "let foo = (3, us)" but would be happy to see directionality be required and then settle for "inout foo = 3". Huascar, did I overlook another use of '$' in the grammar? Lonnie VanZandt Field Applications Engineer Denver, CO Artisan Software Tools mobile: 720 201-1349 desk: 303 482-2943 lonnie.vanzandt@artisansw.com -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Mon 2/25/2008 12:24 AM To: cmw@sce.carleton.ca Cc: ESPINOZA Huascar 218344; marte-ftf@omg.org Subject: Re: RE : Issue 12209: using $ in naming variables (and variable calls) I was thinking along the same lines as Murray. I prefer the use of a keyword as opposed to a key symbol for statements. (The original idea of $ signs in TVL was twofold: to identify variables and also to make them easier to spot when looking at expressions.) Cheers...Bran On 2/24/08, Murray Woodside wrote: OK, it seems that the $ sign got highjacked to be used as a special signifier instead of designating a variable name, without ever being discussed. I think it would be better to use "let" to designate declarations, consistently with OCL, and keep the $ sign for NFPs. The way it is used now is obscure and confusing. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Mon, 18 Feb 2008, ESPINOZA Huascar 218344 wrote: > It seems that there is a misundertanding (please correct me). You think that the '$' is part of the name? If so, I must clarify that the name is always the same. '$' is only a notation keyword. > Huascar > > ________________________________ > > De: ESPINOZA Huascar 218344 > Date: lun. 18/02/2008 20:54 > À: Bran Selic > Cc: marte-ftf@omg.org > Objet : RE : Issue 12209: using $ in naming variables (and variable calls) > > > Thank you Bran. > > I'd like to clarify two points: > > -A parser needs to know whether a variable is being declared or used (called). Otherwise, the syntax will be ambiguous. OCL does so. To declare a variable, OCL uses "let " [nameVar: type = initExpr]. In VSL, "let " is replaced by $. > -The in, out, and inout qualifiers for a variable declaration are optional. I agree with the usage scenario you mentionned as the general case. This is why this meta-attribute is optional. > -->However, I just realized that there is a mistake in the grammar because it is not optional, while in the metamodel it is so. > > Let me evaluate a better resolution for this issue, while keeping language simplicity and the difference in both kinds of variable expressions (declaration and calls). > > Regards, > Huascar > > ________________________________ > > De: Bran Selic [mailto:bran.selic@gmail.com] > Date: lun. 18/02/2008 20:37 > À: ESPINOZA Huascar 218344 > Cc: marte-ftf@omg.org > Objet : Re: Issue 12209: using $ in naming variables (and variable calls) > > > Well, I hate to be the one who goes against the flow, but, like Murray, I feel that a consistent use of the $ prefix was a good thing. I cannot see any justifiable technical reason for differentiating the name in a declaration versus its usage/invocation in expressions. So, my suggestion is either remove it from both places or keep it in both. (From what I recall, OCL does not use mixed forms for variables.) > > In favour of keeping the $ prefix is the fact that it makes it easy to visually spot the variables in an expression. That was the primary reason we chose to use in SPT. This was partly due to the fact that we did not have an "in" or "out" attribute associated with variables in SPT. The principle there was simple: any variables that did not have explicitly assigned values were automatically deemed output variables, while those that had values were "in" variables. > > Now, this may look like a weakness in the language, but I actually think that the explicit declaration of "in' and "out" has drawbacks, since it forces you to declare the type of analysis you are doing directly in the specification. OTOH, in practice, it is often the case that you want to play around with choosing which values you want to fix (i.e., input values) and which ones you want to compute. This allows various kinds of searches through the possibilities. You may want to fix one value and see what happens, and then, later, leave it as a dependent variable. I am not sure if this is possible in VSL, but if not, then we have lost something by forcing "in" and "out" to be declared in the variable declaration. > > I realize the latter is a separate topic from the original issue, but, perhaps, I am raising another one. > > Cheers...Bran > > > On Feb 18, 2008 11:32 AM, ESPINOZA Huascar 218344 wrote: > > > Hi all, > > Issue 12209 (see below) relates to using '$' not only in variable declaration but also in 'variable call expressions' has been uploaded in the MARTE FTF wiki. Source: Murray Woodside. > > http://www.omgwiki.org/marte/lib/exe/fetch.php?id=annex_b_wg&cache=cache&media=12209_closednochange_ballot1.doc > > I'd like to clarify that at this point we (Hauscar and Séb Demathieu) don't concur in a common resolution with Murray (you'll find the Murray' argumentation at the end of this email). However, I'm providing this initial resolution (closed no change) to open discussion in the mailing list. > > Please let me know you opinion. > > Regards, > > -- > Huascar ESPINOZA, Ph.D. > CEA Saclay > DRT/DTSI/SOL/LISE > 91191 GIF/YVETTE CEDEX > Phone/Fax: +33 1 69 08 45 87 / 20 82 > France > > ___ > Disposition: Closed, no change > OMG Issue No: 12209 > Title: using $ in naming variables (and variable calls) > Source: > Carleton University (Dr. Murray Woodside, cmw@sce.carleton.ca) > > Summary: > In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name. > > Throughout the document there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning. > Examples are found in NFP (Fig 8.9) and many other chapters. > > These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement. > > In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples. > > Resolution: > There are two kinds of VSL expressions related to variables: 'variable declaration' and 'variable call'. In VSL, we use '$' as a prefix only in the declaration notation, and in the 'call', we use only the name. We really need to make difference between both because VSL parsers need to make the difference. > > It's true that having a distinctive symbol for 'variable call' different than other 'names' in a VSL expression 'names', such as enumeration literals or PropertyCallExpression, would help to a fast awareness of VSL variable calls. > However, some reasons would suggest avoiding such a modification: > > -Using only the name for both variables and property call expressions is also used by OCL, and there were not reported any issue related to confusing impressions for language users. > > -In MARTE, most of VSL variable expressions are used at "declaration" level, because in a regular NFP tuple, the value resulting from the evaluation of an expression or variable is specified in a dedicated slot ("value"). This means that VariableCallExpressions are mainly used in Algebraic (math, logical, conditional) expressions, where having a transparent syntax in terms of "parameters" either coming from a UML Property or VSL Variable origin is desirable to avoid complexity in VSL expressions. > > -Having simple and short expressions is a main concern in VSL to embed them in graphical models without charging models, and for easy learning of the language. > > For these reasons, we suggest to close this issue with no change. > > Disposition: Closed, no change > > > > Murray's counterposition: > > -----Message d'origine----- > De : Murray Woodside [mailto:cmw@sce.carleton.ca] > Envoyé : jeudi 14 février 2008 13:06 > À : ESPINOZA Huascar 218344 > Cc : Sébastien Demathieu > Objet : Re: Issue 12209 - Use of '$' in variables > > Using a different name (with a prefix $) in the declaration is an > uncomfortable solution for making the declaration distinct. Better would > be to change the statement, for instance the declaration could have two == > signs. > > Using a $ everywhere reminds a reader > that this is a parameter, an NFP, rather than the name of an object. there > are so many names in a ndesign, and parameters introduce many many more. > > I have found that remembering to use a different name in the declaration > leads to constant errors. > > Murray Woodside > > Distinguished Research Professor > Dept of Systems and Computer Engineering, > Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. > (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca > (http://www.sce.carleton.ca/faculty/woodside.html) > > > > > > > > > > Subject: PRE-VOTING on Issue 12209 Date: Fri, 28 Mar 2008 10:43:59 +0100 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: PRE-VOTING on Issue 12209 Thread-Index: AciQXRghSA7t/tZRRIKOIF0nyZr+0QAWUXWw From: "ESPINOZA Huascar 218344" To: "GERARD Sebastien 166342" , X-OriginalArrivalTime: 28 Mar 2008 09:43:59.0255 (UTC) FILETIME=[3F6D0270:01C890B8] Hi all, Issue 12209, related to the notation in variables ('$', 'let ', etc.) with a current resolution ClosedNoChange has not a consensus. Bran recommended following a pre-voting process. However, I wrote the 'Resolved' resolution just now. I don't know if we will have the time to include it in Ballot 1, but I'd like to begin this pre-voting now. Here attached you will find the two contender resolutions. **Please vote for one of these resolutions: 'ClosedNoChange' or 'Resolved'** The winner resolution will be included in the Ballot (I hope Ballot 1). Meanwhile, we (at CEA) will have a "pre-pre-voting" process because I prefer 'ClosedNoChange' whereas it seems that Séb prefers 'Resolved'. Séb: in addition, issue 11878 has been moved to Ballot 2 (as indicated in the wiki). Please remove it from ballot 1. Best regards, Huascar -----Message d'origine----- De : GERARD Sebastien 166342 Envoyé : jeudi 27 mars 2008 23:51 À : marte-ftf@omg.org Objet : MARTE FTF: draft ballot 1 Hi all, here is the drft for the ballot1. I propose to start the vote on next Monday in order to give you some time to check every think is ok for this ballot and add new resoltuion if you wnt. For Lonnie: revised text section of the issue 11771 needs to be completed. If you can do it before next Monday, it is perfect. Othewie, I propose to transfert it in the next ballot. Cheers, Sébastien. 12209_Resolved_Ballot1.doc Date: Fri, 28 Mar 2008 10:59:32 +0100 From: Sébastien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: ESPINOZA Huascar 218344 Cc: GERARD Sebastien 166342 , marte-ftf@omg.org Subject: Re: PRE-VOTING on Issue 12209 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m2SA14LU023756 Huascar, all, I understand that the proposed change will relates only to the syntax and does change the ability to have inline variable declaration as in "fp (priority=out$loc_prio:Integer:Integer)" for SchedulableResource.schedParam (current syntax). Am I right ? Thanks, Sébastien ESPINOZA Huascar 218344 a écrit : Hi all, Issue 12209, related to the notation in variables ('$', 'let ', etc.) with a current resolution ClosedNoChange has not a consensus. Bran recommended following a pre-voting process. However, I wrote the 'Resolved' resolution just now. I don't know if we will have the time to include it in Ballot 1, but I'd like to begin this pre-voting now. Here attached you will find the two contender resolutions. **Please vote for one of these resolutions: 'ClosedNoChange' or 'Resolved'** The winner resolution will be included in the Ballot (I hope Ballot 1). Meanwhile, we (at CEA) will have a "pre-pre-voting" process because I prefer 'ClosedNoChange' whereas it seems that Séb prefers 'Resolved'. Séb: in addition, issue 11878 has been moved to Ballot 2 (as indicated in the wiki). Please remove it from ballot 1. Best regards, Huascar -----Message d'origine----- De : GERARD Sebastien 166342 Envoyé : jeudi 27 mars 2008 23:51 À : marte-ftf@omg.org Objet : MARTE FTF: draft ballot 1 Hi all, here is the drft for the ballot1. I propose to start the vote on next Monday in order to give you some time to check every think is ok for this ballot and add new resoltuion if you wnt. For Lonnie: revised text section of the issue 11771 needs to be completed. If you can do it before next Monday, it is perfect. Othewie, I propose to transfert it in the next ballot. Cheers, Sébastien. Subject: RE: PRE-VOTING on Issue 12209 Date: Fri, 28 Mar 2008 11:05:05 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRE-VOTING on Issue 12209 Thread-Index: AciQum9ZK3JlQvHhTHmaYnB2lx2sVgAAC3WA From: "ESPINOZA Huascar 218344" To: Sébastien Demathieu Cc: "GERARD Sebastien 166342" , X-OriginalArrivalTime: 28 Mar 2008 10:05:06.0404 (UTC) FILETIME=[32B49A40:01C890BB] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m2SA5Vw2024678 Séb, There is no "inline" variable declarations for none of the resolutions. Regards, Huascar -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : vendredi 28 mars 2008 11:00 À : ESPINOZA Huascar 218344 Cc : GERARD Sebastien 166342; marte-ftf@omg.org Objet : Re: PRE-VOTING on Issue 12209 Huascar, all, I understand that the proposed change will relates only to the syntax and does change the ability to have inline variable declaration as in "fp (priority=out$loc_prio:Integer:Integer)" for SchedulableResource.schedParam (current syntax). Am I right ? Thanks, Sébastien ESPINOZA Huascar 218344 a écrit : > Hi all, > > Issue 12209, related to the notation in variables ('$', 'let ', etc.) with a current resolution ClosedNoChange has not a consensus. Bran recommended following a pre-voting process. However, I wrote the 'Resolved' resolution just now. I don't know if we will have the time to include it in Ballot 1, but I'd like to begin this pre-voting now. > > Here attached you will find the two contender resolutions. > > **Please vote for one of these resolutions: 'ClosedNoChange' or 'Resolved'** > > The winner resolution will be included in the Ballot (I hope Ballot 1). > > Meanwhile, we (at CEA) will have a "pre-pre-voting" process because I prefer 'ClosedNoChange' whereas it seems that Séb prefers 'Resolved'. > > Séb: in addition, issue 11878 has been moved to Ballot 2 (as indicated in the wiki). Please remove it from ballot 1. > > Best regards, > > Huascar > > > > > > -----Message d'origine----- > De : GERARD Sebastien 166342 > Envoyé : jeudi 27 mars 2008 23:51 > À : marte-ftf@omg.org > Objet : MARTE FTF: draft ballot 1 > > Hi all, > > here is the drft for the ballot1. I propose to start the vote on next Monday in order to give you some time to check every think is ok for this ballot and add new resoltuion if you wnt. > > For Lonnie: revised text section of the issue 11771 needs to be completed. If you can do it before next Monday, it is perfect. Othewie, I propose to transfert it in the next ballot. > > Cheers, > > Sébastien. > Date: Fri, 28 Mar 2008 12:02:22 +0100 From: Sébastien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: ESPINOZA Huascar 218344 Cc: GERARD Sebastien 166342 , marte-ftf@omg.org Subject: Re: PRE-VOTING on Issue 12209 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m2SB4kJo003313 Okay, the term "inline" may not be appropriate. What I meant is to be able to declare a variable within a tuple or a choice, tentatively through the "expr" member of a ValueSpecification. In the case of the scheduling parameter expression, if we consider the new syntax, would it be valid to write: fp (priority= (expr= let out loc_prio:Integer:Integer ) ) where (loc_prio is the name of the variable) ? Sébastien ESPINOZA Huascar 218344 a écrit : Séb, There is no "inline" variable declarations for none of the resolutions. Regards, Huascar -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : vendredi 28 mars 2008 11:00 À : ESPINOZA Huascar 218344 Cc : GERARD Sebastien 166342; marte-ftf@omg.org Objet : Re: PRE-VOTING on Issue 12209 Huascar, all, I understand that the proposed change will relates only to the syntax and does change the ability to have inline variable declaration as in "fp (priority=out$loc_prio:Integer:Integer)" for SchedulableResource.schedParam (current syntax). Am I right ? Thanks, Sébastien ESPINOZA Huascar 218344 a écrit : Hi all, Issue 12209, related to the notation in variables ('$', 'let ', etc.) with a current resolution ClosedNoChange has not a consensus. Bran recommended following a pre-voting process. However, I wrote the 'Resolved' resolution just now. I don't know if we will have the time to include it in Ballot 1, but I'd like to begin this pre-voting now. Here attached you will find the two contender resolutions. **Please vote for one of these resolutions: 'ClosedNoChange' or 'Resolved'** The winner resolution will be included in the Ballot (I hope Ballot 1). Meanwhile, we (at CEA) will have a "pre-pre-voting" process because I prefer 'ClosedNoChange' whereas it seems that Séb prefers 'Resolved'. Séb: in addition, issue 11878 has been moved to Ballot 2 (as indicated in the wiki). Please remove it from ballot 1. Best regards, Huascar -----Message d'origine----- De : GERARD Sebastien 166342 Envoyé : jeudi 27 mars 2008 23:51 À : marte-ftf@omg.org Objet : MARTE FTF: draft ballot 1 Hi all, here is the drft for the ballot1. I propose to start the vote on next Monday in order to give you some time to check every think is ok for this ballot and add new resoltuion if you wnt. For Lonnie: revised text section of the issue 11771 needs to be completed. If you can do it before next Monday, it is perfect. Othewie, I propose to transfert it in the next ballot. Cheers, Sébastien. Subject: RE: PRE-VOTING on Issue 12209 Date: Fri, 28 Mar 2008 12:07:00 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRE-VOTING on Issue 12209 Thread-Index: AciQwzh8nqdKg3WAQ2uXSC8jpbS+ewAAGErg From: "ESPINOZA Huascar 218344" To: Sébastien Demathieu Cc: "GERARD Sebastien 166342" , X-OriginalArrivalTime: 28 Mar 2008 11:07:02.0054 (UTC) FILETIME=[D967CC60:01C890C3] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m2SB8mCB004139 As proposed by Murray, the '$' should be part of the variable name, always. This is what the 'Resolved' resolution proposes. Please, proposes other resolution if you feel that none of the resolutions is sufficient. Thank you. Huascar -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : vendredi 28 mars 2008 12:02 À : ESPINOZA Huascar 218344 Cc : GERARD Sebastien 166342; marte-ftf@omg.org Objet : Re: PRE-VOTING on Issue 12209 Okay, the term "inline" may not be appropriate. What I meant is to be able to declare a variable within a tuple or a choice, tentatively through the "expr" member of a ValueSpecification. In the case of the scheduling parameter expression, if we consider the new syntax, would it be valid to write: > fp (priority= (expr= let out loc_prio:Integer:Integer ) ) where (loc_prio is the name of the variable) ? Sébastien ESPINOZA Huascar 218344 a écrit : > Séb, > > There is no "inline" variable declarations for none of the resolutions. > > Regards, > > Huascar > > -----Message d'origine----- > De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] > Envoyé : vendredi 28 mars 2008 11:00 > À : ESPINOZA Huascar 218344 > Cc : GERARD Sebastien 166342; marte-ftf@omg.org > Objet : Re: PRE-VOTING on Issue 12209 > > Huascar, all, > > I understand that the proposed change will relates only to the syntax > and does change the ability to have inline variable declaration > as in "fp (priority=out$loc_prio:Integer:Integer)" for > SchedulableResource.schedParam (current syntax). > > Am I right ? > > Thanks, > > Sébastien > > > > ESPINOZA Huascar 218344 a écrit : > >> Hi all, >> >> Issue 12209, related to the notation in variables ('$', 'let ', etc.) with a current resolution ClosedNoChange has not a consensus. Bran recommended following a pre-voting process. However, I wrote the 'Resolved' resolution just now. I don't know if we will have the time to include it in Ballot 1, but I'd like to begin this pre-voting now. >> >> Here attached you will find the two contender resolutions. >> >> **Please vote for one of these resolutions: 'ClosedNoChange' or 'Resolved'** >> >> The winner resolution will be included in the Ballot (I hope Ballot 1). >> >> Meanwhile, we (at CEA) will have a "pre-pre-voting" process because I prefer 'ClosedNoChange' whereas it seems that Séb prefers 'Resolved'. >> >> Séb: in addition, issue 11878 has been moved to Ballot 2 (as indicated in the wiki). Please remove it from ballot 1. >> >> Best regards, >> >> Huascar >> >> >> >> >> >> -----Message d'origine----- >> De : GERARD Sebastien 166342 >> Envoyé : jeudi 27 mars 2008 23:51 >> À : marte-ftf@omg.org >> Objet : MARTE FTF: draft ballot 1 >> >> Hi all, >> >> here is the drft for the ballot1. I propose to start the vote on next Monday in order to give you some time to check every think is ok for this ballot and add new resoltuion if you wnt. >> >> For Lonnie: revised text section of the issue 11771 needs to be completed. If you can do it before next Monday, it is perfect. Othewie, I propose to transfert it in the next ballot. >> >> Cheers, >> >> Sébastien. >> >> Date: Fri, 28 Mar 2008 12:30:04 +0100 From: Sébastien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: ESPINOZA Huascar 218344 Cc: GERARD Sebastien 166342 , marte-ftf@omg.org, cmw@sce.carleton.ca Subject: Re: PRE-VOTING on Issue 12209 Currently, we use '$' for variable declarations and just the variable name for variable call expressions (VarCallExpression). I'm fine with using 'let' for variable declaration and '$'+variable name for variable call expression. However, it seems that the '$' is rather a keyword than a part of a variable name. Therefore, a variable declaration would be 'let out variableName:Integer'. Introducing '$' in both variable declaration and variable call expression might create difficulties in the parsing of VSL expression. Murray, please can you let us know what you think about it? Thanks, Sébastien ESPINOZA Huascar 218344 a écrit : As proposed by Murray, the '$' should be part of the variable name, always. This is what the 'Resolved' resolution proposes. Please, proposes other resolution if you feel that none of the resolutions is sufficient. Thank you. Huascar -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : vendredi 28 mars 2008 12:02 À : ESPINOZA Huascar 218344 Cc : GERARD Sebastien 166342; marte-ftf@omg.org Objet : Re: PRE-VOTING on Issue 12209 Okay, the term "inline" may not be appropriate. What I meant is to be able to declare a variable within a tuple or a choice, tentatively through the "expr" member of a ValueSpecification. In the case of the scheduling parameter expression, if we consider the new syntax, would it be valid to write: fp (priority= (expr= let out loc_prio:Integer:Integer ) ) where (loc_prio is the name of the variable) ? Sébastien ESPINOZA Huascar 218344 a écrit : Séb, There is no "inline" variable declarations for none of the resolutions. Regards, Huascar -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : vendredi 28 mars 2008 11:00 À : ESPINOZA Huascar 218344 Cc : GERARD Sebastien 166342; marte-ftf@omg.org Objet : Re: PRE-VOTING on Issue 12209 Huascar, all, I understand that the proposed change will relates only to the syntax and does change the ability to have inline variable declaration as in "fp (priority=out$loc_prio:Integer:Integer)" for SchedulableResource.schedParam (current syntax). Am I right ? Thanks, Sébastien ESPINOZA Huascar 218344 a écrit : Hi all, Issue 12209, related to the notation in variables ('$', 'let ', etc.) with a current resolution ClosedNoChange has not a consensus. Bran recommended following a pre-voting process. However, I wrote the 'Resolved' resolution just now. I don't know if we will have the time to include it in Ballot 1, but I'd like to begin this pre-voting now. Here attached you will find the two contender resolutions. **Please vote for one of these resolutions: 'ClosedNoChange' or 'Resolved'** The winner resolution will be included in the Ballot (I hope Ballot 1). Meanwhile, we (at CEA) will have a "pre-pre-voting" process because I prefer 'ClosedNoChange' whereas it seems that Séb prefers 'Resolved'. Séb: in addition, issue 11878 has been moved to Ballot 2 (as indicated in the wiki). Please remove it from ballot 1. Best regards, Huascar -----Message d'origine----- De : GERARD Sebastien 166342 Envoyé : jeudi 27 mars 2008 23:51 À : marte-ftf@omg.org Objet : MARTE FTF: draft ballot 1 Hi all, here is the drft for the ballot1. I propose to start the vote on next Monday in order to give you some time to check every think is ok for this ballot and add new resoltuion if you wnt. For Lonnie: revised text section of the issue 11771 needs to be completed. If you can do it before next Monday, it is perfect. Othewie, I propose to transfert it in the next ballot. Cheers, Sébastien. Date: Fri, 28 Mar 2008 10:09:09 -0400 (EDT) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: Sébastien Demathieu Cc: ESPINOZA Huascar 218344 , GERARD Sebastien 166342 , marte-ftf@omg.org Subject: Re: PRE-VOTING on Issue 12209 I would prefer that $ be not a keyword, but part of the syntax of a quantitative variable name. An example of this use id PERL, in which all variables are marked by beginning with $. Then let can be the keyword where that is needed. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Fri, 28 Mar 2008, Sébastien Demathieu wrote: Currently, we use '$' for variable declarations and just the variable name for variable call expressions (VarCallExpression). I'm fine with using 'let' for variable declaration and '$'+variable name for variable call expression. However, it seems that the '$' is rather a keyword than a part of a variable name. Therefore, a variable declaration would be 'let out variableName:Integer'. Introducing '$' in both variable declaration and variable call expression might create difficulties in the parsing of VSL expression. Murray, please can you let us know what you think about it? Thanks, Sébastien ESPINOZA Huascar 218344 a écrit : As proposed by Murray, the '$' should be part of the variable name, always. This is what the 'Resolved' resolution proposes. Please, proposes other resolution if you feel that none of the resolutions is sufficient. Thank you. Huascar -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : vendredi 28 mars 2008 12:02 À : ESPINOZA Huascar 218344 Cc : GERARD Sebastien 166342; marte-ftf@omg.org Objet : Re: PRE-VOTING on Issue 12209 Okay, the term "inline" may not be appropriate. What I meant is to be able to declare a variable within a tuple or a choice, tentatively through the "expr" member of a ValueSpecification. In the case of the scheduling parameter expression, if we consider the new syntax, would it be valid to write: fp (priority= (expr= let out loc_prio:Integer:Integer ) ) where (loc_prio is the name of the variable) ? Sébastien ESPINOZA Huascar 218344 a écrit : Séb, There is no "inline" variable declarations for none of the resolutions. Regards, Huascar -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : vendredi 28 mars 2008 11:00 À : ESPINOZA Huascar 218344 Cc : GERARD Sebastien 166342; marte-ftf@omg.org Objet : Re: PRE-VOTING on Issue 12209 Huascar, all, I understand that the proposed change will relates only to the syntax and does change the ability to have inline variable declaration as in "fp (priority=out$loc_prio:Integer:Integer)" for SchedulableResource.schedParam (current syntax). Am I right ? Thanks, Sébastien ESPINOZA Huascar 218344 a écrit : Hi all, Issue 12209, related to the notation in variables ('$', 'let ', etc.) with a current resolution ClosedNoChange has not a consensus. Bran recommended following a pre-voting process. However, I wrote the 'Resolved' resolution just now. I don't know if we will have the time to include it in Ballot 1, but I'd like to begin this pre-voting now. Here attached you will find the two contender resolutions. **Please vote for one of these resolutions: 'ClosedNoChange' or 'Resolved'** The winner resolution will be included in the Ballot (I hope Ballot 1). Meanwhile, we (at CEA) will have a "pre-pre-voting" process because I prefer 'ClosedNoChange' whereas it seems that Séb prefers 'Resolved'. Séb: in addition, issue 11878 has been moved to Ballot 2 (as indicated in the wiki). Please remove it from ballot 1. Best regards, Huascar -----Message d'origine----- De : GERARD Sebastien 166342 Envoyé : jeudi 27 mars 2008 23:51 À : marte-ftf@omg.org Objet : MARTE FTF: draft ballot 1 Hi all, here is the drft for the ballot1. I propose to start the vote on next Monday in order to give you some time to check every think is ok for this ballot and add new resoltuion if you wnt. For Lonnie: revised text section of the issue 11771 needs to be completed. If you can do it before next Monday, it is perfect. Othewie, I propose to transfert it in the next ballot. Cheers, Sébastien. Subject: RE: PRE-VOTING on Issue 12209 Date: Fri, 28 Mar 2008 15:33:34 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRE-VOTING on Issue 12209 Thread-Index: AciQ3mQROn3JFjUvSxCiqQeEr3nNsgAABCYw From: To: , Cc: , , X-OriginalArrivalTime: 28 Mar 2008 14:33:34.0713 (UTC) FILETIME=[B4017E90:01C890E0] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m2SEYlaV014903 Hi Murray, Just for information (I missed previous discussion thread on this topic): Could you explain why there is a need to use the "hacking-like" '$' special character to reference variables? Why "javascript" style cannot be used here? Like having a 'var' or a 'let' keyword for declararing the variable and then usage of "plain" variable names (with no special characters) to reference to them? Thanks, Mariano -----Message d'origine----- De : Murray Woodside [mailto:cmw@sce.carleton.ca] Envoyé : vendredi 28 mars 2008 15:09 À : Sébastien Demathieu Cc : ESPINOZA Huascar 218344; GERARD Sebastien 166342; marte-ftf@omg.org Objet : Re: PRE-VOTING on Issue 12209 I would prefer that $ be not a keyword, but part of the syntax of a quantitative variable name. An example of this use id PERL, in which all variables are marked by beginning with $. Then let can be the keyword where that is needed. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Fri, 28 Mar 2008, Sébastien Demathieu wrote: > Currently, we use '$' for variable declarations and just the variable > name for variable call expressions (VarCallExpression). > > I'm fine with using 'let' for variable declaration and '$'+variable > name for variable call expression. However, it seems that the '$' is > rather a keyword than a part of a variable name. Therefore, a variable > declaration would be 'let out variableName:Integer'. > Introducing '$' in both variable declaration and variable call > expression might create difficulties in the parsing of VSL expression. > > Murray, please can you let us know what you think about it? > > Thanks, > > Sébastien > > > > ESPINOZA Huascar 218344 a écrit : >> As proposed by Murray, the '$' should be part of the variable name, always. >> This is what the 'Resolved' resolution proposes. >> >> Please, proposes other resolution if you feel that none of the >> resolutions is sufficient. >> >> Thank you. >> >> Huascar >> >> >> -----Message d'origine----- >> De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] >> Envoyé : vendredi 28 mars 2008 12:02 >> À : ESPINOZA Huascar 218344 >> Cc : GERARD Sebastien 166342; marte-ftf@omg.org Objet : Re: >> PRE-VOTING on Issue 12209 >> >> Okay, the term "inline" may not be appropriate. What I meant is to be >> able to declare a variable within a tuple or a choice, tentatively >> through the "expr" member of a ValueSpecification. >> >> In the case of the scheduling parameter expression, if we consider >> the new syntax, would it be valid to write: >> >>> fp (priority= (expr= let out loc_prio:Integer:Integer ) ) >>> >> where (loc_prio is the name of the variable) ? >> >> Sébastien >> >> >> ESPINOZA Huascar 218344 a écrit : >> >>> Séb, >>> >>> There is no "inline" variable declarations for none of the resolutions. >>> >>> Regards, >>> >>> Huascar >>> >>> -----Message d'origine----- >>> De : Sébastien Demathieu >>> [mailto:sebastien.demathieu@thalesgroup.com] >>> Envoyé : vendredi 28 mars 2008 11:00 À : ESPINOZA Huascar 218344 Cc >>> : GERARD Sebastien 166342; marte-ftf@omg.org Objet : Re: PRE-VOTING >>> on Issue 12209 >>> >>> Huascar, all, >>> >>> I understand that the proposed change will relates only to the >>> syntax and does change the ability to have inline variable >>> declaration as in "fp (priority=out$loc_prio:Integer:Integer)" for >>> SchedulableResource.schedParam (current syntax). >>> >>> Am I right ? >>> >>> Thanks, >>> >>> Sébastien >>> >>> >>> >>> ESPINOZA Huascar 218344 a écrit : >>> >>>> Hi all, >>>> >>>> Issue 12209, related to the notation in variables ('$', 'let ', >>>> etc.) with a current resolution ClosedNoChange has not a consensus. >>>> Bran recommended following a pre-voting process. However, I wrote >>>> the 'Resolved' resolution just now. I don't know if we will have >>>> the time to include it in Ballot 1, but I'd like to begin this pre-voting now. >>>> >>>> Here attached you will find the two contender resolutions. >>>> >>>> **Please vote for one of these resolutions: 'ClosedNoChange' or >>>> 'Resolved'** >>>> >>>> The winner resolution will be included in the Ballot (I hope Ballot 1). >>>> >>>> Meanwhile, we (at CEA) will have a "pre-pre-voting" process because >>>> I prefer 'ClosedNoChange' whereas it seems that Séb prefers 'Resolved'. >>>> >>>> Séb: in addition, issue 11878 has been moved to Ballot 2 (as >>>> indicated in the wiki). Please remove it from ballot 1. >>>> >>>> Best regards, >>>> >>>> Huascar >>>> >>>> >>>> >>>> >>>> >>>> -----Message d'origine----- >>>> De : GERARD Sebastien 166342 Envoyé : jeudi 27 mars 2008 23:51 À : >>>> marte-ftf@omg.org Objet : MARTE FTF: draft ballot 1 >>>> >>>> Hi all, >>>> >>>> here is the drft for the ballot1. I propose to start the vote on >>>> next Monday in order to give you some time to check every think is >>>> ok for this ballot and add new resoltuion if you wnt. >>>> >>>> For Lonnie: revised text section of the issue 11771 needs to be >>>> completed. If you can do it before next Monday, it is perfect. >>>> Othewie, I propose to transfert it in the next ballot. >>>> >>>> Cheers, >>>> >>>> Sébastien. >>>> Subject: RE: PRE-VOTING on Issue 12209 Date: Fri, 28 Mar 2008 15:03:33 -0000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRE-VOTING on Issue 12209 Thread-Index: AciQwzh8nqdKg3WAQ2uXSC8jpbS+ewAAGErgAAeYgik= From: "VanZandt, Lonnie" To: "ESPINOZA Huascar 218344" , S.©bastien Demathieu Cc: "GERARD Sebastien 166342" , As one who is playing around with a VSL grammar, we ought to be able to clean up that grammar so that we do not have to concatenate the direction, declaration token, and variable like "out$myvar". We ought to be able to write "out $myvar" and, in fact, ought to be _forced_ to include whitespace between the direction keyword and the declaration token. I do not care much for any particular declaration token as long as it does not make difficult the parsing of unary operator expressions. For example, "-" would be a really bad choice. I'm not clear how we could have VSL-scoped variables without inline declarations because there is no way to express a collection of value specifications within the properties that are typed as value_specifications. That is, there is no predicate such as "value_specification -> specification ( SEMI specification )*". The implication is that a value_specification is either only a declarative statement or is a specification potentially containing inline declarations. Lonnie VanZandt Field Applications Engineer Denver, CO Artisan Software Tools mobile: 720 201-1349 desk: 303 482-2943 lonnie.vanzandt@artisansw.com -------------------------------------------------------------------------------- From: ESPINOZA Huascar 218344 [mailto:Huascar.ESPINOZA@cea.fr] Sent: Fri 3/28/2008 5:07 AM To: Sébastien Demathieu Cc: GERARD Sebastien 166342; marte-ftf@omg.org Subject: RE: PRE-VOTING on Issue 12209 As proposed by Murray, the '$' should be part of the variable name, always. This is what the 'Resolved' resolution proposes. Please, proposes other resolution if you feel that none of the resolutions is sufficient. Thank you. Huascar -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : vendredi 28 mars 2008 12:02 À : ESPINOZA Huascar 218344 Cc : GERARD Sebastien 166342; marte-ftf@omg.org Objet : Re: PRE-VOTING on Issue 12209 Okay, the term "inline" may not be appropriate. What I meant is to be able to declare a variable within a tuple or a choice, tentatively through the "expr" member of a ValueSpecification. In the case of the scheduling parameter expression, if we consider the new syntax, would it be valid to write: > fp (priority= (expr= let out loc_prio:Integer:Integer ) ) where (loc_prio is the name of the variable) ? Sébastien ESPINOZA Huascar 218344 a écrit : > Séb, > > There is no "inline" variable declarations for none of the resolutions. > > Regards, > > Huascar > > -----Message d'origine----- > De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] > Envoyé : vendredi 28 mars 2008 11:00 > À : ESPINOZA Huascar 218344 > Cc : GERARD Sebastien 166342; marte-ftf@omg.org > Objet : Re: PRE-VOTING on Issue 12209 > > Huascar, all, > > I understand that the proposed change will relates only to the syntax > and does change the ability to have inline variable declaration > as in "fp (priority=out$loc_prio:Integer:Integer)" for > SchedulableResource.schedParam (current syntax). > > Am I right ? > > Thanks, > > Sébastien > > > > ESPINOZA Huascar 218344 a écrit : > >> Hi all, >> >> Issue 12209, related to the notation in variables ('$', 'let ', etc.) with a current resolution ClosedNoChange has not a consensus. Bran recommended following a pre-voting process. However, I wrote the 'Resolved' resolution just now. I don't know if we will have the time to include it in Ballot 1, but I'd like to begin this pre-voting now. >> >> Here attached you will find the two contender resolutions. >> >> **Please vote for one of these resolutions: 'ClosedNoChange' or 'Resolved'** >> >> The winner resolution will be included in the Ballot (I hope Ballot 1). >> >> Meanwhile, we (at CEA) will have a "pre-pre-voting" process because I prefer 'ClosedNoChange' whereas it seems that Séb prefers 'Resolved'. >> >> Séb: in addition, issue 11878 has been moved to Ballot 2 (as indicated in the wiki). Please remove it from ballot 1. >> >> Best regards, >> >> Huascar >> >> >> >> >> >> -----Message d'origine----- >> De : GERARD Sebastien 166342 >> Envoyé : jeudi 27 mars 2008 23:51 >> À : marte-ftf@omg.org >> Objet : MARTE FTF: draft ballot 1 >> >> Hi all, >> >> here is the drft for the ballot1. I propose to start the vote on next Monday in order to give you some time to check every think is ok for this ballot and add new resoltuion if you wnt. >> >> For Lonnie: revised text section of the issue 11771 needs to be completed. If you can do it before next Monday, it is perfect. Othewie, I propose to transfert it in the next ballot. >> >> Cheers, >> >> Sébastien. >> >> Subject: RE : PRE-VOTING on Issue 12209 Date: Sat, 29 Mar 2008 16:52:08 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRE-VOTING on Issue 12209 Thread-Index: AciQ3mQROn3JFjUvSxCiqQeEr3nNsgAABCYwADV+c30AABppzw== From: "ESPINOZA Huascar 218344" To: Cc: X-OriginalArrivalTime: 29 Mar 2008 15:52:54.0278 (UTC) FILETIME=[F3573A60:01C891B4] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m2TFufDK027615 Hi Mariano, A message from Bran could answer to your question.... > ________________________________________ > De : Bran Selic [mailto:bran.selic@gmail.com ] > Envoyé : lundi 25 février 2008 08:24 > À : cmw@sce.carleton.ca > Cc : ESPINOZA Huascar 218344; marte-ftf@omg.org > Objet : Re: RE : Issue 12209: using $ in naming variables (and variable calls) > > I was thinking along the same lines as Murray. I prefer the use of a keyword as opposed to a key symbol for statements. (The original idea of $ signs in TVL was twofold: to identify variables and also to make them easier to spot when looking at expressions.) > > Cheers...Bran > > ________________________________ De: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Date: ven. 28/03/2008 15:33 À: cmw@sce.carleton.ca; sebastien.demathieu@thalesgroup.com Cc: ESPINOZA Huascar 218344; GERARD Sebastien 166342; marte-ftf@omg.org Objet : RE: PRE-VOTING on Issue 12209 Hi Murray, Just for information (I missed previous discussion thread on this topic): Could you explain why there is a need to use the "hacking-like" '$' special character to reference variables? Why "javascript" style cannot be used here? Like having a 'var' or a 'let' keyword for declararing the variable and then usage of "plain" variable names (with no special characters) to reference to them? Thanks, Mariano -----Message d'origine----- De : Murray Woodside [mailto:cmw@sce.carleton.ca] Envoyé : vendredi 28 mars 2008 15:09 À : Sébastien Demathieu Cc : ESPINOZA Huascar 218344; GERARD Sebastien 166342; marte-ftf@omg.org Objet : Re: PRE-VOTING on Issue 12209 I would prefer that $ be not a keyword, but part of the syntax of a quantitative variable name. An example of this use id PERL, in which all variables are marked by beginning with $. Then let can be the keyword where that is needed. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Fri, 28 Mar 2008, Sébastien Demathieu wrote: > Currently, we use '$' for variable declarations and just the variable > name for variable call expressions (VarCallExpression). > > I'm fine with using 'let' for variable declaration and '$'+variable > name for variable call expression. However, it seems that the '$' is > rather a keyword than a part of a variable name. Therefore, a variable > declaration would be 'let out variableName:Integer'. > Introducing '$' in both variable declaration and variable call > expression might create difficulties in the parsing of VSL expression. > > Murray, please can you let us know what you think about it? > > Thanks, > > Sébastien > > > > ESPINOZA Huascar 218344 a écrit : >> As proposed by Murray, the '$' should be part of the variable name, always. >> This is what the 'Resolved' resolution proposes. >> >> Please, proposes other resolution if you feel that none of the >> resolutions is sufficient. >> >> Thank you. >> >> Huascar >> >> >> -----Message d'origine----- >> De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] >> Envoyé : vendredi 28 mars 2008 12:02 >> À : ESPINOZA Huascar 218344 >> Cc : GERARD Sebastien 166342; marte-ftf@omg.org Objet : Re: >> PRE-VOTING on Issue 12209 >> >> Okay, the term "inline" may not be appropriate. What I meant is to be >> able to declare a variable within a tuple or a choice, tentatively >> through the "expr" member of a ValueSpecification. >> >> In the case of the scheduling parameter expression, if we consider >> the new syntax, would it be valid to write: >> >>> fp (priority= (expr= let out loc_prio:Integer:Integer ) ) >>> >> where (loc_prio is the name of the variable) ? >> >> Sébastien >> >> >> ESPINOZA Huascar 218344 a écrit : >> >>> Séb, >>> >>> There is no "inline" variable declarations for none of the resolutions. >>> >>> Regards, >>> >>> Huascar >>> >>> -----Message d'origine----- >>> De : Sébastien Demathieu >>> [mailto:sebastien.demathieu@thalesgroup.com] >>> Envoyé : vendredi 28 mars 2008 11:00 À : ESPINOZA Huascar 218344 Cc >>> : GERARD Sebastien 166342; marte-ftf@omg.org Objet : Re: PRE-VOTING >>> on Issue 12209 >>> >>> Huascar, all, >>> >>> I understand that the proposed change will relates only to the >>> syntax and does change the ability to have inline variable >>> declaration as in "fp (priority=out$loc_prio:Integer:Integer)" for >>> SchedulableResource.schedParam (current syntax). >>> >>> Am I right ? >>> >>> Thanks, >>> >>> Sébastien >>> >>> >>> >>> ESPINOZA Huascar 218344 a écrit : >>> >>>> Hi all, >>>> >>>> Issue 12209, related to the notation in variables ('$', 'let ', >>>> etc.) with a current resolution ClosedNoChange has not a consensus. >>>> Bran recommended following a pre-voting process. However, I wrote >>>> the 'Resolved' resolution just now. I don't know if we will have >>>> the time to include it in Ballot 1, but I'd like to begin this pre-voting now. >>>> >>>> Here attached you will find the two contender resolutions. >>>> >>>> **Please vote for one of these resolutions: 'ClosedNoChange' or >>>> 'Resolved'** >>>> >>>> The winner resolution will be included in the Ballot (I hope Ballot 1). >>>> >>>> Meanwhile, we (at CEA) will have a "pre-pre-voting" process because >>>> I prefer 'ClosedNoChange' whereas it seems that Séb prefers 'Resolved'. >>>> >>>> Séb: in addition, issue 11878 has been moved to Ballot 2 (as >>>> indicated in the wiki). Please remove it from ballot 1. >>>> >>>> Best regards, >>>> >>>> Huascar >>>> >>>> >>>> >>>> >>>> >>>> -----Message d'origine----- >>>> De : GERARD Sebastien 166342 Envoyé : jeudi 27 mars 2008 23:51 À : >>>> marte-ftf@omg.org Objet : MARTE FTF: draft ballot 1 >>>> >>>> Hi all, >>>> >>>> here is the drft for the ballot1. I propose to start the vote on >>>> next Monday in order to give you some time to check every think is >>>> ok for this ballot and add new resoltuion if you wnt. >>>> >>>> For Lonnie: revised text section of the issue 11771 needs to be >>>> completed. If you can do it before next Monday, it is perfect. >>>> Othewie, I propose to transfert it in the next ballot. >>>> >>>> Cheers, >>>> >>>> Sébastien. >>>> Subject: RE : PRE-VOTING on Issue 12209 Date: Sat, 29 Mar 2008 17:02:00 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRE-VOTING on Issue 12209 Thread-Index: AciQwzh8nqdKg3WAQ2uXSC8jpbS+ewAAGErgAAeYgikANM0YKg== From: "ESPINOZA Huascar 218344" To: "VanZandt, Lonnie" , Sébastien Demathieu Cc: "GERARD Sebastien 166342" , X-OriginalArrivalTime: 29 Mar 2008 16:02:01.0155 (UTC) FILETIME=[394E0930:01C891B6] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m2TG8LEO030004 Hi Lonnie, I must confess that I didn't understand your last paragraph I think that we had a lot of discussion around this issue before. A more efficient way to solve it is that if you have another proposal, you make a short description, send it to the mailing list, and we add it to the voting options. Meanwhile, if you agree with one of the already proposed options, please vote for it. Thank you, Huascar ________________________________ De: VanZandt, Lonnie [mailto:lonnie.vanzandt@artisansw.com] Date: ven. 28/03/2008 16:03 À: ESPINOZA Huascar 218344; Sébastien Demathieu Cc: GERARD Sebastien 166342; marte-ftf@omg.org Objet : RE: PRE-VOTING on Issue 12209 As one who is playing around with a VSL grammar, we ought to be able to clean up that grammar so that we do not have to concatenate the direction, declaration token, and variable like "out$myvar". We ought to be able to write "out $myvar" and, in fact, ought to be _forced_ to include whitespace between the direction keyword and the declaration token. I do not care much for any particular declaration token as long as it does not make difficult the parsing of unary operator expressions. For example, "-" would be a really bad choice. I'm not clear how we could have VSL-scoped variables without inline declarations because there is no way to express a collection of value specifications within the properties that are typed as value_specifications. That is, there is no predicate such as "value_specification -> specification ( SEMI specification )*". The implication is that a value_specification is either only a declarative statement or is a specification potentially containing inline declarations. Lonnie VanZandt Field Applications Engineer Denver, CO Artisan Software Tools mobile: 720 201-1349 desk: 303 482-2943 lonnie.vanzandt@artisansw.com ________________________________ From: ESPINOZA Huascar 218344 [mailto:Huascar.ESPINOZA@cea.fr] Sent: Fri 3/28/2008 5:07 AM To: Sébastien Demathieu Cc: GERARD Sebastien 166342; marte-ftf@omg.org Subject: RE: PRE-VOTING on Issue 12209 As proposed by Murray, the '$' should be part of the variable name, always. This is what the 'Resolved' resolution proposes. Please, proposes other resolution if you feel that none of the resolutions is sufficient. Thank you. Huascar -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : vendredi 28 mars 2008 12:02 À : ESPINOZA Huascar 218344 Cc : GERARD Sebastien 166342; marte-ftf@omg.org Objet : Re: PRE-VOTING on Issue 12209 Okay, the term "inline" may not be appropriate. What I meant is to be able to declare a variable within a tuple or a choice, tentatively through the "expr" member of a ValueSpecification. In the case of the scheduling parameter expression, if we consider the new syntax, would it be valid to write: > fp (priority= (expr= let out loc_prio:Integer:Integer ) ) where (loc_prio is the name of the variable) ? Sébastien ESPINOZA Huascar 218344 a écrit : > Séb, > > There is no "inline" variable declarations for none of the resolutions. > > Regards, > > Huascar > > -----Message d'origine----- > De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] > Envoyé : vendredi 28 mars 2008 11:00 > À : ESPINOZA Huascar 218344 > Cc : GERARD Sebastien 166342; marte-ftf@omg.org > Objet : Re: PRE-VOTING on Issue 12209 > > Huascar, all, > > I understand that the proposed change will relates only to the syntax > and does change the ability to have inline variable declaration > as in "fp (priority=out$loc_prio:Integer:Integer)" for > SchedulableResource.schedParam (current syntax). > > Am I right ? > > Thanks, > > Sébastien > > > > ESPINOZA Huascar 218344 a écrit : > >> Hi all, >> >> Issue 12209, related to the notation in variables ('$', 'let ', etc.) with a current resolution ClosedNoChange has not a consensus. Bran recommended following a pre-voting process. However, I wrote the 'Resolved' resolution just now. I don't know if we will have the time to include it in Ballot 1, but I'd like to begin this pre-voting now. >> >> Here attached you will find the two contender resolutions. >> >> **Please vote for one of these resolutions: 'ClosedNoChange' or 'Resolved'** >> >> The winner resolution will be included in the Ballot (I hope Ballot 1). >> >> Meanwhile, we (at CEA) will have a "pre-pre-voting" process because I prefer 'ClosedNoChange' whereas it seems that Séb prefers 'Resolved'. >> >> Séb: in addition, issue 11878 has been moved to Ballot 2 (as indicated in the wiki). Please remove it from ballot 1. >> >> Best regards, >> >> Huascar >> >> >> >> >> >> -----Message d'origine----- >> De : GERARD Sebastien 166342 >> Envoyé : jeudi 27 mars 2008 23:51 >> À : marte-ftf@omg.org >> Objet : MARTE FTF: draft ballot 1 >> >> Hi all, >> >> here is the drft for the ballot1. I propose to start the vote on next Monday in order to give you some time to check every think is ok for this ballot and add new resoltuion if you wnt. >> >> For Lonnie: revised text section of the issue 11771 needs to be completed. If you can do it before next Monday, it is perfect. Othewie, I propose to transfert it in the next ballot. >> >> Cheers, >> >> Sébastien. >> Date: Wed, 23 Apr 2008 17:43:12 +0200 From: Sébastien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: "'ESPINOZA Huascar 218344'" Cc: Laurent Rioux , marte-ftf@omg.org Subject: Re: Issues Annex B (VSL) X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m3NFimIA016455 Huascar, Here are our comments on the VSL resolutions: - 12209: please can you let us know what is the resolution to be added to the ballot (A or B)? - 11163: do we understand the rationale beyond this request before making it "closed, no change"? Maybe we can get in touch with the author of the issue? - 11339: this issue focuses only on a "syntax error": there is no conceptual problem: In the BNF of VSL, one calls a term that is not defined in other part of the BNF. If we would just introduce this new term in the BNF then we're done. I can propose a resolution for this one if you want. - 11548: This issue is different from 11547 because the "[ ]" operator applies to a variable here. If one cannot apply a "[ ]" operator on a variable that relates to a collection then we might have a problem with the use of collections in VSL. We need to address this problem at any rate (for ballot 2 or for the next round). - 11549: The resolution is not complete in the sense that the proposed changes do not appear in an updated version of the BNF (introducing the "( )" terms along with the priorities). - 11872: It is not clear that can support the proposed changes through a library. We have attempted to made these changes and we did not get to a conclusion at this point on whether we can or we cannot do it. I would suggest changing it to "deferred" Please let me know what you think about it. Thanks, Sébastien Laurent Rioux a écrit : There are still missing 3 issues inside the wiki and to solve Laurent -----Message d'origine----- De : ESPINOZA Huascar 218344 [mailto:Huascar.ESPINOZA@cea.fr] Envoyé : mercredi 23 avril 2008 16:25 À : marte-ftf@omg.org Objet : Issues Annex B (VSL) Hello, I uploaded the issue resolution for Annex B (VSL) to the MARTE wiki. Please let me know if you have any questions. Issue 12209 has two proposals. We still need to have a consensus on this. Regards, Huascar -- Huascar ESPINOZA, Ph.D. CEA LIST Model-Driven Engineering for Real-Time Embedded Systems 91191 GIF/YVETTE CEDEX Phone/Fax: +33 1 69 08 45 87 / 20 82 FRANCE Date: Thu, 24 Apr 2008 12:08:27 -0400 (EDT) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: ESPINOZA Huascar 218344 Cc: =?X-UNKNOWN?Q?S=E9bastien_Demathieu?= , marte-ftf@omg.org, Laurent Rioux Subject: issue on '$' notation I am not pleased with the resolution, and I prefer to retain the option to use in practice a signifier like $ to identify variables which communicate between the UMl and the analysis. As Bran pointed out, this is always an option. As for the UML TimeObservation being readily comprehended, I have never met anyone who understood it or used it, so I cannot tell. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Thu, 24 Apr 2008, ESPINOZA Huascar 218344 wrote: Murray, You included Issue 12209 in GQAM, but it's related to VSL notation. I already proposed a resolution in Annex B WG for 12209. Regards, Huascar -----Message d'origine----- De : ESPINOZA Huascar 218344 Envoyé : jeudi 24 avril 2008 16:42 À : cmw@sce.carleton.ca Cc : 'Sébastien Demathieu'; 'VanZandt, Lonnie' Objet : Murray: issue on '$' notation Hi Murray, Issue 12209: After some discussions with Seb. Demathieu, I decided to let the issue resolution as ClosedNoChange. The reasons are described in the issue resolution: http://www.omgwiki.org/marte/lib/exe/fetch.php?id=annex_b_wg&cache=cache&media=12209_closednochange_ballot2.doc Regards, Huascar -- Huascar ESPINOZA, Ph.D. CEA LIST Model-Driven Engineering for Real-Time Embedded Systems 91191 GIF/YVETTE CEDEX Phone/Fax: +33 1 69 08 45 87 / 20 82 FRANCE Subject: RE: issue on '$' notation Date: Thu, 24 Apr 2008 18:21:11 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue on '$' notation Thread-Index: AcimJXJpSQxaXjUzS+a0UOJ01T6RDQAAH8dw From: "ESPINOZA Huascar 218344" To: Cc: Sébastien Demathieu , , "Laurent Rioux" X-OriginalArrivalTime: 24 Apr 2008 16:21:12.0264 (UTC) FILETIME=[3628D480:01C8A627] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m3OGNCrY017008 Hi Murray, The '$' still exists for communicating with analysis tools. There is nothing that risks a straightforward communication with analysis tools. A variable it will be identified by a VSL parser without ambiguity. This resolution was solved by consulting with people that implemented VSL parsers and MARTE-analysis tool bridges. The resolution only avoids defining more complex keywords (such as 'let') that only complicate the reading of a UML graphical model, that are good for programming languages, but generate unreadable models. VSL should privilege compact and understandable value annotations. If there are more votes against this resolution, I'd suggested deferring the issue, but otherwise, I'd prefer to close the issue as far as a lot of discussion was done for this issue. Please let me know. Regards, Huascar -----Message d'origine----- De : Murray Woodside [mailto:cmw@sce.carleton.ca] Envoyé : jeudi 24 avril 2008 18:08 À : ESPINOZA Huascar 218344 Cc : Sébastien Demathieu; marte-ftf@omg.org; Laurent Rioux Objet : issue on '$' notation I am not pleased with the resolution, and I prefer to retain the option to use in practice a signifier like $ to identify variables which communicate between the UMl and the analysis. As Bran pointed out, this is always an option. As for the UML TimeObservation being readily comprehended, I have never met anyone who understood it or used it, so I cannot tell. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Thu, 24 Apr 2008, ESPINOZA Huascar 218344 wrote: > Murray, > > You included Issue 12209 in GQAM, but it's related to VSL notation. I already proposed a resolution in Annex B WG for 12209. > > Regards, > > Huascar > > -----Message d'origine----- > De : ESPINOZA Huascar 218344 > Envoyé : jeudi 24 avril 2008 16:42 > À : cmw@sce.carleton.ca > Cc : 'Sébastien Demathieu'; 'VanZandt, Lonnie' > Objet : Murray: issue on '$' notation > > Hi Murray, > > Issue 12209: After some discussions with Seb. Demathieu, I decided to let the issue resolution as ClosedNoChange. The reasons are described in the issue resolution: http://www.omgwiki.org/marte/lib/exe/fetch.php?id=annex_b_wg&cache=cache&media=12209_closednochange_ballot2.doc > > Regards, > > Huascar > > -- > Huascar ESPINOZA, Ph.D. > CEA LIST > Model-Driven Engineering for Real-Time Embedded Systems > 91191 GIF/YVETTE CEDEX > Phone/Fax: +33 1 69 08 45 87 / 20 82 > FRANCE > Subject: RE: issue on '$' notation Date: Thu, 24 Apr 2008 17:33:50 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue on '$' notation Thread-Index: AcimJXJpSQxaXjUzS+a0UOJ01T6RDQAAH8dwAADCL+E= From: "VanZandt, Lonnie" To: "ESPINOZA Huascar 218344" , Cc: S.©bastien Demathieu , , "Laurent Rioux" What ever is the proposal for the resolution, let's just refer to it as a proposal to be voted on and let the vote decide. If we now say an issue is "resolved" and we have yet to vote on the issue then we should all understand that we only mean that the issue has a proposed resolution and not that the issue was decided without due consideration of all voting members. Furthermore, I prefer that we definitively vote on issues rather than defer them or abstain because these other actions just delay final resolution. Lonnie VanZandt Field Applications Engineer Denver, CO Artisan Software Tools mobile: 720 201-1349 desk: 303 482-2943 lonnie.vanzandt@artisansw.com -------------------------------------------------------------------------------- From: ESPINOZA Huascar 218344 [mailto:Huascar.ESPINOZA@cea.fr] Sent: Thu 4/24/2008 10:21 AM To: cmw@sce.carleton.ca Cc: Sébastien Demathieu; marte-ftf@omg.org; Laurent Rioux Subject: RE: issue on '$' notation Hi Murray, The '$' still exists for communicating with analysis tools. There is nothing that risks a straightforward communication with analysis tools. A variable it will be identified by a VSL parser without ambiguity. This resolution was solved by consulting with people that implemented VSL parsers and MARTE-analysis tool bridges. The resolution only avoids defining more complex keywords (such as 'let') that only complicate the reading of a UML graphical model, that are good for programming languages, but generate unreadable models. VSL should privilege compact and understandable value annotations. If there are more votes against this resolution, I'd suggested deferring the issue, but otherwise, I'd prefer to close the issue as far as a lot of discussion was done for this issue. Please let me know. Regards, Huascar -----Message d'origine----- De : Murray Woodside [mailto:cmw@sce.carleton.ca] Envoyé : jeudi 24 avril 2008 18:08 À : ESPINOZA Huascar 218344 Cc : Sébastien Demathieu; marte-ftf@omg.org; Laurent Rioux Objet : issue on '$' notation I am not pleased with the resolution, and I prefer to retain the option to use in practice a signifier like $ to identify variables which communicate between the UMl and the analysis. As Bran pointed out, this is always an option. As for the UML TimeObservation being readily comprehended, I have never met anyone who understood it or used it, so I cannot tell. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Thu, 24 Apr 2008, ESPINOZA Huascar 218344 wrote: > Murray, > > You included Issue 12209 in GQAM, but it's related to VSL notation. I already proposed a resolution in Annex B WG for 12209. > > Regards, > > Huascar > > -----Message d'origine----- > De : ESPINOZA Huascar 218344 > Envoyé : jeudi 24 avril 2008 16:42 > À : cmw@sce.carleton.ca > Cc : 'Sébastien Demathieu'; 'VanZandt, Lonnie' > Objet : Murray: issue on '$' notation > > Hi Murray, > > Issue 12209: After some discussions with Seb. Demathieu, I decided to let the issue resolution as ClosedNoChange. The reasons are described in the issue resolution: http://www.omgwiki.org/marte/lib/exe/fetch.php?id=annex_b_wg&cache=cache&media=12209_closednochange_ballot2.doc > > Regards, > > Huascar > > -- > Huascar ESPINOZA, Ph.D. > CEA LIST > Model-Driven Engineering for Real-Time Embedded Systems > 91191 GIF/YVETTE CEDEX > Phone/Fax: +33 1 69 08 45 87 / 20 82 > FRANCE > Date: Thu, 24 Apr 2008 13:14:53 -0400 (EDT) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: ESPINOZA Huascar 218344 Cc: Sébastien Demathieu , marte-ftf@omg.org, Laurent Rioux Subject: RE: issue on '$' notation I can vote for the resolution on this basis, Huascar. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Thu, 24 Apr 2008, ESPINOZA Huascar 218344 wrote: Hi Murray, The '$' still exists for communicating with analysis tools. There is nothing that risks a straightforward communication with analysis tools. A variable it will be identified by a VSL parser without ambiguity. This resolution was solved by consulting with people that implemented VSL parsers and MARTE-analysis tool bridges. The resolution only avoids defining more complex keywords (such as 'let') that only complicate the reading of a UML graphical model, that are good for programming languages, but generate unreadable models. VSL should privilege compact and understandable value annotations. If there are more votes against this resolution, I'd suggested deferring the issue, but otherwise, I'd prefer to close the issue as far as a lot of discussion was done for this issue. Please let me know. Regards, Huascar -----Message d'origine----- De : Murray Woodside [mailto:cmw@sce.carleton.ca] Envoyé : jeudi 24 avril 2008 18:08 À : ESPINOZA Huascar 218344 Cc : Sébastien Demathieu; marte-ftf@omg.org; Laurent Rioux Objet : issue on '$' notation I am not pleased with the resolution, and I prefer to retain the option to use in practice a signifier like $ to identify variables which communicate between the UMl and the analysis. As Bran pointed out, this is always an option. As for the UML TimeObservation being readily comprehended, I have never met anyone who understood it or used it, so I cannot tell. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Thu, 24 Apr 2008, ESPINOZA Huascar 218344 wrote: Murray, You included Issue 12209 in GQAM, but it's related to VSL notation. I already proposed a resolution in Annex B WG for 12209. Regards, Huascar -----Message d'origine----- De : ESPINOZA Huascar 218344 Envoyé : jeudi 24 avril 2008 16:42 À : cmw@sce.carleton.ca Cc : 'Sébastien Demathieu'; 'VanZandt, Lonnie' Objet : Murray: issue on '$' notation Hi Murray, Issue 12209: After some discussions with Seb. Demathieu, I decided to let the issue resolution as ClosedNoChange. The reasons are described in the issue resolution: http://www.omgwiki.org/marte/lib/exe/fetch.php?id=annex_b_wg&cache=cache&media=12209_closednochange_ballot2.doc Regards, Huascar -- Huascar ESPINOZA, Ph.D. CEA LIST Model-Driven Engineering for Real-Time Embedded Systems 91191 GIF/YVETTE CEDEX Phone/Fax: +33 1 69 08 45 87 / 20 82 FRANCE > (http://www.sce.carleton.ca/faculty/woodside.html)