Re: apo 2
Simon Cozens wrote: John Porter wrote: $thing is; Existence is not the same as essence. strike() while $the_iron is; -- John Porter
Re: So, we need a code name...
da Du ron ron ron -- John Porter
Subroutine attributes, from a long time ago
Old stuff becomes relevant again...
-
From: [EMAIL PROTECTED] (Larry Wall)
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED] (Larry Wall), [EMAIL PROTECTED] (Perl 5 Porters)
Date: Wed, 3 Sep 1997 16:32:29 -0700
Message-Id: [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
: According to Larry Wall:
: Also, you can put your beloved article in:
: sub foo is a locked method returning list { }
:
: I hope you're not serious, Larry.
I'm serious about thinking through all the possibilities before we
settle on anything. All things have the advantages of their
disadvantages, and vice versa.
Part of language design is purturbing the proposed feature in various
directions to see how it might generalize in the future. Sometimes we
choose the generalization. Sometimes we don't.
I'm just pointing out here that treating subroutine attributes as a
list of little pragmas that can be ignored if not understood has some
interesting benefits for people who like to be verbose. It also has
some marginal benefits in terms of backward compatibility. I wouldn't
ever write the full sentence myself, but then, I never use goto either.
: Perl may permit poetry, which is
: fine by me, but this is going out of your way to accept the syntax of
: full English sentences, and that's beyond the pale. Besides, why
: should a reader expect that a declarative description of foo would be
: followed by the body of foo?
It's appositival, if it's there. And it doesn't have to be there.
And it's really obvious that it's there when it's there.
: I'm inclined to stick with the more adjectival
:
: my obedient persistent frozen mongrel Dog $fido = new DOG;
:
:
: I don't mind adjectives. But full declarative sentences *shudder*
Oh, get ahold of yourself. Nobody's proposing that we parse English.
As with all the other proposals, it's basically just a list of words.
You can deal with that... :-)
We can certainly outlaw any words that don't correspond to something
like a package name, or whatever.
And I still think is is prettier than :, if we want a mandatory
delimiter. But I'm sure I can think up lots of arguments for : too.
I hope I'm not getting so famous that I can't think out load anymore.
Larry
- End forwarded message -
--
Contrariwise, continued Tweedledee, if it was so, it might be, and
if it were so, it would be; but as it isn't, it ain't. That's logic!
-- Lewis Carroll, Through the Looking Glass
Re: Subroutine attributes, from a long time ago
[EMAIL PROTECTED] writes: : : why should a reader expect that a declarative description : of foo would be followed by the body of foo? Isn't the functional definition of a sub just another one of its attributes, anyway? -- John Porter
Re: Subroutine attributes, from a long time ago
On Mon, May 07, 2001 at 10:07:50AM -0400, John Porter wrote: Isn't the functional definition of a sub just another one of its attributes, anyway? Oh my. Form 1, Content 0. -- An ASCII character walks into a bar and orders a double. Having a bad day? asks the barman. Yeah, I have a parity error, replies the ASCII character. The barman says, Yeah, I thought you looked a bit off. -- from Skud
Re: Apo2: \Q ambiguity
[Quoting Michael G Schwern, on May 6 2001, 22:58, in Re: Apo2: \Q ambigui] Hmmm, maybe you can point out the compose key on my keyboard, I can't find it. ;) Pick whatever you find convenient. I use the right control key. From my .Xmodmap: ! Compose key keycode 109 = Multi_key I know what Larry went through. I had to do quite a bit of work just to be able to type a £ symbol. I wound up remapping my 'option' key (that's 'alt' to you non-Mac people) to £. Compose L - for me. I still haven't managed to get my xterms to display it right and had to switch from my normal Clean font in emacs because it doesn't support high ascii to Neep. My favourite font is -dec-terminal-medium-r-normal--14-140-75-75-c-80-iso8859-1 but -misc-fixed-medium-r-normal--10-*-75-75-*-*-iso8859-1 will do as well. Note that these support ISO-8859-1. Stupid American Computers aren't quite ready for the Unicode invasion. And this is only just Latin-1... Back to Perl6! -- Johan
Re: So, we need a code name...
On Sun, 6 May 2001, Jarkko Hietaniemi wrote: durian. Aw, nuts. You beat me to it. Do we really think the externals will be spiky and the internals smelly but delicious? --- Joe M.
Re: Apoc2 - Context and variables
On Fri, May 04, 2001 at 09:06:47PM -0700, Nathan Wiger wrote: %a = (%b : %c);# flattened like Perl 5 Why not this? *%a = (%b, %c); # flattened. splat! This makes sense to me since * is already proposed as the slurping operator and since the LHS is providing context for the RHS. (%a, %b) = (%c, %d); # kept separate Indeed. (%a,%b) = (%b,%a); # Swap 'em. (%a, %b) = (%c : %d); # %a slurps all of flattened %c and %d, # %b gets nothin' (*%a, %b) = (%c,%d);# %a slurps, %b gets nothing (%a, *%b) = (%c,%d);# %a = %c, %b gets the rest I'm sure your imaginations can twiddle the cardinality knob appropriate for generalization :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: Apoc2 - STDIN concerns
$$STDIN # Return one element regardless of context. @$STDIN # Return number of element wanted by context. *$STDIN # Return all element regardless of context. How about $STDIN.$ # Return one element regardless of context. $STDIN.@ # Return number of element wanted by context. $STDIN.* # Return all element regardless of context.
Re: durians
Grocers either stock [durians] outside or frozen. And I believe there are laws in some of the SE Asian countries where they are more common that makes getting on public transportation with a durian illegal. Jeff
Re: Apoc2 - STDIN concerns
* Simon Cozens [EMAIL PROTECTED] [05/05/2001 17:51]:
%foo = ( foo = 1, bar = 1, '=' = 'baz' )
Of course, that could be spelt
%foo = +foo +bar =(baz);
Actually, it couldn't be because the in = would end the parsing.
Same problem that the POD chars have.
I think Uri's qh() suggestion is the cleanest:
use CGI qh(:standard !h2 !h3 version = 1.4);
And it would make hash declarations cleaner:
%hash = qh(
foo
bar
jim = 'bob'
var
);
Plus maybe even a pragma to set the default value:
{
use default hashval = 'closed';
%dotcoms = qh(
pets
amazon = 'open'
onlinechoice
etour
nettaxi = 'life support'
);
}
In fact use default could set stuff like what should mean truth too:
use default false = qw(0 ),
true = qw(!undef);
Or something like that. That last one might help take care of the |||
flamewars.
-Nate
Re: Apoc2 - STDIN concerns
I think Uri's qh() suggestion is the cleanest: Interesting train of thought, since one of the ideas was that qw() is ugly and has to go. (Larry's been saying this for nearly two years now, it's just that people sometimes don't listen. :) Let's keep it and add something similarly ugly to keep it company! i use Perl everyday, so from my practical standpoint, i find that qw() helps my code to look a lot cleaner and simpler to read monty
Re: Apoc2 - STDIN concerns
On Mon, May 07, 2001 at 01:27:52PM -0700, Nathan Wiger wrote: I'm not against a cleaner way to do qw() in principle, but I definitely think is not it for a lot of reasons (glob, readline, can't use =, iterators, ...) Sheesh. Yes, those would be problems with using in Perl 5. However, we are not designing Perl 5. -- `First Up Against The Wall When The Revolution Comes! Woohoo! So long as they promise to use latex gloves, I'm happy. :)' - Thorfinn, in the Monastery.
Re: Apoc2 - STDIN concerns
Uri Guttman wrote: what larry seems to want is qh() for quote hash. %foo = qh( foo bar baz ) is like %foo = ( foo = 1, bar = 1, baz = 1 ) Thank you for giving me a chance to drag out my favorite soapbox again. :-) What is needed is better support for treating hashes as sets. We want to be able to say keys(%foo) = (... list of keys ...); It is not sufficient to invent fancy syntaxes for the RHS of this equation, because the RHS should be able to be any list source. Ref. my RFC that didn't make it in in time: http://www.min.net/~jdporter/setashash.html -- John Porter All men are subjects.
Re: Apoc2 - STDIN concerns
Larry Wall wrote:
We do have to worry about the Cnext loop control function though.
It's possible that in
FOO: while (1) {
next FOO if /foo/;
...
}
the CFOO label is actually being recognized as a pseudo-package
name! The loop could well be an object whose full name is CMY::FOO.
Or something like that. But maybe that's a gross hack. Seems a bit
odd to overload Cnext like that. Maybe we need a different word.
Pardon me if someone has already suggested this, but...
Couldn't labels really be (aliases to) iterator objects?
So that
next FOO
really *does* mean
FOO.next
--
John Porter
All men are subjects.
Re: Apoc2 - STDIN concerns
* Simon Cozens [EMAIL PROTECTED] [05/07/2001 13:33]: I'm not against a cleaner way to do qw() in principle, but I definitely think is not it for a lot of reasons (glob, readline, can't use =, iterators, ...) Sheesh. Yes, those would be problems with using in Perl 5. However, we are not designing Perl 5. I know. My point is there's a lot of lessons that have been learned from the years of Perl development. They're coordinated into qw() in Perl 5. It works very well, as do the other q-ops. Incredibly well, actually. And = in is still a problem for any parser, even Perl 6's. To quote you: : http://dev.perl.org/rfc/28.pod : : Perl 6 is our opportunity to give Perl a good spring clean. When : you're spring cleaning a house, you throw out the trash and dust : down the ornaments, but you don't burn it down and build a shopping : mall instead. : : I think it's reasonably fair to assume that we're all Bprimarily : working on Perl 6 because we like Perl and we want to make it better, : not because language design is a fun thing to do of an evening. If : that's the case, nobody wins if we bend the Perl language out of all : recognition, because it won't be Perl any more. So let's not do this. : Let's keep Perl recognisably the language we know and love; let's : enhance it, by all means, but let's not turn it into something it : isn't. I'm not trying to be a jerk at all, but I think at times we're losing sight of the above. -Nate
Re: Apoc2 - STDIN concerns
On Mon, May 07, 2001 at 01:43:56PM -0700, Nathan Wiger wrote: To quote you: : http://dev.perl.org/rfc/28.pod I'm not trying to be a jerk at all, but I think at times we're losing sight of the above. I hope not, since it was primarily written with you in mind. :) -- He was a modest, good-humored boy. It was Oxford that made him insufferable.
Re: Apoc2 - STDIN concerns
* Simon Cozens [EMAIL PROTECTED] [05/07/2001 13:46]: To quote you: : http://dev.perl.org/rfc/28.pod I'm not trying to be a jerk at all, but I think at times we're losing sight of the above. I hope not, since it was primarily written with you in mind. :) Hmm, that's odd. As I recall I was one of the most fervent proponents of RFC 28: http://www.mail-archive.com/perl6-language@perl.org/msg00778.html Or did you mean something else? If you read my RFC's with a this guy loves Perl mindset I think you'll find most all of them are not actually that radical. The only ones that are really out there are ones like RFC 159, but even that's designed to be hidden under the hood. But I think we're getting a little off-topic... -Nate
Re: Apoc2 - Context and variables
Edward Peschko wrote:
If
%a = @b;
does
%c = map{ ($_ = undef ) } @a;
Yep... particularly considering something neat like
keys(%a) = @b;
could be defined to do that. Or, even niftier
@%a = @b;
--
John Porter
Re: Apoc2 - Context and variables
On Mon, May 07, 2001 at 05:35:53PM -0400, John Porter wrote:
Edward Peschko wrote:
If
%a = @b;
does
%c = map{ ($_ = undef ) } @a;
Yep... particularly considering something neat like
keys(%a) = @b;
And what is wrong with
@a{@b} = ();
which I use all the time. But I guess in perl6 that would
be written as
%a{@b} = ();
Graham.
Re: Apoc2 - Context and variables
Graham Barr wrote:
And what is wrong with
@a{@b} = ();
which I use all the time.
I use it too, because that's the perl5 idiom. But what's wrong with
it is that you don't have a set on the LHS, you have some funky hash
slice thing, with both the hash AND the keys being assigned into it.
Have you read my RFC? The essential problem with trying to use hashes
as sets (in perl5) is that sometimes it's the hash *variable* which is
the set, and sometimes it's the *set of keys* of the hash which is the
set, and most set-oriented operations have to use some klunky
combination of both views.
If the hash variable type had some method for accessing the set of keys
directly as a (pseudo)array, that would be one way to neatly solve the
problem. That's why I proposed the @%foo syntax. But more python-like
syntaces are possible, if desired.
--
John Porter
All men are subjects.
Re: Apoc2 - Context and variables
On Mon, May 07, 2001 at 05:35:53PM -0400, John Porter wrote: Yep... particularly considering something neat like keys(%a) = @b; See my earlier comments on lvalue operators. I *hope* lvalues will be a lot more flexible in Perl 6. :) -- Be not anxious about what you have, but about what you are. -- Pope St. Gregory I
Re: Apoc2 - STDIN concerns
Simon Cozens writes: However, we are not designing Perl 5. This gets to a theme that is turning into more and more of an irritant in following (and very occasionally participating) in the ongoing discussion here. There seems to be a sense among some participants that certain issues are Off Limits. I got quite a bit of static from my comments about the desirability of retaining the . concatenation operator. In any process like this, certainly some issues have reached a preliminary resolution before they are opened for public discussion, others are relatively undecided, and still others have two or more competing approaches that need to be resolved. It strikes me as counterproductive to say, Oh, that's ALREADY been decided (with the distinct undertone of by the way please note how out of touch you are), or That's fine but we're not designing Perl 5 here (with the apparent inference that concerns about syntax and efficiency have been trumped by the onrushing demands of the various new schemata being proposed). Especially in cases where Larry hasn't even addressed the specifics yet. This is not conducive to open discussion and gaining the widest review and consideration for all the complex/interactive aspects of a language development process. No doubt Larry will reject many of our notions out of hand, for a variety of reasons, but at the same time I note that he typically provides a precis and justification for those as they come along. Remember, A2 has been out for less than a week. Those who see their role as shepherding this process along by avoiding things already decided risk losing the input and involvement of those with practical concerns. I trust Larry and the others who are going to end up coding all this stuff to take all input and assess it accordingly. Now perhaps there would be some use for a process like the evidentiary and procedural rules of court. In a trial, certain things are stipulated as facts and not further discussed. Other things are put off the record as irrelevant or biased and are not included in the final decision. And so on. But I don't think we need to be that hypertechnical about this. While a word to the wise about nearly-finalized decisions ought to be sufficient, remember that none of us are mind readers, and if we wish to have the widest range of appropriate input, it is well to recognize that not everyone here is a core Perl developer. out, phred
Re: Apoc2 - STDIN concerns
On Mon, May 07, 2001 at 05:14:23PM +, Fred Heutte wrote: It strikes me as counterproductive to say, Oh, that's ALREADY been decided (with the distinct undertone of by the way please note how out of touch you are), or That's fine but we're not designing Perl 5 here (with the apparent inference that concerns about syntax and efficiency have been trumped by the onrushing demands of the various new schemata being proposed) Hrm, no. You completely misunderstood why I said that. I said that because if we *are* going to change the syntax, saying that it will clash with the old syntax is an invalid argument, because it won't clash because we'll change it! -- dd.c: sbrk(64); /* For good measure */ - plan9 has a bad day
Re: Apoc2 - STDIN concerns
Simon Cozens makes a good point in response to my slightly overamped oration on the qualities of dissent. I am seeing most of the current discussion on this list as being brainstorming on details, not painting the vast new blue skies, and that is as it should be. Acknowledging that making changes involves tradeoffs is an important part of that. We are ultimately dealing with the fact that the working subset of commonly shared non-alphanumeric keys on keyboards is somewhat limited (where IS that darn Compose key anyway!). This isn't so bad; the constrained set avoids APLism, and as many may know, that way lies madness! http://www.chilton.com/~jimw/keyboard.html And so there's a bit of a three-dimensional Rubik's Cube game here to try and rejigger the use of the keyboard to make the language more efficient and productive and maybe even clean out some of the accumulated crud out there. Onward. I resume my stance as interested layman... Fred
Re: Apoc2 - STDIN concerns
On Mon, May 07, 2001 at 05:47:59PM +, Fred Heutte wrote: And so there's a bit of a three-dimensional Rubik's Cube game here to try and rejigger the use of the keyboard to make the language more efficient and productive and maybe even clean out some of the accumulated crud out there. http://babe.pobox.com/~mengwong/pcd/yapc1999/orwant-1.html -- BITTERNESS: Never be Afraid to Share Your Dreams with the World, Because there's Nothing the World Loves More Than The Taste of Really Sweet Dreams http://www.despair.com
