12:31 a.m.
For some time now hansl has had three string-handling commands that
are C-like in their syntax, namely printf, sprintf and sscanf. As we
move towards gretl 2.0 (not immediately imminent; I expect at least
a couple more 1.9.N releases first), I'd like to rationalize these.
At present printf and sprintf are available in command form only,
while sscanf has been both a command and a function for over two
years, with the command being deprecated in favour of the function
since gretl 1.9.4 (2011-02-24). In today's CVS I finally removed the
sscanf command so that only the function remains.
First I'll say what I'd like to do, then I'll offer a rationale.
Proposal: Make both print and sprintf into functions, deprecate the
commands of the same name, and eventually (by 2.0) remove the
commands.
Reasoning: Considered as gretl commands, printf and sprintf are
anomalous, they don't have a structure similar to other commands.
Considered as functions, however, they are not anomalous. And if
they were implemented as functions they would be more efficient (run
faster) and we could remove some ad hoc code that's required to
support them as commands.
Suppose we did this. From the script-writer's point of view printf
would be very little changed. Instead of
printf "x = %g\n", x
you'd write
printf("x = %g\n", x)
(putting in the parentheses; wearing your seat-belt!).
What about sprintf? In this case I think we could usefully change
the structure a little. I would favour
string s = sprintf(format, args)
where the function returns the string created by the substitution of
the arguments ("args") into the format. Since this departs from the
signature of the C function of the same name one could make a case
for renaming the function in hansl ("strbuild" or some such), though
I'm not particularly recommending that.
Related: if printf were to become a function in hansl, what if
anything should it return? The C function returns the number of
characters printed. We could probably arrange that if anyone thinks
it's useful, otherwise it could return 0 on success, non-zero if
anything went wrong, or it could be a "void" function that doesn't
give a return value.
Allin Cottrell
1:19 a.m.
On Wed, 25 Sep 2013, Allin Cottrell wrote:
Proposal: Make both print and sprintf into functions, deprecate the
commands
of the same name, and eventually (by 2.0) remove the commands.
Sorry, typo, I meant "printf", not "print". The print command can
stay as it is, including its string literal variant.
Allin Cottrell
7:58 a.m.
Am 26.09.2013 02:31, schrieb Allin Cottrell:
Proposal: Make both print and sprintf into functions, deprecate the
commands of the same name, and eventually (by 2.0) remove the
commands.
[where really printf was meant, not print]
Hey this feels like Python 2 -> Python 3...
Seriously, changing printf would break a lot of existing code, so there
should be a very good reason I guess; and/or offer something like 2to3
in the Python world, that is some tool that tries to automatically
change hansl scripts to gretl2.0 syntax.
What about sprintf? In this case I think we could usefully change
the structure a little. I would favour
string s = sprintf(format, args)
Just yesterday I actually was asking myself why the sister function
sscanf() is not returning the (numerical) output instead of stuffing it
in an argument. I would like that more (and it would in general save a
line of code, the initialization of the receiving variable, right?).
thanks,
sven
9:38 a.m.
On Wed, 25 Sep 2013, Allin Cottrell wrote:
For some time now hansl has had three string-handling commands that
are C-like in their syntax, namely printf, sprintf and sscanf. As we
move towards gretl 2.0 (not immediately imminent; I expect at least
a couple more 1.9.N releases first),
At the very very least! :)
I'd like to rationalize these.
Excellent idea.
At present printf and sprintf are available in command form only,
while sscanf has been both a command and a function for over two
years, with the command being deprecated in favour of the function
since gretl 1.9.4 (2011-02-24). In today's CVS I finally removed the
sscanf command so that only the function remains.
First I'll say what I'd like to do, then I'll offer a rationale.
Proposal: Make both printf and sprintf into functions, deprecate the
commands of the same name, and eventually (by 2.0) remove the
commands.
[an extremely lucid series of reasons follow...]
sscanf - ok (besides, it's gone already)
sprintf - ok
printf - I'm a bit hesitant. As Sven said, this is almost certain to break
ALL existing hansl code. Of course, the argument goes both ways. If it has
to be done, the sooner the better.
*Perhaps* the right sequence of steps, if we want to minimise the fallout
is:
- introduce, as an experimental feature, the printf function asap, and
start using it internally as soon as possible (for example, in the sample
scripts, or in addons)
- introduce the new tokenizer supporting the printf command (of course,
provided it isn't to difficult to fit existing syntax into it; Allin?)
- provide some way (the more the better), to sanitize existing scripts:
the equivalent to the python gadget Sven was referring to. This shouldn't
be too hard to do once the tokenizer is proven and robust. It could be a
stand-alone app, or even, maybe, an online thing: you upload the
"printf-as-a-command" inp/gfn file(s) and download the sanitized
"printf-as-a-function" corresponding file(s). Before you say it's
overkill, an infrastructure like this would make it viable to think of
even bolder changes for 2.0.
- make the output from the printf command deliberately annoying; for
example, by printing a big "DEPRECATED" before and after
- stop supporting printf as a command at 2.0
Related: if printf were to become a function in hansl, what if
anything should it return? The C function returns the number of
characters printed. We could probably arrange that if anyone thinks
it's useful, otherwise it could return 0 on success, non-zero if
anything went wrong, or it could be a "void" function that doesn't
give a return value.
If we have the choice, I'd go the C way, if only for compatibility (with
Matlab/octave "fprintf" too). Or maybe, like Ox's "print", the
number of
arguments.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
1:05 p.m.
On Thu, 26 Sep 2013, Riccardo (Jack) Lucchetti wrote:
*Perhaps* the right sequence of steps, if we want to minimise the
fallout is:
- introduce, as an experimental feature, the printf function asap, and start
using it internally as soon as possible (for example, in the sample scripts,
or in addons)
Yes, agreed.
- introduce the new tokenizer supporting the printf command (of
course,
provided it isn't to difficult to fit existing syntax into it; Allin?)
It can be made to work.
- provide some way (the more the better), to sanitize existing
scripts: the
equivalent to the python gadget Sven was referring to. This shouldn't be too
hard to do once the tokenizer is proven and robust. It could be a stand-alone
app, or even, maybe, an online thing: you upload the "printf-as-a-command"
inp/gfn file(s) and download the sanitized "printf-as-a-function"
corresponding file(s). Before you say it's overkill, an infrastructure like
this would make it viable to think of even bolder changes for 2.0.
Yes, that had occurred to me too -- well, the stand-alone program idea
anyway. The online script-updater is also a nice idea, and would be easy
to do given the program.
Allin
4109
days inactive
4109
days old
4 comments
3 participants
participants (3)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Sven Schreiber