strings cannot be cut into several lines

classic Classic list List threaded Threaded
4 messages Options
Eric Dubois Eric Dubois
Reply | Threaded
Open this post in threaded view
|

strings cannot be cut into several lines

Hello

Can someone explain me why in Scilab 6, you cannot wirte a string on several lines each line ending by "..."?

When you have a very long string, you have 2 choices that are not appealing:
- write this string on a line, which is not very readable;
- define several strings covering different components of the string and then add them to build your string, which is a time consuming.

This change makes my productivity when programming in Scilab decline and I do not see teh drawbacks that the old working entailed.

Thansk for your answer.

Regards 

Éric


_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Antoine ELIAS-2 Antoine ELIAS-2
Reply | Threaded
Open this post in threaded view
|

Re: strings cannot be cut into several lines

Hello Eric,

In Scilab 5, you could write strings on multiple lines using ... but not only, it worked with everything.

-->1..
-->2
 ans  =
 
    12. 

and more horrible

-->fun..
-->ction toto(..
-->)
-->disp("fu..
-->nction");
-->endf...
-->unction
 
-->toto()
 
 function  

In fact "..." are used to ignore the following end line.

I hope you can understand we want to remove this kind of coding style.
To replace ... for strings case can you use + operator.

-->"string1 and ...
-->string2"

become

-->"string1 and " + ...
-->"string2"
 ans  =
 
 string1 and string2

Antoine
Le 08/09/2018 à 10:41, Éric Dubois a écrit :
Hello

Can someone explain me why in Scilab 6, you cannot wirte a string on several lines each line ending by "..."?

When you have a very long string, you have 2 choices that are not appealing:
- write this string on a line, which is not very readable;
- define several strings covering different components of the string and then add them to build your string, which is a time consuming.

This change makes my productivity when programming in Scilab decline and I do not see teh drawbacks that the old working entailed.

Thansk for your answer.

Regards 

Éric



_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev


_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Eric Dubois Eric Dubois
Reply | Threaded
Open this post in threaded view
|

Re: strings cannot be cut into several lines

In reply to this post by Eric Dubois
Thanks Antoine for your quick and precised answer.

I understand the point, but besides "ascending compatibility" (which as a user I give -quite naturally- more weight than you as a developper), it makes the writing of long strings rather heavy and I think that an exception should have been made for strings. In fact, for long strings the solution you mention (and I mentionned also in ly previous e-mail) consisting in adding strings seems to mesomehow artificial, since it amounts to build a variable by splitting it into several ones.

As an example of my point, take the Troll code of the macroeconomic model "Opale", that has been recently realeased by the French Treasury (https://www.tresor.economie.gouv.fr/Articles/2018/09/05/la-dg-tresor-met-a-la-disposition-du-public-les-codes-sources-des-modeles-mesange-opale-et-saphir). Since Troll is proprietary and not Opensource software, I have undertaken (and in fact managed) to translate it into Scilab (which involves many blocks, sucha s a symbolic derivativefor instance.

If you take an excerpt of the code that adds some equations to an existing model, it is written in Troll :

ADDEQ bottom
td_p3m_d7_ch : DEL(1: LOG(td_p3m_d7_ch)) = p3md7cst'c
                    + p3md7balpos'c * balpos
                    + p3md7balneg'c * balneg
                    + p3md7juppos'c * juppos
                    + p3md7jupneg'c * jupneg
                    + p3md7filneg'c * filneg
                    + p3md7indic1999q3'c* indic1999q3
                    + p3md7rdbr0'c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))
                    + p3md7rdbr1'c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))(-1)
+ p3md7tcho0'c * DEL(TCHO)
+ p3md7vs0'c * DEL(TEMPVS1)
+ mup3md7'c * (
LOG(td_p3m_d7_ch(-1)) - p3m_d7_ch_cale(-1)
- 1 * LOG(TD_B6_S143(-1)/TD_P3M_D5_CH(-1))
)
+ DEL(p3m_d7_ch_cale),
td_p3p_d7_ch : td_p3p_d7_ch = coefp3pd7_ch * td_p3g_d7_ch ,
td_p51s_dhfz7_ch : DEL(LOG(td_p51s_dhfz7_ch)) = -0.002801
+ 0.257006 * (DEL(LOG(td_p51s_dhfz7_ch(-2)))-DEL(p51s_dhfz7_ch_cale(-2)))
                    - 0.592343 * DEL(LOG(td_p51s_dhfz5_ch/TD_B1_BMNA5_CH))
                    + 1.363988     * DEL(LOG(td_b1_bmna7_ch))
                    + 0.002681 * DEL(TUC) // ça devrait être DEL(TUC)(-1) => à changer
- 0.093789 * (
LOG(td_p51s_dhfz7_ch(-1))- LOG(td_b1_bmna7_ch(-1)) -
( -1.854938 -0.018102 * COUT_REEL(-1) )
- p51s_dhfz7_ch_cale(-1) )
+ DEL(p51s_dhfz7_ch_cale),

In Scilab 5.5.2 it should be written:

ADDEQ('bottom','...
td_p3m_d7_ch : DEL(1: LOG(td_p3m_d7_ch)) = p3md7cst''c ...
                    + p3md7balpos''c * balpos ...
                    + p3md7balneg''c * balneg ...
                    + p3md7juppos''c * juppos ...
                    + p3md7jupneg''c * jupneg ...
                    + p3md7filneg''c * filneg ...
                    + p3md7indic1999q3''c* indic1999q3 ...
                    + p3md7rdbr0''c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH)) ...
                    + p3md7rdbr1''c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))(-1) ...
