And I do think people would rebel at using Latin-1 for that one.
I get enough grief for Â...Â. :-)
I can imagine that these cause some trouble with people using a charset
other than ISO-8859-1 (Latin-1) that works well with 8 bit, like Greek,
Arabic, Cyrillic and Hebrew.
For these guys Unicode is
Please bare with me, I do follow this list, but sporadically.
What it all boils down to, obviously, is that we, as lazy programmers, want
to have to type less, but still leave the code make sense when read. So to
me, that should automatically throw out stuff such as C<$x = ( $foo § .a +
.b + .c )
"Oh, it's got lots of Japanese in it, I'd better read it..." :)
[EMAIL PROTECTED] (Larry Wall) writes:
> Some will argue that since English doesn't have a grammatical
> postfix topicalizer like Japanese, we should stick with something
> like more English-like:
>
> $x = (.a + .b + .c given $f
Larry Wall wrote:
Now, if we had a unary = that assigned to the current topic, we could do
it with the existing topicalizer as
given my Dog $dog { = .new }
But I'm not recommending that approach, because I dislike unary =, and
because I don't want every declaration to have to say "given".
On Fri, Mar 12, 2004 at 09:19:46AM -0800, Dave Whipp wrote:
: Why are we mixing the concepts of assignment and topicalization --
: especially in a way that doesn't generalize. Why can't we invent a
: "topicalization" operator, analogous to the old binding operator, that
: simply sets its LHS as th
On 3/12/04 12:43 PM, Larry Wall wrote:
> Some good questions only have bad answers. This might be one of them.
I have been watching this thread with increasing unease, asking myself
exactly what the potential benefit is of this proposed feature and syntax.
I'm all for saving some typing, but yees
On Fri, Mar 12, 2004 at 12:29:36PM +1100, Deborah Pickett wrote:
: That triggered a thought about unary operators. What about:
:
: $a !=;# i.e., $a = ! $a;
Well, an argument could be made that the corresponding syntax is really:
!= $a;
But you have to read the
A = B ==> A
On Fri, Mar 12, 2004 at 03:47:22AM -0500, Austin Hastings wrote:
> > -Original Message-
> > From: Larry Wall [mailto:[EMAIL PROTECTED]
> >
> > Now in the specific case of . and .= we don't exactly have a normal
> > binary operator, because the right side is not an expression.
>
> $tis.=«
"Larry Wall" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Unfortunately we can't just use topicalization to say
>
> my Cat $tom = .new()
>
> because most people won't expect simple assignment to break their
> current topic.
>
> So another option is to replace = with somethin
Austin Hastings writes:
>
>
> > -Original Message-
> > From: Larry Wall [mailto:[EMAIL PROTECTED]
> > On Thu, Mar 11, 2004 at 06:49:44AM -0800, Gregor N. Purdy wrote:
> > : So, will "mutatingness" be a context we'll be able to inquire on
> > : in the implementation of a called routine?
>
> -Original Message-
> From: Damian Conway [mailto:[EMAIL PROTECTED]
>
> Larry wrote:
>
> > On the other hand, I suspect most people will end up declaring it
> >
> > int method
> > self:rotate (int $a is rw) {...}
> >
> > in any event, and reserve the =rotate for .=rotate, which c
On Fri, 12 Mar 2004 10.51, Damian Conway wrote:
> There are also cases where something like:
>
> $a ||= $b;
>
> or:
>
> $a += $b;
>
> changes the type of value in $a. Should we flag those too? Currently we do
> warn on the second one if $a can't be cleanly coerced to numeric. Would
> th
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> On Thu, Mar 11, 2004 at 06:49:44AM -0800, Gregor N. Purdy wrote:
> : So, will "mutatingness" be a context we'll be able to inquire on
> : in the implementation of a called routine?
>
> Probably not, but it's vaguely possi
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> On Thu, Mar 11, 2004 at 11:38:11AM +, Andy Wardley wrote:
> : Larry Wall wrote:
> : > multi sub *scramble (String $s) returns String {...}
> : [...]
> : > Or you can just call it directly as a function:
> : > sc
14 matches
Mail list logo
