J. David Blackstone writes:
> Re: #1, above, I'd go so far as to suggest that nearly every system
> call in Perl (along with just about every punctuation variable) should
> find itself in a module and only in a module.
(nat as nat)
I'd like to suggest that Pascal is a language to *avoid* emula
<[EMAIL PROTECTED]>, aka Skud, aka Kirrily Robert, will be the
chair for the language working group. Her job is to make sure
you all produce lots of RFCs. Many thanks, Kirrily, for taking
on this, uh, "rewarding" task. :-)
WORKING GROUP: perl6-language
CHAIR: Kirrily Robert
DEADLINE: 13 O
On Tue, Aug 01, 2000 at 12:27:56PM -0400, Chaim Frenkel wrote:
>
>(Kirrily, this one is for the record.)
>
>I'd also like to add, redo, next, last escaping a subroutine.
Can you please give me more detail on that? An RFC would be ideal :)
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://
Jeremy Howard wrote:
> > > > @foo = @bar x 3;
> > > > @foo = @bar * 4;
> > > > @LoL = @foo * @bar;
> > > > @baz =~ s/here/there/;
> Exactly. Currently PDL provides a lot of the numeric side of this, but
> wouldn't it be nice if perl 6 had the hooks in place to allow PDL to
> integrate ev
Thus it was written in the epistle of Matthew Persico,
> Johan Vromans wrote:
> >
> > On Mon, Jul 31, 2000 at 09:50:11PM -0600, Nathan Torkington wrote:
> > > So Larry is doing most of the evaluation for us. He's the one who
> > > gave us the good things in the Perl language we have now. He'll
On Tue, 01 Aug 2000, Dan Sugalski wrote:
> At 02:18 PM 8/2/00 +1000, Damian Conway wrote:
> >According to the latest TPJ, he's "the Mad Scientist of Perl".
> >Clearly a trouble-maker of the worse kind!
>
> The fiend! We shall have to deal with him straightaway. Time to dispatch
> the Perl Police!
On Tue, Aug 01, 2000 at 09:13:44PM -0500, J. David Blackstone wrote:
> Creating an all new function is a very good idea, I think. The
> whole function "localtime" should just plain go away.
Also remember that localtime() is intimately tied to gmtime(), and
timelocal(), timegm() of Time::Local.
At 02:18 PM 8/2/00 +1000, Damian Conway wrote:
>> >PS> Perhaps the best of both worlds would be
>> >PS> design-by-contract? A la Conway?
>> >
>> >Conway? Who's Conway?
>>
>> Dunno. He had some sort of thing a few weeks ago. The Public Conway
> 4.0 or
>> something, I th
On Tue, Aug 01, 2000 at 11:02:01PM -0500, J. David Blackstone wrote:
> The C operator should be retained due to its usefulness for
> dynamic scoping, but should be renamed to avoid confusion. I'm
> currently suggesting a name of C. More euphonious
> suggestions are requested.
This should probab
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, I might add.)
Well, one of the rumors bandied about wa
At 01:02 PM 8/2/00 +0900, Simon Cozens wrote:
>On Tue, Aug 01, 2000 at 11:37:49PM -0400, Dan Sugalski wrote:
> > Right. That was my point. (The original poster wanted to pull IO out of
> the
> > core entirely)
>
>Ah. Barbarians-at-gates approach, then.
Damn straight. Dump the boiling oil! :)
>O
> >PS> Perhaps the best of both worlds would be
> >PS> design-by-contract? A la Conway?
> >
> >Conway? Who's Conway?
>
> Dunno. He had some sort of thing a few weeks ago. The Public Conway 4.0 or
> something, I think it was. :)
According to the latest TPJ, he's "the Mad Sci
On Tue, Aug 01, 2000 at 11:37:49PM -0400, Dan Sugalski wrote:
> Right. That was my point. (The original poster wanted to pull IO out of the
> core entirely)
Ah. Barbarians-at-gates approach, then. On the other hand, there is
a lot of rubbish that *can* go out of core; I'd like to see core being
The following RFC reflects an assumption I've been making about
where Perl6 will go. Feel free to shoot it down, if I'm the only who
feels this way. :)
=head1 TITLE
Lexical variables made default
=head1 VERSION
Maintainer: J. David Blackstone <[EMAIL PROTECTED]>
Date: 1 August 2000
Versi
At 10:53 PM 8/1/00 -0400, Chaim Frenkel wrote:
>What do things that are moving out of the executable to auto loaded
>space be called?
>
> perl near core?
>
>"We've got insertion. Formats have entered near-core space..."
I've been thinking of 'em as "opcode wannabes", but I like yours bett
At 11:08 PM 8/1/00 -0400, Chaim Frenkel wrote:
> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>PS> Perhaps the best of both worlds would be design-by-contract? A la Conway?
>
>Conway? Who's Conway?
Dunno. He had some sort of thing a few weeks ago. The Public Conway 4.0 or
something,
At 06:47 PM 8/1/00 -0700, Nathan Wiger wrote:
>Now *that's* an advantage I like! Being able to turn on certain warnings
>just for certain packages (rather than just a global all-or-nothing $^W)
>would be really cool.
Like, like... Lexical Warnings! Now *that* would be a keen idea! :)
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)
The two things are orthogonal. Threading doesn't place any sort o
At 12:24 PM 8/2/00 +0900, Simon Cozens wrote:
>On Tue, Aug 01, 2000 at 11:01:14PM -0400, Dan Sugalski wrote:
> > Right, I know the underside will be yanked and redone. (Hopefully with
> > async support on platforms that have it to do some I/O and processing
> > overlap) It's not getting removed fr
On Tue, Aug 01, 2000 at 11:01:14PM -0400, Dan Sugalski wrote:
> Right, I know the underside will be yanked and redone. (Hopefully with
> async support on platforms that have it to do some I/O and processing
> overlap) It's not getting removed from the core language from a perl
> programmer stan
At 11:08 PM 8/1/00 -0400, Chaim Frenkel wrote:
> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>PS> Perhaps the best of both worlds would be design-by-contract? A la Conway?
>
>Conway? Who's Conway?
http://www.csse.monash.edu.au/~damian/TPC/2000/Contract/paper.html
--
Peter Scott
Paci
At 10:45 PM 8/1/00 -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> I'd rather not do it for globals, though. (Actually I'd be just as
>happy to
>DS> see local go missing entirely, but that's just me looking at the guts...)
>
>But local() is so useful. A
At 11:04 AM 8/2/00 +0900, Simon Cozens wrote:
>On Tue, Aug 01, 2000 at 09:39:28PM -0400, Dan Sugalski wrote:
> > I like perl's smart built-in IO just fine, thanks. :) Don't mind making it
> > better, but I do mind making it optional.
>
>If we're going to do line disciplines, we need a built-in std
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> Perhaps the best of both worlds would be design-by-contract? A la Conway?
Conway? Who's Conway?
Anyway, the design by contract might be interesting...
(I wonder if internals should require it. (Dan are you listening.))
And how would
At 09:39 PM 8/1/00 -0400, Bryan C. Warnock wrote:
>On Tue, 01 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 Un
What do things that are moving out of the executable to auto loaded
space be called?
perl near core?
"We've got insertion. Formats have entered near-core space..."
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> I assume 'core perl engine' i.e. /usr/bin/perl or perl.e
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I'd rather not do it for globals, though. (Actually I'd be just as happy to
DS> see local go missing entirely, but that's just me looking at the guts...)
But local() is so useful. A nice anonymous place to store a value and have
it rest
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)
> "PC" == Piers Cawley <[EMAIL PROTECTED]> writes:
>> * no need to declare variables: I think variables shoul
> At 09:38 AM 8/2/00 +1000, Jeremy Howard wrote:
> >Dan Sugalski wrote:
> > > I've been thinking that it'd be nice to support extended array/list
stuff
> > > to allow the rudiments of matrix operations into perl:
> > >
> > > @foo = @bar x 3;
> > > @foo = @bar * 4;
> > > @LoL = @foo * @bar;
>
> "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-sensitive things again. :-)
--
Randal L. S
> "BC" == Brust, Corwin <[EMAIL PROTECTED]> writes:
BC> But is this useful?
BC> sub baz { return ( 'one','two' ) }
BC> my ($foo, $bar) = &baz; # $foo == 'one', $bar == 'two'
Certainly.
I just don't like the fact that the runtime scalar context is having
a compile time semantic effect.
It'
Nick Ing-Simmons wrote:
>
> Buddha Buck <[EMAIL PROTECTED]> writes:
> >I haven't looked at the internals for local, but isn't:
> >
> >{
> > local $foo;
> >
> > ...
> >}
> >
> >effectively syntactic sugar for:
> >
> >{
> > my $unnamed_foo = $foo; # $unnamed_foo not accessible
> >
> > .
On Tue, Aug 01, 2000 at 03:04:27PM -0600, Nathan Torkington wrote:
> Piers Cawley writes:
> > > Iterators
> > Doable in perl5 already.
> > > Reduce (e.g. $x = reduce { sum } @list;
> > Doable in perl5
> > > Case/Switch
> > Why? And Damian's already proved it can be done.
>
> Perl's
On Tue, 01 Aug 2000, J. David Blackstone wrote:
> How about this: perhaps we should compile a list of system calls
> that _should_ remain in the core language. I think it will probably
> be very small.
I would suspect no more than the ones that perl needs internally for
itself, excluding, of
May I offer an alternative. Why do an interpreter?
I remember reading good things about Threaded Interpreters
(e.g. Forth) So why not do a TIL? Compile it to machine calls/jumps.
Should be much faster than the inner run loop.
This would fit in with Dan and Nick's keep it in cache.
So there cou
Nathan Wiger wrote:
>
> > C is, at times, less than logical. Witness the localtime fun: some of it's
> > zero-based, some of it's one-based, and some of it's -1900-based. All from the
> > same function. The localtime concept is needed, the localtime brain damage is
> > really not.
>
> I agree co
> > I disagree with keeping the same name as a Unix function, but having a
> > radically different calling sequence or return value. If you want a
> > new interface, *name* a new interface.
>
> Amen!
Agreed, completely. I posted a follow-up under "Re: date interface" that
some might be interest
Dan Sugalski wrote:
> >Languages like C and
> >Pascal even go so far as to make I/O an "option" that you have to
> >#include (or whatever, depending on the language; Pascal makes you
> >specify it explicitly in some way I don't quite remember), and they
> >seem to do fine.
>
> For some pretty pat
On Tue, Aug 01, 2000 at 09:39:28PM -0400, Dan Sugalski wrote:
> I like perl's smart built-in IO just fine, thanks. :) Don't mind making it
> better, but I do mind making it optional.
If we're going to do line disciplines, we need a built-in stdio replacement.
Full ground-up rewrite, like sfio bu
> C is, at times, less than logical. Witness the localtime fun: some of it's
> zero-based, some of it's one-based, and some of it's -1900-based. All from the
> same function. The localtime concept is needed, the localtime brain damage is
> really not.
I agree completely. I take issue with changin
At 09:12 PM 8/1/00 -0400, Bryan C. Warnock wrote:
>On Tue, 01 Aug 2000, Matthew Cline wrote:
>
> > Doesn't tying slow things down? If you did compile time type
> > checking, this would take no perfromance hit. Also you could, say,
> > add some opcodes for doing runtime checking, so that runtime
Alan Burlison wrote:
>
> Steve Simmons wrote:
>
> > I'd prefer that we break these vars out into a set of hashes with
> > appropriate names:
> >
> > $PERL_CORE{warnings} vs $^W
> > $PERL_CORE{version} vs $^V
> > $PERL_FORMATS{name} vs $^
> > $P
On Tue, 01 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
At 05:51 PM 8/1/00 -0600, 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 ho
At 06:59 PM 8/1/00 -0500, J. David Blackstone wrote:
> I'm presuming we can count on really fast methods to be one of the
>goals of the internals group. Perl is where I learned O-O
>(discovering wasn't just a useless buzzword), and I'd like to see
>Perl6 make O-O much more natural, without forc
At 09:38 AM 8/2/00 +1000, Jeremy Howard wrote:
>Dan Sugalski wrote:
> > I've been thinking that it'd be nice to support extended array/list stuff
> > to allow the rudiments of matrix operations into perl:
> >
> > @foo = @bar x 3;
> > @foo = @bar * 4;
> > @LoL = @foo * @bar;
> > @baz =~ s/h
At 05:19 PM 8/1/00 -0600, Tom Christiansen wrote:
> >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 *
Johan Vromans wrote:
>
> On Mon, Jul 31, 2000 at 09:50:11PM -0600, Nathan Torkington wrote:
> > So Larry is doing most of the evaluation for us. He's the one who
> > gave us the good things in the Perl language we have now. He'll be
> > the one vetoing the ridiculous ideas.
>
> Larry said: "Pe
On Tue, 01 Aug 2000, Matthew Cline wrote:
> Doesn't tying slow things down? If you did compile time type
> checking, this would take no perfromance hit. Also you could, say,
> add some opcodes for doing runtime checking, so that runtime
> checking would be faster than doing it with tying, but w
On Tue, 01 Aug 2000, Simon Cozens wrote:
> On Tue, Aug 01, 2000 at 03:07:36PM -0600, Nathan Torkington wrote:
> > I disagree. If there was a bsdm.pm or -B option that gave strong type
> > checking, then many would be happy.
>
> You can do this with attributes and tying.
Doesn't tying slow things
On Tue, 01 Aug 2000, Dan Sugalski wrote:
> At 11:57 PM 7/31/00 -0700, Matthew Cline wrote:
> >Something else which might be useful for tainting would be something like:
> >
> > taint_var($foo);
> > no_taint_var($bar);
> >
> >With this, any value assigned to $foo would become tainted, and a
The librarian address doesn't seem to be working, so I'm injecting this
here.
=head1 TITLE
Request For New Pragma: Implicit
=head1 VERSION
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Date: 01 Aug 2000
Version: 1
Mailing List: perl6-language
Number: TBD
=head1 ABSTRACT
On Tue, Aug 01, 2000 at 10:27:18PM +0100, Alan Burlison wrote:
> Michael Fowler wrote:
>
> > use typing qw(very-strict);
> >
> > my integer $foo : very-strict = 4;
> >
> > Which would enforce that you can only assign integer constants to $foo
> > (which are seen at compile-time), or oth
On Tue, Aug 01, 2000 at 05:31:56PM -0600, Tom Christiansen wrote:
> >Several people have suggested strong typing as a feature, and have been shot
> >down one by one. However, I think it can be done without forcing it on
> >everyone.
>
> Can it? Are you prepared to make everyone declare the full
> "Christopher" == Christopher K Oei <[EMAIL PROTECTED]> writes:
>> This brings back an idea I had a while ago. How about defining a module,
>> that could be part of the standard distribution, that offered those
>> shortcuts. So newbies could do something like
>>
>> use newbie;
>> or
>> use
> "Damian" == Damian Conway <[EMAIL PROTECTED]> writes:
Damian> There's a protoype implementation available as part of the
Damian> switch.pm module, which will hit the CPAN some time this week
Damian> (assuming I don't actually *die* of jet-lag :-)
Not to be morbid, but you do have the code
> "Alan" == Alan Burlison <[EMAIL PROTECTED]> writes:
Alan> Graham Barr wrote:
>> > Reduce (e.g. $x = reduce { sum } @list;
Alan> Is it sufficiently more useful than:
Alan>$x = 0; map $x += $_, @list;
As long as you write that as:
$x = 0; $x += $_ for @list;
su
> "Ariel" == Ariel Scolnicov <[EMAIL PROTECTED]> writes:
Ariel> reduce needs to be able to take an (optional?) "distinguished element"
Ariel> to start from. Consider this:
Ariel>reduce sum () == 0
Ariel>reduce times () == 1
Ariel>reduce catenate () == ''
Ariel> Where do we get
=head1 TITLE
messages.rfc - An RFC to discussing the wisdom of allowing run time error
and warning messages to be modified at run time
=head1 VERSION
Maintainer: Corwin Brust <[EMAIL PROTECTED]>
Date: 1 Aug 2000
Version: 1
Mailing List: perl6-language
Number: ???
=head1 ABS
> "Chaim" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
> "CF" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
CF> (Kirrily, this one is for the record.)
CF> I'd also like to add, redo, next, last escaping a subroutine.
Chaim> Make that _NOT_ escaping a subroutine.
Chaim> map { ...; last
> "Chaim" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
Chaim> I don't find this meaningful:
Chaim> sub foo() { return (1,7) }
Chaim> $x = &foo();# $x == 7;
I do. It's perfectly consistent.
$x = SUBROUTINE CALL
...
SUBROUTINE CALL = (1,7)
You just factor out the subro
Tom Christiansen wrote:
>
> >Several people have suggested strong typing as a feature, and have been shot
> >down one by one. However, I think it can be done without forcing it on
> >everyone.
>
> Can it? Are you prepared to make everyone declare the full, formal, and
> fancy types for the ret
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 with Perl?
>
> -
Re: the Time::Object module, Tim Jenness wrote:
> Sounds good since:
>
> 1. It removes unnecesary core functionality to a loadable module
>
> 2. Can be retrofitted to perl5 code fairly easily (essentially as easy as
> exporting a backwards compatible localtime() function).
>
> 3. It no longer h
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
On Tue, Aug 01, 2000 at 05:51:29PM -0600, 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 conf
>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 with Perl?
--tom
On Wed, 2 Aug 2000, Jeremy Howard wrote:
> Dan Sugalski wrote:
> > I've been thinking that it'd be nice to support extended array/list stuff
> > to allow the rudiments of matrix operations into perl:
> >
> > @foo = @bar x 3;
> > @foo = @bar * 4;
> > @LoL = @foo * @bar;
> > @baz =~ s/here/
On Tue, 1 Aug 2000, J. David Blackstone wrote:
> Moving from bootstrap to perl6-language ...
>
> In response to [EMAIL PROTECTED]'s requirements document, Hildo
> Biersma wrote:
> > In issue 3.2.1 (localtime), note that the month starting at 0 is very
> > useful for arrays - which is of the cour
Dan Sugalski wrote:
> I've been thinking that it'd be nice to support extended array/list stuff
> to allow the rudiments of matrix operations into perl:
>
> @foo = @bar x 3;
> @foo = @bar * 4;
> @LoL = @foo * @bar;
> @baz =~ s/here/there/;
>
This would really fill a gap, if the speed is th
>Several people have suggested strong typing as a feature, and have been shot
>down one by one. However, I think it can be done without forcing it on
>everyone.
Can it? Are you prepared to make everyone declare the full, formal, and
fancy types for the return values of all their functions?
C
Plus you're still running à la pod mode, not à la code mode,
as mentioned on p630 of PP3. (I just looked to make sure multiline
comments were in the index. They are.)
--tom
>I apologize if this has already been gone over but I would really like to
>throw one out there: real Multi-line comments.
>This one has been bugging me for a long time. Any ideas?
>How about #/ lots of lines of code here, this is not backwards compatable,
>however /#
Do you really think
>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 *main::fred does.
--tom
Moving from bootstrap to perl6-language ...
In response to [EMAIL PROTECTED]'s requirements document, Hildo
Biersma wrote:
> In issue 3.2.1 (localtime), note that the month starting at 0 is very
> useful for arrays - which is of the course the reason it is done this
> way. I am not convinced goi
On Tue, 1 Aug 2000, John Barnette wrote:
> Michael Fowler wrote:
> > On Tue, Aug 01, 2000 at 05:28:08PM -0400, Michael Mathews wrote:
> > > Unlike many programming languages Perl does not currently implement true
> > > multiline comments. This can be confusing/tedious to programmers. This could
>
On Tue, Aug 01, 2000 at 03:07:36PM -0600, Nathan Torkington wrote:
> I disagree. If there was a bsdm.pm or -B option that gave strong type
> checking, then many would be happy.
You can do this with attributes and tying.
--
Also note that i knew _far_ more about the people that call address
mu
On Tue, 01 Aug 2000, Alan Burlison wrote:
> > Threading constructs built into the language
>
> The majority of perl programs won't be threaded - beware of making
> simple things harder.
That is, to me, a backwards way of thinking about it. Every perl
program is threaded. Most just have one th
Michael Fowler wrote:
> I'm not sure exactly what you consider to be a "true multiline comment", but
> Perl definitely has them by my definition.
>
> =pod
>
> Hi, this is a multiline comment.
>
> =cut
...and there are a lot WORSE ways to do this in current Perl:
sub multiline-comment {}
mul
To see why not, try this (because it won't work)
print "foo" =pod ."bar" =cut . "baz"
whereas in javascript this will work (prints "foobaz")
document.write("foo" /* + "bar" */ + "baz");
Also (as stated in the RFC) wouldn't adding POD "comments" all over a script
interfere with real POD (
Michael Fowler wrote:
> On Tue, Aug 01, 2000 at 05:28:08PM -0400, Michael Mathews wrote:
> > Unlike many programming languages Perl does not currently implement true
> > multiline comments. This can be confusing/tedious to programmers. This could
> > be solved by adding a syntax to Perl 6 that wou
On Tue, Aug 01, 2000 at 05:28:08PM -0400, Michael Mathews wrote:
> Unlike many programming languages Perl does not currently implement true
> multiline comments. This can be confusing/tedious to programmers. This could
> be solved by adding a syntax to Perl 6 that would allow for true multiline
>
John Porter wrote:
> qc( here's some text which will evaluate to "silent undef". );
> Could be very much like qw() ...
Cool, I like the perlishness of your proposal. But not so sure about "qc".
Would this be a function? Why would it be a function? What would qc imply,
"quote comment"? This is co
=head1 TITLE
type inference
=head1 VERSION
Maintainer: Steve Fink <[EMAIL PROTECTED]>
Date: 1 Aug 2000
Version: 0 (unreleased)
Mailing List: [EMAIL PROTECTED]
Number: (unassigned)
=head1 ABSTRACT
Types should be inferred whenever possible, and optional type qualifiers
may be used to
On Tue, 1 Aug 2000, Tony Payne wrote:
>
> > Isn't this almost a case for revamping the prototyping system? You can
> > define your API in terms the current perl variables (nothing in the above
> > suggests that integers versus floats is the main problem) and have a
> > prototype system that actu
At 09:25 PM 8/1/00 +, Nick Ing-Simmons wrote:
>Alan Burlison <[EMAIL PROTECTED]> writes:
> >
> >No, I disagree. Perl gains a lot of its expressive power from being lax
> >about typing. I suspect it will also impose an unacceptable overhed for
> >the vast majority who don't want it - at the v
At 02:31 PM 8/1/00 -0700, Tony Payne wrote:
> > No, I disagree. Perl gains a lot of its expressive power from being lax
> > about typing. I suspect it will also impose an unacceptable overhed for
> > the vast majority who don't want it - at the very least every variable
> > access will have to c
Okay, here's my first attempt at an RFC, contributing to the community,
and dredging back up my design experience after being forced to hack for
8+ years. I'm not completely familiar with POD format, so I've probably
made mistakes. I'm also not a full-blown perl or C guru, so I've
probably made
Nick Ing-Simmons wrote:
> Cross posted to internals ('cos it is...)
Be it on your head... ;-)
> We should consider using "vtables" to avoid the cost of the conditional
> branches (and running out of flag bits).
>
> Thus this function would call variables "type check" "method" -
> which for nor
On Tue, 1 Aug 2000, Tony Payne wrote:
> > No, I disagree. Perl gains a lot of its expressive power from being lax
> > about typing. I suspect it will also impose an unacceptable overhed for
> > the vast majority who don't want it - at the very least every variable
> > access will have to check
Michael Mathews wrote:
>
> =head2 Proposal
>
> 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 (# many lines
Despite my throw-it-over the transom comments on global vars, that's
not really why I came here (tho I will pitch in on the topic).
The perl features that most bites me in the ass is how module versioning
and searching works. The easiest way to describe what I want is by
examples, so here are se
> Isn't this almost a case for revamping the prototyping system? You can
> define your API in terms the current perl variables (nothing in the above
> suggests that integers versus floats is the main problem) and have a
> prototype system that actually allows you to specify that "argument 3
> sho
> No, I disagree. Perl gains a lot of its expressive power from being lax
> about typing. I suspect it will also impose an unacceptable overhed for
> the vast majority who don't want it - at the very least every variable
> access will have to check an 'are you typed' flag.
I agree that weak typ
Alan Burlison <[EMAIL PROTECTED]> writes:
>
>No, I disagree. Perl gains a lot of its expressive power from being lax
>about typing. I suspect it will also impose an unacceptable overhed for
>the vast majority who don't want it - at the very least every variable
>access will have to check an 'are
Nathan Torkington wrote:
> Perl's goal is to make easy things easy. I think case/switch is
> something that belongs in the core, not in a module. Just because
> something can be done now doesn't mean it doesn't deserve tighter
> integration in the next version of Perl, or that it can't be done
On Tue, Aug 01, 2000 at 05:23:27PM +0200, Dominic Dunlop wrote:
> At 15:19 +0100 2000-08-01, Tim Bunce wrote:
> > >RegEx (internals?)
> >
> >Yes, Yes, Yes.
>
> I could argue for regex being language too:
> If the language group is
> going to give each of perl's reserved words (and much
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
>
>LW> But yelling that formats are essential to the core reminds me of my
>LW> kids, who sometimes act as if they're being excoriated when we're
>LW> merely trying to get them out of their dirty clothe
Michael Fowler wrote:
> use typing qw(very-strict);
>
> my integer $foo : very-strict = 4;
>
> Which would enforce that you can only assign integer constants to $foo
> (which are seen at compile-time), or other similarly declared integers (or
> possibly promoted floats, chars, etc. if y
Okay, so no one seemed to be offended at my original post/suggestion -- must
mean I should try to take it a little further :)
Here's the RFC in POD even.
--Michael
=head1 TITLE
Multiline Comments for Perl.
=head1 VERSION
Maintainer: Michael J. Mathews <[EMAIL PROTECTED]>
Date: 01 Aug 20
1 - 100 of 205 matches
Mail list logo
