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