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 @foo, @bar; # Are the parens required in p6? >> # or >> my (@foo, @bar) is ; # Can you distribute properties? >> <...> >> @foo += @bar; >> >> where 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. > >
Re: hyper operators - appalling proposal
[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); >> >> That would not be very pretty, indeed. It would also not be very >> efficient. (BTW, its b**2 - 4ac, not + :)A more efficient, pretty, yeah the minus sign got lost in all the clutter. My point I think :) >> and clear way would be like this: > > Not necessarily true! The compiler can figure out that a sequence of > operators is hyped and avoid the temporary arrays (like your for-loop). > It takes a little more work, but it's really not all that hairy when the > necessary information is right in the syntax. > > Furthermore, the beauty of the hyper-operators (or the implicitly-vector > normal operators below) is they don't give the programmer a loop body in > which to do wierd things to the arrays. Since > > @y = $a ^* @x ^+ @b > > is all a single operation from the user's perspective, the compiler can > make it faster than a loop written in pure Perl. This is exactly what happens in PDL currently, but instead you say $y = $a * $x + $b where everything is an object > I actually find myself using @a in numeric context quite a bit, but > would > have no objections to changing it to @a.length, since the former is > completely bizarre to someone not familiar with Perl. glad you agree. I want to hear what Larry says. > >> I wouldn't mind if this proposal was accepted, but I also think the >> hyper >> operator syntax is nice. At least for what I'm doing, in which it's >> usually Yet Another shorthand for a C (or now just C) >> loop. > > Maybe we could add a hyper-context to cut down on the line-noise without > startling Perl 5 programmers: > > @solution = ^( -@b + sqrt(@b**2 + 4*@a*@c) ) / (2*@a) ) Still looking ugly! > Or (this might break something): > > @solution ^= -@b + sqrt(@b**2 + 4*@a*@c) ) / (2*@a); > But would not work if there was no = sign - e.g. foo(@x * @b +1) > (then watch as people have all their inplace-array-bitwise-xors change > meaning;) > > I agree that the ^op syntax is painful if you have to type it a lot, but > for the majority of people not using Perl for numerical code, > hyper-operation is something out of the ordinary, and seems to deserve > syntactic markers. For example: > > my @things = @args || @defaults; # @args if it is true, else @defaults > # vs > my @things = @args ^|| @defaults; # $args[$_] || $defaults[$_] for 0..X > > If infix operators are implicitly vector, the first's becoming the > second > could be a bit surprising. Even more so since, if we're handling > infinite > lists, hyper-operators should iterate over the number of items in their > shorter argument. I say the latter is more useful and it is time to break with the past > > On Monday, July 15, 2002, at 01:03 PM, Erik Steven Harrison wrote: > > > Where I see a big win for hyper operators is in places where the > scafolding code ordinarly clutters the actual work. I like being able > to write > > @defaults ^//= 1; > > don't you? > > -Erik @defaults = 1 > On Monday, July 15, 2002, at 01:52 PM, Aaron Sherman wrote: > Sure, that's always an option. I think Perl has a lot going for it other > than the way vectorization happens, and with the ability to define your > own array behavior, you can pretty much do this however you want anyway. Yes but it would be nuts to have PDL arrays do things one way and inbuilt compact arrays do things another way. Karl
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. > 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 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: ... 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 @%
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 @%
"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 @%
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 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 @%
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 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 @%
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 @%
"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: > > 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 @%
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 @%
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 @%
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: 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 @%
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 *programmer*.
> Programmers, being people (well, more or less... :), work best with symbols
> and rich context. Stripping contextual clues out of code does the
> programmer a disservice. We're at the point where we don't have to cater to
> the limitations of the computer hardware. That means we'll be better off if
> we cater to the limitations (and strengths!) of people's wetware.
>
> Let's not move backwards and force people to work like machines. Instead,
> lets force machines to work like us.
>
> Dan
>
> --"it's like this"---
> Dan Sugalski even samurai
> [EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
Re: RFC 109 (v1) Less line noise - let's get rid of @%
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 things which are > > variables (prefixed by C<$>) and not-variables (subroutines and > > keywords). > > A useless distinction at the lexical level. Get rid of "$" too. > x is a symbol; perl can look up what it means. > > -- > John Porter It may be useful on a human level though. I agree that would be another solution - even more radical than my proposal. Karl
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
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:
>
> - 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)
>
>
> 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?
