8:18 a.m.
Hi,
this is a quite fundamental remark I guess, but at the same time perhaps
doesn't affect too many concrete things.
I think that hansl still might resemble C too much in some aspects, and
the only real reason that I can see is that the gretl founders come from
the C background.
* The "printf" command:
For newcomers something like 'printf "hi: %s, %d", s1, d1' must look
horrible. In other languages including even Ox or --I believe-- C++ it
is possible to write things in the natural ordering, so in hansl this
would become something like:
'print "hi: " ~ s1 ~ d1'
Of course, for more finetuned control the current printf possibilities
would still be needed, but for many cases a default formatting of
numbers would be enough I think.
* Function names like "strstr": Tastes will vary here, but when we
discussed whether or not the name of the function was intuitive for what
it does, the only real argument was that it's just the C name. But IMHO
for the hansl user it should be irrelevant whether gretl in the
background is implemented in C or whatever other language.
Probably there are more examples, but I guess the "printf" thing is the
most glaring one from a user's point of view.
Happy to hear your thoughts,
Sven
10:16 a.m.
On Sun, 18 Sep 2016, Sven Schreiber wrote:
Hi,
this is a quite fundamental remark I guess, but at the same time perhaps
doesn't affect too many concrete things.
I think that hansl still might resemble C too much in some aspects, and the
only real reason that I can see is that the gretl founders come from the C
background.
* The "printf" command:
For newcomers something like 'printf "hi: %s, %d", s1, d1' must look
horrible. In other languages including even Ox or --I believe-- C++ it is
possible to write things in the natural ordering, so in hansl this would
become something like:
'print "hi: " ~ s1 ~ d1'
Of course, for more finetuned control the current printf possibilities would
still be needed, but for many cases a default formatting of numbers would be
enough I think.
Both Matlab and R have sprintf. I take this as an indication that the
concept itself is not only valid, but appropriate to a high-level
language. But I admit you have a point; the number of times people have
said to me that "printf" is incomprehensible is impossible to
over-estimate.
I guess we could introduce a refinement to the current incarnation of
"print" in two directions:
* enable print to output expressions rather than simple variables (we
alredy have eval for that though)
* envisage some syntax so that you have a pre-cooked set of "sensible"
choices via a multi-argument "print" _function_, as in
print("hi:", stringvar, "!, you are the", n, "-th person I've
met!")
which would also have the advantage of handling expressions natively.
In this example, the idea would be that if "n" is an integer, we
automatically apply "%d", otherwise we go for "%g", etcetera
etcetera.
* Function names like "strstr": Tastes will vary here, but
when we discussed
whether or not the name of the function was intuitive for what it does, the
only real argument was that it's just the C name. But IMHO for the hansl user
it should be irrelevant whether gretl in the background is implemented in C
or whatever other language.
This is a matter of taste, as you say; I guess we could perhaps be more
cautious in the future if/when we introduce new functions.
-------------------------------------------------------
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
-------------------------------------------------------
2:43 p.m.
Am 18.09.2016 um 12:16 schrieb Riccardo (Jack) Lucchetti:
* enable print to output expressions rather than simple variables (we
alredy have eval for that though)
Yes, the issue print-vs.-eval has come up several times. In principle
"eval" should be made redundant by extending "print" to become the
union
of what is now print and eval -- if I'm not missing something, that is.
* envisage some syntax so that you have a pre-cooked set of
"sensible"
choices via a multi-argument "print" _function_, as in
print("hi:", stringvar, "!, you are the", n, "-th person
I've met!")
which would also have the advantage of handling expressions natively.
In this example, the idea would be that if "n" is an integer, we
automatically apply "%d", otherwise we go for "%g", etcetera
etcetera.
Exactly. The only thing I don't quite understand is why does it have to
be a function instead of a command (or both). Ok, famously Python's most
obvious change from 2 to 3 was that 'print' became a function, too. But
in the hansl context, what's the rationale? Extending the print command
would seem more intuitive from a user's point of view. Or to put it
differently: Otherwise why allow the current 'print' command if
functions are so much better?
thanks,
sven
5:06 p.m.
On Sun, 18 Sep 2016, Sven Schreiber wrote:
> * envisage some syntax so that you have a pre-cooked set of
"sensible"
> choices via a multi-argument "print" _function_, as in
>
> print("hi:", stringvar, "!, you are the", n, "-th person
I've met!")
>
> which would also have the advantage of handling expressions natively.
>
> In this example, the idea would be that if "n" is an integer, we
> automatically apply "%d", otherwise we go for "%g", etcetera
etcetera.
Exactly. The only thing I don't quite understand is why does it have to be a
function instead of a command (or both). Ok, famously Python's most obvious
change from 2 to 3 was that 'print' became a function, too. But in the hansl
context, what's the rationale? Extending the print command would seem more
intuitive from a user's point of view. Or to put it differently: Otherwise
why allow the current 'print' command if functions are so much better?
I can see two reasons: (1) this way, you leave the print command untouched
in the interest of backward compatibility (2) we have a much better
apparatus for parsing arguments to functions than commands, and
implementation would be IMO much easier.
-------------------------------------------------------
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
-------------------------------------------------------
8:30 p.m.
On Sun, 18 Sep 2016, Sven Schreiber wrote:
Am 18.09.2016 um 12:16 schrieb Riccardo (Jack) Lucchetti:
>
> * enable print to output expressions rather than simple variables
> (we alredy have eval for that though)
Yes, the issue print-vs.-eval has come up several times. In
principle "eval" should be made redundant by extending "print" to
become the union of what is now print and eval -- if I'm not
missing something, that is.
First off, the genetic difference between "print" and "eval" is
historical: "print" is an ancient command (originally used only for
printing series), while "eval" is an offshoot of what was once our
"new genr" apparatus (a proper recursive descent parser). "New genr"
has been around for many years now but it long postdates "print". If
these respective histories were the only real difference between the
two commands, there would surely be a case for merging them.
However, I don't think history is the only relevant difference.
While some usages of the two are pretty much equivalent, each
command offers generality in its own specific dimension.
In the case of "print" you can print the values of multiple objects:
you can put the names of as many objects as you like (simply
space-separated) on a "print" command line.
In the case of "eval" you are allowed just one expression on the
command line, but it does not have to be the name of an existing
object; it can be as complex as you like, as in
eval (y - X*inv(X'X)*X'y)'(y - X*inv(X'X)*X'y)
(not a smart usage, but never mind).
It seems to me these extensions cannot be combined. An
argument-array which simply lists a bunch of objects of arbitrary
type is fine for "print" but is not something that's going to work
with "eval", which is inherently looking for something that makes
syntactical sense -- something that would be OK on the right-hand
side of an assignment, except that you don't care to assign the
result to anything.
Even in very basic usage, there's a difference which I sometimes
find useful (in the sense of having a reason to prefer one or the
other command, depending on the context): "eval" simply dumps the
result, while "print" may add some extra information (e.g. in the
matrix case, where the name and dimensions of the matrix are
displayed). Sometimes I'd like to see the extra info, sometimes not.
Allin
7:04 p.m.
On Sun, 18 Sep 2016, Sven Schreiber wrote:
Hi,
this is a quite fundamental remark I guess, but at the same time perhaps
doesn't affect too many concrete things.
I think that hansl still might resemble C too much in some aspects, and the
only real reason that I can see is that the gretl founders come from the C
background.
* The "printf" command:
For newcomers something like 'printf "hi: %s, %d", s1, d1' must look
horrible. In other languages including even Ox or --I believe-- C++ it is
possible to write things in the natural ordering, so in hansl this would
become something like:
'print "hi: " ~ s1 ~ d1'
Of course, for more finetuned control the current printf possibilities would
still be needed, but for many cases a default formatting of numbers would be
enough I think.
OK, maybe this just me, but personally I hate, despise and deplore
the various supposedly "user-friendly" alternatives to C-style
printf as found in Ox, R and some other languages. I find it
terribly confusing to have to mix quoted string-literal chunks and
variable names, all comma separated, in a single statement. It gets
even more confusing when you want literal parentheses in the output.
With printf, you have a clear separation of just one string literal,
the format, and whatever variables or expressions you want to print.
Granted, there's a learning curve -- particularly if you want fine
control over the output (but typically you can't get fine control at
all with the alternatives) -- but you can get pretty decent results
in hansl just knowing two conversions: "%g" for numerical values and
"%s" for strings.
So I would be more inclined to try writing up a nice printf tutorial
for beginners than to mess with the text/variable mash-up approach.
* Function names like "strstr": Tastes will vary here, but
when we discussed
whether or not the name of the function was intuitive for what it does, the
only real argument was that it's just the C name. But IMHO for the hansl user
it should be irrelevant whether gretl in the background is implemented in C
or whatever other language.
I agree the language of implementation in the background should not
govern the features of hansl visible to the user. However, one
design decision in hansl is to favour terse function-names, and in
the case of strstr I'm not sure there's a much better alternative
terse name for a function that searches string1 for an occurrence of
string2. Using the C name may not be ideal, but it has the small
advantage that C function-names are used in many other languages
besides C, so once you know what "strstr" does, you'll find it'll do
the same in quite a few languages.
All the same, if/when we introduce other C-workalikes in hansl, we
shouldn't just assume that they should be named as in C, if we can
come up with something more indicative of what the function does.
Allin
9:02 p.m.
Am 18.09.2016 um 21:04 schrieb Allin Cottrell:
OK, maybe this just me, but personally I hate, despise and deplore
the
various supposedly "user-friendly" alternatives to C-style printf as
found in Ox, R and some other languages. I find it terribly confusing to
have to mix quoted string-literal chunks and variable names, all comma
separated, in a single statement.
(Side remark: What _is_ confusing about string literals in hansl is the
way how literals are given without quotes in a foreach loop --as in
"loop foreach i peach pear plum"--, and probably in a few more places;
but I've said that before.)
It's a matter of taste of course, but Jack's experience regarding user
feedback would seem to support my intuition about what people find
user-friendly.
Anyway, one could probably get pretty close to what I have in mind with
the following example (working code!):
<hansl>
function string str(scalar n)
if isnan(n)
return "NaN"
elif missing(n)
return "NA"
elif (n - 1e-5) <= int(n) && int(n) <= (n + 1e-5) # is integer
return sprintf("%d", n)
else
return sprintf("%g", n)
endif
end function
eval "hey" ~ str(0.5) ~ "hu"
eval "zoom" ~ str(1/0) ~ " zap"
</hansl>
In some sense I'm just using the str() function as a short form for the
sprintf() function with an implicit format default.
Now I've read your latest email about eval and print, but personally I
still think it's a bit of a pity that I cannot use print here, as it
would sound/read more natural IMHO. (Does the eval output actually also
get diverted if an "outfile" command is active?)
With printf, you have a clear separation of just one string literal,
the
format, and whatever variables or expressions you want to print.
I don't really see how the string literal can be called separated from
the format when the format spec comes right in the middle of the literal!?
cheers,
sven
9:35 p.m.
On Sun, 18 Sep 2016, Sven Schreiber wrote:
Am 18.09.2016 um 21:04 schrieb Allin Cottrell:
> OK, maybe this just me, but personally I hate, despise and deplore the
> various supposedly "user-friendly" alternatives to C-style printf as
> found in Ox, R and some other languages. I find it terribly confusing to
> have to mix quoted string-literal chunks and variable names, all comma
> separated, in a single statement.
(Side remark: What _is_ confusing about string literals in hansl is the way
how literals are given without quotes in a foreach loop --as in "loop foreach
i peach pear plum"--, and probably in a few more places; but I've said that
before.)
Granted. There are some places in hansl syntax where we really
require a string literal (or a set of same) but in the interest of
(supposed) user-friendliness we accept an unquoted version of the
argument. I'm prepared to admit that was probably a mistake ;-)
It's a matter of taste of course, but Jack's experience
regarding user
feedback would seem to support my intuition about what people find
user-friendly.
OK, but I'm not sure that people always know what's good for them!
(See the US electorate's flirtation with Donald Trump.) The thing
is, those dumbed-down printf variants might look quite nice at first
-- say, if you have just one string and one variable to print -- but
they don't take you far, and in the end you have to learn printf
anyway. Try printing something that contains literal parentheses and
literal commas (not that unusual) and your head is soon hurting
badly unless you're using printf.
> With printf, you have a clear separation of just one string
literal, the
> format, and whatever variables or expressions you want to print.
I don't really see how the string literal can be called separated from the
format when the format spec comes right in the middle of the literal!?
Sorry, I guess I wasn't clear. What I meant is: the format == (the
only string literal in a printf call), unless one is perverse enough
to supply string literals as arguments, which should never be
necessary [*].
Allin
[*] Unless one is supporting multilingual output. That's routine in
the gretl C source code, but not something your average user is
attempting in hansl.
8:41 a.m.
Am 18.09.2016 um 23:35 schrieb Allin Cottrell:
On Sun, 18 Sep 2016, Sven Schreiber wrote:
> (Side remark: What _is_ confusing about string literals in hansl
is
> the way how literals are given without quotes in a foreach loop --as
> in "loop foreach i peach pear plum"--, and probably in a few more
> places; but I've said that before.)
Granted. There are some places in hansl syntax where we really require a
string literal (or a set of same) but in the interest of (supposed)
user-friendliness we accept an unquoted version of the argument. I'm
prepared to admit that was probably a mistake ;-)
And I'm willing to admit that maintaining too much backwards
compatibility in a relatively young language as hansl might backfire in
those cases...
OK, but I'm not sure that people always know what's good for
them! (See
the US electorate's flirtation with Donald Trump.) The thing is, those
dumbed-down printf variants might look quite nice at first -- say, if
you have just one string and one variable to print -- but they don't
take you far, and in the end you have to learn printf anyway.
I must say I'm surprised to hear that and I don't agree at all. This is
the kind of argument that we usually hear against GUI programs and also
against syntax features like significant whitespace and so forth.
Basically most of the stuff that makes up gretl and hansl.
So let me wrap up a couple of alternative syntax suggestions (meaning
only one of them is needed):
1) Like Jack said, a new print() function with comma-separated arguments
which can be string literals or (scalar?) variable identifiers.
2) What about string conversion with the $-sign like we already can do
in loops? So that something like this would work:
check = 3
print "Value of check: $check" # wanted output: Value of check: 3
(I know, this would require escaping a literal '$'.)
3) A new built-in str() function as in my previous post, that does
conversion to string with some default formatting (%d, %g), such that my
'eval "hey: " ~ str(somenumber)' solution would work out of the box.
Thanks,
sven
8:35 p.m.
On Mon, 19 Sep 2016, Sven Schreiber wrote:
Am 18.09.2016 um 23:35 schrieb Allin Cottrell:
> On Sun, 18 Sep 2016, Sven Schreiber wrote:
>> (Side remark: What _is_ confusing about string literals in hansl is
>> the way how literals are given without quotes in a foreach loop --as
>> in "loop foreach i peach pear plum"--, and probably in a few more
>> places; but I've said that before.)
>
> Granted. There are some places in hansl syntax where we really require a
> string literal (or a set of same) but in the interest of (supposed)
> user-friendliness we accept an unquoted version of the argument. I'm
> prepared to admit that was probably a mistake ;-)
And I'm willing to admit that maintaining too much backwards
compatibility in a relatively young language as hansl might
backfire in those cases...
Well, OK, we could revisit that.
> OK, but I'm not sure that people always know what's good
for
> them! (See the US electorate's flirtation with Donald Trump.) The
> thing is, those dumbed-down printf variants might look quite nice
> at first -- say, if you have just one string and one variable to
> print -- but they don't take you far, and in the end you have to
> learn printf anyway.
I must say I'm surprised to hear that and I don't agree at all.
This is the kind of argument that we usually hear against GUI
programs and also against syntax features like significant
whitespace and so forth. Basically most of the stuff that makes up
gretl and hansl.
Having spent thousands of hours developing and maintaining the gretl
GUI I'm not about to deprecate graphical interfaces. What we're
talking about here is the relative merits of two command-line
interfaces for printing information, when the exact content is not
known at code-writing time. In my opinion the printf substitutes are
inferior designs, and printf is not as hard to learn as many seem to
think -- particularly in the context of hansl, where "%g" will do
quite nicely for any numerical arguments, including "integers". (In
C and other low-level languages one has a wide variety of numerical
types that require their own specific conversions, and that gets
more complicated.)
But anyway ...
3) A new built-in str() function as in my previous post, that does
conversion to string with some default formatting (%d, %g), such
that my 'eval "hey: " ~ str(somenumber)' solution would work out
of the box.
This seems to me the most acceptable of the alternative proposals,
though personally I'm not convinced it's nicer or easier than
printf "hey: %g\n", somenumber
What do others think?
Allin
9:07 p.m.
I've come to like the printf() way of doing things. I used it extensively
in Using Gretl for Principles of Econometrics. It first appears in chapter
2, but for some reason I didn't bother explaining the syntax until chapter
5 (pages 94 and 95). Something else to fix!
As has been said in this thread, it's a fairly standard way of printing
numbers and text that yields predictable results. Stata has a very simple
"display" command that allows you to print text and numbers with less fuss,
e.g.,
di "The sample size is " e(N)
but it is very basic and there is no real control over the formatting. I
know there are fancier and more complicated ways of formatting output in
Stata, like 'esttab' for tabular data, but it uses the same C like syntax
as gretl.
Lee
On Mon, Sep 19, 2016 at 3:35 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
On Mon, 19 Sep 2016, Sven Schreiber wrote:
Am 18.09.2016 um 23:35 schrieb Allin Cottrell:
>
>> On Sun, 18 Sep 2016, Sven Schreiber wrote:
>>
>
> (Side remark: What _is_ confusing about string literals in hansl is
>>> the way how literals are given without quotes in a foreach loop --as
>>> in "loop foreach i peach pear plum"--, and probably in a few more
>>> places; but I've said that before.)
>>>
>>
>> Granted. There are some places in hansl syntax where we really require a
>> string literal (or a set of same) but in the interest of (supposed)
>> user-friendliness we accept an unquoted version of the argument. I'm
>> prepared to admit that was probably a mistake ;-)
>>
>
> And I'm willing to admit that maintaining too much backwards
> compatibility in a relatively young language as hansl might backfire in
> those cases...
>
Well, OK, we could revisit that.
OK, but I'm not sure that people always know what's good for them! (See
>> the US electorate's flirtation with Donald Trump.) The thing is, those
>> dumbed-down printf variants might look quite nice at first -- say, if you
>> have just one string and one variable to print -- but they don't take you
>> far, and in the end you have to learn printf anyway.
>>
>
> I must say I'm surprised to hear that and I don't agree at all. This is
> the kind of argument that we usually hear against GUI programs and also
> against syntax features like significant whitespace and so forth. Basically
> most of the stuff that makes up gretl and hansl.
>
Having spent thousands of hours developing and maintaining the gretl GUI
I'm not about to deprecate graphical interfaces. What we're talking about
here is the relative merits of two command-line interfaces for printing
information, when the exact content is not known at code-writing time. In
my opinion the printf substitutes are inferior designs, and printf is not
as hard to learn as many seem to think -- particularly in the context of
hansl, where "%g" will do quite nicely for any numerical arguments,
including "integers". (In C and other low-level languages one has a wide
variety of numerical types that require their own specific conversions, and
that gets more complicated.)
But anyway ...
3) A new built-in str() function as in my previous post, that does
> conversion to string with some default formatting (%d, %g), such that my
> 'eval "hey: " ~ str(somenumber)' solution would work out of the
box.
>
This seems to me the most acceptable of the alternative proposals,
though personally I'm not convinced it's nicer or easier than
printf "hey: %g\n", somenumber
What do others think?
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
Lee Adkins
Professor of Economics and Department Head
Economics and Legal Studies in Business
Oklahoma State University
Email: lee.adkins(a)okstate.edu
Fax: 405-744-5180
Phone: 405-744-5196
URL: www.learneconometrics.com
7:58 a.m.
Am 19.09.2016 um 23:07 schrieb Lee Adkins:
I've come to like the printf() way of doing things.
Me, too! Otherwise I would have raised the issue years ago. It's not a
personal thing for myself here. I noticed this C-ism with printf() when
I recently learned that even in C++ you can do something like:
<cpp> std::cout << "hey :" << somenumber; </cpp>
So IMO you cannot dismiss this as something only for dummies.
Stata has a very
simple "display" command that allows you to print text and numbers with
less fuss, e.g.,
di "The sample size is " e(N)
I like the "less fuss" part, exactly my point. This is currently not
possible in hansl.
but it is very basic and there is no real control over the
formatting.
I know there are fancier and more complicated ways of formatting output
in Stata, like 'esttab' for tabular data, but it uses the same C like
syntax as gretl.
And I'm not proposing to ditch that syntax from gretl!
BTW, Re Allin's post: I didn't even know that %g can be universally
used, even though I have been using printf() for years. (I'm always
using %d and %f.) If there is such a useful default, why not make it
exactly that, a default? Of course users will have to learn more if they
want more control, but in perhaps 80% of the cases the "less fuss"
solution is all that's needed.
In the end it's a matter of what users want, and the only evidence for
that is my gut feeling and what Jack said about what he was told by many
people. Maybe we should ask on the users list (although it is not
representative of potential gretl users, there will be a conservative
selection bias).
thanks,
sven
3015
days inactive
3017
days old
11 comments
4 participants
participants (4)
-
Allin Cottrell -
Lee Adkins -
Riccardo (Jack) Lucchetti -
Sven Schreiber