Re: Timely object destruction
On Mon, 2 Jun 2003, Benjamin Goldberg wrote: All values needing timely destruction would inherit from a class RefCounted. I like this concept a lot, but maybe we can take it a little further and make it transparent to the programmer. Suppose that the internals only tracked objects that have a DESTROY method (or whatever it will be called in Perl6)? You get the same benefit without the additional brain-overhead of manually indicating that the class needs to be tracked. -Miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: Funding the design team
On Thu, 20 Mar 2003, David Storrs wrote: Folks, give us your address (or a PO box, or something), where we can send checks. The checks won't be tax deductible, but are we really doing this for the tax deduction? ... or a PayPal account. I've got $1.36 in my account ready to send to the development team. Sorry, the Electronic Frontier Foundation got the other $5 that was in that account this morning. -Miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: Language Discussion Summaries
The idea of discussion summaries has been well received, so I'm going to push forward with a few. I invite everyone here to join in. The idea is *not* that Miko writes summaries of every thread. The idea is that the proponent of an idea, or someone very interested in an idea, writes a summary as a clean final presentation of the idea and its reception. Submitting a summary of your pet proposed feature is a good way to put the idea in front of the decision makers. You can show off your idea without the clutter of endless detailed commentary. That being said, you still need to present a balanced summary of the all opinions, including those you disagree with. The summaries will be located at http://www.idocs.com/perl6/ Here's how to submit a summary. Use the template at http://www.idocs.com/perl6/template.html . The HTML is set to use the stylesheets on my server, so you can edit the summary on your own machine and submit it once it's clean and ready. Email the summary to me at [EMAIL PROTECTED] The summary should be written after discussion of the idea has winded down. I won't announce in the list the appearance of individual summaries, but I will occasionally post a list of new summaries. I'll be starting with three of my own favorites: vrep (http:[EMAIL PROTECTED]/msg09684.html), the monolithic Loop controls thread (http:[EMAIL PROTECTED]/msg09684.html), and named params in subroutines (http:[EMAIL PROTECTED]/msg09551.html). -Miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: Language Discussion Summaries
On Tue, 4 Feb 2003, Buddha Buck wrote: You suggest doing it in HTML. Wouldn't it make more sense to do it in POD, the standard documentation language for Perl? For now, since it's a web site, let's stick to HTML. If somebody just way prefers POD, contact me off list and we'll figure out the best way to proceed. And how do these differ in concept to the RFC process Perl 6 has already gone through? Wouldn't it make sense, assuming that clean, final presentations of proposed ideas or features in Perl are useful, to re-open the RFC process? RFC's are proposals before the comments. The summaries are, well, summaries of the comments. My main concern is that Larry, Damian, et al, are likely to have a hard time reading through all the comments in the language list (Damian isn't even in the list right now), so the summaries are a way of letting them cut to the chase on the discussion of each idea. -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: Language Discussion Summaries
On Tue, 4 Feb 2003, Buddha Buck wrote: You are aware the that RFCs went through a revision process, and the finalized RFCs that the Design Team are looking at are supposed to include the final form of the idea after discussion, and a summary of what was thought of it? Many of the RFCs weren't written until after the idea had been discussed. Sure, I'm aware of that. However, the language list goes on (and sometimes, on and on and on). If those discussions are to be useful, somebody needs to summarize them. -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: Shortcut: ?=
On Mon, 3 Feb 2003, Deborah Ariel Pickett wrote: I guess what I'm saying is that someone needs to provide a real-world, non-contrived, example showing ??= in use. Fair enough. Real World, Non-Contrived: In all databases that I've ever worked with there are exactly two possible values for a boolean database field. Those two values are usually 't' and 'f', though in my designs I prefer to use '1' and '0', to keep things more perlish. Now, when a value comes in from a web page, it might be anything. In particular a checkbox is going to be either undef (if the checkbox wasn't checked, the standard is that the field isn't sent at all) or whatever the INPUT tag's VALUE attribute is set to, or 'on' (if VALUE isn't set). There is simply no way to directly get 'f' or 0 from the HTTP request, and 't' requires extra work. Ergo, it's necessary to massage the data a little to fit it into 't' and 'f'. In short, although Perl is quite robust about what's true and false, other computer systems are more fussy. I personally find myself explicitly setting variables to 1 or 0 quite frequently, and I always use ?:. It would be a nice little shorthand addition to have ??= in Perl6. Obviously this isn't a major requirement. It's just a nice little shortcut that would clean the code in the same way the other shortcuts do. I always feel somehow redundant type C$var = $var ? 1 : 0, and ??= would just be nice and tidy. -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Language Discussion Summaries
SUMMARY Members of the Perl6 Language list produce summaries discussions of proposed features of the Perl6 language. These summaries will improve the signal to noise ratio for Larry and his lieutenants as they try to keep up with feelings in the list. See http://www.idocs.com/perl6/ for the first example of a summary. DETAILS With Damian taking a break from the list, I've become concerned that ideas generated in this list will become buried in the volume of messages. If Larry, Damian, and other members of the core team have to read through every bottomless thread just to find out the ideas and opinions of the list members, they may never be able to keep up. Therefore, I propose that members of the language list provide summaries of the discussions in the group. Each summary describes a proposed idea feature of the language, then summarizes the list's feelings on the idea. Different opinions will be presented. The summaries will also attempt to provide a feeling for the weight of opinion, e.g., most people felt this way, some people felt differently, etc. The summaries will also link to the original threads so that readers can peruse the raw data. Although these summaries will be necessarily subjective, the authors will attempt to be journalistically objective. The authors will be clearly identified. If the authors participated in the thread, that fact will also be identified. Finally, anybody on the list who chooses may add a note that they concur with the summary (sorta like in science journals where authors are simply people who agree). Dissenting opinions (i.e. people who think the summary is innaccurate) might also be presented, but I'd rather just incorporate those opinions into the summary and reach a consensus that the summary correctly summarizes the thread. See http://www.idocs.com/perl6/ for the home page for the summaries and one example summary. -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: newline as statement terminator
On Tue, 4 Feb 2003, [iso-8859-1] Stéphane Payrard wrote: In the tradition of Perl concision, I would like newline to be a statement terminator everywhere it can: that is when a) the parser expects an operator _and_ b) we are not in the middle of a parenthesised expression. I don't mean to be abrupt here, especially seeing as how this list has been so patient with some of my ideas but... PLEASE NO. The rules you suggest for keeping track of when a semicolon is required sound more confusing than the simple rule of end of statement, put semicolon. I like to break up my long statements in all sorts of arbitrary places, and adding the worries of when a newline might be significant puts a knot in my stomach just thinking about it (literally). Note that, for Perl 6, Larry has already opened the path in his fourth apocalypse: NOTE TO ALLISON RANDAL: in your face-to-face meetings next week, please make sure that Larry Wall isn't really Guido van Rossum with a fake mustache. -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Shortcut: ?=
SUMMARY C$var ?= $x : $y as a shortcut for C$var = $var ? $x : $y. DETAILS We have ||=, +=, -=, etc. These shortcuts (I'm sure there's some fancy linguistic term for them) save us a few keystrokes and clean up the code. So, concerning C? :, I find myself doing this type of thing a lot: $var = $var ? 1 : 0; How 'bout a shortcut for that, something like this: $var ?= 1 : 0; -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: purge: opposite of grep
On Fri, 6 Dec 2002, Damian Conway wrote: The selector block/closure would, naturally, be called in Cint context each time, so (again, as Larry pointed out) a boolean function would naturally classify into two arrays. Though it might at first be a little counterintuitive to have to write: OK, but I would assert that the false/true classification is going to be the more common case, not classify by index position, and that furthermore there will be a lot of situations where the false/true value may be any number, not just 1 or 0. For example, suppose I want to separate a list of people into people who have never donated money and those who have. Assuming that each person object has a donations property which is an array reference, I would want to classify them in this manner: (@nevers, @donors) := classify($_-[donations]) @people; According to the Cint model, that would give me people who have donated zero times, and people who have donated once, and the people who have donated more than once would be lost. Now, of course you can force the dontations into a boolean context, but, frankly, I think If we force people to always remember to force boolean context, just to preserve the (IMHO) unusual case of classifying by integer, we're, on balance, making more work for the world. Ergo, I suggest we simply have a separate command for the false/true situation: (@nevers, @donors) := falsetrue($_-[donations]) @people; (Yes, falsetrue is a stupid name, please replace with something better.) -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: purge: opposite of grep
On Wed, 4 Dec 2002, John Williams wrote: While purge is cute, it certainly is not obvious what it does. Of course neither is grep unless you are an aging unix guru... How about something which is at least obvious to someone who knows what grep is, such as vgrep or grep:v? How about my original inclinaton: perg? It just screams out the opposite of grep. -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: purge: opposite of grep
On Thu, 5 Dec 2002, Robert Spier wrote:
-R (who does not see any benefit of 'perg' over grep { ! code } )
My problem with grep { ! code } is the same problem I have with if (!
expression): I've never developed a real trust in operator precedence.
Even looking at your pseudocode example, I itched to fix it with grep {!
(code) }.
This may be a weakness on my part, but I like computers to address my
weaknesses: I certainly spend enough time addressing theirs.
-miko
Miko O'Sullivan
Programmer Analyst
Rescue Mission of Roanoke
Re: purge: opposite of grep
On Thu, 5 Dec 2002, Dave Whipp wrote:
Only if we apply a bit of magic (2 is a true value). The rule might be:
How about if we just have two different methods: one for boolean and one
for multiple divvies:
my(@true, @false) := @array.cull{/some test/};
my (@a, @b, @c) := @array.divvy{some code}
Miko O'Sullivan
Programmer Analyst
Rescue Mission of Roanoke
Re: purge: opposite of grep
On 5 Dec 2002, Rafael Garcia-Suarez wrote: If you want good'ol Unix flavor, call it vrep. Compare the ed(1) / ex(1) / vi(1) commands (where 're' stands for regular expression, of course) : :g/re/p :v/re/p I like it. Fits in with our Un*x heritage, and doesn't have any existing meaning that implies things it doesn't do. -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
purge: opposite of grep
SUMMARY
Proposal for the purge command as the opposite of grep in the same way
that unless is the opposite of if.
DETAILS
I've lately been going a lot of greps in which I want to keep all the
elements in an array that do *not* match some rule. For example, suppose
I have a list of members of a club, and I want to remove (i.e. purge)
from the list everybody for whom the quit property is true. With grep
it's done like this:
@members = grep {! $_-{'quit'}} @members;
Obviously that works well enough, but just like unless somehow
simplifies the logic by removing that leading !, purge can simplifiy the
array filter:
@members = purge {$_-{'quit'}} @members;
FWIW, I came up with purge because my first inclination was to spell
grep backwards: perg. :-)
-miko
Miko O'Sullivan
Programmer Analyst
Rescue Mission of Roanoke
Re: Perl6 Operator List
From: Larry Wall [EMAIL PROTECTED] : ? - force to bool context : ! - force to bool context, negate : + - force to numeric context : - - force to numeric context, negate : ~ - force to string context We're obviously missing the force to string context, negate operator. :-) Mr. Wall, may I be excused? My brain is full. Oh, I have to stick it out with everyone else? OK, um Just so I understand... why do we need force to blah context operators at all? Are we planning on doing a lot of context forcing? Isn't a lot of context forcing mean that the context concept isn't working? Nay, say I. I think context will continue to work. Which means... maybe we don't need all that shorthand. I've been quite happy with the scalar function in Perl5. What if we just had a few more functions like that for the occasional context forcing, or even just one context function that takes a context name as the first argument. -Miko uh oh, I just forced myself into numeric context and negated myself
Re: perl6 operator precedence table
On top of which, Damian has expressed an interest in ! for a superpositional xor. Which would behave how, exactly? ! the way people expect, I fear. -Miko
Re: @array = %hash
From: Nicholas Clark [EMAIL PROTECTED]
In Damian's excellent perl6 talk, I think he said that by default a hash
in list context will return a list of pairs. Hence this
@array = %hash
for %hash with n keys would give an array of n elements, all pairs.
Will there actually be a pair object class? Something like this...
foreach my $pair in %myhash {
print $pair.name, '=', $pair.value, \n;
}
-Miko
Re: Light ideas
From: Damian Conway [EMAIL PROTECTED] what would true (the string) be converted to? In a numeric context: 0 (as in Perl 5). which was my point. You wouldn't want to cast any ol' scalar as a number just to get 1 or 0 representations or TRUE or FALSE... that wouldn't DWIM. -Miko
Re: Light ideas
- There's already a huge population of programmers out there who already use this notation. I frankly admit that I think of PHP as a great idea that wasn't done quite right. I agree. Including that notation! ;-) Touche. Darn it's difficult disagreeing with pithy people. :-) OK, would that notation ( arr[] = $var ) be something that could be added by a module, in the same way that operators and /* */ will be addable? I don't know exactly what the syntax for adding /* */ will be, but if you can say to the preprocessor something like s#/*#=comment#g then perhaps you can also say something like s#\[\s*\]\s*=#binpush#g and then also define binpush as an operator. -Miko
perl6-language@perl.org
This is a small collection of ideas for the Perl6 language. Think of this
posting as a light and refreshing summer fruit salad, composed of three
ideas to while away the time during this August lull in perl6-language.
Give split an option to keep the delimiters in the returned array
I often find that I want to split an expression, but I don't want to get rid
of the delimiters. For example, I've been parsing a lot of SQL lately, and
I find myself needing to split expressions like this:
rank=?
It would be really groovy if that expression could be split with the
delimiters in place, something like this:
tokens = split _/[?=*-+]/, $sql, keep='all';
and get back an array with these values: ('rank', '=', '?')
But that raises a problem: what if the expression is this (note the spaces):
rank = ?
In that case I would want the = and ? but I wouldn't want the spaces. A
slightly different option could keep just stuff in parens:
tokens = split _/\s*([?=*-+])\s*/, $sql, keep='parens';
Set preferred boolean string for scope
In Perl5, if you use a boolean expression (e.g. $x==$y) you get back 1 for
true and an empty string for false. That makes sense, of course, but I've
always preferred 1 for true and 0 for false. I generally use exactly only
those two values for true and false in my databases, and I find I'm forever
writing things like ($x==$y ? 1 : 0) to tidy up my booleans.
It would be cool if in Perl6 you could indicate the preferred default values
of true and false for a given namespace or scope, something like this:
use BooleanValues TRUE=1, FALSE=0;
Perl itself could respect these requests in expressions like $x==$y.
Functions that declare themselves as booleans can return anything they like,
but the results would be translated into the caller's preferred true/false
values. If no such values are indicated for a namespace then whatever the
functions returns is returned.
Push with []
Our friends over in PHP have a nifty little way of saying push this onto
the end of the array. You simply assign the value to the array using an
empty index. In Perl6 it could look like this:
arr[] = $var;
The expression above would be exactly equivalent to
push arr, $var;
I've always found the first form more intuitive: it feels like I'm assigning
something. It's a paradigm issue... I'm not suggesting that we get rid of
push, just that we create this additional form that allows the programmer to
think of it in a different way.
Re: Light ideas
From: Dave Mitchell [EMAIL PROTECTED]
But perl5 already does this:
Dave gets the First to Point Out the Feature Exists award. I knew that
out of three ideas I'd be lucky if just one of them was actually a new
feature idea.
I might still say that the parens don't make things quite obvious... what if
I need to use parens for a complex regex but *don't* want the delimiters?
But I'm not sure that it's worth changing if it already exists in some form.
From: Damian Conway [EMAIL PROTECTED]
[talking about the boolean representation thing]
Though I must say I can't see the real need for this. Especially when
you can prefix any boolean expression with unary + and ensure that
any s are converted to 0's anyway.
what would true (the string) be converted to? Here's my point more
explicitly: in a boolean context, there's no need to get any specific string
(0, 1, yup) as long as it correctly expresses true or false. It's when
you convert a boolean into a string or number that it becomes convenient to
define how they are represented by default. Yes, of course there are already
ways to change a variable from [some representation of false] to 0, but by
giving a slick way to default the string, a lot of ?? :: type stuff can be
done away with.
{
temp sub false() {0}
# etc.
}
That sounds like a great way to do it. A follow up question, then: would it
be easy enough to accomplish that in a use-type format? I.e., something
like I said earlier:
use StrictBoolean TRUE=1, FALSE=0;
or even just let it default:
use StrictBoolean;
@arr[] = $var;
I have to admit that don't find that syntax very intuitive.
Besides, in Perl 5 the same functionality just:
$arr[@arr] = $var;
In Perl 6, that would be:
@arr[+@arr] = $var;
or:
@arr[@arr.length] = $var;
or maybe just :
@arr[.length] = $var;
The issue of what is more intuitive is of course highly subjective, but I
would argue that for several reasons the more concise version is more
unituitive to the population at large:
- Generally, shorter is better as long as it isn't ambiguous (maybe it is
ambigous, what do you think?)
- It doesn't get bogged down in what the stuff in the braces means
- Those +s and ?s and _s are going to take some getting used to. People
will probably learn this little shortcut faster than they learn the new
casting symbols.
- There's already a huge population of programmers out there who already use
this notation. I frankly admit that I think of PHP as a great idea that
wasn't done quite right. I'd love to see the PHPers of the world migrate to
Perl.
Oh, and sorry about the subject line in the previous email... my
cut-n-pasting was off target.
-Miko
Re: 6PAN (was: Half measures all round)
For the record, you will hear no disagreement from me. I recognize that this is a HARD problem. Nonetheless, I think it's an important one, and solving it (even imperfectly, by only supporting well-defined platforms) would be a major coup. I'd like to take that even further: just supporting Win32 binaries would be a major coup. Very few windows users can compile, but a much more significant percent of Un*x users can. A few more ways to address issues of multi-platform (my favorite is at the end): - Divide and conquer: design the 6PAN so that individuals and small groups can set up their own binary specific distribution sites. One person might decide to set up a Win32 distribution site, another a Mac distribution site. They can all register on the central 6PAN server. Users can then choose which distributions they prefer in general. - Unit testing: with binaries it becomes more imperative that downloaded modules are rigourously tested. Unit tests should be distributed with modules, and download clients should have a way of saving errors and (if the user givesd permission) sending them back to the developer. - My favorite: don't do binaries. With bytecode Pure Perl makes all the more sense. I'm not saying binaries should be prohibited, but the culture should steer away from them.
Re: 6PAN (was: Half measures all round)
[This seems like a good time to post something that's been on my mind for some time.] SUMMARY The world needs a really easy CPAN client. Here's one design for such a thing. DETAILS A few brief philosphical points: 1) People like languages that have tons of built-in doohickeys. See PHP and Java. 2) Instead of a huge standard library, a really easy to use CPAN client allows programmers to have the world of modules almost as easily as built-in, and with the advantage of up-to-date-ness and quantity. 3) The current CPAN.pm isn't really easy to use. Now matter how simple it may seem to the Perl Guru community, inexperienced users find it intimidating to download CPAN modules. Remember: beginners end up ruling the world. See Microsoft. Solution: a simple program that is called from the command line. Here's a brief tour: Download and install a module from CPAN. Loading a module also automatically loads its dependencies. cpan load Date::EzDate The command above would ask the user if they want to install using the current directory as the root of library tree, and is also mentions that if they want to specify another dir they can use this command: cpan --lib ~/lib load Date::EzDate Update a module. cpan update Date::EzDate Don't download dependencies: cpan --dep 0 load Date::EzDate Update all currently installed modules: cpan update * Update a namespace: cpan update Date::* Get help on using cpan: cpan help No configuration files (.e.g .cpan) are necessary. However, you can use a configuration file if you want tp indicate a .cpan-like file cpan --conf ~/.cpan load Date::EzDate Get from a particular FTP server cpan --server cpan.idocs.com load Date::EzDate By default, progress messages are kept to a minimum. No more of those hundreds of lines of bewildering make messages. cpan --lib ~/perllib load Date::EzDate finding server downloading module determining dependencies downloading dependencies installing done Optional verbose mode cpan --verbose load Date::EzDate (hundreds of lines of lovely make messages) Request particular operating system compilation (e.g. Win32) (usually not needed explicitly because cpan.pl will know which compilation to ask for) cpan --compile win32 load Date::EzDate Indicate latest development vs. latest stable cpan --latest beta load Date::EzDate Remove a module cpan remove Date::EzDate - Other Misc CPAN Ideas - Authors don't need to indicate dependencies. CPAN figures it out from the use's and require's. CPAN will not accept modules that depend on other modules that aren't on CPAN. (Yes, there might be a chicken and egg problem there, I'm sure we can find a solution.) This leads me to... - Run-time dependencies: Dependencies can be indicated explicitly with something like this: use Dependency Date::Language::French; - CPAN conformity: All modules served from CPAN must meet certain specifications. They must include a version, POD, license statement, and probably other meta-info. The meta-info would be standardized so that the system could tell that the module conforms. - Automated load balancing: cpan.perl.org doesn't have to pay for the bandwidth of the whole world. cpan.pl should recognize a command from CPAN.org to redirect to another server. - 6pan.org: The domain name 6pan.org is available as of this writing. Larry, are you planning on saying 6PAN enough to merit somebody registering 6pan.org?
Re: Idea
From: Chris Angell [EMAIL PROTECTED]
I have an idea for the int() function. I think it would be cool if it
returned false/undefined when the argument passed to it is a
whole number.
This is related to something I've been pondering about variables and typing.
Question A: In Perl6, how are types enforced? What would be the result
of trying to compile and run the following code:
my int $foo;
$foo = 'Fred';
The rest of this message assumes that the answer to A is run time error.
I'd like to propose the following concept: by default, the result of the
above code would still be a runtime error, but with the use of a special
pragma/module, the result would be that the code runs as if $foo were an old
fashioned dynamically typed scalar. *However*, that scalar would still know
it's an integer trapped in a string's body. The same pragma/module that
allowed this sort of thing to happen would have a general purpose sub that
would indicate if a variable's value matches its typing:
unless match_type($fred) {
die 'The $foo variable must be an integer';
}
Some compile-time checks would be rearranged a little. The compiler would
refuse to allow you pass that variable to a declaration that wants some
other type of argument. However, if you let the variable get passed
unchecked to a sub that wants something else then you would get a run-time
error.
Here's one advantage to this approach. When I write an application in a
language that uses dynamic typing, I have to deal with the reality that
sometimes people type weird values into web forms. They put their names into
number fields, etc. To handle these types of errors I have to jump through
all kinds of hoops to deal with the weird values that come in. A lot of
times these hoops involve storing the input into a string variable, testing
the string, then assigning it again to the real variable. OTOH, with
dynamic typing, I still need to run a bunch of regexes against the variable
to test if it works. The proposed feature allows a simplified approach to
type testing.
-Miko
Re: Why not {,n} in quantifiers?
From: Larry Wall [EMAIL PROTECTED]
It's unlikely that {n,m} will still have that meaning in Perl 6. Maybe
we'll
have something like this:
Perl 5 Perl 6
{1,3} 1..3
{3} 3
{3,} 3+
{0,3} 3-
What are your feelings on multiple ranges for matches? E.g. the following
expression means 1 to 3, 5, or 10 or more:
1..3|5|10+
-Miko
Re: Selective exporting of properties/methods
While thinking Eiffel-ish thoughts the other day, I began to wonder if
Perl6's classes could go beyond the simple private/public/protected
scheme by optionally allowing for a property or method to only be
accessed by a certain set of classes.
Many times when I've used OO languages I've wished for something like this.
What I've often wanted would be standard method that is called before every
subroutine call. If that method returns false then the method that was
called is not called. A standard set of security information is passed in.
That could get kind of expensive so the security method is only called if
the class is specifically set to use it. Something like this:
class Foo::Bar {
use Class::Security::Method 'checker';
sub checker (%meta) {
if (some_security_check())
{return 1}
return 0;
}
}
-Miko
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
From: David Whipp [EMAIL PROTECTED] It it too much to ask, of the creator of a tied array, to implement their code in such a way that *reading* an element of that array does not have significant side-effects? Actually, I think that *is* a significant imposition. The whole point of tied arrays ( and hashes, scalars, etc) is that they act like arrays but internally do whatever they want. But could we go back a step? Could somebody explain why we need lookaheads, or perhaps what exactly a lookahead is in this context? Part of the current interface for tied arrays is that they know how long they are. It seems like it would be a relatively simply algorithm to say if there are still elements left in the array then populate the loop variable with the next element and run the block. Else, leave the variables as they are, run the LAST block. -Miko
Re: Loop controls
From: Damian Conway [EMAIL PROTECTED]
while (my $res = $search-getnext) { ...}
has a valid meaning in Perl 6. In fact, it's meaning in Perl 6 is far more
reasonable than in Perl 5.
I don't think the new meaning makes sense at all. Essentially it's saying
the statement gets run many times but the variable only gets declared
once. It makes sense to declare a variable many times when it gets a
fresh, new block for each declaration, like when it's inside a loop, but to
use it in a statement that is run many times but declares the var only once
seems like it ought to throw a warning about declaring the same variable in
the same scope multiple times.
use warnings 'P52P6';
that would point out potential problems like this.
Cool idea.
-Miko
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
The implication is that we can only provide advanced PRE_LAST
style blocks (or their equiv.) on the Cforeach loop. The fact
that they are impossible on the Cwhile loop should not
constrain our thinking for the Cforeach loop.
Just checking here: is PRE_LAST a separate and non-mutually exclusive
concept from LAST? I.e., would this make sense:
foreach arr - $i {
PRE_LAST {print before last loop\n}
LAST {print after last loop\n}
print $i\n;
}
If so, wouldn't look-aheads still result in chaos and confusion for tied
arrays?
If not, then I'd definitely disagree: to me, for's and while's are just
different flavors of loop and should behave the same in every way
possible.
-Miko
Re: Loop controls
while getNextValue() - $i {
...
}
while getOtherNextValue() - $i {
...
}
which generates no warning because each C$i is a parameter of the
corresponding loop block, and hence scoped to that block.
Ok, now I understand the plan. In brief, in the following example $result
is scoped to the block that encloses the whole loop:
while (my $res = $search-getnext) { ...}
However, in the next example, $res is scoped to the loop:
while $search-getnext() - $res { ...}
Right? OK, that sounds cool. We still have loop-scoped variables. I'd
like to suggest, though, that the first example would refuse to compile. If
the plan is to significantly change the behavior of something as popular as
that construct (and I did some research, it's VERY popular, details
available on request), it would make more sense to refuse to compile than to
DWIDM (Do What I Don't Mean).
-Miko
Re: Loop controls
From: David Whipp [EMAIL PROTECTED]
don't { die } unless .error;
Whoa. This don't thing is starting to look eerily useful. Shades of the
Parrot parody.
-Miko
Re: Loop controls
Damian said: 6. Cotherwise would seem to fit the bill rather nicely. To me, otherwise is a synonym for else, and that makes it too confusingly similar. I foresee forever explaining to people the difference between Celse and Cotherwise. I'm not sure if Cotherwise is popular because it is similar to Celse, but I think the similarity is a reason *not* to use it. How about Cnoloop? It's absolutely clear what it means and won't be confused with else. I now confidently await Larry's coming up with an entirely different solution ;-) I keep picturing Larry tugging thoughtfully on his mustache while reading this thread, a smile on his face, his finger hovering over the reveal button. -Miko
Re: Loop controls
Damian posted: NAME Acme::Don't - The opposite of `do' Wonderful job, Damian! I'll get to work on the complementary Acme::TryNotTo module. :-) -Miko
Re: Loop controls
Jonathan said:
I actually think exactly the opposite. In my mind otherwise would
just be a synonym for else so that
loop { ... } else { ... }
loop { ... } otherwise { ... }
would both be syntactically valid.
I believe that the intention is that they *aren't* synonyms, i.e. they look
similar but are different, leading to confusion. I imagine people who date
twins sometimes kiss the wrong twin and *that* probably throws an exception.
Same concept.
-Miko
Re: Loop controls
Damian said:
The CBETWEEN block can't decide whether to execute until
it knows whether the loop is going to iterate again. And it can't
know *that* until it has evaluated the condition again. At which
point, the $filename variable has the wrong value. :-(
The example is a little contrived perhaps, but it might be a common
problem.
I don't think your example is contrived at all. It's just a situation where
a little
education is all that's needed. The rule could be quite simple: BETWEEN is
run before every iteration except for the first iteration. Any variables
that you
use in BETWEEN are for the iteration that is about to run, not the iteration
that
just ran. Once people gt that concept things become clear.
However, it was because of your conundrum that I first proposed that
Cbetween (not CBETWEEN) is put after the loop. To me that makes it
absolutely clear that between isn't part of any one iteration:
while whatever() {
...
}
between {
...
}
I should admit, however, that this thread has made me prefer BETWEEN inside
the block. It keeps open the possibility of loops becoming part of if-elsif
chains, even if it's not the choice to allow that right now.
-Miko
Re: Loop controls
Damian, now having terrible visions of someone suggesting Celswhen ;-) Then may I also give you nightmares on: elsdo, elsdont, elsgrep, elstry ... :-) -Miko
Re: Loop controls
Then if you want else when or else do, you're all set. It's an easy change and there are no new keywords. Agree with everything else you said. One minor question: how would else do be different than else? do always does, doesn't it? -Miko
Re: Loop controls
Well, if there's no while (replaced by generic loop, per Apoc4) why would there be an until? Whoa. I actually had a moment of panic there. Then I checked for myself. I don't see anything in Apoc4 about getting rid of while. It may be excluded from evolution, but it's still there, sorta like the alligator. Larry uses while in several examples. So, the answer to your question is: yes, I do propose that there should be an elsif, elsloop and elsfor. That's it. Three words, not an expansive list of ever-more-complex words. Why not also elswhile? According to Apoc4, while still gets the cool loop controls like NEXT, why shouldn't it get to join the els party? Even alligators evolve a little. BTW, like so much in Perl, I found elsfor etc. ugly at first, then I grew to like it. Is it really that lexically nonsensical? -Miko
Re: Loop controls
Concerning the els(loop|for|while) controversy, I'd like to bring it back to the point that started it all: loop-else. There seems to be a fair amount of support for a loop-else contruct. Can we/Larry decide to accept loop-else, regardless of what other decisions need to be made? It would be a shame to see a really useful construct like that get tossed out because we're afraid we can't stop ourselves. I would rather see loop-else with no elsloop than lose the whole idea. -Miko
Re: Loop controls
and C$cond is defined *outside* the block. So if Larry were to allow
Celse
on loops, you'd be able to write:
[snip]
Given how rarely this kind of thing is actually needed (I've *never* used
such
a construct), I suspect that an explicit variable is adequate.
I don't know if we're talking about the same thing, but I live using loops
that declare variables in the test, so please exegize me. Which of these
lines, if any, would cause a compiler error or warning?
while my $cond = blah() {
...
}
else {
print $cond;
}
print The condition is: $cond\n;
If none then you're seriously rocking my world.
-Miko
Re: Loop controls
In Perl 6 a lexical variable is scoped to the block in which it's
declared.
Since C$cond is declared in the block *containing* the Cwhile and
Celse,
it's scoped to that block. So you can use it inside the Cwhile's block,
inside the Celse's block (assuming Larry allows such a construct), and
in
the following Cprint statement.
OK, will at least this statement still work as it does in Perl5? Notice
addition of parens.
use strict;
...
while (my $result = blah() ) {
...
}
print $result, \n;
i.e., $result is scoped to each iteration of the while loop, and the
compiler crashes on the last line because $result isn't my'ed.
If that changes, I for one will need to go rewrite virtually every script
and library I maintain, not to mention changing my coding style to something
more Java-like in its inconenience. My personal pain aside, it seems
counter-intuitive to me. $result gets my'ed over and over and over. In my
world view that should result in a warning about declaring the same variable
twice in the same scope.
Even if the addition of the parens does make a difference, it doesn't look
quite logical to me. Parens in an evaluation are just grouping mechanisms,
not structural controls. $me $you is the same as ($me you). So the
addition of parens in the example above looks like just a redundant
indication of grouping, not a declaration of a change in scoping rules.
-Miko
Re: Please rename 'but' to 'has'.
This is now extensible to any number of precedence levels, and you can now use simple string comparison to compare any two precedences. It even short circuits the comparison as soon as it finds a character that differs. Gee, maybe I should patent this. Too late. Amazon has already patented the concept of string comparisons. Microsoft is in litigation over the number 2. -Miko
Re: Loop controls
Of course it brings other less wholesome things to mind like elsfor and elsloop and if ... elsfor and for ... elsif ... elsloop ... else, but why not? Well, I agree with the concept, but boyoboy those names ain't gonna fly. We'll have to head down the road of unlessfor elseuntil unlessuntil Two issues spring to mind: 1) Do we have a reality check on why this syntax is needed? I agree it's cool idea, but can anyone name a real-world scenario where it would be useful? Can we do things just bcause they're cool? That approach didn't work too well for me as a teenager, but then nothing else did either. 2) Could we come up with a generic syntax? Some simple that allows for any combination? -Miko
Loop controls
SUMMARY
A proposal for a set of loop structures that simplify code that is based on
loop iterations.
foreach my $var (arr) { ... }
before { ... } # run before first iteration, only if there is at least
one iteration
between { ... } # run between iterations, not before first or after last
after { ... } # run after last iteration, only if there is at least
one iteration
noloop { ... }# run if there are no iterations
DETAILS
Virtually every time I write code for a loop I need to do some set of stuff
before the loop (if there were actually any loops), some more stuff after
the loop (again, only if there were actually any loops), and yet another
bunch of stuff if there were no loops at all. I also frequently need to do
something only between loops, but not before or after. For example, suppose
the code loops though the results of a search. The code should output a
header at the top, a footer at the bottom, an HR between each loop, and
should do none of that if nothing was found. (This example is only slightly
exagarated: except for the HR in between, all my searches do all of that.)
Currently we would implement these requirements using an iteration counter:
my $counter = 0;
foreach my $res ($myob-getresults) {
if ($counter) {
# output divider
}
else {
# output header
}
# do stuff to display the result
$counter++;
}
# close if there were any loops
if ($counter) {
# output footer
}
# lack of results message if no loops
else {
# print no results message
}
Now, I'll be the first to admit that that isn't a terribly complicated
algorithm, but it took me while to come up with that algorithm and it always
feels like I have to contort my code to make it work... the header goes
inside the loop when I feel like it should go before the loop, the divider
comes before the header (or I have to use if not, which means doing a
confusing test for a negative). The proposed solution is similar to the
benefit foreach gave us: it just makes things easier. It organizes the code
into logical blocks based on the process of looping through the elements:
before {
# output header
}
foreach my $res ($myob-getresults) {
# do stuff to display the result
}
between {
# output divider
}
# footer if there were any loops
after {
# output footer
}
# lack of results message if no loops
noloop {
# print no results message
}
The blocks should go outside the loop, not inside like has been discussed
for other loop controls. None of these structures are about the process
inside any particular iteration... they are always outside of any specific
iteration. Also, it would make sense to allow before to go before the
loop... after all, it's stuff that happens before the loop.
-Miko
Re: Loop controls
(note: this repsonse arrived just in my mailbox, not to the list, but I
thought I'd post my response to the list. -Miko)
Okay, that's if you can store the results somewhere all at once, but
so was your example. Iteration objects could be used to optimize for
the case where you can't (or don't want to) store all of the results.
Not necessarily. The loop constructs would work equally well with while
loops where one thing is retrieved at a time:
while (my $record = $query-fetch_row_hashref ) {
}
between {
# output separator
}
$res = $obj-getone;
if ($res) {
# output header
while ($res) {
# loopy code here
$res = $obj-getone;
}
# output footer
} else {
# no loop
}
Eesh... I've always prefered to get the next thing in one place. It seems
redundant to me to get it in two different places.
With the syntax you've proposed there's no conceptual tie between the
before, after, between, and noloop constructs and the loop they
are associated with.
They are associated the same way that an is, elsif, and else are associated,
or a try - catch - finally. I.e., you don't put anything in between them.
Also, are you sure you want the between to be in
a separate lexical scope from the loop?
No, I'm not sure, but I think it makes more sense than putting it inside the
loop.. if it's inside is it associated with the loop before or the loop
after? Maybe there is a elegant way to allow the iteration to pass
information to the between loop.
-Miko
Re: Loop controls
And HR won't be printed before Done.? It *will* be printed there, according to the current design. A CNEXT is *always* called when the iteration leaves the block (whether it's coming around again or not). By analogy, CNEXT is a terminator, not a separator. Darn, we're so close. I understand the need for a terminator clause, but NEXT doesn't quite strike me as the best name for such a clause. To me NEXT indicates that it is called before the *next* iteration. I liked POST. OK, I smell an already-settled issue. Backup proposal: if you're already married to NEXT as a terminator, how about BETWEEN as a separator? As for Larry deciding if else makes sense to follow loops, I'd like to put in a vote for please do. It just makes sense, at least once you've gotten used to thinking of arrays in boolean context. -Miko
Tagmem* (was Unary dot)
Wouldn't Know a Tagmemic if it Bit Him on the Parse Ooh, can I steal that as a title? (Though I'll s/Tagmemic/Tagmeme/.) I like it! :) You got it! I hope this isn't too off topic, but... is the word tagmeme somehow related to the urban legend concept of a cultural meme? -Miko
Subroutine variables are like underwear
SUMMARY
A way to declare public names for params irrelevant to the internal variable
names:
sub load_data (-filename $filename_tainted ; 'version' 'ver'
$version_input / /= 1) {...}
DETAILS
Subroutine variables are like underwear: you don't generally go showing them
to everybody. So, when I noticed how named params seem to be designed for
Perl 6, I felt, well, bashful about it. Consider this sub declaration:
sub load_data ($filename ; $version / /= 1) {...}
You could call this sub like this:
my %data = load_data(filename='weblog', version=1);
Now, suppose I decide I don't like the variable name $filename. I might
want to change it to $filename_tainted. I wouldn't want to have to change
every call to that subroutine, especially if I've put the module on CPAN.
Yes, I could do this:
sub load_data ($filename ; $version / /= 1) {
my $filename_tainted = $filename;
undef $filename;
}
but gosh that's a lot of work just to maintain flexibility in a few
variable names. Even worse, sometimes I can't remember if it's $filename or
$file_name or $filepath or $file_path or... you get the idea. So, suppose
there were a way to declare that any of one or more named params counts as
the name for the param. There are several ways to do this, here's my idea:
each named param can be preceded by one or more names that begin with - or
are quoted. Bare strings without - or quotes aren't allowed because those
would be data types. Here's an example:
sub load_data (-filename $filename_tainted ; 'version' 'ver'
$version_input / /= 1) {...}
Setting names wouldn't be required. If they aren't set, then Perl uses the
name of the variable. One question would be if the variable name is still
used as the name for a param. My inclination is no: declaring them means
you want the declared name, not the private name. If you want all the
names, you declare them all.
-Miko
Re: Defaulting params
sub foo($a=1, $b, $c=3) { ... }
is ambiguous: While foo(2) sets $a=1, $b=2, $c=3, it's impossible to
say what foo(4,5) should do.
foo(2) means that $a = 2, $b defaults to undef, $c defaults to 3
foo(4,5) means $a = 4, $b = 5, and $c defaults to 3.
-Miko
Defaulting params
The current plans indicate that a subroutine's params should be defaulted
like this:
sub load_data ($filename ; $version / /= 1) {...}
(The space between / and / is on purpose, my emailer has problems if they
are together.) If that's the technique, how does the caller indicate that
the second param is *supposed* to be undef? If I were to call a sub like
this:
load_data ($filename, undef);
then I would expect that means that I am explicitly saying the second
argument is supposed to be undef. However, if I call it like this:
load_data ($filename);
then I'm not sending the second param and it can be whatever the default is.
Ergo, I propose that / /= and simply = are both allowed and mean slightly
different things:
# $version is 1 if the second param isn't sent at all
sub load_data ($filename ; $version = 1) {...}
# $version is 1 if the second param is undef
sub load_data ($filename ; $version / /= 1) {...}
(Yes, this is a repeat of an earlier suggestion. It was suggested I might
repost reworded.)
-Miko
defaulting parameters
Hi everyone! My name is Miko O'Sullivan, and I've been a devoted Perl
Hacker for several years now. I'm looking forward to participating in the
discussion of Perl 6. To give a little perspective on my comments, I got my
degree in Marketing about a decade ago, and I've never quite decided if I'm
a marketer who programs or a programmer who markets. Indeed, the three
people who have most influenced my programming have been Larry Wall, Donald
Knuth, and Liberace. The Great Liberace is on the list because of his
motto: Give The People What They Want.
In the context of Perl 6, what do The People Want? When I'm writing modules
and other things that other developers will use, I usually find that the #1
thing they want is ease-of-understanding: if they can't understand it
between two bites of ramen, it's too complicated.
With that verbose introduction in mind, I'd like to jump in the waters of
the discussion with this concern. In Exegesis 3 Damian suggests default
params like this:
sub load_data ($filename ; $version / /= 1) {...}
(Disclaimer: I'm putting a space between / and / because otherwise my mail
client does funny things with the text. Sheesh.) Now, I'm thrilled about
/ /= . However, the technique for defaulting params seems a unnecessarily
complicated. The following code could mean just the same thing.
sub load_data ($filename ; $version = 1) {...}
It all depends on how you read it. If you read it as first get _, then
overlay it with these new variables then only / /= makes sense. But if you
read it create these new variables, then overlay it with _ then they both
make sense. It's sorta like %options = ('version' = 1, _); The great
advantage of the latter structure is that it's easier to understand, and
(dare I say it?) it's the way other programming languages work. Perl 6 is
already getting a reputation as ten times more cryptic than Perl 5, and
though it's always been an undeserved reputation, let's not feed the flames.
Peace and Happy Coding
- Miko
