Re: hyper operators - appalling proposal
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: Trey Harris wrote: Yes. This is my fear of hyperoperation being the default for normal aggregates. Loops--and large, multiply-nested, potentially-infinite ones--can spring out of code that doesn't look loopy at all. Erm... you know what I mean. :-) Karl, do you have any objection to marking aggregates for which hyperoperation is to be the default? Then you could say: my mumble foo, bar; # Are the parens required in p6? # or my (foo, bar) is mumble; # Can you distribute properties? ... foo += bar; where mumble is matrix, hyper, or something along those lines (choosing great names is Larry, Damian and Allison's jobs, not mine :-) If we simply made such hyperoperated aggregates builtins rather than requiring user-defined classes, this would offer a compromise, would it not? This is a good compromise. The numerics person might even be able to say: use default = hyperops; # somewhere at the top of your script res = foo * sqrt(bar); while brent and others can do their CGI scripts without having to wait for the end of the known Perl universe.
hyper operators - appalling proposal
In Apocalypse 2 Larry Wall wrote: RFC 082: Arrays: Apply operators element-wise in a list context APL, here we come... :-) This is by far the most difficult of these RFCs to decide, so I'm going to be doing a lot of thinking out loud here. This is research--or at least, a search. Please bear with me. snip So the resolution of this is that the unmarked forms of operators will force scalar context as they do in Perl 5, and we'll need a special marker that says an operator is to be auto-iterated. That special marker turns out to be an uparrow, with a tip o' the hat to higher-order functions. That is, the hyper-operator: a ^* b Excuse me, but *bletch*, - this is as ugly as sin. Especially when we get into complex formulae. Imagine: solution = (^-@b + sqrt(b^**2 ^+ 4^*@a^*c) ) ^/ (2^*@a); (or would it be ^sqrt() ?) - This looks like sendmail :-) What is wrong with using a * b - the only reason I can think is to preserve a backward compatibility which is not needed? perl6 is supposed to prefer improvement over backward compatibility. The last thing we need is yet more line noise in perl6. This is a pity because in many ways perl6 changes all look rather attractive to me (e.g. consistent sigils, use of . vs -, no need to make PDL arrays any different from perl arrays). Why do we need to preserve x as array length when you are proposing x.length ? As instigator of PDL, I am very concerned. Clearly inbuilt vectorization and compact arrays in perl6 will make PDL obsolete. I have no problem with that. A sign of success to get in the core. :-) What I do have a problem with is replacing it with a construct this ugly. If I was forced to write vector code like this I *WILL* give up on perl, and resort to Numerical Python or IDL instead. appalled, Karl Glazebrook
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
get rid of them all!! Ilya Zakharevich wrote: On Thu, Sep 28, 2000 at 11:39:51AM -0400, Karl Glazebrook wrote: so what is wrong with the statement '@y = 3*@x;' then ? That other constructs *also* create an array context, in which the behaviour of multiplication you propose is not appropriate. for example? A prototypeless-function call. Ilya
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Ilya Zakharevich wrote: so what is wrong with the statement '@y = 3*@x;' then ? That other constructs *also* create an array context, in which the behaviour of multiplication you propose is not appropriate. for example? I did not see any viable proposal on changing things in a major way. To design such a change is a *major* work. We need to keep a lot of possible combinations with other features in mind, and understand all the ramifications and desired/undesired interaction. We need insight. We need to balance the tradeoffs. This is what will happen no doubt, and what will emerge will probably be less than the radicals hope for and more than the conservatives would want! I did not mean interviews. 10 years ago I read the manual. It was clearly there. I am sure it was, the guy is nuts. Karl.
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
[EMAIL PROTECTED] wrote: Ilya Zakharevich wrote: ...Do you say you are confused by using vectors (=scalars) instead of arrays? I'm not having a problem with that personally but *many* users of PDL have complained about being confused by this. They assume ndim == array == perl array. Christian Yes this is the point. I guess another way of looking at it is saying that 3*@a operates in a list context not a scalar context and that we will define the behaviour of '*' in this context. (Currently it is not defined, hence @a is converted to scalar(@a)). Karl
Re: RFC 272 (v1) Arrays: transpose()
Jeremy: you should look at the PDL mv() and xchg() methods and factor this into your thinking! Karl
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Ilya Zakharevich wrote:
But with Fortran such things are not *needed*. Compilers are smart
enough to convert (equivalents to)
map 3*$_, 34..67
This is true, but easier (and less buggy) to say what you
exactly what you mean. 102:201:3
Anyway the idea has been proposed, it won't break Perl, we'll see
what happens.
f(3*@a)
would typically be a list context - and suddently instead of 3*(1+$#a)
you get Cmap 3*$_, @a.
This is true, what I would propose is we declare 3*(1+$#a) outmoded and
always have it mean Cmap 3*$_, @a in all contexts.
This of course will break perl5 code. Note mine because I always say
3*scalar(@a) because 3*@a does not look like 3*(1+$#a) to me. I don't
know how many people would depend on that feature.
There is also the problenm that we are arguing somewhat in a vacuum
as we don't know how radical perl6 (in terms of syntax changes) will
be.
Anyhow the various proposals are out there, we'll see what happens.
Why? Currently you can make them look like references to array. See
Math::Pari for an implementation. Overloading '@{}' gives yet another
way to do this.
True but the user has to remember 'owe I am now using a special PDL
array which means I have to always use a reference to it rather than
treat it like a perl array'. Not good.
It's really hard to explain why people should use @x[1..10] for
perl arrays and $x-slice("1:10") for PDL arrays!
Use
$x-[1..10]
for both.
This is true, but inelegant. If perl @x arrays are not considered useful
why not get rid of them and always use references?
Karl
Re: RFC 272 (v1) Arrays: transpose()
Jeremy Howard wrote: Karl Glazebrook wrote: you should look at the PDL mv() and xchg() methods and factor this into your thinking! Actually, the RFC is based on PDL's xchg()! I forgot to document using negative numbers to count from the last dimension--I'll add that into the next version. Are there any other differences with xchg() that you think would be useful? I haven't used mv() before, but now I look at it I can see it's pretty interesting. Is this used much? If we add it to the RFC, do you think we'd want a separate function, or add another arg to transpose: transpose([$a,$b], 0, @arr); # xchg transpose([$a,$b], 1, @arr); # mv Think about threading sumover sums a piddle along axis 0, e.g. a 3x4x5 piddle - 4x5 now we can use sumover $x-mv(2,0) to sum along axis 2 instead. we get a 3x4 piddle Think about this for N-dims - mv can be used to bring any dimension to the front. Easier than to use xchg - no need to worry about which axis is being swapped with. OK sumover is equivalent to NumPy's add.reduce But we also have medover and NumPy has no median.reduce medover and sumover are trivial PP functions and mv has no memory copy overhead Karl
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Ilya Zakharevich wrote: You are trading a frequently used shortcut @a == 1 + $#a for a rarely-used-but-beautiful/intuitive semantic. I'm not sure it is a win. It's now boiling down to a matter of opinion and we'll have to agree to differ. Of course I use array arithmetic all the time as a heavy PDL user. Moveover, $x = 3 * @_; suddently being equivalent to $x = @_; does not look very promising... But would it not be easy to catch and warned by a p5tp6 converter? No, you do not use "a special PDL array", you use "a vector". A subtle change in wording - and no conflict. sure, but vector to me means 1D and also some sort of transformation properties whereas a PDL array is just a N-dim square container. anyway semantics - we call them 'piddles' which is moderately amusing but inelegant. This is true, but inelegant. If perl @x arrays are not considered useful why not get rid of them and always use references? Actually, this is what Perl is using internally (they are softreferences==globs, but who cares?). Hmm Karl
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Ilya Zakharevich wrote:
As shipped: no. But if this is made a primitive (which I would not
like), then the only change which is needed is to make the
tie::multi::range() token to be followed by 3 numbers.
[Aside: Why not make ternary-range operator into 10 :: 20 :: 2 ?]
That would work. My point is that having a stride is a fundamental
feature in other array languages (IDL, Matlab, PDL) and would be
useful in the perl core.
Finally as an overload expert what do you think about the proposals
to make arrays overloadable objects so one can say things like:
@x = 3 * @y;
This is not an overloading issue, this is the context resolution
issue. IMO, the cryptocontext turns out to be evil with an exception
of extremely short scripts - and this is with what we have now.
A proposal like this would make a nuisance into a nightmare. Yes, it
looks nice, but it contradicts many rules, so in the long run it is
going to be a significant step back.
...Unless the whole idea of cryptocontext is turned to become something else...
I am not sure what you mean by "cryptocontext"?
I guess the motivation here is to make non-core arrays (such as PDL
objects) look as much as possible like Perl arrays to simplify the
appearance to users.
It's really hard to explain why people should use @x[1..10] for
perl arrays and $x-slice("1:10") for PDL arrays!
I can see that allowing expressions on @x would require considerable
changes to perl core.
Is there a nice way to resolve this problem?
Karl
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Hi Ilya, I have three questions about your RFC: Firstly does your proposal allow for a slice like 10..20:2 (i.e. with a stride of 2) ? If not is there an easy way to incorporate that? Secondly, what about having multidim support in the core so that the tie-tokenisers get optimised away? i.e. would we be able to say something like: @x = @y[10..20; 1..3] for core arrays Finally as an overload expert what do you think about the proposals to make arrays overloadable objects so one can say things like: @x = 3 * @y; Katl
Re: Proposed RFC for matrix indexing and slicing
Nathan Torkington wrote: Karl Glazebrook writes: Yes. And for the record I also think the current approach of lets generate ten million RFCs and Uncle Larry knows best is nuts. There are already too many RFCs on this topic alone to grasp coherently. Do you have a better suggestion? Nat subgroups should iron out there differences among themselves and come up with a coherent set of proposals. the final decision should not be in the hands of one person. Karl
Re: New variable type: matrix
Dan Sugalski wrote:
At 12:28 PM 8/29/00 -0400, Karl Glazebrook wrote:
But scalars are not compact.
Since scalars are singular things, how would you compact them anyway?
If I say $a = ones(float,10,10) in PDL then each element of $a
is a 4 byte floating point number.
This is not a perl scalar.
If I then say $b = $a-slice("(5),(5)") then $b is a zero-dim
piddle - not a scalar.
Karl
Re: New variable type: matrix
Using semicolons is an interesting idea. But consider: @a[10:20; 30:40]; The ":"s and ";" are awfully hard to visually distinguish. c.f. @a[10:20, 30:40]; What do people feel about the whole replacing ".." by ":" issue? Karl
Re: RFC 148 (v1) Add reshape() for multi-dimensional array reshaping
Consider @x[10:20, 20:40:2, 30:50] This ALMOST works in the current Perl. @x gives array context, then the , produces a list. If [] is overloaded on @a then the subroutine sees a list like "10:20", "20:40:2", "30:50" The only reason it does NOT work in the current perl is that "10:20" is a syntax error. What would be required to make this go away? i.e. to have 10:20 appear as a plain strring. What else would it effect? Sounds like almost a solution... Karl
Re: RFC 109 (v2) Less line noise - let's get rid of @%
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. It boils down to a question of philosophy I clearly felt Perl ought to be more like python, clearly the majority disagreed with me. I have no problem with that. That's fine. I still like Perl. I think the issue got talked out very well, some good points were made I see no point in pursuing that discussion any further - given some 90% of the people on perl6-language opposed losing the @%$ distinctions clearly it has no chance of being implemented! And there seems not much more to say on the issue. The only problem I had with the whole discussion, and with ongoing disucssions on other subjects on perl6-language-data, is nobody seems to have any idea how radical perl6 should be. Larry says "anything goes" which is fine, but unhelpful. We need some context into which to frame the whole discussion. Karl Jonathan Scott Duff wrote: On Mon, Aug 28, 2000 at 05:39:20PM -, Perl6 RFC Librarian wrote: =head1 TITLE Less line noise - let's get rid of @% ... I withdrew it on 28th August as I figured I had lost the argument! I'm sorry, but this just doesn't jive with me. There is no "argument". We are discussing proposed features for perl 6. If you were somehow convinced that your idea is a bad one, than that's a good reason for withdrawing an RFC. If you're withdrawing it because no one seems to agree with you, yet you still think it's a good idea (this is how I read your sentence above), then that's just plain *WRONG* IMHO. Ignore me if I'm reading between the lines a little too much. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: New variable type: matrix
Hi Baris,
I agree with your sentiments. Most people in PDL DO come from the
number crunching/scientific background.
I would say that a matrix is just a special case of a general
N-dimensional compact array which obeys various rules. PDL
supplies a matrix-mult operator ("x") and other matrix ops.
Note it is useful to have BOTH "x" and "*".
Our goal is to get true multi-dim arrays like PDL, as you say,
into the core. Then one would have matrices too.
What the prefix should be is of course as interesting question,
currently PDL uses $, @ could be used if overloading became possible.
Is there a real case for a special prefix?
Karl
Baris Sumengen wrote:
I am little bit confused and probably very ignorant but one thing seems to
me very useful. Why doesn't perl support a new data type matrix. If perl
wants to become a real "programming language" not just a scripting language
it should support number crunching internally in a more intuitive way. I
don't know if this is suggested before but until now the messages I read
mentioned only making perl arrays consistant with pdl arrays.
etc.
Re: Some PDL issues (was Re: Test)
Nathan Torkington wrote:
(1) The current
$pdl-slice("0:$n,(0)");
syntax sucks.
Would:
$pdl-[0:$n][0][:]
suffice? I figure this would translate into something like:
$pdl-subscript( 0, $n )
-subscript( 0 )
-subscript( undef, undef )
That is, you can overload [] on objects but instead of being @{}
as it currently is (where your overload sub returns an array ref)
you get to handle the subscript operation yourself.
Some comments:
"-" really sucks as something to routinely type in to a interactive shell
all the time. I hate it.
$pdl[0:$n][0][:]
would be fine as a syntax
BUT we really want the subscription operation to be fast and efficient -
which means doing it with one subroutine call not 3. This is where the
$pdl[0:$n,0,:] form wins as you can imaging the subroutine just seeing
"0:$n,0,:" in one arg.
Also another common idiom in PDL is:
$pdl[0:$n,(0),:]
where the () means - lose this dimension of size unity. I.e. make the result
MxN rather than Mx1xN. How would this be handled?
(2) We see the need for a multidimensional, packed and typed array.
The question is: should such an array type be part of perl6 or should it
be left to a module to implement such types?
I vote module.
I guess having true multidim arrays in the core would lead to a [a,b,c[
slicing syntax.
Karl
Re: ... as a term
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 dimension.
you can also say:
a[10:20,...,10:30,30]
etc.
Karl
Larry Wall wrote:
If you're into dwimmery, you could make all of these work, too:
print (1, 2, 4, ...)
print (1, 4, 9, 16, 25, ...)
print (1, 1, 2, 3, 5, ...)
print ('a', 'b', 'c', ...)
print (3, 1, 4, 1, 5, 9, 6, 2, 5, ...)
: BTW, I propose the this new operator be pronounced "yadda yadda yadda". :-)
If you want to save the world, come up with a better way to say "www".
(And make it stick...)
Larry
Re: RFC 109 (v1) Less line noise - let's get rid of @%
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 idea what it is or how to handle it. The @x
case may have been useful in Perl4 but the world is now much more complicated.
o Why do I think perl has too much line noise? Because of code like this:
@{$x-{$$fred{Blah}}}[1..3]
I believe we need to think of ways of trying to sort out the messes use
of references in perl currently promote. One way is to make everything a
$x as I outlined, then have everything which is not a simple scalar passed
by reference automatically. Clearly there could be other solutions but
something must be done.
People on this list seem very passionate about these sort of constructs, but
I think if one took a poll of less godlike users there would be a different
opionion.
I've read all the articles about context and grammar and about Perl being the
first post-modern lanuage too.
o Why don't I just bugger off and use python?
Well I am getting tempted. :) Seriously I like perl, I like it's easy control
structures and it's lack of object-mania. It's much better for simple stuff.
Now I've been told several times to bugger off and use python can we take
that argument as read and get back to some more constructive discussion about
what is good in Perl, and what is good in Python too and how Perl might be
improved.
Karl
Re: RFC 109 (v1) Less line noise - let's get rid of @%
"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 scalar. So, $x[3] *is* a scalar.
That scalar could be a reference to a list. It could be a reference to a 2D
PDL image. It could also contain a tar of the perl source distribution. We
can *never* tell what a scalar contains just by looking at it.
exactly.
I don't think this is a problem with the line-noise markers themselves -- I
think this ambiguity is inherent in the idea of scalars, and the idea that
references are scalar. On the surface this seems reasonable: a reference is
a single thing. The implications of that idea lead to ugly code, though.
yes.
So maybe the idea of scalars isn't useful for references, and maybe it's
worth suggesting that references shouldn't really be scalars...
Yes, I guess what I am arguing is because we are now using references for
most things the concept of @lists as such as of little use.
@{$x-{$$fred{Blah}}}[1..3]
Ugh. I hope no one's arguing that this is pretty. (In fact, I think anyone
who believes this is pretty or elegant should probably not be allowed near
sharp objects...)
On the other hand, I'm not convinced that just cutting the line noise helps.
It seems to me that the concept of really only having three first-class data
types (scalar, hash, array), the fact that these types are intimately tied
to context, and the fact that perl will do some automagic context-dependent
stuff limits the amount of change we can make without altering perl beyond
recognition.
In particular:
@x[3] = grep foo, @bar ;
and
$x[3] = grep foo, @bar ;
have very different results because of context. Changing this is a big deal
for the way perl works (at least from my point of view).
It depends on whether we are after a radical redefinition of the language
or not.
Further, it really looks to me like the basic complaint isn't with the
markers themselves, but rather that dereferencing complicated things is not
just complicated, but *really* complicated.
And confusing.
I think some of these comments have been meant as "go away and use Python",
but I think some of them were meant as "what can Perl learn from Python"?
That's where I am coming from.
Personally, I want to know what Perl should learn from Python. (I've kind
of liked Python when I've used it, but it doesn't run reliably on some of
the platforms I need to have my stuff work on. Because of this, I seldom use
Python, and I'm not familiar enough with it to know what the good points
are.)
I think it's the cleaner object syntax and the was you can pass everything
around by reference without a lot of $@{} - which IS confusing.
Back to line noise: do I support removing line noise? Nope. Do I support
the current dereferencing syntax? I'm not fond of it for complicated
expressions. I don't have a better suggestion, though.
I am glad my suggestion has at least triggered some debate.
I'm glad this is getting discussed, because I'd like to see it improved, but
I don't have any answers. I just wanted to throw in my $0.02, though, and
say thanks very much for bringing up what I think is the *real* question
here... which is "can we improve the syntax for dereferencing thingys? "
Indeed.
Karl
Re: RFC 109 (v1) Less line noise - let's get rid of @%
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 to see how cutting out the
"line noise" would make it easier to decipher (I can, however, see how
splitting it into several expressions, possibly after signing travel
papers for the programmer, would improve it immeasurably). Could you
post the proposed "new code", along with explanations of the proposed
syntax?
That way us "people will die of suffocation at speeds above 12kmh"
old-fashioned perl4-head !@#$*#@$[-}})[-lovers will have a concrete
proposal in front of our eyes. I contend that any consistently
extendable proposal will lead to horrors at least on the scale of the
example above.
I hate the example above! Please prove me wrong!
I can see this is a good way to provide a concrete target for people to
aim at!
OK I would go for
($x[$fred{Blah}])[1..3]
I am imagining a language were all arrays and hashes are implicitly passed by
reference, so I only need $fred{Blah} not $$fred{Blah},
that also gets rid of the -. So $x[$fred{Blah}] is an array, then I am making
up some syntax for taking the elements of something complicated instead of
$array[1..3], other syntaxes might be possible. This still looks complicated but
less so - and all you have to do to figure out what is going on is count braces.
Maybe even
$x[$fred{Blah}][1..3]
would be possible - the problem with pretend languages is that you don't get to debug
them!
(I am assuming a multidim would be $x[a,b,c] not $x[a][b][c])
or a better syntax to me would be
$x[$fred{Blah}][1:3]
as a:b is what every other language uses for ranges. But that is another story!
I guess they key point is that if everything is a reference then we don't have
to worry about de-referencing all the time and other godawfulness. So I might
say
$x=[1,2,3]; # Or whatever shape brackets
$x[42] = 2;
and pass $x to a subroutine and use it in exactly the SAME WAY. (i.e. not @$x[42] -
yes I have heard of prototypes).
Maybe I should write another RFC, if I dare!
Karl
Re: RFC 109 (v1) Less line noise - let's get rid of @%
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 with.
Well there was the Highlander one but nothing else was obvious. Of course
the RFC list could do with a search engine.
Yeah, and isn't it cool that Perl gives you easy access to using and
understanding such complex data structures:
print @{ $cars-{$model} };
That "junk" makes it easy to see that you're derefencing a hashref that
contains a key which is pointing to an array. How is this:
it's a list of stuff - but a list of WHAT stuff? The @ is essentially
useless.
print cars-model;
any clearer? Nicer to look at? Maybe for some. Not for me, I like the
yep. yep, and easier to teach.
former. Maybe it doesn't let you know exactly what you're getting, but
you're a lot closer. And this:
print "Welcome back, $fullname, to $website!\n";
is MUCH better than this:
print "Welcome back " . fullname . " to " . website . "!\n";
I agree. That's why I believe in retaining the $. The distinction between
variable and non-variable is still useful.
Those days are gone. Perl 5 introduced the idea of Objects
and now any variable can be one of ten million possible
types all of very different behaviours.
Not true!! Only $scalars can hold objects. Now, @arrays and %hashes can
hold groups of objects, but only $scalars can hold objects.
"Groups" is a meaningless concept. You have particular objects which store stuff.
Is an image of a distant galaxy singular (one image) or plural (ten zillion pixels).
My argument, based on my practical experience, is that all the @% are essentially
useless now.
However, if you have object polymorphism, then you don't have this
problem. Objects are automatically converted to numbers and strings
on-demand. The internals people are doing some really interesting stuff
along these lines.
There is already overloaded stringify. Why does RFC49 not discuss this?
To summarize, you should read RFC's 49, 73, 28, and the link to TomC's
email I sent you. These address the real problems, and not the symptoms.
Yes. And I read TomC's stuff on those lines at least 6 years ago. Which
was why I got annoyed.
The point remains - why treat hashes and arrays as special prefix types?
It just confuses the language to have to use $ for one kind of collection
and @ for another.
ok we could use @ for everything - but @ implies 1D ness.
Karl
Re: RFC 109 (v1) Less line noise - let's get rid of @%
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 things: @foo[2..10] @$foo No I completely understand their purpose, I just argue it is no longer useful. * current typing provides rudimentary compile-type checking. Saying: $foo = (1,3,5); gives a warning. Saying: this would create a $foo array %foo = "Nat"; gives a warning. You'd lose that. To get it back you'd need this would give a syntax error! * no sample code. If you're proposing something as big as this, I *really* want to see how it's going to change the language. Take an existing 30 line program that does lots of work with variables and convert it. Show me how it affects things like slices. I want to make sure that code that is currently easy doesn't become hard. good point. what code would you like? don't get mean. :) * you complain that @foo will become more meaningless once we have different data structures that act as collections. You don't consider using @foo for those, though: my @foo : FIFO = (4,5); This fits in with my personal vision of how Perl6 will handle new data types: better support for tie, basically. You can plug in your own C or Perl code to implement new types that masquerade as scalars, arrays, or hashes. Someone else suggested this in the thread, and you treated it as already dealt with in the RFC, but I don't think it's dealt with at all. I can't see how saying my @foo : SOME_TYPE_THAT_IMPLEMENTS_ARRAY_OPERATORS = (4,5); is going to debase the meaning of '@'. "Groups" is a meaningless concept. You have particular objects which store stuff. Is an image of a distant galaxy singular (one image) or plural (ten zillion pixels). My argument, based on my practical experience, is that all the @% are essentially useless now. Karl
Re: RFC 109 (v1) Less line noise - let's get rid of @%
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 used to believe that too! Honest... I think you do a significant disservice to brush off criticism so blithely. Complaining that anyone who disagrees with you has not read the RFC is unlikely to garner much support. It was the response which was blithe, it just re-iterated arguments we are all completely familar with and did not address my point in the RFC. Line noise or not, I like the type prefixes. Great. I don't like them. snrub($a); snrub(@a); snrub(%a); snrub(@$a) snrub(%$a) Each one of these does something different. I know, just by looking at the expression, with absolutely no further knowledge of what the function and variable involved are, the general nature of what is going on. I know whether the function is receiving one argument or several. I can make reasonable assumptions about what will happen to the contents of the variable. I know something about what operations I can perform on the variable. and this is supposed to be good? presumably snrub() has a first line like my($apples, $oranges, $price)=@_ and it would be far clearer to call it that way. Perhaps we should remove context? Sure, you won't be able to test for @a == 5 any more, but we can just rewrite that as $a-length == 5. At this point, there isn't much need for the $, though, so we can just say a-length == 5. That - is ugly, though; maybe we can turn it into a . like the rest of the world, at which point we're every bit as good as Python! Y'know, I like Python. Lot of nice things in that language. Maybe we should all jump over to their mailing lists rather than wasting our time with Perl 6. Python is really nice and we should endeavour to learn why a lot of people like it so much rather than telling them 'good riddance'. Karl
Re: RFC 109 (v1) Less line noise - let's get rid of @%
"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 hashlike objects represented as scalars. However, this is what the tie interface was designed for. If your object works like an array or a hash, by all means, provide the ability to tie it to an array or a hash. The tie(0 interface is not very useful for multidim arrays, you have to say $x[42][44][49] and do multiple levels of tieing whereas one just desires to say $x[42,44,49] Having once lived in darkness before the marvels of OO enlightened me (meaning I used to just think object-oriented was a useless buzzword), I am still very sympathetic towards allowing people to come to Perl without any requirement that they learn OO. While this proposal certainly does not require OO, it seems to be assuming the universal use of it. I like that too. I find the standard prefix symbols so intuitive I find it hard to articulate the reasons why I balk at giving them up. It's like explaining breathing or the ability to distinguish colors. I strongly disagree with the assertion that the Perl type prefixes are line noise. I think that phrase is very emotionally charged but carries little objective fact, and I think you would do better to come up with a different title. Just my humour. You should have seen the draft. Don't get too emotional - I don't expect to win. I noticed that the examples you cited in a later example about "cluttered" code all seemed to include references. May I suggest that perhaps you would be happy if there were just a cleaner syntax for dealing with references? Perhaps. Karl
Re: RFC 109 (v1) Less line noise - let's get rid of @%
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 really what you mean?
I guess I do. I guess I just hate contexts!
If a function does stuff to lists it should take a list prototype.
One of the fundamental concepts in Perl is context. Would you care to
address the point of what happens to context when you remove @ and %
prefixes?
I think I just did :)
Re: RFC 109 (v1) Less line noise - let's get rid of @%
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 reason that no language after Algol68 used a context dependant grammar. There is a reason that nearly all modern computer languages don't make expression evaluation dependant on expression context. The reason is *not* that this is easier for computers. It is easier, sure, but not all that much. But it is *a lot* easier for humans. A rose is a rose is a rose. Human minds really don't like context dependancy. MfG Kai
Re: RFC 109 (v1) Less line noise - let's get rid of @%
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 concerned. What's wrong with that? There are no rules as to what we are allowed to discuss. Judging from your posts, you use perl largely in conjunction with PDL [1]. As I understand the situation, PDL uses objects (blessed scalar This is true. references) to manipulate arrays because the standard perl array is inadequate for the task. Therefore, in your experience '@' is only used for a limited, rarely needed array and '$' for a wide variety of useful arrays. Hence this RFC. Please don't think the RFC is PDL-porters derived - there are enough of those to come :) This one is personal and based on how I view doing things. It seems to me that you could have picked a different slant on this RFC. Instead of forcing Perl to look like PDL, you could have proposed that perl allow PDL to look like Perl. PDL wouldn't exist if there wasn't something about Perl that people love. Otherwise, they would be working on FORTRAN or C or IDL. If perl can make another group of Well FORTRAN and C are not array languages, and IDL costs N*$1000. Now there IS Numerical Python if you can put up with indents! people happy, so much the better. But you have to realize that this change would make a large number of people miserable. Could you rework this RFC to be a pragma? Or propose making @ work with other types of arrays? Or withdraw it? The current form is offensive to me (and I suspect many other perl programers as well). Offensive is a strong word for what is essentially a discussion about computer lingo syntaces! I am proposing what I think is a good long term improvement in perl, my own view. Even if it doesn't go through (and I'd be very surprised if it did) there are still good cases for making PDL arrays look like perl arrays to abolish user confusion. There will probably be less-earthshaking RFCs from pdl-porters along these lines. Karl
Re: RFC 84 (v1) Replace = (stringifying comma) with =
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 that there are two types of people: those who don't mind the punctuation, and those who do. We already know what Perl is like with punctuation. Let the anti-punctuation folks make their RFCs, and let Larry decide. I think they're wasting their time, but it's not about what I think. And somewhere within those python-esque convolutions, there may be some ideas that Larry will adopt. Nat
Re: RFC 109 (v1) Less line noise - let's get rid of @%
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. 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 used to believe that too! Honest... I am looking forward to reading some *real* criticisms... Karl
Re: RFC 109 (v1) Less line noise - let's get rid of @%
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 objects, why should @x be special? Rather
since there are infinitely many kinds of variable let's take the perl6
opportunity to make things simple and just use C$x for everything.
But @ and % provide important context clues (if not to perl than
certainly for programmers). We could also eliminate the plural case in
English, but this would be endlessly confusing for native speaker
(err... speakers). Why not change @x so that it can represent other
types of arrays? For instance:
my @x;# standard Perl array
my @y[2, 3]; # 2x3 matrix (syntax guess)
my FIFO @z; # FIFO stack (another guess)
or one could just *use* english plurals...
my $speaker = 'Jim';
my $speakers = ('Fred','Bill','Sally','Betty');
my $male_speakers = $speakers[0:1]; # If perl supported this style of range - see RFC
coming soon
# BUT:
my $image = read_huge_2d_list_of_numbers('file');
my $favorite_pixels = $image[10:20,50:100];
my $best_pixel = $image[11,55];
Karl
Re: PDL-P: Re: Reduce [was: Re: Random items (old p5p issues)]
OK I will raise to the bait
I think it's a bit unfair to say that PDL people have failed to 'bite',
there was quite a bit of discussion on our list after your post. Also
some concern about how much of perl6 is vapourware.
I am game to take part in discussions.
It has always been apparent to me that Numerical Python is better integrated
than PDL. Some language changes in core python WERE made to accomodate it,
also Python had less syntax clutter to get around.
I definitely support embedding many of the key PDL ideas into the language
- they key one is a much easier syntax for a multi-dim slice. We are currently
driven to
$a-slice("10:100,30:200");
compared to IDL AND NumPy: a[10:100,30:200]
I'd propose simply building the a:b syntax into the core of Perl6. It's
convenient and almost standard.
perl6 should provide simple arrays, but they should be allowed to be
replaced with objects with no change of syntax. So
@a[10:100,30:200];
Would work whether @a was a perl list of lists or a PDL compact array.
So would @a * @b
Loop unrolling sounds really good, their should be hooks for objects to
provide their own implementation. Proper overloading and ability to
overload by arg type are required, i.e.
sub myfunc{ float x, complex y }
sub myfunc{ float x, float y }
Their should also be hooks for slices, for example if one is implementing
a complex objects (e.g. representing a map) - one might want a slice in
physical units instead of array indices.
I'd even propose getting rid of @a for arrays and $a for scalars and just
making the "a". I've never really liked that feature of perl - I am sure
some users agree and some disagree - might be worth taking a straw poll.
In this age where everything may (or 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 to find a 'perlish' but not heavyweight approach...
Ah, good. I assume that having established the challenge, you'll be
rising to it? :-)
Yes of course. But I want to first of all see the following RFCs from Damian
he's promised:
* Built-ins: min() and max() functions and acceptors
* Built-ins: reduce() function
* Data structures: Semi-finite (lazy) lists
* Subroutines: higher order functions
* Subroutines: lazy evaluation of argument lists
* Superpositions: vector operations via superpositions
Damian is likely to write these in a way that is nicely integrated together,
based on past experience. What I'd then like to do is to see how these fit
together to fill in the stuff I mentioned earlier today:
quote
- Matrix ops
- Support for lazy evaluation
- Compile time expression unrolling (e.g. so that $a = sum(@b*@c+@d) does
just one loop and no memory copy, as would occur with expression templates
in C++)
- Ability to specify infinite lists (e.g. like in Haskell)
- Generic programming (iterators, algorithms, etc, eg. like in the STL)
/quote
I think the way I'd like to do this is to try and implement a couple of
interesting bits of code that I've found are good tests of numerical
programming environments. Stuff that just looks beautiful in Mathematica
(which supports functional, rule-based, and procedural programming), but is
full of loops and control structures in most languages. That way any bits
that are missing will be pretty obvious (at least bits that matter to me!)
I've tried to get input from PDL porters by cross-posting a couple of times,
but haven't got much of a bite yet. I'm nervous about finding that we either
reinvent the wheel, or break useful stuff that they've done... Are there any
PDL gurus here who are interested in getting involved in some of these
perl6-language issues?
Re: PDL-P: Re: Reduce [was: Re: Random items (old p5p issues)]
Also on the issue of loop unrolling and efficient looping.
PDL has what we call 'threading'.
This allows a C-level function to specify the dimensionality of
the arguments it accepts. For example a function addtoline() which
hyptheticaly adds a constant to a row vector might
have a 'signature'
a(n); b(); [o]c(n);
So a(n) is a 1D input, b() is a scalar (0D) which addtoline might add
to all the elements of a(n) and c(n) is the output 1D.
What is really useful is that if you add extra dimensions they
get looped over automatically, at the C-level so really fast.
e.g. a(100,10), b(10), c(100,10)
- adds to all 10 rows of a.
ALSO they way it is implemented is the array pointers are calculated
by C macros in such a way as to support transpositions and slicing
with zero memory overhead. Thus if I want to add one to every *column*
of a, in a slice:
addtoline $a-xchg(0,1)-slice("10:20,20:40"), 10, $c
here xchg creates a virtual transposition of the first two dims, and slice
creates a virtual slice. This is all done by storing extra info in the
$a object.
I think these ideas would be of use in any discussion of perl6 numerical
efficiency - there are other ways I guess. The core idea is to try and stay
in compiled loops.
The other advantage of this 'threading' is that it then automatically parallelizes
the problem - we even have an experimental PDL implementation which can use
multiple CPUs to do 'threads'.
One problem we are continually faced in PDL is we do all this at the C-level
- but then we run into problems where if we have pure-perl PDL functions they
can't do these tricks.
Another problem though is while one can usually write many complicated multi-dim
problems with threading tricks, and avoid 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
