Re: A6: Strict signature checking - was: Complex Parameter Types
-- On Fri, 14 Mar 2003 10:08:15 Larry Wall wrote: >On Thu, Mar 13, 2003 at 07:36:00PM -0800, Brent Dax wrote: >: I think that there should be two types of arg typing[1]: 'strict' and >: 'loose'. Strict arg typing doesn't coerce, except to turn subclasses >: into superclasses; loose arg typing, on the other hand, coerces whenever >: possible. The mechanism for choosing between strict and loose arg >: typing should be under the caller's control, not the callee's. (The >: callee decides what types they want, and the caller decides how to >: create those types. This seems consistent with Perl's philosophy of >: being flexible and making B&D optional.) > >Precisely. The parameter types are completely invariant for the >callee. They are optionally invariant for the caller depending on some >kind of stricture. But I darn well want the naive user to be able to >pass a Scalar to an Int parameter and have it DWTM without them knowing >a blessed thing about these mysterious entities called "classes". > >We've got to keep the entry ramp low, or Perl is no longer Perl. > >The real question is whether this particular stricture is part of the >default "use strict" that classes and modules assume. There are >decent arguments on both sides of that one, but just to mollify Damian >I'm inclined to come down on the strict side for that. > I'll put my vote down on strictness (as in "complain about mismatch as soon as possible") by default. But just as prototypes are ignored when we prepend & in Perl 5 can't some similar frobobnitz say "But on this here call, wait till runtime and coerce if needed"? After all, it's not the kind of thing a callee should dictate, but the caller. >This week. :-) I'm easy. -Erik > >Larry > Get 25MB of email storage with Lycos Mail Plus! Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Arrays vs lists; A possible solution?
--
On Thu, 13 Feb 2003 16:03:41
Joseph F. Ryan wrote:
>Erik Steven Harrison wrote:
>
>>
>>--
>>
>>On Wed, 12 Feb 2003 17:14:17
>> Erik Steven Harrison wrote:
>>
>>
>>>--
>>>
>>>On Wed, 12 Feb 2003 18:29:29
>>>Joseph F. Ryan wrote:
>>>
>>>
>>>>As near as I can tell, the only problem with the nice flow of:
>>>>
>>>>A I is a piece of data.
>>>>A I is a variable that holds a literal.
>>>>
>>>>A I is a sequence of literals and scalars.
>>>>An I is a variable that holds a list.
>>>>
>>>>is the "Rvalue-assign list", which takes the form of:
>>>>
>>>>($r1, $r2, $r3) = (1, 2, 3);
>>>>
>>>>
>>>I don't see a problem here. The list on the right is still just
>>>value, unmodifiable. It is a list of rvalues. When you use a variable
>>>on the right hand side it is a rvalue. Similarly, a list of variables
>>>doesn't flatten to it's values - it is the list itself that it is
>>>immutable. It's individual members still retain asignibility in
>>>rvalue context.
>>>
>>>
>>
>>Okay, pardon me for replying to myself, but that was _really_ badly
>>worded. An example
>>
>>
>>foreach ($foo, $bar, $baz) {
>>.zoomdingle;
>>}
>>
>>The objects in the list retain full status qua objects even though
>>they are in a list, which is why we can call methods on them.
>>Similarly, the fact that a scalar variable acts as a value on the
>>lefthand side and a rvalue on the right hand side is retained even
>>though it is in a list. It is the list itself which is immutable.
>>Python programmers will grasp this real fast - it's just a tuple.
>>
>
>You're completely right. See my last message :-)
I *am*? Mark it on your calender!
-Erik
>
>
>Joseph F. Ryan
>[EMAIL PROTECTED]
>
>
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Arrays vs lists; A possible solution?
--
On Wed, 12 Feb 2003 17:14:17
Erik Steven Harrison wrote:
>
>--
>
>On Wed, 12 Feb 2003 18:29:29
> Joseph F. Ryan wrote:
>>As near as I can tell, the only problem with the nice flow of:
>>
>> A I is a piece of data.
>> A I is a variable that holds a literal.
>>
>> A I is a sequence of literals and scalars.
>> An I is a variable that holds a list.
>>
>>is the "Rvalue-assign list", which takes the form of:
>>
>>($r1, $r2, $r3) = (1, 2, 3);
>
>I don't see a problem here. The list on the right is still just
>value, unmodifiable. It is a list of rvalues. When you use a variable
>on the right hand side it is a rvalue. Similarly, a list of variables
>doesn't flatten to it's values - it is the list itself that it is
>immutable. It's individual members still retain asignibility in
>rvalue context.
Okay, pardon me for replying to myself, but that was _really_ badly
worded. An example
foreach ($foo, $bar, $baz) {
.zoomdingle;
}
The objects in the list retain full status qua objects even though
they are in a list, which is why we can call methods on them.
Similarly, the fact that a scalar variable acts as a value on the
lefthand side and a rvalue on the right hand side is retained even
though it is in a list. It is the list itself which is immutable.
Python programmers will grasp this real fast - it's just a tuple.
-Erik
>
>-Erik
>
>>
>>Well, what if an "Rvalue-assign list" is simply decoupled from
>>a normal "data list." The confusion would end. The concepts
>>themselves are separate, so why shouldn't the names be? "data
>>lists" become "The One True List Type", and "Rvalue-assign lists"
>>become something like "Rvalue sequences" (or a catchier name).
>>Peace would reign on earth, or at least p6-lang and p6-doc.
>>
>>(I hope I'm not missing something obvious here, at any rate :)
>>
>>
>>Joseph F. Ryan
>>ryan.311@osu
>>
>>
>
>
>
>Get 25MB of email storage with Lycos Mail Plus!
>Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
>
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Arrays vs lists; A possible solution?
-- On Wed, 12 Feb 2003 18:29:29 Joseph F. Ryan wrote: >As near as I can tell, the only problem with the nice flow of: > > A I is a piece of data. > A I is a variable that holds a literal. > > A I is a sequence of literals and scalars. > An I is a variable that holds a list. > >is the "Rvalue-assign list", which takes the form of: > >($r1, $r2, $r3) = (1, 2, 3); I don't see a problem here. The list on the right is still just value, unmodifiable. It is a list of rvalues. When you use a variable on the right hand side it is a rvalue. Similarly, a list of variables doesn't flatten to it's values - it is the list itself that it is immutable. It's individual members still retain asignibility in rvalue context. -Erik > >Well, what if an "Rvalue-assign list" is simply decoupled from >a normal "data list." The confusion would end. The concepts >themselves are separate, so why shouldn't the names be? "data >lists" become "The One True List Type", and "Rvalue-assign lists" >become something like "Rvalue sequences" (or a catchier name). >Peace would reign on earth, or at least p6-lang and p6-doc. > >(I hope I'm not missing something obvious here, at any rate :) > > >Joseph F. Ryan >ryan.311@osu > > Get 25MB of email storage with Lycos Mail Plus! Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Arrays vs. Lists
--
On Tue, 11 Feb 2003 12:28:23
Luke Palmer wrote:
>> Date: Tue, 11 Feb 2003 10:34:57 -0800
>> From: Michael Lazzaro <[EMAIL PROTECTED]>
>>
>> On Monday, February 10, 2003, at 05:56 PM, Luke Palmer wrote:
>> > Indeed, this supports the distinction, which I will reiterate:
>> >
>> > - Arrays are variables.
>> > - Lists are values.
>>
>> My hesitation about the 'arrays are variables' part is that Damian
>> corrected me on a similar thing when I was writing about scalars. A
>> variable is more like "a name of a container for a value", e.g. there's
>> three parts to it:
>>
>> - the name (what it's called in the namespace)
>> - the container (a specific container implementation)
>> - the value (what's inside it)
>>
Maybe I'm confused about why there is
confusion. An array is an object (in fact
all containers are objects, or
implementations thereoff). We can call
methods on it, and dispatch functions
differently based on it's type - which is
why we can treat lists and arrays
differently.
A list is not a object - it is a value,
immutable. It is the data that the array
object wraps around.
The name @array names arrays which Perl can
autovivify. The '@' is part of it's name. If
Perl sees a name begining with @ is hasn't
seen before is creates the array object
automatically. So
@array = (1,2,3,4);
really means
@array := Array.new (1,2,3,4)
or possibly (treating = as an overloaded
operator on the type Array)
(@array := Array.new) = (1,2,3,4)
the commas being operators which construct
the list value.
Or am I confused?
-Erik
>> So I don't know that arrays are variables, so much as arrays are
>> containers, if we want to get pedantic about it (which I don't, but...
>> documentation... sigh).
>
>Well, that doesn't assume the definition of the variable includes a
>namespace entry. So, yes, I suppose container would be better. The
>thing the namespace entry points to, but not the value.
>
>> Just to clarify... in P6, is this an array reference, or a list
>> reference?
>>
>> [1,2,3]
>>
>> What about this?
>>
>> \@array
>>
>> I'd say both of them are array references, but there's no variable
>> associated with the first one
>
>I'd agree.
>
>> -- it's just an anonymous container. So I'd rewrite the definition
>> to:
>>
>>- Lists are an ordered collection of scalar values
>>- Arrays are containers that store lists
>
>I think that's a pretty good one.
>
>> (Coupled with Uri's explanations, of course... it's the 'container'
>> part that allows read/write, as opposed to simply read.) Yes/no?
>
>Yes, from my perspective, the container is the one that knows
>read/write. Basically, the only you can't modify lists is that they
>have no operations defined that can modify them. Arrays on the other
>hand, do.
>
>>
>> > Arrays are things that know about lists. They know how to get a
>> > particular element out of a list. They know how to *flatten
>> > themselves, interpolating themselves into the surrounding list. They
>> > know how to map, grep, sort, splice themselves. They know how to turn
>> > themselves into a scalar. Lists don't know how to do these things.
>>
>> But is it OK for a list to be silently promoted to an array when used
>> as an array? So that all of the following would work, and not just 50%
>> of them?
>>
>> (1..10).map {...}
>> [1..10].map {...}
>
>I don't really know here. I'm not sure whether this should work
>I think if lists don't have the C method, that shouldn't work.
>
>> (@a,@b,@c).pop
>> [@a,@b,@c].pop
>
>Why would you suppose the former to work? Or do you mean that to mean
>(@a.pop,@b.pop,@c.pop)? Can lists have methods?
>
>This clear distinction that I once had in my mind is getting blurrier
>and blurrier. :(
>
>Luke
>
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: A4 aliasing syntax (and a note on statement modification)
--
On Fri, 7 Feb 2003 16:28:43
gpurdy wrote:
>All --
>
>A4 gives this example of C:
>
>for @foo -> $a, $b { ... } # "for @foo into $a and $b..."
>
>but, this seems more natural to me (and, it turns out, closer to the P5
>syntax for ill or good):
>
>for $a, $b <- @foo { ... } # "for $a and $b from @foo..."
All else aside, I think that a <- will not
fly. It's too easily read as greater-than-unary-minus
-Erik
>
>(heck, that even looks like shifting -- "shifty aliasing". The A4 syntax
>looks like popping until you realize it is really shoving the left N
>thingees into the containers on the right -- Syntactical Action at a
>Distance).
>
>
>
>Then, A4 gives this example of C:
>
>grep -> $x { $x eq 3 } @list # "grep into $x, $ eq 3 from @list"
># NOTE: String comparison to a number...
>
>But, this would match the C example better, IMO (and puts the
>alias name near the source of the things it will be aliasing):
>
>grep { $x eq 3 } @list -> $x # "grep $x eq 3 where @list into $x"
>
>My guess is that Larry wanted $x to appear before the block it
>will be used in, and that C's swapping of block and list
>(when compared to C) makes doing so ugly (IMO).
>
>
>
>But, this would be more natural overall (again, IMO), following my
>suggestion for C, above:
>
>grep { $x eq 3 } $x <- @list # "grep $x eq 3 where $x from @list"
>
>Whether what I suggest makes sense to anyone else or not, I do
>think the disparity between C and C in A4 should be
>dealt with...
>
>--
>
>Oh, and A4 also says "Standard Perl declarations will be plainly
>marked with C or C." The C<< -> >> or C<< <- >> notation
>for what amounts to a C should be mentioned nearby, IMO.
>
>--
>
>On another note, this would seem to be a handy statement modifier
>form for greppage:
>
>my @threes = @list when $_ eq 3; # NOTE "where" sounds better
>
>although appropriate aliasing syntax for this eludes me at the moment...
>
>my @threes = $x <- @list when $x eq 3;
>
>feels weird with the $x near the '='. And neither of these feels right
>either:
>
>my @threes = @list when -> $x { $x eq 3 }; # Close to A4 C
>ayntax
>my @threes = @list -> $x when $x eq 3; # Close to A4 C syntax
>
>
>Regards,
>
>-- Gregor
>
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
RE: [RFC] Perl6 Operator List, Take 5
--
On Thu, 31 Oct 2002 15:08:06
Brent Dax wrote:
>Erik Steven Harrison:
># All that said, can anyone come up with a case to
># confuse with <$File_Handle>?
>
>If you assume infinite lookahead, it's fine, but if not...
>
>...
>
>Is that a call to
>
> sub something() returns(IO::Handle)
>
>or a hypered
>
> sub operator:something($operand:)
>
Granted. So, I'm not as bright as I'd like to be. But
it's not unreasonable to ask for the parens to
disambiguate, and I think that I could live with a
required as opposed to girly French
angles I can't type, especially since (at least for
me) the vector ops are the common case.
I'll be up front and honest: I don't know enough about parsers. But don't we know what
operators were using before we parse, and use that knowledge to disambiguate? Sure we
can define new operators, but aren't we already assuming infinite lookahead if we can
define new operators and use them without a foreward declaration?
-Erik
>?
>
>--Brent Dax <[EMAIL PROTECTED]>
>@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>
>Wire telegraph is a kind of a very, very long cat. You pull his tail in
>New York and his head is meowing in Los Angeles. And radio operates
>exactly the same way. The only difference is that there is no cat.
>--Albert Einstein (explaining radio)
>
>
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
RE: [RFC] Perl6 Operator List, Take 5
--
On Thu, 31 Oct 2002 11:26:13
Brent Dax wrote:
>I can honestly say at this point that I'd rather give up <$iterator>
>than lose hyperops.
I was thinking the same thing not long ago. But now
that I think about it, is ever going to be
confused for <$File_Handle>? The vector operation cosy
up well to the concept of iteration anyway. Hell, if
were desperate (and I think we are) then why not just
double the brackets to <[op]> or []. Sure it's
ugly, but I prefer it to ^[op] any day of the week,
and it's not going to be ambiguous.
All that said, can anyone come up with a case to
confuse with <$File_Handle>?
-Erik
And I consider relegating them to the << >>
>digraphs losing them, because I'm never going to be able to remember how
>to type them, and neither will anybody else.
>
>Let's look at this logically. Here's all the punctuation (non-\w)
>characters on my keyboard and what they do in Perl 6:
>
> TERMOPERATORDOUBLE
>OPERATOR
>` backticks nonenone
>' string constantsnone** none
>" string constantsnonenone
>
># comment comment comment
>
>$ scalar sigilnonenone
>@ array sigil nonenone
>% hash sigil modulo none
>
>& sub sigil junction and** logical and
>! logical not none (?)none
>^ complement junction xor** logical xor**
>| nonejunction or** logical or
>
>/ regex divide defined or (in
>5.9)
>* list flatten* multiplyexponent
>- numify and negate subtraction
>postdecrement
>+ numify**addition
>postincrement
>~ stringify* concat**smart
>match
>
>= noneassignment
>comparison
>\ get reference nonenone
>.. method call** method call** range constructor
>? force to bool* none** trinary operator
>
>, nonelist composer list composer
>; nonestatement end statement end
>(in parentheses) super-comma none
>: nonesuper-comma package
>separator, trinary operator
>
>
>( )expression grouping sub parameters yuck
>{ }hash composing hash subscripts yuck
> block composing block composing yuck
>[ ]array composing array subscriptsyuck
>< >iterator syntax comparison ops shift-left, shift-right
>UNUSED:5 8 9
>
>Items marked with a * are new, ** are changed. There are twenty-two
>'none's on that list, but none of them line up. (Isn't Perl great?!?)
>
>';;' is available (it doesn't mean anything in either term or operator
>context), but it's really ugly. The other possibilities I see there
>have the same problem.
>
>There are potentially some meaningless sequences, especially with
>sigils, but those'll look quite cluttered. Actually, one of the few
>good meaningless ones is ^[op] (with the square brackets). In term
>context it would normally mean "bitwise complement this array", and in
>operator context it would mean "add this array to an xor junction". If
>we lose xor junctions (which I'm not necessarily advocating, mind you),
>this sequence is pretty much open.
>
>Damn. Larry, I don't envy you your job. :^)
>
>--Brent Dax <[EMAIL PROTECTED]>
>@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>
>Wire telegraph is a kind of a very, very long cat. You pull his tail in
>New York and his head is meowing in Los Angeles. And radio operates
>exactly the same way. The only difference is that there is no cat.
>--Albert Einstein (explaining radio)
>
>
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Perl6 Operator List (REMAINING ISSUES)
-- On Wed, 30 Oct 2002 16:37:09 Michael Lazzaro wrote: >OK, by my count -- after editing to reflect Larry's notes -- only a few >issues remain before the ops list can be completed. > > > >1) Need a definitive syntax for hypers, > ^[op] and +op; >have been most seriously proposed -- something that keeps a >bracketed syntax, but solves ambiguity issues. Maybe this is a bit radical (but hey, I'm not ashamed) but why not do what Larry proposed way back in Apoc. 1, namely, grabbing <> from iterators. Angel Faus already made a proposal for grabbing them for a qw() variant. I'd prefer stealing them for meself. I love hyperops (vector ops, if you prefer), can't easily type +hyperop;, and ^[hyperop] leaves a bad taste in my mouth. Maybe we could give fuel to Cozen's fire by totally dropping consistency, and generalize hypers to some quote like variant allowing you to define your own delimiters. Hey! then maybe hyper is spelled map . . . -Erik -- On Wed, 30 Oct 2002 16:37:09 Michael Lazzaro wrote: >OK, by my count -- after editing to reflect Larry's notes -- only a few >issues remain before the ops list can be completed. > > > >1) Need a definitive syntax for hypers, > ^[op] and +op; >have been most seriously proposed -- something that keeps a >bracketed syntax, but solves ambiguity issues. > >2) Possible inclusion of unary prefix ^, meaning "complement". >(Assuming doesn't conflict with (1)) > >3) Possible inclusion of "like"/"unlike" or similar as synonyms for ~~ >!~. Which we don't have to decide now. > > > >All other op issues, by my count, revolve around the meanings of >specific hyperop constructs. There is one, overriding question with >the hyperops, which is the precise relation between an op, an >assignment op, and their (three!) hyperop equivs: > > A op B > A op= B > A ^[op] B > A ^[op=] B > A ^[op]= B > >If we can formalize the precise relationship between the three hypers >in the presence of scalar and list (and hash?) values for A and B, I >believe we can answer nearly all the hyperop questions definitively. >For example: > >@a ^[op] @b # array v array >$a ^[op] @b # scalar v array >@a ^[op] $b # array v scalar >$a ^[op] $b # scalar v scalar > >@a ^[op=] @b # array v array >$a ^[op=] @b # scalar v array >@a ^[op=] $b # array v scalar >$a ^[op=] $b # scalar v scalar > >@a ^[op]= @b # array v array >$a ^[op]= @b # scalar v array >@a ^[op]= $b # array v scalar >$a ^[op]= $b # scalar v scalar > >Some of these are nonsensical, some of them aren't. So which are >which, and can someone demonstrate that the rule holds true for ALL >hyperoperators, as opposed to just MOST? ;-) > >MikeL > > Get 25MB of email storage with Lycos Mail Plus! Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Wh<[ie]>ther Infix Superposition ops
-- On Wed, 30 Oct 2002 07:13:40 Damian Conway wrote: >Yes. That superpositions are going to be so widely used once people >catch on, that users going to curse us every time they have to >write C at the start of every scope. So, I open my inbox and see that it has been stuffed with Perl 6 language. It's like a little gift. :-) But then I see this debate over the use of superpositions. If there are those who are still disbelieving then go look at the prior art. Icon is a fine little programming language (though a little too "pretty" for my tastes) that uses very similar syntax to what were talking about here. The big difference is that Icon supports loads of (very nice and clean) backtracking. | and & are Icon's || and &&, but Icon's backtracking gives us a really cool idiom. Superpositions offer us the same thing in Perl 6. Take a look at Icon over at http://www.cs.arizona.edu/icon/ . Once I saw it I did a Piers: "This is something I want in Perl and I want it right now!" > >;-) > >Damian > > > Get 25MB of email storage with Lycos Mail Plus! Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: labeled if blocks
--
On Sat, 26 Oct 2002 21:02:20
Larry Wall wrote:
>On Sat, 26 Oct 2002, Steve Canfield wrote:
>: Will Perl6 have labeled if blocks? Like this:
>:
>: BLAH:
>: if ($foo) {
>: ...
>: last BLAH if $bar;
>: ...
>: }
>
>I don't see why we need it offhand. But we might well have something
>that returns out of the innermost {...} anyway, so you could use that.
Well, I always thought that labeled blocks in general would give us a
way to label lexical scopes. If so, why shouldn't it apply to if
blocks?
-Erik
>
>Larry
>
>
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Character Properties
-- On Mon, 21 Oct 2002 16:49:57 Dan Sugalski wrote: > >Almost. At least perl 5's macros look like C. Emacs' macro horrors >make C look like Lisp... This is because C is _clearly_ a dialect of Lisp . . . -Erik >-- > Dan > >--"it's like this"--- >Dan Sugalski even samurai >[EMAIL PROTECTED] have teddy bears and even > teddy bears get drunk > Get 25MB of email storage with Lycos Mail Plus! Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Private contracts?
--
On Thu, 3 Oct 2002 18:46:14
Michael G Schwern wrote:
>
>I see us already smashing too many things into the method signature as it
>is. It will rapidly get messy if you have a method with a complex signature
>and a handful of attributes and preconditions.
This is the sort of creeping elegance which made me
worry about is/but in the first place.
>
>Also, where do the postconditions go? In the signature at the front?
Well, if pre and post conditions are blocks they don't
have to go in the signature at all. We can affect a
lexical scope outside of the lexical scope, so we can
simply define the PRE and POST blocks lexically to the
method _outside_ of the method. No need to put it in
the signature. Assuming method foo
foo.MY{ PRE } := sub { ... };
This is all contingent on the idea that we can name
lexical scopes (such as with loop labels, named rules
and subs, methods). The precondition here will refer
to whatever method foo is defined, wherever it is
defined in the inheritance heirarchy. If you want to
point to a specific foo, use it's fully qualified
name, if you want to point to a lexically scoped foo
__FILE__.MY{ '&foo' }.MY{ PRE } := sub { ... };
#Ugly, ain't it?
though why you wouldn't want to do it in the method
definition itself is beyond me.
Now this example syntax is ugly intentionally. It's
ugly so that someone smarter than me will feel the
need to fix it. The symbol table, taking a reference
to a class, the %MY stash are all a little vague
anyway, and I'd like to see someone propose good
syntax for it.
-Erik, of the evil mailer
That
>doesn't make sense, it should go at the end so you can keep them in mind
>when you're writing the return code.
>
>Consider...
>
> method foo($this, $that) is memoized is something
> is pre { $this <= 42 }
> is pre { $that == $this / 2 }
> is pre { a lot of code which is hard to
>shove into a block of code
>this close to the right margin }
> is post { what is a post condition
> doing at the front? }
> {
> ...
> }
>
>They can, of course, be pulled back from the margin:
>
> method foo($this, $that) is memoized is something
> is pre { $this <= 42 }
> is pre { $that == $this / 2 }
> is pre { now we have a little bit more room to play with using
> a differnt indentation style }
> is post { but post conditions are still distanced from the
>code which return()s }
> {
> ...
> }
>
>I realize that conditions are technically part of the signature, but putting
>them in there paints us into a stylistic corner.
>
>I'm also not fond of the pre/PRE distinction. Few of the other special
>blocks (given, eval, try, invar, etc...) use all cap names. At least I hope
>not. Simply attaching an "is private" attribute to a pre condition block
>seems the simplest way to go about it. Just like any other private thing,
>it's not inherited and not visible outside the current class. "pre" vs
>"PRE" doesn't convey that meaning.
>
>
>--
>
>Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
>Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
>AY! The ground beef, she is burning my groin!
>http://sluggy.com/d/990105.html
>
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: for loop and streams
--
On Thu, 26 Sep 2002 14:06:50
John Williams wrote:
>We should respect default values if arrays can declare them.
>
>Perhaps there will be a modifier for operator declarations to declare what
>the default behavior should be. Otherwise I don't know how different
>behaviors for different operators would be possible, especially for
>user-defined operators.
Having an operator force some very narrow kind of
context to control what the list returns is very
strange. The list should respond in some generalized
way (undef or whatever the list is set to pretend is
undef) and have the operator choose how to respond to
that, and return whatever it deems to be the "result"
of the operation. Under this mechanic the only tricky
part is figuring out when the list is exhausted and
when it is passing the autoviv value legitimately.
Related note, if we can define default values for a
list, is that a compile time or runtime property. I
confess as to not knowing quite how to tell. I would
hope it was runtime for the syntax alone:
@users but autovivs ("Anonymous User");
-Erik
> sub operator:foo is hyper_default(1) ...
>I agree with "Blech", but we can procrasticate doing it at least until
>Damian makes it clear how operators will define their behavior.
>
>Otherwise, a contextualized undef (0 in numeric context, '' in string)
>would seem DWIM to me.
>
>I wouldn't want to throw tons of warnings from one operation, so maybe
>hyper-operating on unequal lengths gets a new warning, instead of throwing
>lots of 'undefined value' warnings.
>
>~ John Williams
>
>
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Argument aliasing for subs
--
On Sun, 08 Sep 2002 22:24:11
Damian Conway wrote:
>
>Think of it as punctuation. As a necessary alternative to the poor
>overworked colon.
>
Or the poor overworked dot?
>
>
>> it all looks the same to me. And I like different things to look different.
>
>A fair point. My counterargument is that you're looking at the wrong bit.
A fair counterargument (a new programming game -
badmitton!)
At this point I originally had a long reply stating my
feelings. In the course of writing it and trying to
anticiplate Damian's counter counter counter arguments
the reply grew and grew until I realized I had changed
sides. But I'll assemble what thoughts were worth
salvaging into a different post and see where they go,
and get Damian off of the CC list :-).
>Hang in there. If these "mixed number" Cs were allowed then I'd suggest
>the semantics be that they indicate that *either* a scalar or array is
>acceptable in the corresponding argument slot. The scalar variant of the
>parameter would be bound to a scalar argument, or to a reference to an array
>argument. The array variant of the parameter would be bound to an array
>argument, or it's zeroth element bound to a scalar argument.
I think that my problem here lies that I want to treat
a property as either a lvalue or a subroutine call,
and my brain keeps screaming "Watch out for variable
interpolation!". I've been bitten by that enough in my
early module writing days that the fear comes quickly.
What I need (and I hope I'm not alone, or with too
much company) is to know exactly what the is does
here. What kind argument is it taking? Value, name, or
reference? Once I pin that down, the whole thing
should be clear.
>
>
>> -Erik
>>
>>>Damian
>>
>> PS - Ha! My name above Damian's :-)
>
>Letting me get the last word, eh? Very kind of you. ;-)
Touche ('cept with an accent on the e there). Maybe were fencing, not playing
badmitton.
-Erik
>
>Damian
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Argument aliasing for subs
-- On Thu, 05 Sep 2002 09:26:08 Damian Conway wrote: >Erik Steven Harrison wrote: > > >> Is it just me or is the 'is' property syntax a little >> too intuitive? Seems like everywhere I turn, the >> proposed syntax to solve a problem is to apply a >> property. > >That's because most of the problems we're discussing are solved >by changing the semantics of a variable, subroutine, or class >in some way, and C properties are the way to do that in Perl 6. > > > > And is the is/but distinction still around? > >Oh, yes. Thanks goodness. > > >> Since but's proposal I've not seen any use of it, and >> the distinction between a compile time and run time >> property was somewhat hazy to me anyway, so I can't be >> sure that it's dead or just of rare use. > >Of rare use (nice turn of phrase, BTW). Thanks. But still, what counts as a runtime property, other than true or false, as in the delightful '0 but true'? What other kind of runtime labels can I slap on a value? -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: Argument aliasing for subs
reposted because my mailer is evil
--
On Thu, 05 Sep 2002 09:31:45
Damian Conway wrote:
>Erik Steven Harrison wrote:
>
>> I know that the property syntax is pseudo established,
>> but I'm beggining to become a bit jaded about all the
>> built in properties were building. What about good ol'
>> aliases?
>>
>> sub hidden (str $name, int $force := $override) {...}
>
>I'm not keen on it because it will be hard to explain
>(or detect) the difference between that and:
>
> sub hidden (str $name, int $force //= $override) {...}
>
Just found this hidden in my inbox. I didn't think anyone was paying
attention ;-).
I think that the difference can be swept under the table in a
handwavy sort of manner by pointing out that these subroutine
declarations shouldn't be pointing to globals or widely scoped
lexicals like that. But this all brings me back to the question of
lexical leaking. Are $name and $force lexical to the sub? I know that
we are trying to avoid lexical scopes leaking into each other, but I
honestly can't figure out how that rules and these argument
declarations interact. Someone care to explain?
>What I most like about the C syntax is (like methods in
>OO Perl), it associates a meaningful *name* with each
>deviation from standard behaviour.
This is the argument that would win me over to the property syntax.
Self documenting code is an admirable goal. But I wonder about our
overuse of 'is'. The performance issues of a hash that lives with
every variable aside, it all looks the same to me. And I like
different things to look different. In a related note, I'm always
confused by whether or not we look at the value of the variable or
it's name. See below . . .
>
>I find:
>
> sub hidden (str $name, int $force is aka($override)) {...}
>
>*much* more readable, since I can read it in English.
Yeah . . . except I want at least single quotes around that darn
$override. Required singles even. Having it be context sensitive to
the type of property is WAY to subtle for me. And if $override is a
reference I'd like that to DWIM (though I understand that I may be
the only person for which that behavior is intuitive). And what
happens with double quotes - a symref? Ack!
If $force is aka(@override) is going to be a compile time error, then
why can't we just $force is aka(override) and just carry the typing
over. And if it's not a compile time error then what in Knuth's name
does it . . . . oh never mind - my head just exploaded.
-Erik
>
>Damian
>
PS - Ha! My name above Damian's :-)
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Argument aliasing for subs
--
On Thu, 05 Sep 2002 09:31:45
Damian Conway wrote:
>Erik Steven Harrison wrote:
>
>> I know that the property syntax is pseudo established,
>> but I'm beggining to become a bit jaded about all the
>> built in properties were building. What about good ol'
>> aliases?
>>
>> sub hidden (str $name, int $force := $override) {...}
>
>I'm not keen on it because it will be hard to explain
>(or detect) the difference between that and:
>
> sub hidden (str $name, int $force //= $override) {...}
>
Just found this hidden in my inbox. I didn't think anyone was paying attention ;-).
I think that the difference can be swept under the table in a handwavy sort of manner
by pointing out that these subroutine declarations shouldn't be pointing to globals or
widely scoped lexicals like that. But this all brings me back to the question of
lexical leaking. Are $name and $force lexical to the sub? I know that we are trying to
avoid lexical scopes leaking into each other, but I honestly can't figure out how that
rules and these argument declarations interact. Someone care to explain?
>What I most like about the C syntax is (like methods in
>OO Perl), it associates a meaningful *name* with each
>deviation from standard behaviour.
This is the argument that would win me over to the property syntax. Self documenting
code is an admirable goal. But I wonder about our overuse of 'is'. The performance
issues of a hash that lives with every variable aside, it all looks the same to me.
And I like different things to look different. In a related note, I'm always confused
by whether or not we look at the value of the variable or it's name. See below . . .
>
>I find:
>
> sub hidden (str $name, int $force is aka($override)) {...}
>
>*much* more readable, since I can read it in English.
Yeah . . . except I want at least single quotes around that darn $override. Required
singles even. Having it be context sensitive to the type of property is WAY to subtle
for me. And if $override is a reference I'd like that to DWIM (though I understand
that I may be the only person for which that behavior is intuitive). And what happens
with double quotes - a symref? Ack!
If $force is aka(@override) is going to be a compile time error, then why can't we
just $force is aka(override) and just carry the typing over. And if it's not a compile
time error then what in Knuth's name does it . . . . oh never mind - my head just
exploaded.
-Erik
>
>Damian
>
PS - Ha! My name above Damian's :-)
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Argument aliasing for subs
> sub hidden (str $name, int $force is aka($override))
>{ ... }
I know that the property syntax is pseudo established,
but I'm beggining to become a bit jaded about all the
built in properties were building. What about good ol'
aliases?
sub hidden (str $name, int $force := $override)
{ . . .}
While less verbose, it's actually more legible to me,
in that the prototype (we still calling it that?)
get's less visual clutter.
In a related note, even if the 'is aka($am, $are,
$also_known_as) = 'Electric Mayhem')' syntax get's
establsihed will the alising trick still work? Or are
we stepping on the Perl 6 rule against leaking lexical
scopes?
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Argument aliasing for subs
Somewhere, in another thread . . .
Dr. Claw wrote . . .
>> sub hidden (str $name, int $force is aka($override))
>>{ ... }
>
>Yeah, that's what I meant.
Is it just me or is the 'is' property syntax a little
too intuitive? Seems like everywhere I turn, the
proposed syntax to solve a problem is to apply a
property. And is the is/but distinction still around?
Since but's proposal I've not seen any use of it, and
the distinction between a compile time and run time
property was somewhat hazy to me anyway, so I can't be
sure that it's dead or just of rare use.
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Perl 6 parser, built in rules, etc.
-- On Wed, 4 Sep 2002 07:45:37 Sean O'Rourke obviated: To me a language's grammar, once >defined, shouldn't do a lot of changing, internally or otherwise. When >was the last time C's grammar changed? Or even gcc's implementation of >it? Granted . . .mostly. Were talking about Perl, the language designed to evolve. How much did the Perl grammer (even if there was no definitive one in the Perl 6 lex-on-the-fly sense) change between Perl 1 and Perl 5? Perl 5 and Perl 5.8? I think the answer to the first question (which I suspect is "a lot") point to perhaps a different issue - how much do we expect Perl to change after this rewrite, and how are we accomodating Perl's inevitable evolution? The answer to the second question (which I think is probably "a little, but some") is more to the point here. Parsing small or experimental features (vstrings and subroutine attricute come to mind) will probably cause changes to the parser. I'd like to keep the potential to introduce such features without breaking existing code. All that said, perhaps there is a solution. I'm not much of a Python programmer, but as I understand it Python offers an internal module called 'future' which holds features planned for inclusion in the next stable release. The idea here is that old code gets a chance to refactor in anticipation of language changes while still bringing new features into the language. Code which uses those features simply imports from the future modules. Hugo is working on the perl6ish pragma which already brings the concept to Perl. Perhaps a Perl 6 pragma can control these feature inclusions to help protect code which accesses the parser? -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Perl 6 parser, built in rules, etc.
It seems to me that what I mostly do is wave my arms about my head with a concern and then stay silent whenever praise is required. Everyone - consider yourselves praised :-) On to the concern (which I am fairly confident someone will obviate). I've never touched the Perl internals (and P5P should be thankful of that) so I'm not sure how much the parser changes. I worry that, since the rules that the Perl 6 grammer uses to parse the language are exposed to the users, that we could be forced to have an ever growing Perl 6 grammer to keep bakcwards compatability. If a reorganization of the parser ever occured, the language level rules would need to be maintained so that a) lexically scoped grammer changes do not break and b) those rules which are useful to all different kinds of parsing tasks (such as parsing quoted constructs) are still there for those programs which will inevitably use them. How are we planning on dealing with this, or do the implementers consider it a non issue? It seems to me that we are forced to do it (meaning the parser) right and cleanly the first time, which is a reasonable but heavy burden. -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: auto deserialization
>From: [EMAIL PROTECTED]
>> Wow, this is nice. He means (I think) that this will be translated into
>> my Date $bday = Date->new('June 25, 2002');
I don't think this is going to work. First off, there
is no predefined constructor name in Perl. Secondly,
you can have multiple constructors in the same class.
And thirdly Date.new (for better or for worse) does
not have to return a Date object.
Finally, if these problems could be surmounted (ie
Perl 6 defines an implicit constructor), then we get
very subtle bugs like this
my Dog $spot = Poodle.new;
$spot is typed to accept Dog subclasses, right? But
what if Dog.new is typed to accept an object as it's
first argument? Or, worse, has no argument list? Does
this construct turn into
my Dog $spot = Dog.new( Poodle.new );
or
my $spot is 'Dog';
$spot = new Poodle.new
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Sigils again
I've sent this message before, but Piers was kind
enough to point out that the CGI script I'm forced to
use to send mail does not readably format my messages,
increasing the likelyhood that they are ignored. So
here's a repost that's (hopefully) better to read.
==
Somewhat random question here:
We all know how to alias things in Perl 5. The binding
operator allows aliasing in Perl 6, I understand. So,
how do we alias grammer rules? Here are my guesses.
Rules live in the same namespace as subroutines, so
you can use the &. Or possibly (because filehandles
are first class objects and formats are phhbbtt)
rule1 := rule2 with no sigil. Even if rules don't work
like this, I'd like to know if that works for subs.
If we think of &sub $scalar @array and %hash as typed
references and the sigils as disambiguating *which*
reference, then perhaps we use <> as in :=
We can't.
A related question - rule {..} can create an anonymous
rule, but how do we create a ref to a named rule?
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Sigils, et all
Somewhat random question here:
We all know how to alias things in Perl 5. The binding operator allows aliasing in
Perl 6, I understand. So, how do we alias grammer rules? Here are my guesses.
Rules live in the same namespace as subroutines, so you can use the &. Or possibly
(because filehandles are first class objects and formats are phhbbtt) rule1 := rule2
with no sigil. Even if rules don't work like this, I'd like to know if that works for
subs.
If we think of &sub $scalar @array and %hash as typed references and the sigils as
disambiguating *which* reference, then perhaps we use <> as in :=
We can't.
I related question - rule {..} can create an anonymous rule, but how do we create a
ref to a named rule?
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
loop and the super comma
Long have I been a fan of giving pure Perl modules the power to change the rules and create a more built-in look, feel, and functionality. So, of course, I love %MY, I love real named parameters, I love the ability to create iterators that look just like native control structures. But while laying in bed (which I should be doing now) a thought occured to me. How would I create an itertor in pure Perl 6 which worked like a C style for, now loop? Pondering this, these vaguely related thoughts passed through my mind: 1. We now have the super comma,which can sperate arguements, so at least that looks right. But without changing the parsing rules, can I make the lack of a comma between the (...) and the block not an error? 2. This still won't work beacuse the three expressions will be evaluated before being passed to the iterator. I could get around this by having them be passed at strings and evaling them, but that defeats the idea of writing a control structure that's bulit in. What feature would Perl 6 have to have to make this possible? I remembered the ugly pass by name thread that I ignorantly started earlier, and realized that being able to hold the expression's evaluation until it's used makes it the perfect fit for this sort of thing. Can someone please show me I'm wrong and that this can be accomplished without pass by name? 3. Finally, if the above we're no longer issues,I realized that it would be easy to write an iterator that breaks our golden rule of blocks - lexical scope should not leak. I'm not yet adept at Perl 6 enough to write out an example of such an iterator, but it would be a simple matter of eva;uating the initial arg to loop, checking %MY to cee what lexicals were created, and then monkeying with the %MY of the closure passed to the iterator as a final argument. Is this an issue, or can does it fall under the "a use declaration makes a prgram a Perl 'dialect' and is free to break the rules"? -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: hyper operators - appalling proposal
>Karl Glazebrook <[EMAIL PROTECTED]> disgusted: > > @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a); >[Stuff] >If I was forced to write vector code like this I *WILL* give up on perl, >and resort to Numerical >Python or IDL instead. > You can always use the map and foreach like we've done all along. And, frankly, I find this (surprisingly) legible. It's no great shakes, but there are regexen which are signifigantly worse. Remember, your never forced to do much of anything in Perl. 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 Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: Perl 6, The Good Parts Version
>What about parsing? I think the fact that Perl 6 will pretty much >have parser capabilities built in is pretty distinctive. > >Ted When someone wants to write a parser, they turn to Perl 90% of the time (at least to prototype). The fact that they're really using a powerful lexer instead of a parser and don't ralize it is a sign of why regex and regex culture needed to change. But I don't think that advances in regexen, however great are what Pythonistas and Java Junkies need to hear to be convinced of Perl 6's power/usefullness. -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: Perl 6, The Good Parts Version
Michael Schwerned: >I've been trying to pick out what parts of Perl 6 would make a Java >programmer sit up and go "I wish I had that" or a Python programmer think >"Hmm, maybe there is more than one way to do it" and, in fine Perl >tradition, a few things which make the whole audience go "what a bunch of >fruitcakes!" In general I like the Python crowd, but there is a tendency to think that other OO heavy languages are really just reimplementations of Python, and you might have to fight that a little, seeing how Perl's increase in OO in the core language is coming along. The thing with Java programmers I think is that the already extant features of Perl's OO will make them drool (in my likely ignorant estimation) if they can be convinced that Perl's OO is 'proper' OO. Seeing how we're getting more Bondage and Dicipline OO, that might make them give the model enough respect to see the rapid development power of being able to look at the guts of a class or object from the outside, at runtime even. This might eliminate the 'catch up' opinion. I think that regexes mostly need to be avoided, simply because outsiders think of Perl too much in terms of regexes and already view us as king. In terms of selling Perl 6, regexes won't win us a crowd. -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: Perl 6 Summary
>But unlike >iterators, when you ask a generator for the next value, it picks up >execution exactly where >it left off when it returned the last value -- i Aren't these what The Damien calls coroutines? Are we getting coroutines (RFC 30, as I recall . . .)? I'm also big on seeing these. Also, thanks to everyone who answered my question. My understanding of pass by name means I understand that we can do iterators without them, and would prefer to. As is often the case, the technical information one recieves online is incorrect. I'm not looking for pass by name to be in the core, and I never was except in as much was necessarry to see strong iterator support. Again, thanks guys and gels. -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: Perl 6 Summary
--
On 02 Jul 2002 09:56:46 +010
pdcawley summed:
> Ruby iterators
>
>Ruby interators were the subject of Erik Steven Harrison's post, which
>also referred to 'pass by name' and 'the Jensen Machine', and wanted to
>know 'the Perl 6 stance on the matter'. Nobody has yet stepped up to the
>plate on this one and, speaking personally, I'm not entirely sure I've
>understood the question.
Fortunately, a little research, has clarified a good bit of my question for me. So I
think I can reposit it more clearly. Here goes.
You all know what pass by reference is, right? And pass by value? Well, Algol 60
(somewhat by accident, it seems) created a third passing semantic, which is just plain
bizzare. A Perlish example, then an explanation.
my $a = 'foo';
pass_by_name ( sub { print $a} );
sub pass_by_name {
my $a = 'bar';
&@_[0];
}
Now, I have trouble keeping Perl 6 and 5 straight, but what I think this does is print
'foo', as the sub ref is a closure, and gets $a bound to it. Fair enough.
But in pass by name, expressions passed to a function aren't evaluated until they are
used inside that function, and are evaluated in the context of the surrounding
function. In a pass by name environment, the above code would print 'bar' as the sub
isn't evaluated until it is used in pass_by_name, and then it gets pass_by_name's
value of $a. Understand? Isn't that weird?
So, pass by name sort of went to the wayside in the history of language design (Algol
60 passed chunks of the parse tree around to make all this possible). There are
benefits (Jensen's Machine is apparantly an example, but don't ask me what it is) but
no one has used it since Algol 68 because it's difficult to explain, and hard to
implement.
Now that you understand the background, here is the impetus for my
question: Ruby has brought pass by name back into the mainstream with it's much lauded
iterators. A Ruby iterator is a block of code that objects can take and are evaluated
as you would expect in a pass by name environment. I haven't used Ruby, but I am
jealous of their iterators. So, my question is, now that we have seen that pass by
name has a practical use, and can be handled in a manner which doesn't confuse the
user, can we steal it, using Ruby as prior art?
Basically, do we get Ruby iterators?
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Perl 6 grammar progress?
--
On Sun, 30 Jun 2002 21:09:40
Sean O'Rourke wrote:
>On Sun, 30 Jun 2002, Ashley Winters wrote:
>
>> I don't know how the grammars are going, and I'm not fit to write one
>> myself,
>
>Hey, neither am I, but that hasn't stopped me from taking a stab or two,
>figuring that through pain comes fitness. The attempt has certainly given
>me a much better understanding of Perl (both 5 and 6) than I had before as
>a mere user. If there's anyone else out there with the time for and
>interest in working on a Parse::RecDescent grammar, feel free to speak up.
>
>> but I wrote a list of variables I'll try to parse using any
>> grammars which go by. Are all of these legal? I suppose that's more of
>> a -language question.
>
>Cc'd accordingly.
>
>> # need more tests for ${}, I'm not evil enough for it
>> ${foo};
>
>Neither am I, but we might as well throw in @{foo}, %{foo}, &{foo}, maybe
>even $*{foo} (global symbolic reference?).
>
>> # Also, there are globals to consider
>> [...]
>
>And the wonderous *@$*foo (flattened dereferenced global $foo?).
>
>> # off the subject, but lets make sure $foo.. is parsed correctly
>> $foo..1;
>
>> $foo..[1];
>> $.foo..{1};
>
>Color me slow, but are these even legal? What does an anonymous list
>constructor do on the LHS of a range operator? I suppose it could just be
>one example of something that is always true, but could it possibly be
>useful other than by the perversity of overloading ".."? And would the
>second require whitespace before the '{' to be parsed as a closure/block?
>
>> @foo{1}; # I ass_u_me {} [] and () can be overloaded?
>
>Blech! Even if it's legal, this seems like it should be a mandatory smack
>upside the head. If we allow this, someone will overload {} to do hash
>slices on %foo, and we'll be right back to Perl 5 ;).
>
>> @foo(1);
>> @foo();
>
>Strange overloading again, or am I missing something? If we allow
>subscripting and calling to be overloaded on variables with any kind of
>sigil, what's the point of having sigils at all?
>
>> foo{1}; # foo is unary here
>
>Is this a hash subscript on a no-argument function returning a hash, or a
>block passed to foo(&block), or a malformed hash constructor being passed
>to foo(%hash)? I vote for the first, because I thought blocks' and
>hashes' opening brackets always needed preceding whitespace (or at least
>/(?
>> foo.(); # Is this &{ foo() }() or foo()? I would vote former
>
>aka foo()()? Sick...
>
>> # As a final sanity check, lets chain these things
>>
>> @.proc[$*PID].ps.{RSS};
>
>== "@{.proc()[$*PID].ps().{RSS}}", right?
>
>> @proc.[$*PID].ps().{RSS};
>
>== "@{proc().[$*PID].ps().{RSS}}"? Or is that '[]' overloaded on a '.'
>operator on '@proc'? In either case, we may have to do a sick amount of
>look-ahead and guess-work to figure out whether the leading '@' is a sigil
>or a dereference. Which has higher precedence: prefix '@' or infix '.'?
>
>You might also want to add a couple of directly-chained subscriptings,
>e.g.
>
>@foo[1]{2}(3)[4..6].
>
>/s,
>sufferer at the fickle hands of PerlQt.
>
>
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Apoc 5 questions/comments
> >Ah, Mr Wardley, I see you have finally apprehended the magnitude of my >nefarious plan. Five years of plotting and scheming, of gaining influence and >gradually insinuating my dastardly code creations into the community >consciousness: all >about to culminate in unleashing of Perl 6 on an unsuspecting populous. What a >pity you shall not live to see it! Henchmen, throw him to the giant >constrictive python! > > Ahhh, duh . . . Docter Claw . . .er Conway, uh, the Python always throws up Perl Coders . . . Shoulds we maybe bash him with the Giant Shell, or TCL him to death . . . -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
RE: regex and xml/html/*ml
--
On Wed, 5 Jun 2002 13:21:39
Brent Dax wrote:
>[EMAIL PROTECTED]:
># Just read (skimmed) apocalypse 5, had one concern - it looks
># like we are on a serious collision course with parsing the
># various *mls.
>#
># before:
>#
># m#..etc#
>#
># after
>#
># m#\\\#
>
>That's intentional. What will that regex do with this?
>
>
>
>That's interpreted the same way, but typed a bit differently. It won't
>match your regex.
>
>The moral of the story is that you should not try to parse the *MLs with
>regexen--use modules instead.
>
>--Brent Dax <[EMAIL PROTECTED]>
>@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>
>Early in the series, Patrick Stewart came up to us and asked how warp
>drive worked. We explained some of the hypothetical principles . . .
>"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
>--Star Trek: The Next Generation Technical Manual
>
>
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
--
On Thu, 16 May 2002 12:36:42
Miko O'Sullivan wrote:
>SUMMARY
>
>Arrays should always have known lengths because that's what arrays do. This
>requirement is enforced culturally, not programmatically.
I totally agree that this should be enforced culturally. I think that the way a tied
array (or hash, for that matter) should handle this in this way:
sub LENGTH { #Possible implicit sub for determining length
return undef but true; #or would this be is?
}
As Larry (I think) approximately said module and class authors should not use undef
for false - it should mean undef. This seems pretty clear to me. "We have a length
here, yes, but we don't know what it is yet. It's undefined".
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Accessor methods ?
>(Perl6 syntax obviously). I hope it's going to be possible to set that >up automagically... (Yeah, I know, if/when Perl 6 gets macros...) I've been playing around with Perl 5.6's lvalue subs. And (though at times irritating to deal with) they're wonderful. It seems to me that the use of an assignment operator is quite clear, and so there is no need for individual method calls for retrieving and setting the attribute. Will this exist in Perl 6? In fact, as long as we're mulling over it, will subroutine attributes be supported in Perl 6 and what kind of changes should we expect? -Erik Harrison Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
perl6-language@perl.org
-- On Mon, 6 May 2002 16:26:16 Dan Sugalski wrote: >*Alot of good answers to questions* Appreciate the descent from the mountain to help clear things up down here. -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: Loop controls
Lots of people said:
>Lots of stuff about 'else' loops.
*Erik thunks himself some deep thought*
I see no true slippery slope here, especially if handled correctly. I suspect that an
explicit or implicit "why not" near the beginning of discussion lead to the feature
feeding frenzy and the slippery slope responses.
To my thinking, assuming this is a needed feature, the ELSE block method is not quite
adequate. We are approaching the limit to the number of implicit blocks within control
structures a mind can be reasonably expected to handle. Although we have made comments
on the placement of these blocks being hapahzard as is, there isn't necessarily a
clear position within the flow of code that is associated with the concepts behind
those blocks. 'ELSE' however seems to clearly need to be after the block to which it
represents an alternative. Scoping issues also tend toward the post block syntax.
The need for such a structure has been most clearly defined and argued for in the case
of 'loop'. While others have said 'I can see advantages' I generally cannot, save in
the case of loop where the synthetic code of the flag to check if the loop was passed
through is a hassle and not clear. Allowing a 'loop {...} else {...}' syntax seems to
fill this niche nicely.
I have always argued that any exceptions to the looping rules should be attatched to
while, as while already had special behavior for DWIM. Now that loop has gained this
behavior anyway, loop seems the most deserving canidate for that reason.
Finally, scoping issues seem to have mostly to do with aliasing. While plenty of
implicit aliasing occurs with 'loop <> {...}' explicit aliasing seems to occur with
'foreach'. By only allowing the else construct on the control structure least likely
to have scoping issues, it makes the learning of the syntax easier. Even if you don't
understand them, you're less likely to run into them. As far as implicit aliasing
goes, I think that it would be clear that the else block only executes if $_ hasn't
been assigned to by the diamond, making it unlikely anyone would be bit by subtle bugs
from the use of $_ in the else block. I hope :-)
So, all of these things seem to say to me that the case can be made for allowing
'loop' to have an 'else' block, and for no other structures to, and that this clock
should work like an if block, and not like the implicit blocks already extant.
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Fisher-Yates shuffle
--
On Fri, 12 Apr 2002 18:27:11
abigail wrote:
>On Fri, Apr 12, 2002 at 04:42:07PM +0100, Piers Cawley wrote:
>> [EMAIL PROTECTED] writes:
>> >
>> > Why isn't
>> >
>> > if %foo {"key"} {print "Hello 1"}
>> >
>> > equivalent with the perl5 syntax:
>> >
>> > if (%foo) {"key"} {print "Hello 1"}
>> >
>> > Which keyword is it expecting?
>>
>> Keyword /els(e|if)/, or end of line, or semicolon. Sorry badly phrased
>> on my part. The closing brace of {"key"} only ends the statement if it
As i understand it (Tell me if I'm wrong) This
%hash {key};
will not work, because space between the hashname and the brace was no longer allowed.
This allows for
if %hash{key} { ... }
and also
if $scalar { ... }.
The only other white space rule is that white space after the closing brace of a
closure, when that closure is the last argument of a user defined sub get's treated as
a semicolon if there is nothing else on that line. This allows custom iterators to
parse (or appear to parse) like builtins.
myforeach @arry, %hash, $scalar {
...
}
#No semicolon required!
What problems does this seem to cause - I don't see anything wrong. I don't see how
(except in the case of closure as last argument) how it matters one way or another
what kind white space appears between tokens.
What am I missing?
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Bracekets
>
>$a is a hash key
>$b is an array index
>$c is another hash key
>
>So, if I try:
>
>@multi_dim[$b][$a][$c]
>
>then it's obviously going to break. But how can I, the
>programmer, easily spot that? It's not as clear as:
>
>@multi_dim{$a}[$b]{$c}
>
>where I can see what I'm getting as I work through the
>data structure.
>
A glance at my email tells me that several messages about this are yet to come, but
I'll risk repeating someone else.
What, exactly is the issue here? If $a is a hash key, that is clear by the funny
character.
%hash[key][additional][levels][of][depth]
If we are worried about about accidentally giving a key where an index is expected, I
don't understand how the semantics are much more confusing that the current ones. A
string'll get converted to a number and get used creating silent errors, or raise a
warning, which is not made more clear by the precence of a brace. If we're talking
about while I'm coding then the level of indirection by making the thing a variable in
the first place defeats any advantage that having the braces might give. For a really
BIG structure, if your are going to forget where the hashes are, then the braces
aren't going to help - you'll just put 'em inthe wrong place.
Printing out the value should solve the problem regardless - the braces don't seem to
make this issue much more clear. (To me anyway. I get the nagging feeling I'm missing
something.)
As to the inspring issue about using [] for hashes, I say go for it if (and only if)
it is a signifigant improvement for the parser. The historical pressure here is high,
so it can't just be a little faster.
However, if this isn't the 'idiomatic' sematics, I can see Perl in non-strict form
silently using whatever is between the []'s regardless of what the reference is. I
wonder at a)what sort of speed penalty we may be looking at for this, b)what degree of
advantage it is for QnD scripts and c)whether or not things like refs should really be
given that lazy a usage. Like modules perhaps, unstrictness in refs might be
unjustifiable.
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Apoc4: The loop keyword
>>Besides no one has commented on Steve Fink's (I think it was him) idea
>>to store the result of the most recently executed conditional in $?. I
>>kinda like that idea myself. It makes mnemonic sense.
H . . . I could grow used to that. A couple of thoughts.
1) It doesn't seem to buy us much that $_ doesn't already, except some slight
legibility in that we can say what the variable holds as in:
foreach $PIN_number (@list) {
my $PIN = $PIN_number;
#Stuff
}
2) What about our new, more complex foreach:
foreach ($key, $value) %hash {
#What's $? here?
}
Perhaps we could use @_, since we're already used to that giving us arguments from
outside the current scope. Using @_ might very well be logical since custom iterators
will be using it anyway.
3) Even given 2 above I'm not sure that:
foreach ($key, $value) %hash {
my ($key, $value) = @_;
# Do stuff
}
is more useful than
do{
my ($key, $value);
foreach ($key, $value) { . . . }
}
simply because at the end of the first we have $key and $value still overwriting any
previous values, and they'll have values afterward. Even if a $? or @_ implementation
existed I'd probably use the do { . . . } anyway for that reason.
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