+ p3md7tcho0''c * DEL(TCHO)  ...  
+ p3md7vs0''c * DEL(TEMPVS1) ...
+ mup3md7''c * (  ...
LOG(td_p3m_d7_ch(-1)) - p3m_d7_ch_cale(-1) ...
- 1 * LOG(TD_B6_S143(-1)/TD_P3M_D5_CH(-1)) ...
) ... 
+ DEL(p3m_d7_ch_cale), ...
 ...
td_p3p_d7_ch  : td_p3p_d7_ch  = coefp3pd7_ch * td_p3g_d7_ch ,  ...
 ...
td_p51s_dhfz7_ch : DEL(LOG(td_p51s_dhfz7_ch)) = -0.002801 ...
+ 0.257006 * (DEL(LOG(td_p51s_dhfz7_ch(-2)))-DEL(p51s_dhfz7_ch_cale(-2))) ...
                    - 0.592343 * DEL(LOG(td_p51s_dhfz5_ch/TD_B1_BMNA5_CH)) ...
                    + 1.363988     *  DEL(LOG(td_b1_bmna7_ch)) ...
                    + 0.002681 * DEL(TUC)  ...
- 0.093789 * ( ...
LOG(td_p51s_dhfz7_ch(-1))- LOG(td_b1_bmna7_ch(-1)) - ...
( -1.854938 -0.018102 * COUT_REEL(-1) ) ...
- p51s_dhfz7_ch_cale(-1) ) ...
+ DEL(p51s_dhfz7_ch_cale)')

And in Scilab 6.0.1:
ADDEQ('bottom','...
td_p3m_d7_ch : DEL(1: LOG(td_p3m_d7_ch)) = p3md7cst''c'+ ...
                    '+ p3md7balpos''c * balpos'+ ...
                    '+ p3md7balneg''c * balneg'+ ...
                    '+ p3md7juppos''c * juppos'+ ...
                    '+ p3md7jupneg''c * jupneg'+ ...
                    '+ p3md7filneg''c * filneg'+ ...
                    '+ p3md7indic1999q3''c* indic1999q3 ...
                   ' + p3md7rdbr0''c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))'+ ...
                    '+ p3md7rdbr1''c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))(-1)'+ ...
'+ p3md7tcho0''c * DEL(TCHO) '+   ...  
'+ p3md7vs0''c * DEL(TEMPVS1)'+ ...
'+ mup3md7''c * ('+  ...
'LOG(td_p3m_d7_ch(-1)) - p3m_d7_ch_cale(-1)'+ ...
'- 1 * LOG(TD_B6_S143(-1)/TD_P3M_D5_CH(-1)) '+...
')'+ ... 
'+ DEL(p3m_d7_ch_cale),'+ ...
 +...
'td_p3p_d7_ch  : td_p3p_d7_ch  = coefp3pd7_ch * td_p3g_d7_ch ,'+  ...
 + ...
'td_p51s_dhfz7_ch : DEL(LOG(td_p51s_dhfz7_ch)) = -0.002801 '+  ...
'+ 0.257006 * (DEL(LOG(td_p51s_dhfz7_ch(-2)))-DEL(p51s_dhfz7_ch_cale(-2)))'+ ...
                   ' - 0.592343 * DEL(LOG(td_p51s_dhfz5_ch/TD_B1_BMNA5_CH))'+ ...
                    '+ 1.363988     *  DEL(LOG(td_b1_bmna7_ch))'+ ...
                    '+ 0.002681 * DEL(TUC)'+  ...
'- 0.093789 * ('+ ...
'+LOG(td_p51s_dhfz7_ch(-1))- LOG(td_b1_bmna7_ch(-1)) - '+...
'( -1.854938 -0.018102 * COUT_REEL(-1) ) '+...
'- p51s_dhfz7_ch_cale(-1) ) '+...
'+ DEL(p51s_dhfz7_ch_cale)')

