I still feel this adds yet another layer of inconsistency and confusion.
I can't look at a piece of code and know what it does, without referring
up N lines to the top of the scripts.
How is the infinite loop problem any different from other Halting problems?
Karl
Christian Soeller wrote:
>
[several replies flattened into one]
On Monday, July 15, 2002, at 01:45 PM, Sean O'Rourke wrote:
> On Mon, 15 Jul 2002, Luke Palmer wrote:
>
>> On Mon, 15 Jul 2002, Karl Glazebrook wrote:
>>
>>> @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a);
>
de like this I *WILL* give up on perl,
and resort to Numerical
Python or IDL instead.
appalled,
Karl Glazebrook
My apologies for being too succinct. "lost" is a bit of an emotive word
which is somewhat inaccuracte.
I still believe in RFC 109 and I think I made a good case based on my
own reasons. However the overwhelming majority of responses were negative,
for their own very good albeit different reasons
Numerical python uses "..." in the same sense for axis
lists in multi-dim arrays. (Improved syntax for multidim
arrays is one wishlist item from PDL for the perl core.
See RFC117)
NumPy allows you to say:
a[..., :];
where "..." means "however many", - so this is a slice along
the last dimen
Ariel Scolnicov wrote:
>
> Karl Glazebrook <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > o Why do I think perl has too much line noise? Because of code like this:
> >
> > @{$x->{$$fred{Blah}}}[1..3]
>
> This is indeed horrible. However, I fail
"Myers, Dirk" wrote:
>
> Karl Glazebrook wrote:
>
> > But what is $x[3] ?
>
> > It could be a scalar.
>
> > BUT it could be a reference to a list.
>
> > It could be a reference to a 2D PDL image.
>
> ... but references are sca
To go through a few points that has arisen:
o Why do I think "@" is useless?
OK clearly @x is a list. Good old perl4.
But what is $x[3] ?
It could be a scalar.
BUT it could be a reference to a list.
It could be a reference to a 2D PDL image.
etc.
so clearly we have no real i
Well said!
Nathan Torkington wrote:
>
> Dan Sugalski writes:
> > Unfortunately, I think you're somewhat under-informed as to the inherent
> > capabilities of people's brains.
>
> Ok, at this point I think all parties have to step away and let the
> RFCs fall where they will.
>
> It's obvious
Jon Ericson wrote:
> I've spent almost a day trying to come up with a polite response to this
> suggestion. I have started this mail 3 or 4 times but deleted what I
> wrote because it was too sarcastic, angry or dismissive. This RFC
Thanks!
> strikes to the very heart of Perl as far as I'm c
Well said!
My take: I like perl, I don't mind it the way it is. But I'd be happier if
it was a lot more like python! (indentation aside)
I guess the question arises - how radical is perl6 allowed to be?
Karl
Kai Henningsen wrote:
> And context dependency is bad for people.
>
> There is a reas
Damien Neil wrote:
> What makes you presume this? Perhaps snrub() is something like this:
>
> sub snrub {
> foreach (@_) {
> frobnicate $_;
> }
> }
>
> You appear to arguing that expressions in function argument lists should
> not be evaluated in a list context. Is this real
"J. David Blackstone" wrote:
>
> > =head1 TITLE
> >
> > Less line noise - let's get rid of @%
>
> I understand that with the pervasiveness of object-orientation we
> are now more than ever seeing objects that behave like arrays and
> hashes and that it seems strange to see these listlike or ha
Damien Neil wrote:
>
> On Tue, Aug 15, 2000 at 05:45:04PM -0400, Karl Glazebrook wrote:
> > I hope people will actually read the RFC before coming back with these
> > canned responses which I (and presumably everyone else on this list)
> > am completely familiar with. I
Nathan Torkington wrote:
> * you misunderstand the purpose of $ and @, which is to indicate
>singular vs plural. You say a $ indicates a string or number,
>but really it indicates a single thing. Similarly @ isn't just
>a variable marker, it's used to indicate that you get multiple
Nathan Wiger wrote:
> Ok, here goes. First off, I *did* read the RFC. I never respond before
Thanks, this response is more like it.
> reading. Personally, I wish people would quit coming up with these silly
> "let's drop the prefixes" RFC's that everyone on this list is completely
> familiar wit
Jon Ericson wrote:
>
> Perl6 RFC Librarian wrote:
>
> [snip reconstructionist history and newer-is-better fallacy]
>
> > I argue in this Brave New World the distinction between C<$x>, C<@x> and
> > C<%x> are no longer useful and should be abolished. We might want
> > to use all kinds of array o
Nathan Wiger wrote:
>
> This is one of the things I really like about Perl: being able to tell
> what type of thing I'm looking at. Is is a list? A single value? A hash
> of values? No sweat, look at the prefix.
I appreciate the point. I discuss it in the RFC and why I think it
no longer works.
My point is that I find the use of $x and @x visually confusing, and now
arrays are often objects anyway really confusing.
Also lots of $$x{'hmm'] and \@x[...] are no good.
This human wants less clutter!
Karl
Dan Sugalski wrote:
> The ultimate target of a program's source code is the *programm
John Porter wrote:
>
> Karl Glazebrook <[EMAIL PROTECTED]>:
> >
> > This RFC proposes that C<$x>, C<@x>, and C<%x> be ditched and
> > replaced with C<$x> for everything.
> >
> > The only distinction left would be between t
d loops, it is sometimes a bit taxing
on the brain! One often wishes one could just write it as C/fortran style
loops and have the language figure out how to do the loops efficiently.
Anyway some integration of concepts for handling large numerical computation
into the core would definitely be a good thing.
Karl Glazebrook
r may not) be an object are $ and @ really
required? There are too many objects types and not enough funny symbols..
even with Unicode.
Karl Glazebrook
Jeremy Howard wrote:
>
> > > BTW, I'd like to see a more lightweight currying mechanism too. The
> > > challenge is
22 matches
Mail list logo
