Nat observed:
> Moving things to modules (a) does little for the size of Perl, and (b)
> promotes Pythonization of the language (i.e., all programs begin with
> 20 lines of `load this module, load that module, load the other
> module'). Your criteria for moving to a module can't simp
On Tue, 1 Aug 2000, Tom Christiansen wrote:
> >3. It no longer has a unix specific flavour (PS I am not anti-unix in any
> >sense) so Mac, VMS and Windows users feel less confused.
>
> Did it get decided that we were *supposed* to make Unix and C programmers
> feel more confused and less at home
J. David Blackstone said:
> Prior to version 5, all implementations of Perl were designed with
> only dynamic variables in mind. Perl5 provided lexical variables in a
> backward compatible way. Perl6 should make lexical variables the default.
> ...
That's certainly a nice idea. However, a lot of
On Tue, Aug 01, 2000 at 09:09:09PM -0500, J. David Blackstone wrote:
>
> I suppose the suggestion I made about stripping out every system
> call is more along the lines of the microperl idea.
>
> How about this: perhaps we should compile a list of system calls
> that _should_ remain in the c
Hello!
I want to make do a nested hash structure, which seems like that:
my $pname = $self->{db}->{product}->offers->{ $product_id} ->
{name};
This kind of structures can be easily created by TableMap.
Problem: If any of the hash keys are undef, then perl "die"-ing with
an error:
=head1 TITLE
Higher resolution time values
=head1 VERSION
Maintainer: Gisle Aas <[EMAIL PROTECTED]>
Date: 2000-08-02
Version: 0.01
Mailing List: perl6-language
Number: TBD
=head1 ABSTRACT
All functions that return time values (seconds since epoch) should use
floating point numbers t
Randal L. Schwartz writes:
| > "Chaim" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
|
| Chaim> It's the overloading of the ',' operator.
|
| Just like the overloading of the @ARRAY_NAME operator or the
| getpwuid() operator. Perhaps you are back to merely complaining about
| all context-s
Nathan Torkington <[EMAIL PROTECTED]> writes:
> Alan Burlison writes:
> > > The ability to have strong-typing (I don't trust Junior Engineers to get it
> > > right and I don't have time to check every line of code they write)
> >
> > No. No no no no. This approach is fundamentally wrong.
>
> (
Damian Conway <[EMAIL PROTECTED]> writes:
> Peter Scott <[EMAIL PROTECTED]> (I think -- Piers) writes:
>> Though a good post condition would benefit from some sort of
>> unconditional catch of return, I suppose. Perhaps allowing
>> continue on the outer sub block...
>
> Argh, no! A g
On Wed, Aug 02, 2000 at 02:18:07PM +1000, Damian Conway wrote:
>> Though a good post condition would benefit from some sort of
>> unconditional catch of return, I suppose. Perhaps allowing
>> continue on the outer sub block...
>
> Argh, no! A good postcondition is either invisible to
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >Typeglobs != symbol tables.
>
> >You can access individual variable bits in the symbol table now without
> >using typeglobs. I don't see why that would have to change.
>
> NB: $main::{fred} does not autoviv a typeglob when used lvaluably,
> but
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> > "PC" == Piers Cawley <[EMAIL PROTECTED]> writes:
>
> >> How locked in to your brain is this lack of consistency? How un-perlish
> >> would it be to cleanup, crypto-context, or the meaning of a list in
> >> a scalar context, or ...
>
> PC> Don't
Steve Simmons <[EMAIL PROTECTED]> writes:
> For deprecation, we should have a %PERL_DEPRECATED{mod}{thing} hash as
> well. `mod' is `CORE', `FORMATS', etc, as above. A value of 0 means the
> function is actually gone, 1 means it's disappearing next major release,
> 2 mean next minor, etc. The p
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> On Tue, Aug 01, 2000 at 08:54:27PM -0400, Bryan C.Warnock wrote:
> > There should be an C pragma that gives new life and meaning to
> > void context constructs. In my case, I want it to print to the default
> > filehandle, (which is also implicit
dLux <[EMAIL PROTECTED]> writes:
> Hello!
>
> I want to make do a nested hash structure, which seems like that:
>
> my $pname = $self->{db}->{product}->offers->{ $product_id} ->
> {name};
>
> This kind of structures can be easily created by TableMap.
>
> Problem: If any of the has
So, I've been reading about the Smalltalk Refactoring Browser
http://st-www.cs.uiuc.edu/users/brant/Refactory/RefactoringBrowser.html
and found myself repeatedly thinking. "Wow, that's cool, I want one of
these for Perl".
Now, it's probably possible to build one of these for perl, though I
have t
On Tue, Aug 01, 2000 at 07:41:59PM -0700, Randal L. Schwartz wrote:
> > "Chaim" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
>
> Chaim> It's the overloading of the ',' operator.
>
> Just like the overloading of the @ARRAY_NAME operator or the
> getpwuid() operator. Perhaps you are back to m
head1 TITLE
The AUTOLOAD subroutine should be able to decline a request
=head1 VERSION
Maintainer: Leon Brocard <[EMAIL PROTECTED]>
Date: 02 Aug 2000
Version: 1
Mailing List: perl6-language
Number: ?
=head1 ABSTRACT
In Perl 5, the first AUTOLOAD subroutine found in an object's heira
Garrett Goebel <[EMAIL PROTECTED]> writes:
>Personally, I like to be able to directly access the symbol table.
I think that will be essential.
And not just the perl5 symbol table but lexicals and the "which file"
and other "methods" that B:: provide.
>It is
>nice when generating classes from
On Wed, Aug 02, 2000 at 12:10:38PM +0100, Leon Brocard wrote:
> The AUTOLOAD subroutine should be able to decline a request
Given that I just whinged about this on p5p, YES.
> =head2 $AUTOLOAD
>
> While we're at it, it may be a good idea to remove the global
> $AUTOLOAD variable and instead pas
On Tue, Aug 01, 2000 at 10:27:08PM +0300, Ariel Scolnicov wrote:
>multimap operation list-of-lists # uurgh.
This made me think of something else that came up in a discussion with Larry
after the conference.
The discussion started off with the ability to do
for ($a,$b) (@list) { ... }
hi,
Why not some sort of functionality like LISP/Prolog i.e. working with lists.
("a",@x,"b",%y) - the list
head ("a",@x,"b",%y) # "a"
head(tile("a",@x,"b",%y)) #@x
head(head(tile("a",@x,"b",%y))) #$x[0]
head(tile(tile("a",@x,"b",%y))) #"b"
if you like it then "splice" etc... ca
> "Martyn" == Martyn Pearce <[EMAIL PROTECTED]> writes:
Martyn> Possibly, although I must ask: since everything is up-for-grabs, I ask
Martyn> (without implying any feeling one-way-or-tother):
Martyn> How useful is the , operator in it's C-style statement separator, as
Martyn> opposed to list
Graham Barr <[EMAIL PROTECTED]> writes:
> On Tue, Aug 01, 2000 at 10:27:08PM +0300, Ariel Scolnicov wrote:
> >multimap operation list-of-lists # uurgh.
>
> This made me think of something else that came up in a discussion with Larry
> after the conference.
>
> The discussion started off
Thus it was written in the epistle of Jeremy Howard,
> J. David Blackstone said:
> > Prior to version 5, all implementations of Perl were designed with
> > only dynamic variables in mind. Perl5 provided lexical variables in a
> > backward compatible way. Perl6 should make lexical variables the d
On Wed, Aug 02, 2000 at 03:40:01PM +0200, Gisle Aas wrote:
> Graham Barr <[EMAIL PROTECTED]> writes:
>
> > On Tue, Aug 01, 2000 at 10:27:08PM +0300, Ariel Scolnicov wrote:
> > >multimap operation list-of-lists # uurgh.
> >
> > This made me think of something else that came up in a discus
IMHO type inference is the best way to get typing into Perl.
We don't lose any expressiveness or hurt backwards compatibility.
About the only thing we need to make visible are a few additional
pragmas to enable type inference warnings.
Steve Fink wrote:
> Types should be inferred whenever possibl
Tom Christiansen asked
> Do you really think
> =for comments
> or
> =begin comments
> ...
> =end comments
> are that bad? Sure, they have to be on statement boundaries, but
> that's more of a feature than a bug.
Hi Tom,
Do I think it is "that bad"? No. Of course not. I use it all the time. In
On Tue, 1 Aug 2000 23:43:24 -0500, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> (I, for one, support renaming local() to Something Better (if only I
> know what that was))
save() as been suggested a number of times.
/L/e/k/t/u
Okay, I'm impressed. 108 messages in my box this morning from the list. Shows spunk.
But I'm concerned. Are you getting enough sleep?
--Michael
On Tue, 1 Aug 2000 23:43:24 -0500, Jonathan Scott Duff <[EMAIL PROTECTED]>
wrote:
> (I, for one, support renaming local() to Something Better (if only I
> know what that was))
how about clone()?
/--- On Wed, Aug 02, 2000 at 12:20:14PM +0100, Piers Cawley wrote:
| > 1, $__ variable, which is the result of the last operation, e.g:
| > my $pname = $self->{db} && $__->{product} && $__->offers &&
| > $__->{
| > $product_id } && $__->{name}
| > 2, &&$ operator, which can be used like t
One argument *against* intra-token-sequence multiline comments is that they
are harder to see, and thus render readers of the code more prone to
misunderstand it. Is this worth really promoting?
The extant pod-based multiline comment solution does not suffer from this,
as it is quite easy to se
>On Tue, 1 Aug 2000 23:43:24 -0500, Jonathan Scott Duff <[EMAIL PROTECTED]>
>wrote:
>> (I, for one, support renaming local() to Something Better (if only I
>> know what that was))
>how about clone()?
I imagine that that name will be taken by something else, such as
cloned interpreters.
Anythi
John Porter wrote:
>
> Michael Mathews wrote:
> > Using a two-character syntax to start and end a multiline comment seems to
> > be a good way to satisfy both the desired similarity to "#" and the desired
> > uniqueness to avoid collision with real single-line quotes. I would suggest
> > a (# man
Tom Christiansen responded:
> One argument *against* intra-token-sequence multiline comments is that
they
> are harder to see, and thus render readers of the code more prone to
> misunderstand it. Is this worth really promoting?
> Settling on one
> pod target for multiline comments, and then
"Michael Mathews" <[EMAIL PROTECTED]> writes:
> Unlike many programming languages Perl does not currently implement true
> multiline comments. This can be confusing/tedious to programmers.
I fail to see this. What is confusing?
As has been pointed out earlier, with multi-line comments like in C
Dan Sugalski <[EMAIL PROTECTED]> writes:
> > > continuations, generators and co-routines.
>
> Could someone point me to a reference on these, please? My CS text
> collection's rather spotty and doesn't cover this stuff.
The Icon Programming Language
Ralph E. Griswold, Madge T. Gri
Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
> perl.exe + perl.dll or .../bin/perl + libperl.so
RFC: Should the perl program be called differently (e.g., perl6) to
allow sites to run 5 and 6 in parallel until their migration is
completed (if ever)?
-- Johan
Johan Vromans writes:
>Well, my editor has no problems to put #'s in front of a section of
>lines, nor to remove them.
Not every editor does this. Perl is supposed to be flexible and make things
easy. It is not more flexible nor easier to require a programmer to use a
certain type of editor.
I d
At 10:55 AM 8/2/00 -0400, Michael Mathews wrote:
>I am prone to agree with this. I would be willing to promote the requirement
>of starting and ending multiline comments on their own line. Maybe something
>like this (this will not work in Perl 5):
>
>code to execute
>=#
>some
>comments to
>ignore
On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote:
> Anything one chooses potentially conflicts with the user's namespace, but
> probably save() or temp() would be better, or even savetemp() or tempsave()
> or scopetemp().
How about deliver() or preserve()?
-Scott
--
Jonathan Sco
>Johan Vromans writes:
>>Well, my editor has no problems to put #'s in front of a section of
>>lines, nor to remove them.
>Not every editor does this. Perl is supposed to be flexible and make things
>easy. It is not more flexible nor easier to require a programmer to use a
>certain type of editor
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I think I'm missing the point. Why pull 'em out like that? Why not just put
DS> the code in the body of the sub? Though a good post condition would benefit
DS> from some sort of unconditional catch of return, I suppose. Perhaps
DS> all
>On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote:
>> Anything one chooses potentially conflicts with the user's namespace, but
>> probably save() or temp() would be better, or even savetemp() or tempsave()
>> or scopetemp().
>How about deliver() or preserve()?
I can slightly gro
On Wed, Aug 02, 2000 at 09:15:38AM -0600, Tom Christiansen wrote:
> >On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote:
> >> Anything one chooses potentially conflicts with the user's namespace, but
> >> probably save() or temp() would be better, or even savetemp() or tempsave()
> >
> "BCW" == Bryan C Warnock <[EMAIL PROTECTED]> writes:
BCW> =head1 ABSTRACT
BCW> Perl 6 should add a new pragma called C.
BCW> =head1 DESCRIPTION
BCW> There should be an C pragma that gives new life and meaning to
BCW> void context constructs. In my case, I want it to print to the default
Buddha Buck wrote:
> The one concern I would raise about this is that a common use of
multi-line
> comments is to dyke out code. As such, it is handy to have the start and
> end markers different, and allow nesting
I see your point. At the risk getting too exotic how about:
#<
> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
NW> An existing Perl 5 script:
NW>my $date = localtime();
NW> Could generate something like
NW>"Function localtime() deprecated - use date() instead"
No, deprecations just as we are coming out of the gate. What goes in
is in for the
I believe that under the current proposal, any unqualified and
hitherto undeclared variables would be implicitly declared to be
lexicals in the current scope. This is to be contrasted with the
status quo, under which such variables are implicitly dynamics in
the current package.
I am not wholly
Since perl6 will/should have a new Configure methodology[1] there
could be a registry (hate that word) of all available function
calls[2], developed during the build processes. Then the core would be
able to infer a 'use' command.
[1] Where is the perl6-configure list? Did anyone request one?
[
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Nah, if it's in for scalars it might as well be in for everything. Not that
DS> much more work to make it proper for hashes and arrays. (muddies empty list
DS> assignments for hashes since you need to track which keys are localized,
DS
=head1 TITLE
Highlander Variables
=head1 VERSION
Maintainer: Andy Wardley <[EMAIL PROTECTED]>
Date: 01 Aug 2000
Version: 1.0
Mailing List: perl6-language
Number: TBA
=head1 ABSTRACT
Perl5 supports three distinct variable types for any given variable
name corresponding to
On Wed, 2 Aug 2000, Chaim Frenkel wrote:
> If it is decided (and I hope not) that localtime and its kin are verboten,
> it should not exists _at all_ in Perl6 and any existance at all would be
> only as a support module for Perl5 backward compatiblity.
Well we should still have POSIX::localtime
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
GB> On Tue, Aug 01, 2000 at 07:41:59PM -0700, Randal L. Schwartz wrote:
>> > "Chaim" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
>>
Chaim> It's the overloading of the ',' operator.
>>
>> Just like the overloading of the @ARRAY_NAME oper
If don't think multiline comments are worthwhile, then we should leave it
out. But I don't see the point in arguing that a functionality should be
kept out of the language because it can be added to the Text-Editing
software!!
I am not really arguing about single-line comments anyway. We all kno
Scott wrote:
> On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote:
> > Anything one chooses potentially conflicts with the user's
> > namespace, but probably save() or temp() would be better,
> > or even savetemp() or tempsave() or scopetemp().
>
> How about deliver() or preserve
On Wed, Aug 02, 2000 at 11:37:06AM -0400, Andy Dougherty wrote:
> On Wed, 2 Aug 2000, Chaim Frenkel wrote:
>
> > If it is decided (and I hope not) that localtime and its kin are verboten,
> > it should not exists _at all_ in Perl6 and any existance at all would be
> > only as a support module for
On Wed, Aug 02, 2000 at 09:26:42AM -0600, Tom Christiansen wrote:
> I believe that under the current proposal, any unqualified and
> hitherto undeclared variables would be implicitly declared to be
> lexicals in the current scope. This is to be contrasted with the
> status quo, under which such v
>> Well we should still have POSIX::localtime().
>True, and hopefully in a more optimal form.
Were you planning on updating the Standard? :-)
--tom
On 2 Aug 2000, Gisle Aas wrote:
> =head1 PERL5 PORTABILITY
>
> Calls to time() could be transformed to int(time()) when converting
> perl5 programs to perl6.
Unless there's a:
use HiRes::Time qw(time);
in effect!
-sam
> How about contain() or detach() or revalue()?
I might just throw out that the operator "let" does the job in Lisp.
> Also, how about renaming my() to local()? Will this be too confusing?
I feel strongly that "my" and "our" should both be renamed,
as well as "local".
--
John Porter
On Wed, 2 Aug 2000, Ala Qumsieh wrote:
> Also, how about renaming my() to local()? Will this be too confusing?
Yes, that would be too confusing.
-sam
> "Chaim" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
GB> On Tue, Aug 01, 2000 at 07:41:59PM -0700, Randal L. Schwartz wrote:
>>> > "Chaim" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
>>>
Chaim> It's the overloading of the ',' opera
On Wed, Aug 02, 2000 at 09:41:06AM -0600, Tom Christiansen wrote:
> >> Well we should still have POSIX::localtime().
>
> >True, and hopefully in a more optimal form.
>
> Were you planning on updating the Standard? :-)
Sure, everything is up for grabs right :)
Actually I meant the way the POSI
On Wed, Aug 02, 2000 at 11:50:10AM -0400, Sam Tregar wrote:
> On 2 Aug 2000, Gisle Aas wrote:
>
> > =head1 PERL5 PORTABILITY
> >
> > Calls to time() could be transformed to int(time()) when converting
> > perl5 programs to perl6.
>
> Unless there's a:
>
>use HiRes::Time qw(time);
>
> in e
>I feel strongly that "my" and "our" should both be renamed,
>as well as "local".
What then do you propose? my() and our() were chosen for their brevity.
I might suggest that one look to Python's use of locals() and
globals(). Currently, globals() is something like keys %{ __PACKAGE__
. "::"},
Tom Christiansen wrote:
> >I feel strongly that "my" and "our" should both be renamed,
> >as well as "local".
>
> What then do you propose? my() and our() were chosen for their brevity.
Well, "var" is pretty short. And perhaps globals could be declared
with something like "var global". Extra
> "RLS" == Randal L Schwartz <[EMAIL PROTECTED]> writes:
> "Chaim" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
Chaim> It's the overloading of the ',' operator.
RLS> Just like the overloading of the @ARRAY_NAME operator or the
RLS> getpwuid() operator. Perhaps you are back to merely com
On Wed, Aug 02, 2000 at 08:45:05AM -0700, Randal L. Schwartz wrote:
> You need a list vs. array distinction. An operator can't return an
> array. It can only return a list. Unless you're inventing a
> different language. :)
You say "operator" and you are right. I think the issue is a sub
can
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 10:42 PM 8/1/00 -0400, Chaim Frenkel wrote:
>> We may need that all variables are by default lexical.
>>
>> Without the explicit declaration of cross-thread visible variables, doing
>> threading may well be difficult (on one's fingers
>Tom Christiansen wrote:
>> >I feel strongly that "my" and "our" should both be renamed,
>> >as well as "local".
>>
>> What then do you propose? my() and our() were chosen for their brevity.
>Well, "var" is pretty short. And perhaps globals could be declared
>with something like "var global".
Thus it was written in the epistle of Michael Mathews,
> If don't think multiline comments are worthwhile, then we should leave it
> out. But I don't see the point in arguing that a functionality should be
> kept out of the language because it can be added to the Text-Editing
> software!!
Agreed
>Please explain what the utility of having unshared variables? I might
>as well just fork().
The only sane situation is to have safety by default. Things should not
be shared unless you say they are.
--tom
On Wed, 2 Aug 2000 16:32:40 +0100 (BST), Andy Wardley <[EMAIL PROTECTED]> wrote:
>
> =head1 TITLE
>
> Highlander Variables
>
> =head1 VERSION
>
> Maintainer: Andy Wardley <[EMAIL PROTECTED]>
> Date: 01 Aug 2000
> Version: 1.0
> Mailing List: perl6-language
> Number: TBA
>
Graham Barr wrote:
> > > But then went onto interators and something like
> > >
> > > @list = interleave(@a,@b,@c);
> > >
> > > which would interleave the lists given, and
> > >
> > > foreach ($a,$b,$c) (interleave(@a,@b,@c))
sub interleave(\@;\@\@\@\@\@\@\@\@) {
my $m = -1;
for
At 10:30 AM 8/2/00 -0400, Michael Mathews wrote:
>Okay, I'm impressed. 108 messages in my box this morning from the list.
>Shows spunk.
>
>But I'm concerned. Are you getting enough sleep?
Of course not. :)
Don't forget we've folks from England, North America, and Japan (that I
know of, and I o
Tom Christiansen wrote:
>
> >Well, "var" is pretty short. And perhaps globals could be declared
> >with something like "var global". Extra verbosity required for globals
> >might be A Good Thing.
>
> But "var" is redundant: that's what the $ is for.
They're not semantically identical. "var"
On Wed, Aug 02, 2000 at 06:15:48PM +0200, H.Merijn Brand wrote:
> If I could, I would VETO!
>
> This would break about 90% of my scripts. I use the same name for different
> type of variables to group them:
Why ? Remember there will (hopefully) be translation from perl5->perl6
so this could pote
On Wed, 2 Aug 2000 08:14:22 +0100 (BST), Matt Sergeant wrote:
>I used to be a C programmer myself (well OK, I was a C++ programmer...),
>but I'd rather any day type "localtime->year" than "(localtime)[5]".
And what would you type instead of
(localtime)[3, 4, 5]
? localtime->(day, mont
H.Merijn Brand wrote:
>
> If I could, I would VETO!
If I could, I would mandate this change. This is definitely in my
Top 10 List of Perl 5 Suckinesses.
> This would break about 90% of my scripts.
Some large percentage of your scripts is going to break anyway.
> I use the same name for dif
On Wed, Aug 02, 2000 at 12:22:10PM -0400, John Porter wrote:
> I guess my question is, why do these need to be builtins?
They don't. But that does not mean they should not be considered.
> There is no limit to the funky algorithms one can come up with;
> not everyting should go in the core.
Tru
On Wed, Aug 02, 2000 at 12:07:31PM -0400, Dan Sugalski wrote:
> At 10:30 AM 8/2/00 -0400, Michael Mathews wrote:
> >Okay, I'm impressed. 108 messages in my box this morning from the list.
> >Shows spunk.
> >
> >But I'm concerned. Are you getting enough sleep?
>
> Of course not. :)
>
> Don't for
> "Graham" == Graham Barr <[EMAIL PROTECTED]> writes:
Graham> You say "operator" and you are right. I think the issue is a sub
Graham> can return either.
Really? How does a sub return "an array"?
(Unless you're about to mutter something about "lvalue subs" :) a sub
can return only an rvalu
>sub mapf(&;\@\@\@\@\@\@\@\@\@) {
Steal from lisp:
map
maap
maaap
mapp
mappp
maappp
...
:-)
--tom
> "John" == John Porter <[EMAIL PROTECTED]> writes:
John> Imho, this is A Bad Practice. Making it impossible would therefore
John> be Good, existing-script-breakage not withstanding.
So you'll break $ARGV and @ARGV? Is that really OK?
And will you extend this to ensuring that scalars, ar
On Wed, Aug 02, 2000 at 09:42:09AM -0700, Randal L. Schwartz wrote:
> > "Graham" == Graham Barr <[EMAIL PROTECTED]> writes:
>
> Graham> You say "operator" and you are right. I think the issue is a sub
> Graham> can return either.
>
> Really? How does a sub return "an array"?
There is a dif
On Wed, Aug 02, 2000 at 10:43:37AM -0600, Tom Christiansen wrote:
> >sub mapf(&;\@\@\@\@\@\@\@\@\@) {
>
> Steal from lisp:
>
> map
> maap
> maaap
> mapp
> mappp
> maappp
dwim
:)
Graham.
Buddha Buck wrote:
>
> The one concern I would raise about this is that a common use of multi-line
> comments is to dyke out code. As such, it is handy to have the start and
> end markers different, and allow nesting.
It nice to be able to bounce on % in vi, too:
=#{
comment
=#}
--
John
> "Graham" == Graham Barr <[EMAIL PROTECTED]> writes:
Graham> There is a difference
Graham> sub abc { return (7,8,9) }
That's returning either a list or a comma operator result, depending
on context.
Graham> sub def { my @a = (9,8,7); return @a; }
That's not returning the array. That's r
Michael Mathews wrote:
>
> At the risk getting too exotic how about:
>
> #< some
> comments
> EOC
Just introduce a new function which is a bit bucket:
# works in perl5.
sub comment(@) { }
comment q{ comments... };
comment <
Graham Barr <[EMAIL PROTECTED]> writes:
> Well theres a difference there when you look at the op tree. That is a call
> to a sub, whereas otherwise it is a op.
Isn't that an internals issue?
-- Johan
> The existing pack and unpack methods are dependent upon a
> simple yet complex 'format' structure, which is often
>difficult to get right, and which carries no information
> regarding the associated variable names.
I know what you mean, but it reads like "black yet whi
Um, yeah it can. It's by no means a certinty, but it most emphaticly can.
A lanaugge that provides only a few rigid means to accomplish most tasks
teaches it desciples to think linearly.
A language which offers flexability and accomidates (dare I say) artistry
teaches it's programers to apreci
>It nice to be able to bounce on % in vi, too:
>=#{
>comment
>=#}
You easy to do this already:
=begin comment {
=end comment }
--tom
On Wed, 2 Aug 2000 12:29:41 -0400, John Porter <[EMAIL PROTECTED]> wrote:
> H.Merijn Brand wrote:
> >
> > If I could, I would VETO!
>
> If I could, I would mandate this change. This is definitely in my
> Top 10 List of Perl 5 Suckinesses.
So here we differ. That's what discussions are for.
>
Randal L. Schwartz wrote:
> John> Imho, this is A Bad Practice. Making it impossible would therefore
> John> be Good, existing-script-breakage not withstanding.
>
> So you'll break $ARGV and @ARGV? Is that really OK?
Yep.
> And will you extend this to ensuring that scalars, arrays, hashes,
Tom Christiansen wrote:
>
> >sub mapf(&;\@\@\@\@\@\@\@\@\@) {
>
> Steal from lisp:
>
> map
> maap
> maaap
> mapp
> mappp
> maappp
> ...
Should be feasible with an AUTOLOAD that takes a certain kind of regular
expression...
sub AUTOLOAD /^ma+p+$/ {
}
Some for the '
Bennett Todd wrote:
>
> (Migrated from bootstrap)
>
> 2000-07-24-10:17:54 Dan Sugalski:
> > Perl 6 will most *definitely* be an embedded perl. Easy and clean
> > embedding is one of my primary goals. A small core with extended
> > functionality provided by non-core things is a secondary one. (An
On Wed, 2 Aug 2000 13:03:51 -0400, John Porter <[EMAIL PROTECTED]> wrote:
> Randal L. Schwartz wrote:
> :
> > I don't see a teaching advantage in saying "the three variable
> > namespaces are all one, but all the other namespaces are distinct".
> > When the rule gets longer, it gets harder to teac
1 - 100 of 294 matches
Mail list logo