For an economist point of view the last writing makes it much more difficult the understanding of the structure of the equations and I fear that it could make external users reluctant to use my code...

Regards,

Éric

Le sam. 8 sept. 2018 à 10:41, Éric Dubois <[hidden email]> a écrit :
Hello

Can someone explain me why in Scilab 6, you cannot wirte a string on several lines each line ending by "..."?

When you have a very long string, you have 2 choices that are not appealing:
- write this string on a line, which is not very readable;
- define several strings covering different components of the string and then add them to build your string, which is a time consuming.

This change makes my productivity when programming in Scilab decline and I do not see teh drawbacks that the old working entailed.

Thansk for your answer.

Regards 

Éric


_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: strings cannot be cut into several lines

Hello,

I agree with you Eric. The example that you provide is rather explicit.

I also certainly agree on some simplifications about strings parsing in Scilab 6.
For instance, no longer allowing ending a string with the " or ' delimiter
that has not been used to start it is a good thing.

After 20 years of using Scilab, i discovered this week in a Xcos block function
that to include a " or ' in a string, doubling it is not mandatory!
Mixed " and ' can be used:
--> "ab"'cde"
 ans  =
 ab'cde

--> "ab'"cde"
 ans  =
 ab"cde

Frankly, IMO this kind of dark feature remaining in Scilab 6.0 would deserve being
removed. I guess that they do not simplify parsing strings, and occurrences in
the existing codes are trivial to detect and convert in the whole code.
By the way, this feature may prevent fixing the request 14287.

So, on one hand we still have this kind of dark complications, and on the other
one a useful feature as continuing strings is removed...

Another example showing a not very consistent policy:
Scilab 6.0 brings block comments /*
this is a multiline
comment
*/
Even if they are poorly still supported, the way is right : they will be really useful.

They implement a new multiline feature, while the multiline strings parsing is removed..

A last example about very handy multiline processing: It is possible to declare
a multiline array using the end-of-line as the ";" line separator. This is also very
useful, noticeably because it allows to copy/paste an array in the code as
is it displayed in the console:
--> A = matrix(1:15,3,5)
 A  =
   1.   4.   7.   10.   13.
   2.   5.   8.   11.   14.
   3.   6.   9.   12.   15.

Now in the code to set A in a literal way:
A = [
   1.   4.   7.   10.   13.
   2.   5.   8.   11.   14.
   3.   6.   9.   12.   15.
     ]
No need to append each line with ... or with ; or with ; ...
Scilab is handy, and users are happy. They just expect that from it.
Nobody would suggest removing this feature.

Back to strings: Octave uses "\" as the multiline continuation character.
It has this meaning only when it ends a line in an opened string.
As it is currently implemented, it unfortunately requires being protected if \ is
used inside the string. This is not handy, and would bring many
backward incompatibilities in Scilab
>> a = " abcd \path\
e"
a =  abcd pathe         <<<< missing \ before p

>> a = " abcd \\path\
e"
a =  abcd \pathe

The way the continuation marks ... worked for strings up to Scilab 5.5.2 was nice.

We could even wonder that even removing ".." might be syntactically possible:
Any string not closed at the end of a line goes on on the next line,
and leading blanks are meaningful:

text = "This is a unique
string defined
on several lines"

Would it be hard to parse?
Anyway, even without improvement, at least restoring the former ".." mark would
remove a regression.

