[Scilab-Dev] strings cannot be cut into several lines
Samuel Gougeon
sgougeon at free.fr
Sun Sep 9 14:31:00 CEST 2018
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
<http://bugzilla.scilab.org/show_bug.cgi?id=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 <grocer.toolbox at gmail.com
> <mailto:grocer.toolbox at gmail.com>> 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
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20180909/8796f006/attachment.htm>
More information about the dev
mailing list