> Language
> Miscellaneous language issues
> item 1.
> Perl is not like other programming languages. Ilya used to say that
> Perl isn't a programming language - Perl's grammar is much more like
> a natural language than a computer one.
Well, $I wonder if anyone except @computers can find
Simon Cozens schrieb:
>
> On Tue, Aug 01, 2000 at 01:13:17PM +0200, Edwin Steiner wrote:
> > > Perl isn't a programming language - Perl's grammar is much more like
> > > a natural language than a computer one.
> >
> > Well, $I wonder if anyone except
Tom Christiansen schrieb:
[snip]
> "Seems" may be the operative term here. Feckless worship of the
> false idol of universal popularity will, in attempting to please
> everyone, be doomed to please no one. A less proselytist message
> would be much useful, perhaps one more along the lines of: "T
Hello!
On Fri, Nov 20, 2009 at 09:39:13AM +0100, pugs-comm...@feather.perl6.nl wrote:
> -constant Dog $fido .= new; # okay: a constant Dog object
> -constant Dog $fido = Dog.new; # same thing
> -constant Dog $fido = $fido.new; # wrong: invalid self-reference
> -constant (Dog
Simon Cozens <[EMAIL PROTECTED]> writes:
> it was addressing a problem at too low a level. This could be because I'm a
> grouchy old-timer, and I carry over a Perl 5 design principle that says that
> changes should be made in as general a way as possible.
It's a very good principle, I think.
One
Luke Palmer <[EMAIL PROTECTED]> writes:
> @A »+« @B # One-at-a-time
> @A «+» @B # Outer product
>
> Or something. Hmm, then both:
>
> @A »+ $b
> @A «+ $b
There is a page you may find inspiring:
http://www.ritsumei.ac.jp/~akitaoka/index-e.html
Sorry, I could n
Hello!
I have some questions about unary _
Is this going to concat $a,$b and $c?
$foo = _($a,$b,$c);
(One way to save underlines and spaces if you have many operands.)
Or would that be:
$foo = _@($a,$b,$c);
What will these do?
$a _=_ ($b,$c);
$a ^_= ($b,$c
Hello!
Is this going to concat $a,$b and $c?
$foo = _($a,$b,$c);
(One way to save underlines and spaces.)
Or would that be:
$foo = _@($a,$b,$c);
BTW: what will these do?
$a _=_ ($b,$c);
$a ^_= ($b,$c); # (better with hypo-operator?, see below)
(WIM in Perl
[EMAIL PROTECTED] (Jeremy Howard) writes:
> Brent Dax wrote:
> > Edwin Steiner:
> > # Could there also be *hypo*-operators, i.e. operators which try to
> > # *lower* (reduce) the dimensionality of their operands to the lowest
> > # common dim. So
[snip]
> > I
[EMAIL PROTECTED] (Edwin Steiner) writes:
> @score +=^ (4,1) *^ @points;
Sorry, I completely f...ed up the example.
What I was thinking of would be more like:
$score +=^ (4,1) ^* @points;
So one hypo- and one hyper-operator.
Assuming @points is 2-dimensional this would:
Hello!
Recently I was coding Perl 5 and quite often I had to change
interpolated strings or C to C or .
I began to wonder, if qq strings couldn't allow sprintf-like
formatting directly.
I could imagine an \F escape sequence with the following syntax:
:'\F' printf-format-without-% '(' expr
Edwin Steiner <[EMAIL PROTECTED]> writes:
> "Leave some --\Fs60{space for this $interpolates string}--."
I'm sorry, this should be:
> "Leave some --\F60s{space for this $interpolates string}--."
Luke Palmer <[EMAIL PROTECTED]> writes:
> As far as the syntax, the () and {} don't make a lot of sense with
> regard to the rest of the language. We could either utilize the
> string/numeric context distinction that already exists in {} and []
> for subscripting, or we could always use () in ana
Edwin Steiner <[EMAIL PROTECTED]> writes:
> Disallowing interpolated formats on \F has the additional advantage of
> making the {} unnecessary in the most common cases (also removing the
> 'force to string').
As an afterthought: This suggests getting rid of the {} ent
Edwin Steiner <[EMAIL PROTECTED]> writes:
> The rule could be like:
>
> \\F
After-afterthought:
We know: Everything between the \F and the next funny character is the
format specifier. This allows extensions to the printf-specifiers:
(These extension and more could al
Austin Hastings <[EMAIL PROTECTED]> writes:
> Now, if you want to talk about the cool amazing formatting syntax
> you've conceived for sprintf replacement, that's fine. But I'm getting
> that warm cozeny feeling that this is burning unnecessary listmips.
Well, it's a bike shed. But it is a bike s
Simon Cozens <[EMAIL PROTECTED]> writes:
> % grep printf cvs/modules/**/*pm | wc -l
> 15
> % grep -v printf cvs/modules/**/*pm | wc -l
> 15360
>
> Well, 0.1% agreed, anyway.
Could also mean the current printf syntax is not too popular.
Reusable code is also less likely to use it than the
17 matches
Mail list logo