Antoine,
Fortunately, only Cédric and you known that the indeed horrible example you gave was possible :((
But the examples are not inside a string.
For my part, i don't understand why preventing such -- possible but unknown -- horrible syntax
demands removing a useful feature.

Now, i know that defining parsing rules is a very complex thing, and that the parser has been rewritten.

Best regards
Samuel

Le 09/09/2018 à 11:21, Éric Dubois a écrit :
Thanks Antoine for your quick and precised answer.

I understand the point, but besides "ascending compatibility" (which as a user I give -quite naturally- more weight than you as a developper), it makes the writing of long strings rather heavy and I think that an exception should have been made for strings. In fact, for long strings the solution you mention (and I mentionned also in ly previous e-mail) consisting in adding strings seems to mesomehow artificial, since it amounts to build a variable by splitting it into several ones.

As an example of my point, take the Troll code of the macroeconomic model "Opale", that has been recently realeased by the French Treasury (https://www.tresor.economie.gouv.fr/Articles/2018/09/05/la-dg-tresor-met-a-la-disposition-du-public-les-codes-sources-des-modeles-mesange-opale-et-saphir). Since Troll is proprietary and not Opensource software, I have undertaken (and in fact managed) to translate it into Scilab (which involves many blocks, sucha s a symbolic derivativefor instance.

If you take an excerpt of the code that adds some equations to an existing model, it is written in Troll :

ADDEQ bottom
td_p3m_d7_ch : DEL(1: LOG(td_p3m_d7_ch)) = p3md7cst'c
                    + p3md7balpos'c * balpos
                    + p3md7balneg'c * balneg
                    + p3md7juppos'c * juppos
                    + p3md7jupneg'c * jupneg
                    + p3md7filneg'c * filneg
                    + p3md7indic1999q3'c* indic1999q3
                    + p3md7rdbr0'c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))
                    + p3md7rdbr1'c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))(-1)
+ p3md7tcho0'c * DEL(TCHO)
+ p3md7vs0'c * DEL(TEMPVS1)
+ mup3md7'c * (
LOG(td_p3m_d7_ch(-1)) - p3m_d7_ch_cale(-1)
- 1 * LOG(TD_B6_S143(-1)/TD_P3M_D5_CH(-1))
)
+ DEL(p3m_d7_ch_cale),
td_p3p_d7_ch : td_p3p_d7_ch = coefp3pd7_ch * td_p3g_d7_ch ,
td_p51s_dhfz7_ch : DEL(LOG(td_p51s_dhfz7_ch)) = -0.002801
+ 0.257006 * (DEL(LOG(td_p51s_dhfz7_ch(-2)))-DEL(p51s_dhfz7_ch_cale(-2)))
                    - 0.592343 * DEL(LOG(td_p51s_dhfz5_ch/TD_B1_BMNA5_CH))
                    + 1.363988     * DEL(LOG(td_b1_bmna7_ch))
                    + 0.002681 * DEL(TUC) // ça devrait être DEL(TUC)(-1) => à changer
- 0.093789 * (
LOG(td_p51s_dhfz7_ch(-1))- LOG(td_b1_bmna7_ch(-1)) -
( -1.854938 -0.018102 * COUT_REEL(-1) )
- p51s_dhfz7_ch_cale(-1) )
+ DEL(p51s_dhfz7_ch_cale),

In Scilab 5.5.2 it should be written:

ADDEQ('bottom','...
td_p3m_d7_ch : DEL(1: LOG(td_p3m_d7_ch)) = p3md7cst''c ...
                    + p3md7balpos''c * balpos ...
                    + p3md7balneg''c * balneg ...
                    + p3md7juppos''c * juppos ...
                    + p3md7jupneg''c * jupneg ...
                    + p3md7filneg''c * filneg ...
                    + p3md7indic1999q3''c* indic1999q3 ...
                    + p3md7rdbr0''c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH)) ...
                    + p3md7rdbr1''c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))(-1) ...
+ p3md7tcho0''c * DEL(TCHO)  ...  
+ p3md7vs0''c * DEL(TEMPVS1) ...
+ mup3md7''c * (  ...
LOG(td_p3m_d7_ch(-1)) - p3m_d7_ch_cale(-1) ...
- 1 * LOG(TD_B6_S143(-1)/TD_P3M_D5_CH(-1)) ...
) ... 
+ DEL(p3m_d7_ch_cale), ...
 ...
