Re: rethinking printf

2002-03-11 Thread ianb

On 10 Mar 02 at 11:14:26PM, Uri Guttman wrote:
> i really think that the printf format spec is so standard and ingrained
> that changing it with # for % or requiring \% is not a good idea.
> 
> but then again, backwards compatibility is not a rule you must always
> obey. i just think in this case it should be.

Especially as this is a case in which the functionality itself is not
broken, and not itself under review, but rather that a seemingly
unrelated proposed change to another part of the language is in effect
breaking printf.

If the printf formats were to be changed simply to accommodate other
changes elsewhere, then they should really be looked at more
generally: what would people like to get out of them, before we break
them?

But even then, backwards compatibility would be nice...


Ian Boreham



Re: rethinking printf

2002-03-11 Thread Tony Hall

On 10 Mar 02 at 11:14:26PM, Uri Guttman wrote:
> i really think that the printf format spec is so standard and ingrained
> that changing it with # for % or requiring \% is not a good idea.
> 
> but then again, backwards compatibility is not a rule you must always
> obey. i just think in this case it should be.

Especially as this is a case in which the functionality itself is not
broken, and not itself under review, but rather that a seemingly
unrelated proposed change to another part of the language is in effect
breaking printf.

If the printf formats were to be changed simply to accommodate other
changes elsewhere, then they should really be looked at more
generally: what would people like to get out of them, before we break
them?

But even then, backwards compatibility would be nice...


Ian Boreham





Greetings

2002-03-11 Thread Luke Palmer

Hello everyone.

I just subscribed to this list. My name's Luke and I'm a perl
devotee. And I'm starting out with a bang. Here goes:

I have just read through exegesis 3, and I found the bit about
defining your own new operators (eg. operator:*#@&) to be a little
strange. Not confusing, but esoteric and random. What functionality
does this provide to the language other than "It's cool."

I think, if anything, it would make things more confusing. Suppose a
module that implemented, say, a vector (disregarding that this isn't
really needed) provided a new operator .prod for dot product. What
would happen in the following case:

  use Vector;
  $v = new Vector;
  $v.prod $j;

Does that last statement mean $v.prod($j), or ($v) .prod ($j)? Not to
mention, how is the user supposed to know that she can't say
$v.prod($j)?

What about the example in the exegesis: 'operator:*#@&'? Take the
following code:
  
  $f *#@&
   $g;

What does this mean? Does this mean $f * $g with #@& as a comment, or
does it mean $f *#@& $g? But anyway, those are just language semantics
that could be worked out one way or another. The big confusion lies in
documentation and memory (human memory, that is). When your reading
through documentation for this Vector class, which would you rather
see?

  Vector provides an operator `.prod' for computing dot
  products. It has the same precedence as the Perl binary *
  operator. It also provides the xprod operator which has the same 
  precedence as Perl's binary + operator.

--or--

  Vector provides two methods, dot and cross, which compute the
  dot product and the cross product, respectively, on their
  arguments.

The latter has significantly less to remember, using the
ever-so-familiar method, rather than entering two new operators with
precedences and all into your knowledge base.

Also I think that these new operators would add a new level of
obfuscation to the language when it's not intended to be
obfuscated. When one encounters the *#@& operator, one must consult
the documentation for that operator, while method names are forced (at
least for people with any good taste) to make a small amount of sense.

Not to mention the extra strain on the lexer, not that it matters
much.

But in general, I suggest that the whole roll-your-own operator thing
be stripped from Perl 6. Not completely, however. I like the idea of
overloading existing operators, which has long been a part of the
language. I also kind of like the idea of defining infix
operators. But I think that would come back to the whole complication
with precedences again, which I don't find much elegance in. 

In summary, roll-your-own operators seem to be a contrived attempt at
being revolutionary, without providing much practicality.

Not to bash them or anything :-P

   Luke Palmer,
   [EMAIL PROTECTED]