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 BD 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 Iliteral is a piece of data.
A Iscalar is a variable that holds a literal.
A Ilist is a sequence of literals and scalars.
An Iarray 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
--
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 Cmap 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: 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 Iliteral is a piece of data. A Iscalar is a variable that holds a literal. A Ilist is a sequence of literals and scalars. An Iarray 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; 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 Iliteral is a piece of data.
A Iscalar is a variable that holds a literal.
A Ilist is a sequence of literals and scalars.
An Iarray 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: 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 Cfor:
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 Cgrep:
grep - $x { $x eq 3 } @list # grep into $x, $ eq 3 from @list
# NOTE: String comparison to a number...
But, this would match the Cfor 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 Cgrep's swapping of block and list
(when compared to Cfor) makes doing so ugly (IMO).
But, this would be more natural overall (again, IMO), following my
suggestion for Cfor, 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 Cfor and Cgrep in A4 should be
dealt with...
--
Oh, and A4 also says Standard Perl declarations will be plainly
marked with Cmy or Cour. The C - or C - notation
for what amounts to a Cmy 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 Cgrep
ayntax
my @threes = @list - $x when $x eq 3; # Close to A4 Cfor 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: Literals, take 2
-- On 17 Nov 2002 11:09:53 -050 Bryan C. Warnock wrote: On Wed, 2002-11-13 at 13:26, Angel Faus wrote: There are many ways to specify literal numeric values in perl, but they default to base 10 for input and output. Once the number has Surely, Perl 6 will allow changing the radix on a more global scale. Of course it will! But just about anything acn be changed with a grammer munge. Theoretically Perl 5 could add radix notation with a source filter. But we don't have to document that. I think that we should avoid refering to pragmas and modules as much as possible in the core documentation. That's a departure from Perl 5. Here's my case: * Were writing the spec. While that doesn't give us licence to be dense and unreadable, we should leave common case information (like documenting the radix pragma) for the tutorials. * Perl 6 will likely not have a standard set of modules and pragmas. As that is the case, we can't assume modules and pragmas in the docs. * Perl 6 can do just about any wild and crazy thing with a grammer munge. Instead of documenting pragmas like radix piecemeal, we should be beating the concept that a use declaration means all bets are off into everybody's heads (beating in a pleasant metaphorical sense. of course). When a use is seen that modules documentation should be grabbed, not the core docs. -Erik use radix(16); # or something of the ilk in which case, the default (ie, non-prefixed) radix will be some property, which itself defaults to base 10. In any case, you should present the radix prefix semantics globally, and then indicate when and where you can imply the radix. That will alleviate confusion on some of the fringe cases - or perhaps the confusion is only mine. :-) been read by perl it becomes just a magnitude. That is it loses all trace of the way it was originally represented and is just a number. This code for instance prints the literal value 14. my $x = 14; # stores the integer 14 in $x print $x; You can represent the literal value in any other base, using the Cradix: syntax. For example: my $i = 2:101110;# binary my $j = 3:1210112; # tertiary my $k = 8:1270; # octal Printing these would give 46, 1310, and 696 respectively. When the base is greater than 10, there is a need to represent digits that are greater than 9. You can do this in two ways: =over =item * Alphabetic characters: Following the standard convention, perl will interpret the A letter as the digit 10, the B letter as digit 11, and so on. my $l = 16:1E3A7; # hexadecimal =item * Separating by dots: You can also write each digit in its decimal representation, and separate digits using the C. character. my $m = 256:255.255.255.0;# 256-base =back For example, the integer 30 can be written in hexadecimal base in two equivalent ways: Do these ways have names? my $x = 16:1D my $x = 16:1.14 These two representations are incompatible, so writing something like C16:D.13 will generate a compile-time error. Also note that a compile-time error will be generated if you specify a digit that is larger than your radix can support. For instance, my $x = 3:23; # error How does one specify a single digit in the... that second one there. The extended notation. my $x = 16:12; # 10:18 my $x = 16:12.; # 10:12 ? Also, given an implied radix, can one use the second extended notation? my $x = 4.5;# Same as 45 in base 10 use radix(16); my $x = 14.8.10; # Same as 0x0d8a; If so, what about the two digit ambiguity? Finally, you can create negative integers by prepending the C- character. To what? To the digits? To the radix? For example: my $x = 18; my $y = -18; my $x = 10:18; my $y = -10:18; my $z = 10:-18; On one hand, you've negated a base 10 number. OTOH, you've got a base 10 negative number. I can think in both directions, but I'm afraid some folks may be confused with the first, whereas the second is clear and just as messy. Perl allows the underline character, C_, to be placed as a separator between the digits of any literal number. You can use this to break up long numbers into more readable forms. There aren't any rules to it; you can use it however you like: 123_456_000.000 (floating point) 2:0110_1000 (binary) 16:FF_88_EE (hexidecimal) =section ** Floating-Point Numbers You can use the decimal representation of the number and the standard exponental notation. my $x = -2.542; my $x = 7.823e12; Not wanting implementation to drive the language, but the parsing of integer and numerical values may all be built upon above. Going back to above, is radix parsing core to numerical parsing? (IOW, is a radix prefix possible *everywhere* an integer is wanted, or is radix notation its own beastie which then wants an integer type? [Much of
RE: Autovivification
--
On Mon, 11 Nov 2002 13:02:12
Brent Dax wrote:
Erik Steven Harrison:
# I think that, if Perl can determine the type with virtually no
# ambiguity, it should autovivify.
#
# Actually, this behavior has already (mostly) been decided over in P6
# language. It was decided (and I agree) that the Perl 5 behavior of
Can you give me a link or a thread name or something?
No, because I am crazy and hallucinated it. I turned a
thread on autovification of read only values and then
filled in my own, biased opinion. Consider my right to
post removed.
# autovivifying references to the basic data types is the incorrect
# behavior, leading to a lot of bugs when dealing wityh complex data
# structures. So no autovifiying an untyped $undefined_var[$foo]
Why? It's pretty obvious that you want an array, and the normal array
Perl 6 provides is a good default.
If this is the case, why should we allow Cmy @foo or C[qw(anon
array)] without a type? After all, they might *really* want a
different type of array!
I always liked that Perl would autovivify references
if I assumed that the data was there. And then I
actually started to write some complex (for me at the
time) tree walking code, only to mangle the structure.
A few slips in a for loop, and boom, the whole thing
fritzed.
But then, I'm a self taught hobbyist. So I may not be
the population we need to play to.
My understanding was that Perl 6 is not abandoning the DWIM principle.
When did this change?
(Sorry if this sounds like I'm attacking you. I'm not--I'm just
attacking your opinion. :^) )
Oh good. My opinion has been getting uppity lately. This should put it in line. :-)
-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: Autovivification
--
On Sat, 9 Nov 2002 23:22:45
Brent Dax wrote:
Michael Lazzaro:
# Brent Dax wrote:
#
# I was writing up some docs (in a perldoc-like style--we can always
# change the form later, but the content is important), and started
# working on documenting references. I ended up with this bit:
#
# I imagine (if there are no objections) that the general
# perldoc writing style (booklike, informal) is probably
# exactly what we want, yes? We'll just break it up into
# *much* smaller individual sections, so that only one concept
# is being taught at a time. Probably.
OK. I'm trying to do that in the stuff I'm writing.
# =head3 Autovivification
# @{%anagrams{$key}}.push $word;
# $undefined_var[$idx]=$scalar;
#
# Hmm, not a clue. I could argue that one both ways. Perhaps (thinking
# aloud) they only autovivify if you've explicitly called out
# the exact type they store, but otherwise generate an
# exception? (Because it seems like the behavior would be
# _very_ handy if you wanted it, and a real pain in the $#@
# when you invoked it unintentionally.)
#
# So maybe if you previously declared them like this:
#
#my \Array %anagrams;
#my \Array $undefined_var;
I think that, if Perl can determine the type with virtually no
ambiguity, it should autovivify.
Actually, this behavior has already (mostly) been decided over in P6
language. It was decided (and I agree) that the Perl 5 behavior of
autovivifying references to the basic data types is the incorrect
behavior, leading to a lot of bugs when dealing wityh complex data
structures. So no autovifiying an untyped $undefined_var[$foo]
However, a question unanswered is whether or not this behavior is
inappropriate when the data structure had been appropriately typed.
-Erik
In this case, since we know they
wanted an array (they used the @ explicitly), we'll autovivify an array.
(I say virtually no because one could make the argument that you don't
know if we wanted a standard array or a typed one.)
--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: Initial notes
On Sat, 09 Nov 2002 13:21:06 Michael Lazzaro wrote: Markus Laire wrote: On 9 Nov 2002 at 18:56, Andrew Wilson wrote: I will be happy to be proved wrong about this but I have a feeling that too much attention to detail will get us bogged down. I also think that we shouldn't try to provide too exact and final documentation at once. Just define each area with enough detail (whatever that means) and then move on. Until whole language-design is somewhat complete, there will be things which requires earlier decisions to be changed. My feelings are mixed. I don't think we need to fill _every_ hole in exact sequence. But I'd like to be as precise and ordered as possible, because I think that's where this group can contribute to the effort: by filling in the details, or encouraging the designers to do it. If we keep the basic needs in mind, we should be fine: -- We should be making sure nothing nasty gets missed. The nightmare scenario is if very basic assumptions need to be revisited a year or two after the fact, because of some oops in the details that has a cascading effect through the entire design. -- In order to be useful to the internals team, we have to specify primitive, narrow behaviors wherever possible, as soon as possible. If the details specify something they weren't originally counting on, it can blow large sections of their code away in trying to meet the new expectations. I think we've all been there before. 8-( Don't know -- we'll just have to play it by ear. The primary thing I *don't* want is for this to be a clone of perl6-language, where umpteen people are asking umpteen different, unrelated questions, and there's no particular motivation to see any of the details through. I've become convinced that one of the most important things we can do is produce test cases - when showing something to a programmer, their gonna want working code. In P6L we bandy about questionable code all the time. What should be done is that once this questionable code has a defined behavior it should be turned into a test and put whereever it needs to go. If the test is well documented, we have clear documentation AND an automatic wy of testing our implementation - ie run the tests. The next big advantage of tests is that we can catch contradictions or snags with decisions made weeks or months apart, in an automatic way. Writing tests for all these behaviors has the side effect of making us experienced Perl 6 programmers before the language is finished. Definitely an edge in the job market :-) -Erik That would make it impossible to make useful progress on documenting anything. So I think the one place we _do_ need to be fairly hard-nosed is in focusing the discussion on only a few topics at a time, and politely directing other questions to perl6-language if we're not prepared to deal with them yet. MikeL 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 op with $File_Handle?
If you assume infinite lookahead, it's fine, but if not...
something ...
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 something() 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 operator 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 [op]. 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 op 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: 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 Cakas 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: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 Cis 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
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 Cis 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: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 Cis 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
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: 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
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: 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: 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 rule1 :=
rule
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 rule1 := rule
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 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, 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
--
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
/(?!\w){/).
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
EvilScientist cat=white 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! /EvilScientist Henchman type=thug 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 . . . /Henchman -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#a href=aimg src=sss!banner..etc#
#
# after
#
# m#\a\ href=a\\img\ src=sss\\!banner\#
That's intentional. What will that regex do with this?
a href=aimg src='sss'!banner
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
Re: Perl (well, Parrot) Internals QA
-- 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