td_p3p_d7_ch  : td_p3p_d7_ch  = coefp3pd7_ch * td_p3g_d7_ch ,  ...
 ...
td_p51s_dhfz7_ch : DEL(LOG(td_p51s_dhfz7_ch)) = -0.002801 ...
+ 0.257006 * (DEL(LOG(td_p51s_dhfz7_ch(-2)))-DEL(p51s_dhfz7_ch_cale(-2))) ...
                    - 0.592343 * DEL(LOG(td_p51s_dhfz5_ch/TD_B1_BMNA5_CH)) ...
                    + 1.363988     *  DEL(LOG(td_b1_bmna7_ch)) ...
                    + 0.002681 * DEL(TUC)  ...
- 0.093789 * ( ...
LOG(td_p51s_dhfz7_ch(-1))- LOG(td_b1_bmna7_ch(-1)) - ...
( -1.854938 -0.018102 * COUT_REEL(-1) ) ...
- p51s_dhfz7_ch_cale(-1) ) ...
+ DEL(p51s_dhfz7_ch_cale)')

And in Scilab 6.0.1:
ADDEQ('bottom','...
td_p3m_d7_ch : DEL(1: LOG(td_p3m_d7_ch)) = p3md7cst''c'+ ...
                    '+ p3md7balpos''c * balpos'+ ...
                    '+ p3md7balneg''c * balneg'+ ...
                    '+ p3md7juppos''c * juppos'+ ...
                    '+ p3md7jupneg''c * jupneg'+ ...
                    '+ p3md7filneg''c * filneg'+ ...
                    '+ p3md7indic1999q3''c* indic1999q3 ...
                   ' + p3md7rdbr0''c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))'+ ...
                    '+ p3md7rdbr1''c * DEL(LOG(TD_B6_S143/TD_P3M_D5_CH))(-1)'+ ...
'+ p3md7tcho0''c * DEL(TCHO) '+   ...  
'+ p3md7vs0''c * DEL(TEMPVS1)'+ ...
'+ mup3md7''c * ('+  ...
'LOG(td_p3m_d7_ch(-1)) - p3m_d7_ch_cale(-1)'+ ...
'- 1 * LOG(TD_B6_S143(-1)/TD_P3M_D5_CH(-1)) '+...
')'+ ... 
'+ DEL(p3m_d7_ch_cale),'+ ...
 +...
'td_p3p_d7_ch  : td_p3p_d7_ch  = coefp3pd7_ch * td_p3g_d7_ch ,'+  ...
 + ...
'td_p51s_dhfz7_ch : DEL(LOG(td_p51s_dhfz7_ch)) = -0.002801 '+  ...
'+ 0.257006 * (DEL(LOG(td_p51s_dhfz7_ch(-2)))-DEL(p51s_dhfz7_ch_cale(-2)))'+ ...
                   ' - 0.592343 * DEL(LOG(td_p51s_dhfz5_ch/TD_B1_BMNA5_CH))'+ ...
                    '+ 1.363988     *  DEL(LOG(td_b1_bmna7_ch))'+ ...
                    '+ 0.002681 * DEL(TUC)'+  ...
'- 0.093789 * ('+ ...
'+LOG(td_p51s_dhfz7_ch(-1))- LOG(td_b1_bmna7_ch(-1)) - '+...
'( -1.854938 -0.018102 * COUT_REEL(-1) ) '+...
'- p51s_dhfz7_ch_cale(-1) ) '+...
'+ DEL(p51s_dhfz7_ch_cale)')

For an economist point of view the last writing makes it much more difficult the understanding of the structure of the equations and I fear that it could make external users reluctant to use my code...

Regards,

Éric

Le sam. 8 sept. 2018 à 10:41, Éric Dubois <[hidden email]> a écrit :
Hello

Can someone explain me why in Scilab 6, you cannot wirte a string on several lines each line ending by "..."?

When you have a very long string, you have 2 choices that are not appealing:
- write this string on a line, which is not very readable;
- define several strings covering different components of the string and then add them to build your string, which is a time consuming.

This change makes my productivity when programming in Scilab decline and I do not see teh drawbacks that the old working entailed.

Thansk for your answer.

Regards 

Éric



_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev



_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev