Thinking about scalars
I have lurked for several months now, and find that I can hold my tongue no longer. The 'discussion' of overloading '+', to include concatenation, suffers from a general degeneration into implementation details, where linguistic sentiment should reign. The contention that '+' should be overloaded is based in machine details, expressed in other languages through 'types'. In this model of the world, a 'string' is fundamentally different from a 'number', and as such each defines a specific context in which the operator exists: (string) + (string) or (number) + (number), or some horrid abberation thereof, which aught not to be. The traditional perl vision, however, holds these divergent things to be both one and the same. But in this, a scalar is really neither a number nor a string. From the point of view of the C++ programmer, there is only a single context which applies, the scalar context: (scalar) + (scalar). Perl's clever solution to how to interpret what a scalar 'means' is to define vocabulary which provides the context. The manner in which the symbol 123 is interpreted depends on the operator, and not the other way round as is the case in C, C++, Java, Ruby. Perl is beautiful because you are manipulating a symbol and not just a series of bits. I'm sorry, and I apologize for this rant, but I feel that the arguments on both side of what to do with '.' and '+' have bogged themselves down in a discussion based on how one represents a symbol on the machine's level, forgetting about the human one. The correct choice is a matter of 'human' intuition and not 'computer programmer' intuition, we have bent our minds too far to accomodate the machines. (BTW: I read Chip Salzenberg's perl code all day at work, so go easy on me :) -- david j. goehrigbit twiddlerwww.valinux.com "There was nothing creative, charming, admirable or innovative in Pokémon except that it parted small children from their money with brutal efficiency. It inexplicably featured the dramatic story of cockfighting monsters who lived in your pants..." - John Tynes
Re: Dot can DWIM without whitespace
On Tue, Apr 24, 2001 at 07:38:50PM -0700, Brent Dax wrote:
[snip four examples are obvious ...]
>>> $a."b";
If a has a method 'foo' such that
$a.foo
is the standard invocation, it would be nice when $b = 'foo' for
$a.foo === $a."$b" === $a.$b
How I see the . operator working in this case is as something like
$a.foo === &{$a{foo}}
Hence that would logically follow that
&{$a{foo}} === $a.foo === &{$a{"$b"}} === $a."$b" === $a.$b === &{$a{$b}}
and this case
>>> a.b;
is either an error, or something very scary.
--
david j. goehrigbit twiddlerwww.valinux.com
"There was nothing creative, charming, admirable or innovative in
Pokémon except that it parted small children from their
money with brutal efficiency. It inexplicably featured the
dramatic story of cockfighting monsters who lived in your pants..."
- John Tynes
Re: RFC 90 (v1) Builtins: zip() and unzip()
On Fri, 11 Aug 2000, Damien Neil wrote: > On Fri, Aug 11, 2000 at 06:41:52PM +0100, Graham Barr wrote: > > I think I like plow() or maybe just weave() > > weave() and ravel()? > > - Damien > Unfortunately, ravel has two opposite meanings (according to www.m-w.com): 1 a : to separate or undo the texture of : UNRAVEL b :to undo the intricacies of : DISENTANGLE 2 : ENTANGLE, CONFUSE The word "ravel" is generally not used, either...you generally see "unravel." Maybe weave() and unweave(), to emphasize that they are go together? Dave
Re: Self-Sorting Containers
On Fri, 11 Aug 2000, David L. Nicol wrote:
> I've started talking about "containers" instead of arrays and hashes
> since those both tie directly to implementation details, and containers
> are abstractions.
[...]
>
> If hashes normally had a sort method of null, they would work normally,
> but you could overload the sort method of any hash with
>
> methodoverloadoperator(%thehashinquestion, 'sort', {$a flubber $b})
>
> What is a better syntax for this?
How about:
%foo{ {$a <=> $b} }
(Obviously, you can put whatever you want as the sort function.)
Here are the advantages I see:
- minimum syntax required
- very clear what you're doing:
1) % is only used to refer to a hash as a whole
2) you generally don't use code refs as keys
Dave
Re: Portable upper/lower case regexp matchesre and procedures
>From the Perl6-language list: On Thu, 10 Aug 2000, Bart Lateur wrote: > On Thu, 10 Aug 2000 17:21:44 +0300, Jason Elbaum wrote: > > > \x match lowercase alpha char > >\X match uppercase alpha char > > You've got my vote, apart from one tiny detail: \x is already in use. I'd also like to see a combined version that just says "match a letter, regardless of case." Other than that, I think this is great. Here's my question of procedure: plenty of times on these lists, I see something that I think is a really good idea. I don't want to waste bandwidth by posting just a "me too!", but I also don't want the idea to die because no one weighed in in support of it. Is there a mechanism in place for this, or could we set up something on the website for voting on the RFCs (perhaps with conditions, like "I agree with this as long as XYZ is [not] done")? Dave
Re: Portable upper/lower case regexp matchesre and procedures
On Sun, 13 Aug 2000, Greg McCarroll wrote:
> * Larry Wall ([EMAIL PROTECTED]) wrote:
> > If something's a mediocre idea, maybe it can be refined into a good idea,
> > and maybe it can't. But voting is unlikely to help there either.
> >
> > Voting doesn't produce consensus. Discussion sometimes does.
[...]
> these posts. So there are probably needs to be a tiny bit of
> procedure, so that ideas fall into one of three loose groups ...
>
> 1.) An idea is obviously good and just accepted
> 2.) An idea spawns discussion that results in concensus.
> 3.) An idea spawns discussion that does not result in
> concensus hence after a certain point, one or more of
> the main proponents or opponents can say this has gone to
> far lets have a vote. The result of this vote is agreed to
> be a working decision that allows things to move forward.
One thing that would also be useful would be a link, next to each
RFC on the RFC index, that shows what its current status is (e.g., "under
discussion", "settled and agreed to", etc). There are a bunch of RFC's up
there which are not currently being discussed; a newcomer has no way of
knowing if something is currently fair game or if he's just missed out on
the discussion and would be wasting time to bring it up. The "status of
various RFC" posts that the RFC Librarian sends out are a big help on
this, but don't go quite far enough (IMHO). (I suppose it's also possible
to search all the archives, but that gets tedious and, with the high
traffic on these lists, is getting more impractical all the time.
Speaking of which, is there currently a way to search all the
lists simultaneously?
Dave
Re: Permanent sublists (was Re: Language WG report, August 16th2000)
On Wed, 16 Aug 2000, Nathan Wiger wrote: > "Bryan C. Warnock" wrote: > > > > ... is the cause for this. All the discussion is taking place in the > > master list before the sublists are spawned. You can only express the > > opinion that foo is not bar and never should be so many times. > > I agree. I think the trend should be to establish some permanent > sublists, which we're informally leaning towards already. Something > like: > >-io = ALL I/O issues, like open/socket/filehandles >-subs = ALL sub/method/func issues, like lvalue subs >-strict = ALL lexical/global variable scoping issues >-objects = ALL OO and module issues >-flow = ALL flow/threading issues >-errors = ALL error handling issues >-datetime = ALL date/time/etc issue I'd like to see this as well. However, I'd like to see some fairly clearly definitions of what each list is and is not intended to cover--I'm not suggesting that we be Draconian about it, but some of these things blur. For example, a closure could be see as a subroutine, so it should go to -subs, but it can also be used as an object, so it should go to -OO. Subroutine calls are a flow issue, so do I post something about subs to -subs or to -flow? You get the idea. Dave
Re: pascal-like "with" was Re: Default filehandles(was Re: commandline option: $|++)
On Wed, 16 Aug 2000, David L. Nicol wrote:
> Anyone for generalizing "select" to a more general "with" keyword
> which would operate on a limited hash and be syntactic sugar for
> replacing all appearances of unqualified variables that match
> the hash's keys with references into it?
>
> %record = loadrecord($studentID);
> with %record {
> print < Dear $Name:
> Your tuition is now due. Please send in a payment
> of at least $Minumum.
>
> SPAM
>
> # anyone for having a python-like floating left edge for
> # retaining indentation of hereis strings?
>
> };
I find myself very much of two minds...I think the like the
general idea, but not the implementation. A couple of thoughts:
1) The keyword should not be "with". While that would make it
more familiar to Pascal programmers, I don't feel that should be a major
incentive to choose a suboptimal keyword and, IMHO, we can do better. I
prefer "express"; it's a synonym of "import", and it seems
descriptive...you are "express"ing the keys of your hash as new scalars.
2) "express" should guarantee that, before it creates a variable
names $FOO, it first calls "local" on any existing $FOO
3) The new variables should be lexicals, defined only within the
"express" block, so that you don't pollute your namespace.
Dave
Re: RFC 56 (v2) Optional 2nd argument to C and C
On Wed, 16 Aug 2000, Glenn Linderman wrote: > > What should happen when the expression given to C, or > > C evaluates to a negative number? I see three options: [...] > > > > 3) C would then act as C and C would > >act as C > > > I like #3 too, does that make a better consensus? Can you guess which option I favor? :> Dave
Re: pascal-like "with" was Re: Default filehandles(was Re: commandline option: $|++)
D'oh. s{2) .+^}{}
Mismatch between brain and fingers there somewhere, thanks for
pointing it out.
Dave
On 17 Aug 2000, Johan Vromans wrote:
> Dave Storrs <[EMAIL PROTECTED]> writes:
>
> > 2) "express" should guarantee that, before it creates a variable
> > names $FOO, it first calls "local" on any existing $FOO
>
> Why, if the variable is lexical (see 3)?
>
> -- Johan
>
Re: pascal-like "with" was Re: Default filehandles(was Re: command line option: $|++)
This seems good...the HOF stuff seems to have pretty well accepted, and
the thumbtack notation with it.
Dave
On Thu, 17 Aug 2000, Clayton Scott wrote:
> > > On Wed, 16 Aug 2000, David L. Nicol wrote:
> > > %record = loadrecord($studentID);
> > > with %record {
> > > print < > > Dear $Name:
> > > Your tuition is now due. Please send in a payment
> > > of at least $Minumum.
> > >
> > > SPAM
> > >
> > > # anyone for having a python-like floating left edge for
> > > # retaining indentation of hereis strings?
> > >
> > > };
>
>
> This seems less of a leap of logic/faith:
> %record = loadrecord($studentID);
> with %record {
> print < Dear ^name:
> Your tuition is now due. Please send in a payment of at least
> ^minumum.
> SPAM
> };
Re: pascal-like "with" was Re: Default filehandles(was Re: commandline option: $|++)
On Thu, 17 Aug 2000, John Porter wrote: > Huh? They need to be "globals", because the "with" mechanism > is going to have to be able to write them into a symbol table. > You can't do this with lexicals. (Well, maybe that'll be different > in perl6?) Well, if you're using the HOF notation, I believe it works. Alternatively, the interpreter can simply DWIM and add in the appropriate derefed-hash-refs in the appropriate places. But globals is fine, as long as you save (localize) the old values first. Dave
Re: implied pascal-like "with" or "express"
On Thu, 17 Aug 2000, Jonathan Scott Duff wrote:
> BTW, if we define C to map keys of a hash to named place holders
> in a curried expression, this might be a good thing:
>
> with %person {
> print "Howdy, ", ^firstname, " ", ^lastname;
> }
>
> # becomes
> sub {
> print "Howdy, ", $person{$_[0]}, " ", $person{$_[1]};
> }->('firstname', 'lastname');
>
> # becomes
> print "Howdy, ", $person{'firstname'}, " ", $person{'lastname'};
>
> (If that's what people meant, I didn't see anyone actually say it).
Well, so far, I like this best of everything that's been proposed
for how "with" will work. I am still passionately against the keyword
"with", since (IMHO) it conveys no sense of what it does. I think any
of the following keywords would be better:
express, alias, in, within
The following words could also be overloaded for this purpose:
map, use
In any case, if I'm tracking correctly, all of the following
should be legit using the new syntax (forgive me for trying a new keyword):
within %person {
&calc_letter_grade(^name, \^letter_grade);
print "^first_name is ^age\n";
print "^{first_name}'s numerical grade is ^num_grade\n";
^num_grade = 0 unless ^never_missed_class;
if ( ^num_grade > 60 ) { print "^name passed!\n"; }
@temp = (^name, ^age);
};
This would translate to the following:
&calc_letter_grade($person{name}, \$person{letter_grade});
print "$person{first_name} is $person{age}\n";
print "$person{first_name}'s numerical grade is
$person{num_grade}\n";
$person{num_grade} = 0 unless $person{never_missed_class};
if ( $person{num_grade} > 60 ) { print "$person{name}
passed!\n"; }
@temp = ($person{name}, $person{age});
Dave
Re: implied pascal-like "with" or "express"
On Fri, 18 Aug 2000, Jonathan Scott Duff wrote:
> On Fri, Aug 18, 2000 at 10:39:36AM -0500, Brian Wheeler wrote:
> > "Using" might be an interesting alternative
>
> Reminds me of BASIC :-)
Works for me.
> > What if the hash keys we want to use are not valid scalar names? For example,
> > I've had keys like "total - female" as keys, but using the ^ syntax
> > would fail on this...
>
> Good point. But who's to say that ^{total - female} doesn't work?
That was actually the point of one of my examples...
print "^{name}'s age is ^age\n";
I wanted to make sure that the {} notation was acceptable with
"hat variables." You need it when you have keys like 'total - female',
and you need it when you are going to have other text butting up against
your variable name.
Dave
OT: pronouncing "www" (was: Re: ... as a term)
On Thu, 24 Aug 2000, Bart Lateur wrote: > On Mon, 21 Aug 2000 18:21:00 -0700 (PDT), Larry Wall wrote: > >If you want to save the world, come up with a better way to say "www". > >(And make it stick...) > > "The world"? This problem only exists in English! > > We pronounce it something similar to "way way way". Personally, I've always said it "dub dub dub". Dave
auto-initializing values
This is something fairly basic, but I haven't seen it in discussion or in
the RFCs. If I've missed it, my apologies.
In Perl 5, when a variable is created, it is given the "undefined" value.
This can lead to lots of spurious "Use of uninit'd variable" warnings.
Suppose you could specify the value with which all variables in the
enclosing scope should be initialized; for example:
{
# handle pensioners here
init_vars = 0;
my ($num_pensioners, $base_pension, $years_service); # all get '0'
}
{
init_vars = 'ERROR::NAME_NOT_FOUND';
my ($name_1, $spouse_name_1); # all get 'ERROR...' message
}
{
init_vars = (1,7,9);
my (@blarg);
}
{
init_vars = \{};
my ($rh_data_record);
}
...etc
An example of when you might use this is when working with a
DB...frequently, I do the following:
1) Set up a large number of variables
2) Put sentinel values in them
3) Fill them with info from the DB
4) Check to see if the sentinel value are still there
5) If so, do error handling
Dave
RE: auto-initializing values
On Mon, 11 Sep 2000, Myers, Dirk wrote:
> >Suppose you could specify the value with which all variables
> >in the enclosing scope should be initialized; for example:
>
> I haven't seen this either, but I suggest that it should be a set of
> pragmas:
> use init_scalar 0 ;
> use init_array () ;
>
> ... especially because I'm not sure what effect :
>
> init_vars = \{} ;
>
> my @foo ;
>
> should have. (Probably none, but how do you specify default values if you
> want to init multiple kinds of data in the same scope?)
My suggestion would be that it simply have no effect. On the
other hand, if a "initial size" attribute were added to arrays, then this
could be very useful...say that you have 50 employees, each of whose data
is stored in a hash. Here's an easy way to get a list of references to
all the hashes, with error handling built in:
init_vars \{name => 'NONE'};
my @employees : size 50; # 50 entries, each a ref to 1 elem. hash
@employees = get_from_db('*');
for (@employees) {
if ( $_{name} eq 'NONE' ) {
die "Oops! DB error\n";
}
}
Dave
Re: auto-initializing values
On Mon, 11 Sep 2000, John Porter wrote:
> Dave Storrs wrote:
> >
> > init_vars \{name => 'NONE'};
> > my @employees : size 50; # 50 entries, each a ref to 1 elem. hash
> > @employees = get_from_db('*');
> > for (@employees) {
> > if ( $_{name} eq 'NONE' ) {
> > die "Oops! DB error\n";
> > }
> > }
>
> I still don't see any compelling benefit for new syntax here.
> Old syntax works great.
>
> my @employees = map { { name => 'NONE' } } 1..50;
Ok, this is a fine complaint. Which is why I started this thread
with the question "Would it be useful if"
> By the way, regardless of how @employees gets initialized above,
> that initialization gets blown away by the next thing you do:
>
> > @employees = get_from_db('*'); # only got 2 records???
>
> Unfortunately, your approach in this particular case is flawed.
*Sigh* This, unfortunately, shows that you completely missed my
point. The point of the exercise was to set up some variables (the entries
in the array), initialize them with sentienl values (i.e., values that are
known to be invalid), fill them with information from a DB, and then check
to make sure that you actually got valid info into each variable. As
regards the imaginary function "get_from_db('*')"...I expected it to be
understood that that meant "get all records from the DB."
Dave
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and HereDocs)
On 14 Sep 2000, Ariel Scolnicov wrote: > 1. It requires the perl parser know about indentation. Of course we >all know that tabs are 8 characters wide (I myself make a point of >bludgeoning anyone who says otherwise), but do we really want to >open this can of worms? No, because for every person such as yourself who is into eight spaces, there is someone else like me who wants four. And don't even get me started on the really strong guys who want three spaces...you know, the Threeite Musclemen. > print << FIRST_HERE_DOC; print << SECOND_HERE_DOC; > This is on the left margin. > This is indented one char. > FIRST_HERE_DOC > This is indented one char. > This is on the left margin. > SECOND_HERE_DOC RFC 111 specifically disallows statements after the terminator because it is too confusing. I would say that the same logic should apply to the start of the here doc; I'm not sure, just from looking at it, if the example above is meant to be two interleaved heredocs, one heredoc after another, or what. Dave
Re: 'eval' odd thought
On Fri, 15 Sep 2000, Bart Lateur wrote:
> On Thu, 14 Sep 2000 18:14:49 -0400, Mark-Jason Dominus wrote:
>
> >The perl 5 -> perl 6 translator should [recursively handle eval]
>
> Blech, no. eval should stay eval. People are responsible for generating
> Perl6 compatible code, if they construct code as strings on the fly.
I would disagree. If I'm using a program to translate my code
from one version of Perl to another, I don't want to have to go in and
hand-fix (possibly large) sections of it...it should just _work_. I'm
with MJD on this one.
Dave
Re: pack/unpack is damn unperlish. Explain them as Perl.
On Mon, 18 Sep 2000, Michael G Schwern wrote:
> I'm sure there are many times when pack should have been used but it
> got hacked together with something else. The prime example is [...]
I must admit I'm with Michael on this one. I've been writing Perl
on and off for two or three years; I consider myself minimally competent
but certainly not great. I do not understand (un)pack and have never used
them. Perhaps I could figure it out if I pored over the man pages and the
book and sat and played with it for several hours, but there has never
been sufficient motivation to do so; given that TIMTOWTDI, I have never
*needed* to use (un)pack...and, as a result, I have probably written less
efficient code as a result.
I guess, if I had to write an explanation of pack/unpack based on
my limited understanding, it would be something like:
"Unpack takes binary data in some particular format and
disassembles it, assigning various pieces of it to variables according to
formatting that you supply. Pack does the opposite, using your supplied
formatting to crunch Perl scalar variables into binary data that is
represented in some specific way. The binary data used by (un)pack will
belong to exactly one type of C numeric variable, meaning that it will be
limited in what kinds of numbers it can store and how it will represent
them."
Is this definition completely off-base?
Dave
Re: Pre-withdrawal notice for RFC184
On Tue, 19 Sep 2000, H.Merijn Brand wrote:
> On 19 Sep 2000 09:23:00 +0300, Ariel Scolnicov <[EMAIL PROTECTED]> wrote:
> >
> > I'm planning to withdraw RFC184 ("Perl should support an interactive
> > mode"), due to lack of interest. There was little discussion of it,
I seem to have missed this one, or I would have been in on the
discussion. Personally, I really like the idea. I have now read the RFC
and will think on it; if enough other people chime in with "wait!wait!",
I'll post some thoughts...otherwise, I'll be sorry to see it go.
Dave
Re: RFC 255 (v2) Fix iteration of nested hashes
On Tue, 19 Sep 2000, Tom Christiansen wrote:
> >This RFC proposes that the internal cursor iterated by the C function
> >be stored in the pad of the block containing the C, rather than
> >being stored within the hash being iterated.
>
> Then how do you specify which iterator is to be reset when you wish
> to do that? Currently, you do this by specifying the hash. If the
Suppose we change each to be:
each HASH
each ITERATOR
and create a new keyword,
iterator HASH
which creates a new iterator for the specified hash. This iterator can
then be eached, just like the hash, and reset using
reset ITERATOR
Usage would then look like this (stealing Damian's code):
%desc = ( blue => "moon",
green => "egg",
red => "Baron" );
$i1 = iterator %desc;
$i2 = iterator %desc;
while ( my ($key1,$value1) = each $i1)
{
while ( my ($key2,$value2) = each $i2 )
{
print "$value2 is not $key1\n" unless $key1 eq $key2;
}
}
print "(finished)\n";
This runs into problems if you currently have an iterator extant and you
modify the hash to which it points. Immediate suggestions on how to
handle this would be:
1) Do what the docs currently do; tell people "don't do that"
2) Have the iterator auto-reset when the hash is modified
(probably bad)
3) Make the hash unmodifiable while there is an iterator extant
(probably bad)
4) Make powerful magic in some way that isn't coming to mind
Dave
Re: RFC 12 (v2) variable usage warnings
On Wed, 20 Sep 2000, Steve Fink wrote: > 1 my ($x, $y, $z); > 2 $z = 1; > 3 my $logfile = "/tmp/log"; > 4 $x = 1 if cond(); > 5 print $x+$y; > 6 undef $z; > 7 print $z; > > --> use of uninitialized variable $y in line 5 (compile time) > --> possible use of uninitialized variable $x in line 5 (compile time) > --> variable $logfile defined in line 3 but never used (compile time) > --> use of undefined value in line 7 (run time) Couldn't the error on line 7 be detected at compile time as well? After all, there is no execution path which will result in $z having a defined value. Dave
Re: RFC 12 (v2) variable usage warnings
On Wed, 20 Sep 2000, Eric Roode wrote: > foo(); > print $x; > > Generate a warning, or not? Which one? Remember, foo() may initialize $x. My suggest (FWIW) would be that, if there is no execution path which leads to $x being defined in the second line, then a "Use of uninit'd variable $x" warning should be thrown at compile time. If there is at least one path that will result in $x being defined AND at least one path that will result in it being undefined, the compile-time warning could be something like "Possible use of undefined variable $x" or "Not all execution paths leave $x defined". Dave
RE: PERL6STORM - tchrist's brainstorm list for perl6
On Fri, 22 Sep 2000, Greg Boug wrote: > > > =item perl6storm #0064 > > > > > > Do something about microsoft's CRLF abomination. > > Perhaps somehow allowing $/ to take multiple input delimeters (perhaps in a > fashion similar to egrep)... How about: [snip] > $/ = "seperator1|seperator2"; > > [snip] so you could conceivably end up with code like: > $/ = "\||\\"; > to delimit on '|' or '\'... Alternatively, we make it work like '-' in a character class...if it's the first character, the RE knows that you want it to a literal hyphen. If used between two characters, you want a range (or, in this case, an alternative). So: $/ = "||foo" would mean 'delimited by a pile for by the sequence foo' Similarly (although this one might be a lot nastier from an -internals viewpoint), we could say that, if the final " is immediately preceded by an '\', then clearly what you wanted was a literal backslash. (That is, "\" would not produce a runaway string...hmmm, that's a good idea all by itself, actually.) Assuming that both of these ideas were implemented, then you could write: $/ = "||\" and it would DWYM. Dave
Re: RFC 245 (v1) Add new C keyword to DWIM for clearing values
On 17 Sep 2000, Perl6 RFC Librarian wrote:
>my $name = undef;
>my($a, $b, $c, $d, $e, $f) = undef;
Well, these two get the result they want. Try this code:
my($a, $b, $c, $d, $e, $f) = undef;
my %h = ( a => $a, b => $b, c => $c, d => $d, e => $e, f => $f );
while (my ($k, $v) = each %h)
{
print defined $v ? "$k is defined" : "$k is undefined";
print "\n";
}
it prints:
a is undefined
b is undefined
c is undefined
d is undefined
e is undefined
f is undefined
Why would anyone expect that assigning undef to anything would produce an
empty string. That makes no sense at all.
>my $name = empty;
what's wrong with $name = '';
>my($a, $b, $c, $d, $e, $f) = empty;
>my(@name, $age, %attrs) = empty;
What is the point of doing
my @name = ();
That's the same as:
my @name;
In fact, only for scalars does your proposed empty builtin do anything
different from my or local in terms of the value of the variable.
> And its purpose is intuitive: It causes a value to become C,
> without being undefined. Note that it can also shorten code in some
> situations.
Well, I don't want to encourage people to needlessly 'initialize'
variables in Perl.
The only case where it makes a difference is where you do:
my $x;
$x .= 'a';
$x .= 'b';
and you'll get an unitialized value warning. In that case, doing:
my $x = '';
is shorter and clearer. There's no point in trying to 'initialize' arrays
or hashes, because you'll never get those warnings with it.
> Nonetheless, feel free to point out why this is a bad idea and I'll
> gladly retract it.
See the above ;)
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: perl6storm #0050
On Sat, 23 Sep 2000, raptor wrote: > > On Thu, 21 Sep 2000, Tom Christiansen wrote: > > > > > =item perl6storm #0050 > > > > > > Radical notion: consider removing precedence. > > > Wrong precedence makes people miserable. > What if we have these 2 rules or no rules AND we can set manualy the > precedence of all operators... as in PROLOG > (op(precedencePriority,associativity!,operator)). I think this would be very unwise. Whenever adding a feature, we need to ask if the power granted outweighs the potential pitfalls created; in this case, I don't think it does. The potential problems of being able to assign precedence as you see fit (talk about action at a distance!) are enormous, and it does not seem to lend the same kind of elegant power that, for example, Damian's HOFs do. Dave
Re: RFC 290 (v1) Remove -X
On 25 Sep 2000, Perl6 RFC Librarian wrote: > =head1 TITLE > > Remove -X > > The prefered mechanism for file tests should be more legible, using > terms like 'readable(FOO)' and 'writeable(FOO)' instead of the > =head1 MIGRATION ISSUES > Perl programmers happy with the -X syntax will need to get used to the > lengthier replacement. Why can't both remain in place? Have the short forms so that those of us who are used to them and don't find them confusing can use them (and so p526 does not need to address this issue), and have the new readability-enhanced ( :> ) versions as well, for them's as want those. This seems like an excellent place to TIMTOWTDI. Dave
Re: RFC 288 (v1) First-Class CGI Support
On Sun, 24 Sep 2000, Nathan Wiger wrote:
> > Offer simple functions to set HTTP headers (e.g. content type, result codes)
> How about %HTTP, which is just flushed on the first line of output?
>use cgi;
>$HTTP{'Content-type'} = 'text/html';
>print "Hello!"; # flushes %HTTP first
I like this a lot, but you need to make sure that it flushes the
hash in the right order if multiple keys are present.
Dave
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
On Mon, 25 Sep 2000, Michael Fowler wrote: > This RFC makes no mention of what happens to the following constructs: > > %foo = (bar => "baz"); This actually isn't a bareword (as I understand it), since the => operator quotes its LHS.
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
I personally have never had problems with these issues and would just as soon that this RFC didn't do through. However, I don't feel particularly strongly about most of it. Specifically: As to autoquoting the lefthand side of -> (thereby making it a class name), I don't particularly care. The only place I use the indirect object syntax if for calls to 'new', where they read very cleanly, so I won't particularly miss them if they go away. There are certain places that I would like to see auto quoting happen. These include: 1) In a 'use' statement. 2) Inside the braces of a hash access or hash slice These places are not ambiguous, and it's a pain to have to put quotes around them every time. Dave
Re: RFC 292 (v1) Extensions to the perl debugger
On 26 Sep 2000, Johan Vromans wrote: > Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > > > The ability to easily retrieve and edit your N most recent commands to the > > debugger (much like a bash_history). > and > > A better default pager. The default pager should assume a 24x80 term > > window ... > > To me, these clearly indicates that the debugger should be run as a > subsystem of some other tool that takes care of this. It is not part > of the debugger itself. For example, take a look at how emacs runs the > debugger. I'm confused...are you suggesting that the debugger should no longer be integrated into perl? If so, I disagree...I absolutely insist that, no matter what pathological distribution someone may put together for Perl, I will get the debugger so at least I have a chance of figuring out what's wrong. The only way to absolutely ensure this is to have it built into the interpreter itself. As to the history file...this is something that I've wanted since I first touched the debugger, and I suspect others would like it as well. As to the pager...the "default pager" is currently "no pager", which is silly. I distinctly remember having the following thought pattern, from back when I was learning how to use the debugger: "Ok, what commands are available? Let's type 'h' " "Hmm...it scrolls off the screen...aha! look, down here at the bottom it says I can do '|dbcmd' to pipe the output of a debugger command through the current pager! Excellent, that's just what I need." " '|h' " [it runs off the screen again] "DOH!" All humor aside, there is too much information in the debugger help screen to fit in 50 lines. That means that anyone trying to use the debugger through a DOS window, or a fixed-size telnet client, can't see the majority of the information. Dave
Re: RFC 292 (v1) Extensions to the perl debugger
On Wed, 27 Sep 2000, Johan Vromans wrote: > What I wanted to indicate is that the input and output handling of the > debugger, currently line input and line output, should not be turned > into a sophisticated user interface with command line recall/editing > and fancy output paging (e.g. two independently scrollable windows, > one for input and one for output). External tools should manage that. > I mentioned the way the perl debugger runs under Emacs, ptkdb is > another good example. > > BTW: the debugger already has command line recall/editing using > Term::ReadLine. I disagree. I want to have perl provide reasonable default behavior for these extremely useful and commonly-desired functions, and I don't want it to be dependent on modules from outside the core or on requiring the user to configure something (after all, if the user must configure it, it's not default). I want perl to provide me with a standard interface which satsifies my basic requirements. I want this interface to be the same on all platforms so I don't need to get used to "oh yeah, today I'm on the Windows box, so it's Shift-UpArrow for the command history." I'm not saying that outside tools shouldn't be built to provide _better_ versions of the standard behavior, or nicer UIs. I'm just saying that the basic versions are not acceptable, and should be improved and standardized. Dave
Re: my and local
To my mind, things would be a lot clearer if my and local were to change places - but I can see why that would not be a good thing. If it's not too late for suggestions for renaming local, what about 'override'. Dave. - Original Message - From: "Michael Fowler" <[EMAIL PROTECTED]> To: "Tom Christiansen" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, September 28, 2000 10:36 AM Subject: Re: my and local > On Thu, Sep 28, 2000 at 10:18:34AM +0100, Tom Christiansen wrote: > > As we sneak under the wire here, I'm hoping someone > > has posted an RFC that alters the meaning of my/local. > > It's very hard to explain as is. my is fine, but local > > should be changed to something like "temporary" (yes, that > > is supposed to be annoying to type) or "dynamic". > > Someone has: > RFC19 "Rename the C operator" http://tmtowtdi.perl.org/rfc/19.pod > > > Michael > -- > Administrator www.shoebox.net > Programmer, System Administrator www.gallanttech.com > -- >
Re: IDEA: lexically scoped subs anyone
On 29 Sep 2000, Piers Cawley wrote:
> Is it possible? Advisable?
I haven't seen it yet, but that doesn't mean it's not in there
somewhere...there's a bunch of RFCs I haven't had time to read. If it
isn't there, it should be. I think this is definitely a cool idea.
Dave
Re: UNIX epoch issues (Re: Why shouldn't sleep(0.5) DWIM?)
On Tue, 30 Jan 2001, Nathan Wiger wrote:
> Jarkko Hietaniemi wrote:
> >
> > As I said the problem isn't the p52p6 doing that kind of transformation.
> > The problem is someone familiar with perl5 writing code in perl6:
> >
> > if (my $fh = open(">/tmp/$$".time())) {
> >
> > and later something crashing and burning because some other place expects
> > to find a filename of the form /^\d+\d+$/, or someone printing into log files
> > like this
Well, FWIW, here are two suggestions on how to handle this, the
grouchy way and the helpful way:
1) (grouchy) If you're writing Perl6, you should be writing Perl6,
and you should know how time() behaves and handle it properly.
2) (helpful) time() returns an int-based time value (as now), but
time() returns a subsecond-value...if we wanted to get really
fancy, then the value of as an int could be the number of
places of accuracy that would be returned.
Dave
Re: Really auto autoloaded modules
On Thu, 1 Feb 2001, Nathan Wiger wrote:
> There's the big problem of overlapping function names. If I say:
>
>$name = param('name');
>
> I probably mean "use CGI". But maybe there's some other module that has
> param() also? What if I really mean "use CGI::Minimal"?
Here's a gross thought (for implementors at least ;)
If it sees
use CGI qw( param header );
the autoloader could look for a module which implements the 'CGI'
interface and has those two functions. This could be CGI or CGI::Minimal.
Then there needs to be a way to figure out which to load. Hopefully the
smallest/quickest.
And code that does this:
use CGI qw( param header heavy_lifting );
Would get CGI.pm.
If the loading is done based on interface implementation (there's a nice
nebulous idea) this could be very slick (and very hairy to implement).
Just a thought.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: Really auto autoloaded modules
On Thu, 1 Feb 2001, Michael G Schwern wrote: > Problem is, its extremely difficult to figure out what module > implements what. Sure, if you see a C you have a I wasn't clear. I was thinking that somehow a module would register with the core what interfaces it support when it is installed. Anything else is madness (ok, my idea is madness too). -dave /*== www.urth.org We await the New Sun ==*/
Re: Really auto autoloaded modules
On Fri, 2 Feb 2001, Jarkko Hietaniemi wrote: > What I think is needed is some sort of opaque tag: the name of the > 'contract' the API claims to fulfill. The name can be the name of > the standard, the name of the company, the name of the individual. > (Java does a very similar thing but they propose embedding the DNS > name as part of the package name: I think they the right idea but > the proposed implementation sucks.) That's what I was thinking. The point is that the module identifies the services it provides. Multiple modules may provide overlapping sets of services. Modules could also be somehow ranked (memory usage and speed come to mind). Then I could put this into my module: needs CGI; needs URI; needs HTML::Output; needs HTTP; There may be five modules implementing the 'CGI' interface, three for URI, and two for HTTP. If it so happens that one module (CGI.pm, for example), implements three of the interfaces I need, then that may be a better choice than loading several separate modules. Or there may be a very fast but less stable (or less portable) XS module for HTTP and a slower but very stable and portable pure Perl version. They would have different module names but would both implement the HTTP interface. One thing this suggests to me is that part of the module install process may include asking the installer what precedence they want to give the module for each of the interfaces it supports. The other question is how we define an interface (as opposed to how we name it). -dave /*== www.urth.org We await the New Sun ==*/
RE: Really auto autoloaded modules
On Fri, 2 Feb 2001, Garrett Goebel wrote: > $Foo::VERSION eq 1.00 > | > | $Foo::VERSION eq 2.00 > | | > Bar Baz > \ / > My::Module Ideally, it should be perfectly legit to have multiple versions of a given module on your system, which would resolve this problem nicely. One possible implementation for that would be to introduce a new special token, __VERSION__. It would work something like this: package Bar::Quux; __VERSION__ 2.0 ...stuff... __VERSION__ 1.3 ...stuff... __VERSION__ 1.0 ...stuff... We then change the semantics of use slightly, so it becomes: use Bar::Quux; # Identical to current; nothing breaks; loads the #code in the first VERSION, then stops parsing use Bar::Quux 1.3; # Parses the file looking for __VERSION 1.3__, #ignores everything except that version When you want to install a new version, you simply prepend it with its version number (or insert it at appropriate place). The order is, of course, irrelevant...you can order it as 1.3, 2.0, 1.0 if you want, but then 1.3 would be loaded by default and you would need to explicitly request other versions. I'm sure this idea can be improved on, but it's a first cut. What do people think? Dave
RE: Really auto autoloaded modules
On Sun, 4 Feb 2001 [EMAIL PROTECTED] wrote: > >>>>> "Dave" == Dave Storrs <[EMAIL PROTECTED]> writes: > > > Dave> When you want to install a new version, you simply prepend it > Dave> with its version number (or insert it at appropriate place). > > Dave> The order is, of course, irrelevant...you can order it as 1.3, > Dave> 2.0, 1.0 if you want, but then 1.3 would be loaded by default > Dave> and you would need to explicitly request other versions. > > Dave> I'm sure this idea can be improved on, but it's a first cut. > Dave> What do people think? > > You want this to work with multiple module versions side by side. We > have a disk namespace where we put every module version in its own > directory, and the user can choose which version is required by > specifying 'use lib'. When a new version comes out, we install it > without touching the existing files - which makes backing out an > upgrade very easy. > > If multiple versions of a module could co-exist in the same program, > e.g. by extending the namespace by the module version number, that > would solve some issues in e.g. mod_perl, or in Storable release x -> > x+1 migration scripts. > > Hildo I see what you mean...I had only been thinking of how to handle it when you had base classes inherited from different versions of the same thing. I'd still like to suggest that we add the ability to consolidate versions into one file; I'm sure that some (many) people prefer to have their versions in separate files, but I (and, I imagine, at least some others) would find it easier if all versions were in one file, thereby making it easy to (e.g.) move all of Foo:: from one machine to another without accidentally leaving bits behind. Suppose you could do the following: use Bar::Quux::1.3; # Parses the file looking for __VERSION 1.3__, #ignores everything except that version use Bar::Quux::2.0; # Ditto for __VERSION 2.0__ Bar::Quux::1.3::do_stuff(); # Calls version 1.3 do_stuff() Bar::Quux::2.0::do_stuff(); # Calls version 2.0 do_stuff() Bar::Quux::do_stuff();# Calls version 2.0 do_stuff(), as that is #highest version currently loaded I believe that all of this could be done with a straightforward aliasing of namespaces at load time. Is this better? Dave
Re: What can we optimize (was Re: Schwartzian transforms)
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote: > Somewhat tangentially: this reminds me of a message a week ago or so > (can't find it anymore in my inbox) which proposed writing C (or C++) > code for Perl 6 so that "modern CPU architectures are happy" (no > pipeline stalls because of "if"-s, etc.) Hello? This is a very > high-level language we are writing, not a DSP core. Optimizing by > choosing good algorithms and data structures, yes, microoptimizing, > maybe, only after the code works first, and even then we would be > following the mirage since CPU architectures do evolve, and in > general, for large codebases, the C compilers are much, much, better > in optimizing than humans. Yes, a human can sit down and read > the databooks and optimize a simple algorithm to hell and back. > But megabytes of source code? Get real. That may have been me: http://archive.develooper.com/perl6-internals%40perl.org/msg02685.html (PDD for coding conventions) The main thrust of that was whether a PDD on coding conventions should have sections on: * Coding style * Naming conventions * Commenting conventions * Portability guidelines * Performance guidelines Based on your comments above (which I hearily agree with), I guess we can safely dispense with that last entry. Dave M.
Re: Larry's Apocalypse 1
On Thu, 5 Apr 2001, Nathan Wiger wrote:
> I'm unsure about the "module main" idea. I like that modules as a whole
> are strict/-w by default. But the "module main" tag causes the same
> problem Larry is opposed to with BASIC/PLUS "EXTEND". That is, every
> Perl 6 program begins with "module main". Maybe there's a better way to
> implement this? ("use 6.0" has much the same problem)
Not every p6 program...only the ones where you want the new
strict/warnings/whatever policies. And you can always put -ws on your
shebang line if you don't want to type "module main."
Dave
Re: Perl 5 compatibility (Re: Larry's Apocalypse 1)
On Thu, 5 Apr 2001, John Porter wrote: > Nathan Wiger wrote: > > the more compatible > > with Perl5 Perl6 is, the more likely it is to be accepted. > > I don't believe that's necessarily true. > If Perl6 proves to be a significantly better Perl than Perl5, > people will adopt it, especially if they're inclined toward > the Perl philosophy anyway. (And at first, those are the only > people we have to convince.) To this end, sacrificing the > Virgin of Perlish Power to the God of Backward Compatibility > would be unwise in the extreme. You are correct, but being backwards compatible is unlikely to _cost_ us adherents and might well gain us some. *shrug* Dave
Re: Larry's Apocalypse 1
On Mon, 9 Apr 2001, Peter Scott wrote: > At 09:36 AM 4/9/01 +0200, Ariel Scolnicov wrote: > > > >One liners are supposed to be SHORT. `--cmd' is LONG. If we MUST go > >the multiflagged way, why not reflect `-e' to get the `-6' flag? At > >the very least, I want a short flag! > > But by the time people learned to use '-6' we'd have Perl 7 out. We could then just add a -7 flag. That's not necessarily bad; Perl 7 will probably face the same issue...it needs to be able to eat Perl [567] code without barfing, but it needs to know what it's getting. Also, the flag would be a good choice in that it's very human-readable. Dave
recap on new operators?
For those of us who came in late...I gather that -> is expected to be
replaced by '.', which means that we need to find something else for '.'.
Somehow, however, I missed out what the exact benefits are of this
replacement--I'm not saying that there *aren't* any, I just never saw the
message where they were spelled out. Could someone please give a recap?
Also, rather than trying to jam extra functionality into '+' or '=~' or
whatever, would it be possible to simply use -> as the concat operator
(i.e., switch '->' and '.')?
Perl 5Perl 6
----
$mail_obj->{header} .= "Hi, John!"$mail_obj.{header} ->= "Hi, John!"
The pros and cons that I see are:
Pro:
- requires the minimum amount of disturbance to the syntax
Con:
- You need to know whether you are looking at Perl5 or Perl6 before you
know how to read the operator (raises problems both for programmers and
for p526 translator script)
- Some of the permutations (e.g. ->= ) look terrible.
Dave
Another string concat proposal
What about using double-dot as the string concat operator: P5P6 ->. . .. .=..= (or =.. for concat after) Many other operators already use doubled characters so this would not be an oddity for perl and it would leave single dot for all the things Larry wants it for without sacrificing the normal meanings of any of the other operators for concat. Dave Hartnoll.
Re: Another string concat proposal
> On Wed, Apr 25, 2001 at 11:53:33AM +0100, Dave Hartnoll wrote: > > What about using double-dot as the string concat operator: > > > > P5P6 > > ->. > > . .. > > .=..= (or =.. for concat after) > > You have missed a row for what the P5 .. operator becomes. > And the ... operator > > [I am neutral as to whether using .. as concatenation is a good idea] > > Nicholas Clark That'll teach me to jump in without proper research. I had forgotten about the .. range operator and I wasn't even aware of the ... variety (I am now). I suppose it would be too cheeky to attempt to redeem myself by suggesting ->> as a range operator? (I would have suggested -> but that introduces problems with it meaning the same as comma in some situations.) P5P6 ->. . .. .=..= (or =.. for concat after) ..->> ...->>> Another option I briefly considered for concat was .+ Perhaps too many changes overall, but food for thought for those without chronic indigestion already! Dave Hartnoll.
Re: Another string concat proposal
I wrote.. > ..(I would have suggested -> but that > introduces problems with it meaning the same as comma in some situations.) Ignore that. I'm getting confused with => sometimes meaning the same as comma. I think I'll quit now before I dig myself any deeper :-) Dave.
Re: .NET
On Wed, 2 May 2001, Dan Brian wrote: > Another snippet from the .NET whitepaper: > > > Everyone believes the Web will evolve, but for that evolution to be > truly empowering for developers, businesses, and consumers, a radical new > vision is needed. Microsoft's goal is to provide that vision and the > technology to make it a reality. > > > In other words, evolution in and of itself is not empowering. Without the > vision[tm], evolution is "deempowering". Well, strictly speaking, they only implied that, without their Vision[tm], evolution would be nonempowering...which is different than deempowering; things could just remain in a steady state. It's still a pretty arrogant claim, no matter which way you slice it. Dave
Re: .NET
On 3 May 2001, Ilya Martynov wrote: > >> You can serialize/deserilize object with Storable > >> > >> $foo = new Bar > >> store_fd $foo, \*SOCKET; > >> > >> and on the other end > >> > >> $foo = retrieve_fd \*SOCKET; > >> $foo->bar; > >> > >> It will work if you have Bar module on both ends. > > DS> Right, but I want it to work if you don't... > > Then maybe SOAP::Lite? SOAP allows to serialize/deserialize objects > and make remote call. SOAP::Lite makes it quite transparent. Errm...wasn't (something like) this discussed just recently and deemed a massive security hole? If I download a program, I don't want to have to inspect every line of source to make that it won't download some bizarre Trojaned module (or even an object instantiated from that module, which is worse because it leaves fewer traces by not writing to disk) from some far corner of Script Kiddie Land. Dave
Re: Apoc2 - concerns ::::: new mascot?
And there was me thinking the shiny ball must be a camel dropping
The 5% solution
Just a quick obeservation:
Given the radicalness of the changes suggested by apo 2, I think it's
fair to say that the proportion of Perl 5 code that will run unchanged
on a Perl 6 interpreter will be heading into single-figure percentages.
While I personally think this will be price well worth paying, we need to
bear in mind that the eventual syntax and semantics of Perl 6 has got
to be such that the writing of the Perl 5 to 6 translator utility is
still feasable. I dont think the syntax will be too much of a problem
(eg %foo{a} vs $foo{a}), but it will be important that there is always
some way of expressing Perl5-ish semantics in such matters as list context
etc.
$soapbox.dismount or dismount $soapbox or $soapbox->dismount();
Re: Apoc2 - concerns ::::: new mascot?
(apologies if this is a duplicate - I think my last post has gotten lost). > The RFC pleads for a community spirit from ORA. Barring that, it seeks > a new symbol for the community entirely I'd suggest a mongoose - eats poisonous snakes for breakfast. There's a sort of tie-in with Perl Mongers == Perl Mongoose as well :-) Dave.
Re: The 5% solution
> Briefly: We want the Perl 6 runtime to be an equivalent of the Microsoft > CLR, so that if you can somehow get bytecode onto it - from whatever > language - you can run it. So we've got some bytecode that perl can run. > Now think about what B::Deparse does. I knew the intention was to go the B::Deparse route, but I'd worry about perl5 byte-code not being semantically similar to Perl 6 bytecode. There's a lot of implicit assumptions about what an aassign op does, say. But the words suck, teach, eggs and grandma are probably appropriate at this point if suitably re-arranged ;-)
Re: Apoc2 - concerns
On Tue, 8 May 2001, Larry Wall wrote: > In this view, * and < could just be two different kinds of "expandable" flags. > But I'm uncomfortable with that, because I'd like to be able to say > > lazy_sub(<$STDIN, <$STDIN, <$STDIN, <$STDIN) > > to feed four lines to lazy_sub without defeating the prototype, er, > signature checking. Maybe you have to us *<$STDIN to do both. But that > would probably say to slurp the whole rest of the file. You know, it would be really cool if you specify the number of lines you wanted like so: <$STDIN # One line *<$STDIN# All available lines *4<$STDIN # Next 4 lines Or even: *$num_lines<$STDIN # Numifies $num_lines, gets that many *int rand(6)<$STDIN # Gets 0-5 lines *&mySub($bar)<$STDIN# mySub returns num, gets that many Dave
Re: apo 2
On Tue, 8 May 2001, Me wrote: > yes? > > And, despite perl5's use of no as the opposite > of use, and given that there may be no use in > perl6 (;>), and thus perhaps no no, (on and off?), > then maybe no could be used as not yes? > > no? Your Honor, I would like to stipulate that that sentence be taken out and shot. ;> Dave
Re: Apoc2 - concerns ::::: new mascot?
> The RFC pleads for a community spirit from ORA. Barring that, it seeks a new > symbol for the community entirely I'd suggest a mongoose - eats poisonous snakes for breakfast. There's a sort of tie-in with Perl Mongers == Perl Mongoose as well :-) Dave.
Safe signals, multiple signals?
There have been multiple mentions of the fact that we intend to have safe signals in Perl 6. I was wondering if it will also be possible to have more than one alarm() set at a time, or some other mechanism for having multiple pending signals. Dave
Re: Apoc2 - concerns
< QUOTE LARRY > Dave Storrs writes: : You know, it would be really cool if you specify the number of : lines you wanted like so: : : <$STDIN # One line : *<$STDIN# All available lines : *4<$STDIN # Next 4 lines : : Or even: : : *$num_lines<$STDIN # Numifies $num_lines, gets that many : *int rand(6)<$STDIN # Gets 0-5 lines : *&mySub($bar)<$STDIN# mySub returns num, gets that many Given appropriate overloading on the iterator object: @foo = $STDIN * 4; Larry < END QUOTE> Actually, on more reflection, I'm going to side with the people who say that the single-character version is not an improvement, and that we should stick with <>. Also, I'd prefer to use the 'x' operator for specifying multiples: @foo = <$STDIN> x 4; @foo = <$STDIN> x &mySub; The parallel with "$foo = 'bar'x2;", where bar is simply repeated twice, is obvious: '<$STDIN' iterates the, uh, iterator, and repeating that operation iterates it multiple times. It even reads nicely "Fetch a line from STDIN times four" (or, more idiomatically, "...four times"). Dave
Re: Safe signals, multiple signals?
On Thu, 10 May 2001, Uri Guttman wrote:
> >>>>> "DS" == Dave Storrs <[EMAIL PROTECTED]> writes:
>
> DS> There have been multiple mentions of the fact that we intend to have safe
> DS> signals in Perl 6. I was wondering if it will also be possible to have
> DS> more than one alarm() set at a time, or some other mechanism for having
> DS> multiple pending signals.
>
> if we have a proper core event loop as dan and i want, multiple timers
> will be part of that. and that will mean we can have timed out
> operations without the mess of eval/die (or whatever 6 will have for
> that).
Cool.
>
> similarly, proper safe signals will store all pending signals and
> deliver each one.
Cooler.
> a core event loop will support all of those features. delivery methods
> can be chosen by the coder, either polling in the op code loop or
> running a proper event loop with no polling (which will be faster).
Completely frozen. (That's a compliment, in this context. :>)
Dave
Re: Apoc2 - concerns
On Thu, 10 May 2001, Larry Wall wrote:
> Dave Storrs writes:
> : should stick with <>. Also, I'd prefer to use the 'x' operator for
> : specifying multiples:
> :
> : @foo = <$STDIN> x 4;
> : @foo = <$STDIN> x &mySub;
> :
> : The parallel with "$foo = 'bar'x2;", where bar is simply repeated twice,
> : is obvious: '<$STDIN' iterates the, uh, iterator, and repeating that
> : operation iterates it multiple times. It even reads nicely "Fetch a line
> : from STDIN times four" (or, more idiomatically, "...four times").
>
> Um, I don't think so. What I wrote above was just a fancy trick with
> straight Perl 5 overloading. You could do that today.
>
> I'd think that what you wrote would have to input one line from $STDIN
> and then dup that line 4 times. Either that, or because it's in list
> context it inputs all the lines and duplicates each 4 times, just like
>
> @foo = @bar * 2;
>
> maybe ought to multiply each element by two, at least the way some
> numericists look at it.
Hmmm...I see your point, but I think it depends on what you see as
the operatee that 'x' is operating on. If it's the string(s) produced by
<>, then you're certainly right. But if it is the act of iterating
itself, then I think my suggestion is still valid. And yes, I realize
that the current behavior is always to act on the string, not the act of
calling the function that produced the string, or whatever. I just think
that we could extend 'x' to have a general repetition meaning. Imagine
the following:
our $a = 0;
our $baz = 'jaz';
sub blah {
$a++;
return 'Hi';
}
$foo = 'bar' x 2; # $foo => 'barbar'
$foo = $baz x 2;# $foo => 'jazjaz'
$foo = blah() x 2; # blah() called twice,
# $foo = 'Hi', $a = 2
$foo = join '', (blah() x 2)# blah() called twice,
# $foo => 'HiHi', $a = 4
$foo = <$STDIN> x 2;# read two lines, discard first,
# stick second into $foo
@foo = <$STDIN> x 2;# read two lines, stick into @foo
Dave
Re: Apoc2 - concerns
On Fri, 11 May 2001, Larry Wall wrote: > Dave Storrs writes: > : calling the function that produced the string, or whatever. I just think > : that we could extend 'x' to have a general repetition meaning. > > I think just patching one operator from verbal status to adverbial > status is not sufficiently general. [...] > <$STDIN> MUMBLE 2 # read twice > 1 .. 100 MUMBLE 3 # count by threes > `glob $x` MUMBLE "/bin/csh" # modify pseudoquote > > It has not yet been decided what form these MUMBLEs will take, > [...but maybe the default] > adverbial MUMBLE is simply ":". Which might cause the above to reduce > to: > > <$STDIN> : 2 # read twice > 1 .. 100 : 3 # count by threes > `glob $x` : "/bin/csh"# modify pseudoquote Wow. This is great; very powerful and very elegant...how Perlish. $verb = "I " cc 'tow'x2 cc ' admiringly'; $verb =~ s/t/k/; # ;> Dave
Re: Perl5 Compatibility, take 2 (Re: Perl, the new generation)
All that follows is merely MHO, so feel free to disregard.
On Fri, 11 May 2001, Nathan Wiger wrote:
> Well, I think we should take a step back and answer a few key questions:
>
> 1. Do we want to be able to use Perl 5 modules in a
>Perl 6 program (without conversion)?
I would say it's absolutely mandatory that we be able to use perl
5 modules--half the power of Perl is CPAN.
>
> 2. Do we want to be able to switch between Perl 5 and
>Perl 6 in a single file (by using "module" to dictate
>P6 and "package" P5)?
This seems like something that could be left out without
outraging too many people.
> 3. Do we want to assume Perl 5 or Perl 6 code? If we
>assume P5, then we have to look for "module" somewhere.
>If we assume P6, we can look for a number of differences,
>such as $foo[1], $foo{bar}, etc to identify P5 code.
It will probably be easier if we assume P6 code, but P5 policies
(warnings, strictness, etc).
> 4. Do we want to be able claim 100% compatibility, or
>"99% except typeglobs", in which case if *foo is
>seen we just drop with "Typeglobs not supported"?
I don't see that we *can* claim 100% compatibility...there's
simply no way, in the real universe, that every P5 script ever written
will run flawlessly through the P6 interpreter (unless we simply swap to
the P5 interpreter upon recognizing P5 code, but even that might not work
in a mixed environment).
On a related topic, here's a crazy off-the-cuff thought...haven't
spent many cycles on it, not sure if it's worth anything, but I'll throw
it out to be shot at:
Can we break the p526 functionality out into a normal P6 module
and, for the first few versions of P6, have the interpreter automatically
load this modules and pass all other code through it before actually
starting to interpret it? This would keep core size down, make the
translator easily available as a separate system/API, and make it easy to
turn off the translation after enough time has passed that P6 is the
assumed standard.
Dave
Re: Time::Local
On Tue, 5 Jul 2005, Gaal Yahas wrote: Regarding Time::Local fields, it's an object now, so the order of things Should that be Time::localtime? In P5 there are Time::localtime & Time::gmtime, which are thin OO facades over the language builtins. Then there's the module Time::Local, which is entirely different. All of those provide useful functionality, and probably Time::Local should be part of the language, _or_ localtime & gmtime should be in a library. * .year is the Gregorian year, no 1900 offeset or anything like that. Yes! * .month and .wday are one-based. Sunday == 1. Haskell has them as enums which avoids off-by one confusion completely; I made them like I did because that's like humans think of them. And yes again! * .picoseconds - we don't promise this granularity is available by the system, but I don't suppose we'll ever need anything finer than that :-) The more granularity the better, really. DateTime right now supports nanoseconds, which was a semi-arbitrary choice that seemed granular enough. Picoseconds is even better. Anyone who needs more probably has some sort of special hardware providing their data anyway, and will need a special interface to it (hand waving). * Once we sort out context and want in pugs, I can return a List when one is expected, instead of an object. Then the order of fields becomes important and I'm inclined to go with year first, like the Haskell module, so that least significant things come last. This is the reverse of p5 Time::Local. When timelocal and timegm are implemented, they will of course use whatever order their inverses use. I'd agree that this makes the most sense. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
Larry Wall wrote: The time function always returns the time in floating point. I don't understand why time() should return a numeric value at all. Surely it should return a DateTime (or Time) object. Using epochs in a high level language seems like a really bad thing to be doing. If I want "duration since epoch" then I should subtract the epoch from the time -- resulting in a duration (which may indeed be a floating point value). my DateTime $epoch is constant = DateTime "2000-01-01 00:00:00"; my Num $seconds_since_epoch = time - $epoch; > In fact, > all numeric times are Num in Perl 6. Then you don't have to worry > about whether picosecond resolution is good enough. Time and > duration objects can, of course, do whatever they like internally, > and among themselves, but someone who says sleep($PI) should get a > $PI second sleep. For the sleep function, it seems reasonable to accept either a DateTime or a Duration, which would sleep either until the requested time, or for the requested duration. Sorry about the rant, but you seem to have pushed one of my hot buttons... Ditto Larry
Re: Time::Local
Douglas P. McNutt wrote:
At 10:55 -0700 7/5/05, Dave Whipp wrote:
I don't understand why time() should return a numeric value at all.
Some of us like to use epoch time, as an integer, to create unique file names which sort
"right" in a shell or GUI.
You can use "{time - $epoch}" or "{time.as<%d>}" or "{int time}". (That
last one is not "{+time}", because that would be a floating-point value,
not an integer).
Re: Time::Local
Darren Duncan wrote: The object should not store anything other than this single numerical value internally (smart caching of conversions aside). I think we can all either agree with that, or dont-care it. The internal implementation is an implementation issue (or library). It doesn't need to be defined by the language. The one important thing is that that language shouldn't define semantics that require more than this single value (e.g. we shouldn't associate the epoch with the object).
Re: Time::Local -- and lexical scope
Dave Whipp wrote:
You can use "{time - $epoch}" or "{time.as<%d>}" or "{int time}". (That
last one is not "{+time}", because that would be a floating-point value,
not an integer).
I was thinking: an epoch is just a time, and "int time" is a duration --
the number of seconds since the current epoch. So, the following should
work:
for 1 .. 2 -> {
use epoch time();
sleep 6;
say int time;
}
This should print something close to "6", twice.
But something niggled me: does the value of the RHS of a "use" get
evaluated at run time, or compile time? In perl5, that could definitely
would only execute the C once.
I could see 3 possible behaviors:
1. C sets the epoch for each iteration of the loop, thus calling
time() one per iteration
2. C executes just once, at compile time. Thus seconds iteration
prints approximately "12"
3. C does a compile-time binding of the epoch to the time()
function. So each iteration prints "0".
Which actually happens?
Re: Time::Local
On Tue, 5 Jul 2005, Juerd wrote: No. Humans don't USE numbers for week days! So beginning at 1 makes no sense, except for humans who like creating lists like (undef, ). In fact, I would prefer to not having any 0 :) This should be separated into day() and day_name(). It's hardly obvious that day() should return a string, much less a bit of English! As for 0 vs 1 as the index, I think this is a bit of a red herring. If you're constantly using this as an array index you're operating at too low a level (IMO). If all your programs start with: my @DayNames = qw( Sunday Monday Tuesday ... ); I think you have a bigger problem than simply adjusting for a 1-indexed day number ;) -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Wed, 6 Jul 2005, Juerd wrote: I think the problem one has is much bigger even if a day *number* is ever displayed. Then beginning with 1 because that's where most humans begin counting, is wrong. It's a technical thing, and that should be kept as simple as possible, and as technical as possible, for easier compatibility with existing technical things. Calling Sunday 1 and not having a 0 would certainly upset and offend me. My weeks begin on Mondays, as do most people's weeks here. At the same time, I can accept any day as the first day if that first day is 0, because 0 is technical and internal anyway, not meant for humans. I'm sure lots of people would want an index 1 to be Sunday, if there is no index 0. This all is solved simply by NOT skipping 0, and using an arbitrarily chosen day for the first. Or, well, for compatibility, Sunday :) Computers and Perl count from 0. People count from 1. If something begins at 1, it is expected to be a people's thing. And with week days, this just doesn't work, as not everyone's week starts at the same day. On reflection, I realized it doesn't matter too much to me. In the end, I'm likely to need a higher-level interface than this to do something interesting (like print a day _name_ or calculate the second Sunday of the month) and that interface will just use the information Perl's builtins give it. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: File.seek() interface
Wolverian wrote: Or maybe we don't need such an adverb at all, and instead use $fh.seek($fh.end - 10); I'm a pretty high level guy, so I don't know about the performance implications of that. Maybe we want to keep seek() low level, anyway. Any thoughts/decisions? We should approach this from the perspective that $fh is an iterator, so the general problem is "how do we navigate a random-access iterator?". I have a feeling that the "correct" semantics are closer to: $fh = $fh.file.end - 10 though the short form ($fh = $fh.end - 10) is a reasonable shortcut.
Re: Hackathon notes
Rod Adams wrote:
multi method foo#bar (Num x) {...}
multi method foo#fiz (String x) {...}
$y = 42;
$obj.foo#fiz($y); # even though $y looks like a Num
$obj.foo($z); # let MMD sort it out.
Having additional tags might also give us something to hang priority
traits off: "foo#bar is more_specific_than(foo#baz);" might influence
the order of clauses in the implicit given/when block. It feels like
there should be a generalization of operator precidence here (even
thought he two are superficially dis-similar, the looser/tighter concept
appears valid).
Re: Perl 6 Summary for 2005-07-05 through 2005-07-12
Damian Conway wrote: Important qualification: Within a method or submethod, C<.method> only works when C<$_ =:= > $?SELF>. C<.method> is perfectly legal on *any* topic anywhere that $?SELF doesn't exist. Just to be clear, this includes any method/submethod with an explicitly named invocant, I hope.
Re: Optimization pipeline
Yuval Kogman wrote: - optimizers stack on top of each other - the output of each one is executable - optimizers work in a coroutine, and are preemptable - optimizers are small - optimizers operate with a certain section of code in mind > ... Optimizers get time slices to operate on code as it is needed. They get small portions - on the first run only simple optimizations are expected to actually finish. > ... A couple of thoughts spring to mind: in these coming times of ubiquitous multi-core computing with software transaction support, perhaps it would be realistic to place optimisation on a low-priority thread. So much code is single-threaded that anything we can do to make use of dual-cores is likely to improve system efficiency. The other thing that I thought of was the question of errors detected during optimisations. It is possible that an optimiser will do a more in-depth type inference (or dataflow analysis, etc.) and find errors in the code (e.g. gcc -O2 adds warnings for uninitialised variables). This would be a compile-time error that occurs while the code is running. If a program has been running for several hours when the problem is found, what do you do with the error? Would you even want to send a warning to stderr?
Re: Referring to package variables in the default namespace in p6
"TSa (Thomas Sandlaß)" wrote:
Here your expectations might be disappointed, sorry.
The non-symbolic form $*Main::foo = 'bar' creates code that
makes sure that the lhs results in a proper scalar container.
The symbolic form might not be so nice and return undef!
Then undef = 'bar' of course let's your program die.
When something knows that it is being evaluated in lvalue context, it
should probably return something like "undef but autovifify:{...}". The
assignment operator could then check for the "autovivify" property when
its LHS is undefined.
Re: Messing with the type heirarchy
Luke Palmer wrote: Everything that is a Num is a Complex right? Not according to Liskov But this is one of the standard OO >>paradoxes, and we're hoping roles are the way out of it. Well, everything that is a Num is a Complex in a value-typed world, which Num and Complex are in. I don't like reference types much (though I do admit they are necessary in a language like Perl), and I'm not sure how this fits there anymore. Anyway, that's beside the point, since a supertyping need is still there for referential types. Doesn't the problem largely go away if we allow Num to be a more general numeric type, and introduce, say, Real for the more constrained set of numbers that Num currently represents. Of course, if it were truely the most general, then it'd permit quaternions, etc., but I think that most people would be happy for Num to be a simplest possible complete arithmetic type.
"set" questions -- Re: $object.meta.isa(?) redux
Luke Palmer wrote: A new development in perl 6 land that will make some folks very happy. There is now a Set role. Among its operations are (including parentheses): (+) Union (*) Intersection (-) Difference (<=) Subset (<) Proper subset (>=) Superset (>) Proper superset (in) Element (=) Set equality Do Sets get a sigil? I'd guess that % would be appropriate, because a hash is simply "Set of Pair" where the membership equivalence class is simply $^member.key. What syntax is used to associate the equiv-class with a set?
Re: $object.meta.isa(?) redux
On Wed, 10 Aug 2005, Luke Palmer wrote: A new development in perl 6 land that will make some folks very happy. There is now a Set role. Among its operations are (including parentheses): (+) Union (*) Intersection (-) Difference (<=) Subset (<) Proper subset (>=) Superset (>) Proper superset (in) Element (=) Set equality It makes this folk very happy for one. I can see two very cool things coming out of this off the bat: 1. You could create a very nice mini-language that is 99% already defined in Perl6 for generating SQL or other RDBMS queries. 2. Writing a true RDBMS in Perl6 will be that much easier, because now all I'll have to do is overload these for the appropriate object types (relation, tuple, etc) and the code for doing various things will flow very naturally. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Set operators in Perl 6 [was Re: $object.meta.isa(?) redux]
[changing the subject line for the benefit of the summarizer ...] On Wed, 10 Aug 2005, Larry Wall wrote: And now some people will begin to wonder how ugly set values will look. We should also tell them that lists (and possibly any-junctions) promote to sets in set context, so that the usual way to write a set of numbers and strings can simply be <1 dog 42 cat 666.5> Groovy, but what about this? <1 dog 42 cat 42> Maybe a warning with an optional fatality under "use strict 'sets'"? -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Mon, 15 Aug 2005, Larry Wall wrote: But the best part is that if we abandon UTC leap seconds for civil time, we don't have to remember leap seconds going forward, only backward from 2000. So you want to take on the (very irritating, I tell you) burden of leap seconds going _backwards_ but not going forwards? But that's in contrast to your saying that the epoch would be December 31, 1999 at 23:59:29.0 UTC. Or did I misread your earlier messages? -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Tue, 16 Aug 2005, zowie wrote: Hmmm... at least backwards leap-seconds are fixed. Handling leap-seconds for all time requires net access or frequent software updates, but a single block of 32 comparisons handles everything up to A.D. 2000. Well, if you want accuracy you need to get that info one way or another, right? Although since most servers use NTP (or whatever MS uses), and that ultimately goes back to UTC from atomic clocks, you can always get an accurate local time (except _during_ leap a second when POSIX goes insane). Anyway, I don't think we should worry about this too much. There are a couple of ways to use epochs. One is to use it for sorting/comparison, like for file last mod times. In that case, the actual datetime the epoch represents is irrelevant. If you need to do anything with the actual datetime, I think it's best to turn it into some higher-level representation, like a date(time) object. The existing Time::Local bits in pugs are a reasonable start at a simple lightweight datetime class, and I'm hoping to be able to provide a more complete set of classes for date & time bits in the future. If we can encourage people to always use one of these, then hopefully most people will never need to care what Perl6's epoch actually _means_. It's just a magic number you pass to some function or library. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Wed, 17 Aug 2005, Autrijus Tang wrote: ...This seems to be quite consistent with the rumoured US proposal to abolish leap seconds by adding leap hours every 500 years or so: Wow, a piece of US government policy I can actually support! Hell must be a cold place right now. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Wed, 17 Aug 2005, Sam Vilain wrote: Why on earth would you want to encourage such a short sighted programming practise? The earth wobbles like a spinning top. In fact It's hardly short sighted to want leap seconds to be abandoned (not in Perl but world wide). The few people who _really_ care about syncing to midnight can still have them, but the rest of the world would be just fine with a leap hour every couple hundred years. synced, etc. Date modules (which, really, people should be using) then have something sensible to work with and can easily provide the alternate times. Environments that really can't guarantee an absolute epoch can simply return unanchored times and let the modules throw exceptions when you try to convert them to real times or times with impossible levels of accuracy. Great, so now code that works in one environment throws a "cannot find an up-to-date leap seconds table" exception in another? Eek! -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Hoping that Params::Validate is not needed in Perl6
one with the existing language. It doesn't add anything at compile time, so it really doesn't need to be part of the language. Anyway, I'd love to hear feedback on this. What did I get right? What did I get wrong? Did I miss a more elegant way to do something? What other types of param validation do other folks use/want to see? -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Hoping that Params::Validate is not needed in Perl6
On Wed, 17 Aug 2005, Luke Palmer wrote:
Dependencies, Exclusions, and "Require one-of"
With P::V I can do this:
{ credit_card_number =>
{ optional => 1,
depends => [ 'credit_card_expiration', 'credit_card_holder_name' ] },
credit_card_expiration => { optional => 1 },
credit_card_holder_name => { optional => 1 },
}
I have no idea how I might do this in Perl6, but I would love to see it
supported as part of parameter declarations
You sortof can:
sub validate (+$credit_card_number,
+$credit_card_expiration,
+$credit_card_holder_name)
where { defined $credit_card_number xor
defined $credit_card_expiration &&
defined $credit_card_holder_name }
{...}
But that's really yucky.
Hideous, indeed. Presumably with macros or some other compile time thing
that can be turned into something more palatable.
Similarly, something I've wanted to add to P::V is exclusions:
{ credit_card_number =>
{ optional => 1,
excludes => [ 'ach_bank_account_number' ] },
}
Another thing that would be really nice would be to require one of a set
of parameters, or one set out of multiple sets, so we could say "we need
credit card info _or_ bank account info".
Yeah, I suppose that would be nice. However, when you're doing these
kinds of complex dependencies, you'd like to provide your own error
messages when they fail. That is, instead of:
'$credit_card_number excludes $ach_bank_account_number'
You could say:
'You can't give a credit card number and a bank account number, silly!'
Actually, I forgot to mention this in my original post, but in general
it'd be nice to be able to provide some sort of callback/object to be
called whenever a parameter check fails, and it'd be nice to be able to
provide more than one, so I can have custom parameter exception logic per
class or sub.
So I wonder whether this kind of logic is better for a P::V module in
Perl 6. Let somebody else think about the hard stuff like that.
It'd be nice to catch this at compile time whenever possible, though.
Presumably this can be done with the existing language. It doesn't add
anything at compile time, so it really doesn't need to be part of the
language.
Even things that do add things at compile time don't need to be part
of the language. That's why "use" is a macro. :-)
Yes, but see above. I know we can do things like add syntax at compile
time, but can we do these sorts of checks? I'm sure the answer is yes,
but how easy will it be? Of course, if it's implemented via a C6AN module
it's only got to be done once, but it's worth thinking about.
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
Re: Hoping that Params::Validate is not needed in Perl6
On Thu, 18 Aug 2005, Yuval Kogman wrote:
You sortof can:
sub validate (+$credit_card_number,
+$credit_card_expiration,
+$credit_card_holder_name)
where { defined $credit_card_number xor
defined $credit_card_expiration &&
defined $credit_card_holder_name }
{...}
multi sub validate () { # no credit card info
}
multi sub validate (
$credit_card_number,
$credit_card_expiration,
$credit_card_holder_name
) {
}
Yeah, while playing with datetime stuff for pugs it occurred to me that
providing a fallback multi sub could be quite handy.
But I'd really like to get this stuff done at compile time wherever
possible. If I write this:
validate( credit_card_number: $number );
it should blow up at compile time, right?
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
Re: Hoping that Params::Validate is not needed in Perl6
On Wed, 17 Aug 2005, Dave Rolsky wrote:
Type Validation, "isa", & "can"
Params::Validate allows for several ways to check the _value_ of a parameter.
One way is to specify a primitive type like "SCALAR" or "ARRAYREF". In P6 we
have that with this:
sub date (Scalar +$year is required, ...)
I'm not sure is "Scalar" is a valid type though, but that's ok because we
have better types built in. In this case we should really use "Int" for a
year.
And another question. How will I make Perl6 not do automatic coercion for
me. If I have this sub:
sub date (Int +$year is required, +$month, +$day)
and someone does this:
date('this year', 12, 1);
I'd prefer for this to fail, rather than giving me -12-01! I vaguely
remember a mention of "use strict 'types'" either on this list or hanging
out with some pugs folks at YAPC.
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
Re: Hoping that Params::Validate is not needed in Perl6
On Thu, 18 Aug 2005, Autrijus Tang wrote: On Wed, Aug 17, 2005 at 11:45:52PM -0500, Dave Rolsky wrote: And another question. How will I make Perl6 not do automatic coercion for me. If I have this sub: sub date (Int +$year is required, +$month, +$day) BTW, Pugs supports the ++ syntax, which iirc is said to be back in favour during the Oscon design meeting: sub date (Int ++$year, +$month, +$day) Uh, great, what's the syntax mean again? It _looks_ like "+" as a prefix now means "must be passed as a name param" and "++" means must be passed as a named param and is required. Seems good to me. You will probably get: 1. a compile time warning of unsafe coercion, possibly made fatal. and 2. a NaN at runtime if you ignore the warning. Excellent. And presumably #1 will be activated by some lexically scoped pragma like "use strict 'types'"? Hurry up and finish. I want to use this language, darnit! And yes, I know about pugs, obviously, but for production usage I need less of a moving target ;) -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Demagicalizing pairs
I've been trying to thing about how to make this read right without too
much line noise. I think Lukes keyword approach ("named") is on the
right track.
If we want named params at both start and end, then its bound to be a
bit confusing. But perhaps we can say that they're always at the end --
but either at the end of the invocant section or the end of the args.
Also, "named" is a bit of a clumsy name. "Where" and "given" are taken,
so I'll use "with":
I think something like these read nicely, without too much line noise:
draw_polygon $canvas: @verticies with color => "red";
draw_polygon $canvas with color => "red": @vertices;
Dave.
Parsing indent-sensitive languages
If I want to parse a language that is sensitive to whitespace indentation (e.g. Python, Haskell), how do I do it using P6 rules/grammars? The way I'd usually handle it is to have a lexer that examines leading whitespace and converts it into "indent" and "unindent" tokens. The grammer can then use these tokens in the same way that it would any other block-delimiter. This requires a stateful lexer, because to work out the number of "unindent" tokens on a line, it needs to know what the indentation positions are. How would I write a P6 rule that defines and tokens? Alternatively (if a different approach is needed) how would I use P6 to parse such a language?
Re: Parsing indent-sensitive languages
Damian Conway wrote:
Alternatively, you could define separate rules for the three cases:
{
state @indents = 0;
rule indent {
^^ $:=(\h*)
{ $ = expand_tabs($).chars }
<( $ > @indents[-1] )>
{ let @indents = (@indents, $) }
}
rule outdent {
^^ $:=(\h*)
{ $ = expand_tabs($).chars }
<( $ < @indents[-1] )>
{ pop @indents while @indents && $ < @indents[-1];
let @indents = (@indents, $);
}
}
rule samedent { ... }
}
I have a couple of questions about this:
1. It's quite possible that a code-block in a parser could call a
function that reads a different file (e.g. for an "include "
statement). How does the state, @indents, get associated with a
particular match? (Sure, I could do an explicit save/restore; but things
might get harder if I was using coroutines to get concurrent matches to
implement, say, a smart-diff script)
2. How does the outdent rule work in the case where a line does 2
outdents? It looks to me as if I'd only get one match of : the
/\h*/ match will advance the match pos, so /^^/ won't match for the
second on the same line, which would cause problems if I'm
trying to match up nested blocks.
Dave.
Re: coercion and context
On Wed, 14 Sep 2005, Luke Palmer wrote: my Int $int = $num; Explicit coercion, however, isn't done with context: it is done with the .as() method: $num.as(Int). I think that's weird. Not to mention the fact that you might have put an Int there for typechecking purposes instead of coersion purposes, and you actually want it to die if $num is a string. Hmmm, how do we get both at once? My 2 cents ... Coercion and typechecking need to be fairly distinguishable for reading and writing code, as they're very different things. I for one like "my Int $int" as type checking, meaning it'll die if not given an int, and some sort of method/function for coercion, presumably the above-mentioned "as(Int)". The default should be type-checking is always strict, and coercion is never automatic, IMO. Otherwise it's just not that useful, because you always have to remember the various auto-coercion rules. Of course, for people who think that's "intuititive", there could be some sort of "use coercion" pragma, maybe something like: use coercion Num => Int uses .int, String => Int uses .numerify_if_looks_like_number, Date => String uses .date; Of course I'm pulling the syntax/API from my nether regions. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: skippable arguments in for loops
Luke Palmer wrote: Joked? Every other language that has pattern matching signatures that I know of (that is, ML family and Prolog) uses _. Why should we break that? IMO, it's immediately obvious what it means. Something tells me that in signature unification, "undef" means "this has to be undef", much like "1" means "this has to be 1". In Perl6 we currently have at least tw oways to say "don't care": In a regex, we say /./ to match anything; in a type signature, we use "Any" to mean that we don't care what the type is. I don't think we need another way to say "don't care". In fact, we could unify things: rules: // matches anything (/./ is shorthand synonym) binding: ($a, Any, $b) := (1,2,3); I'll admit that "Any" doesn't immediately shout "skip", but it would really be the fact that there's no variable associated with it that means "skip", If we'd wanted to skip an integer, we could say: ($a, Int, $b) := (1,2,3); Why would Perl need to add "_" as a synonym for "Any"? It's only a couple of characters shorter! The argument for /./ being a synonym in rexen is easier to make: it's common, it's legacy, and it's 4 chars shorter.
Look-ahead arguments in for loops
Imagine you're writing an implementation of the unix "uniq" function:
my $prev;
for grep {defined} @in -> $x {
print $x unless defined $prev && $x eq $prev;
$prev = $x;
}
This feels clumsy. $prev seems to get in the way of what I'm trying to
say. Could we imbue optional binding with the semantics of not being
consumed?
for grep {defined} @in -> $item, ?$next {
print $item unless defined $next && $item eq $next;
}
The same behavior, but without the variable outside the loop scope.
It would also be good not to overload the meaning of $?next to also tell
us if we're at the end of the loop. In addition to FIRST{} and LAST{}
blocks, could we have some implicit lexicals:
for @in -> $item, ?$next {
print $item if $?LAST || $item ne $next
}
Re: Look-ahead arguments in for loops
Damian Conway wrote:
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
There's nothing particularly wrong with it -- just as ther's nothing
particularly wrong with any number of other "we don't need this, because
we can program it" things. Perl5 had many other these: "we don't need a
switch statement", "we don't need function signatures", etc.
My original idea, not consuming optional bindings, is barely a new
feature: just a clarification of the rules in a corner-case of the
language. Others took the idea and ran with it and added the bells as
whistles. I guess the best alternative is to say that optional bindings
aren't allowed in this context -- that leaves the issue open for Perl
6.1 (or a module).
Re: Exceptuations
Luke Palmer wrote:
Of course, exactly how this "public interface" is declared is quite undefined.
Reading this thread, I find myself wondering how a resumable exception
differs from a dynamically scropted function. Imagine this code:
sub FileNotWriteable( Str $filename ) {
die "can't write file: $filename";
}
sub write_file (Str $filename) {
FileNotWriteable($filename) unless -w $filename;
...
}
sub my_program {
temp sub FileNotWriteable( Str $filename ) {
return if chmod "+w", $filename;
OUTER::FileNotWriteable( $filename );
}
...
write_file("foo.txt");
...
}
Ignoring syntactic sugar, what semantics does exception handling have
that a dynamically scoped function does not?
In the case of non-resumable exceptions, we see things like deferred
handling -- the exception is passed as a property of an undef value. I
assume such an exception cannot be resumed, so it does appear to me that
there are fundamental differences between resumable things, and
non-resumable, deferrable, exceptions. What is the benefit of unifying
them under a common syntax (CATCH blocks)?
Larry suggested that the exception mechanism might be a way of unifying
errors and warnings; but perhaps the opposite is true. Perhaps what we
see is a needed to generalize the distinction between warnigns and errors.
Dave.
Re: zip: stop when and where?
Luke Palmer wrote:
zip :: [a] -> [b] -> [(a,b)]
It *has* to stop at the shortest one, because it has no idea how to
create a "b" unless I tell it one. If it took the longest, the
signature would have looked like:
zip :: [a] -> [b] -> [(Maybe a, Maybe b)]
Anyway, that's just more of the usual Haskell praise.
Given that my idea about using optional binding for look-ahead didn't
fly, maybe it would work here, instead:
@a Y @b -> $a, $b { ... } # stop at end of shortest
@a Y @b -> $a, ?$b { ... } # keep going until @a is exhaused
@a Y @b -> ?$a, ?$b { ... } # keep going until both are exhaused
I think we still need a way to determine if an optional arg is bound.
Can the C function be used for that ("if exists $b {...}")?
Dave.
$value but lexically ...
C properties get attached to a value, and are available when the
value is passed to other functions/ etc. I would like to be able to
define a property of a value that is trapped in the lexical scope where
it is defined. The example that set me thinking down this path is
sub foo( $a, ?$b = rand but :is_default )
{
...
bar($a,$b);
}
sub bar( $a, ?$b = rand but :is_default )
{
warn "defaulting \$b = $b" if $b.is_default;
...
}
It would be unfortunate if the "is_default" property attached in &foo
triggers the warning in &bar. So I'd like to say somthing like
sub foo( $a, ?$b = 0 but lexically :is_default ) {...}
or
sub foo( $a, ?$b = 0 but locally :is_default ) {...}
to specify that I don't want the property to the propagated.
