Re: what will be in Perl6 ?

On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote: > raptor writes: > : http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html > > That's a good summary of what we've been thinking. Here's another > article that talks about a lot of the things we *should* be thinking. > In fa

Re: RFC: variable usage warnings

Tom Christiansen wrote: > > >"symbol $main::x used only once" -> "use of uninitialized variable > >$main::x" > >"use of uninitialized value" -> "use of undefined value" > > Perhaps then > > "use of uninitialized value" -> "use of undef as discrete value" > or > "use of uninitialized val

Re: RFC: variable usage warnings

Updated RFC. --- =head1 TITLE variable usage warnings =head1 VERSION Maintainer: Steve Fink <[EMAIL PROTECTED]> for now Date: 2 Aug 2000 Version: 0.2 (unreleased) Mailing List: [EMAIL PROTECTED] Number: (unassigned) =head1 ABSTRACT "VARIABLE used only once:

Re: RFC: variable usage warnings

>. You misunderstand; I am *not* addressing the >perennial complaint that the "use of uninitialized value" doesn't >identify the source of the undefined value. Ok. >"symbol $main::x used only once" -> "use of uninitialized variable >$main::x" >"use of uninitialized value" -> "use of undefined v

Re: RFC: variable usage warnings

Tom Christiansen wrote: > > >The warning message "use of uninitialized value" should also > >disappear, to be replaced with "use of undefined value", and the > >warning for the purpose described in this RFC should be "use of > >uninitialized variable C<$x>". > > What about if there's only an exp

Re: multiline comments

>The way I see it Santa (aka Larry) has asked for our wish list. This is not >the time to dwell on all the ways we can make due with our old toys. I still think saying :10,20s/^/##XXX## / is the cleanest and most visually apparent block comment. >PS I'm all for a new list. How do I get one? I s

Re: perl 6 requirements

On Wed, Aug 02, 2000 at 08:10:01PM +0100, Alan Burlison wrote: > "Randal L. Schwartz" wrote: > > > Graham> sub def { my @a = (9,8,7); return @a; } > > > > That's not returning the array. That's returning a copy of the contents > > of @a in a list context, and the number of elements of @a in a s

Re: RFC: multiline comments

On Wed, Aug 02, 2000 at 03:00:04PM -0400, Michael Mathews wrote: > Ted Ashton wrote: > > The qc() > > proposal fits in well with the Perl "look-and-feel" and seems pretty > > comfortable to me. If there are concerns about obfuscatory potential, a > > use strict 'comments' could require that the q

Re: Reduce [was: Re: Random items (old p5p issues)]

In message <[EMAIL PROTECTED]> Gisle Aas <[EMAIL PROTECTED]> wrote: > The upcoming Python (v2.0) introduces a builtin called zip() that does > the same thing: > > for a,b,c in zip(aa,bb,cc): > ... > > There are also question on how long the resulting list should be if > @a, @b,

Object oriented Perl6?

I'm interested in how OO Perl 6 will be. It's very hard to develop big project in a language without OO support, so I think OO should be a very important part of Perl6. Currently alot of languages support OO very well, e.g. C++/Java/Python/JavaScript. I know that Perl6 will support OO in kernel,

Re: RFC: Reimplement Warnings and Tainting as Pragmas

> >Warnings and Tainting should be reimplemented as pragmas. > > What part of warnings(3) and perllexwarn(1) are you in disagreement with? Not yet fully-versed on everything having todo with 5.6, appears I made a bit of an oversight (i.e., as you mention 'use warnings' is already in 5.6)! So wh

Re: multiline comments

Hi Tom, Of course you should consider that the programmer may be block commenting a section of code precisely because it does contain sytax errors. I often do so as a way of isolating hard to track bugs. I can't imagine how getting more courteous error messages would be a Good Thing! Lets face i

Re: date interface (was Re: perl6 requirements, on bootstrap)

At 11:30 AM 8/2/00 -0400, Chaim Frenkel wrote: >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. Yes. What I'd l

Re: RFC: multiline comments

>Tom Christiansen wrote: >> > comment <> >> Smack--the lexer cowers before you! >Well, hey, while we're daydreaming... :-) I suppose I should have written The lexer misses! You hit--More--the lexer cowers before you. --tom

Re: perl6 requirements

Chaim Frenkel <[EMAIL PROTECTED]> writes: >> "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 >>>

Re: RFC: multiline comments

Tom Christiansen wrote: > > comment < > Smack--the lexer cowers before you! Well, hey, while we're daydreaming... :-) -- John Porter

Re: RFC: Filehandle type-defining punctuation

>But that, precisely, was my point: Arrays *and* hashes. If there is more than >one plural whatzitz, then why can't there be more than one singular whatzitz? >(and don't say, "because plural *means* more than one" :-). If having a >filehandle character would make the code clearer, then let's do

Re: RFC: multiline comments

>Proposal: here-docs specified with regexes, and no special >meaning for newlines. > comment <

Re: multiline comments

Michael Mathews wrote: > > > if (0) { > > } > > 1) what if the block contains syntax errors? > 2) what if the bloack contains unmatched braces? > 3) this is not easier to type or remember than the currently available > workarounds. TIMTOWTDI. -- John Porter

Re: RFC: multiline comments

Tom Christiansen wrote: > > I still like this solution prototype: > > sub comment($) { } > > comment <<"END OF FIRST COMMENT"; > asdf > asdf > asdf > asdf > asdf > END OF FIRST COMMENT So do I. Actually, here-docs can be a bit unwieldy, what with the requirement for the e

Re: multiline comments

>> What is wrong with >> >> if (0) { >> >> } >1) what if the block contains syntax errors? Then the compiler carefully and courteously notifies you of such. >2) what if the bloack contains unmatched braces? See above. >3) this is not easier to type or remember than the currently available >

Re: RFC: Reimplement Warnings and Tainting as Pragmas

>Wanted to get this out as an idea that could encompass lots of the >concerns I'm seeing about warnings and such: >=head1 TITLE >Warnings and Tainting should be reimplemented as pragmas. What part of warnings(3) and perllexwarn(1) are you in disagreement with? --tom

Re: RFC: Filehandle type-defining punctuation

Thus it was written in the epistle of Jon Ericson, > Ted Ashton wrote: > > Thus it was written in the epistle of Tom Christiansen, > > > Nope. A filehandle is a singular whatzitz. It thus mandatory takes > > > the singular prefix; to wit, $. What's next? Integer and float and > > > complex and

Multi-line comment sub list?

As in - maybe it's time for... -Corwin Corwin Brust Software Engineer Alliance Data Systems formerly Harmonic Systems, Inc. 701 Fourth Ave South, Suite-1600 Minneapolis, Minnesota 55415 Office (612) 672-3584 Mobil(612) 239-8073 Email[EMAIL PROTECTED]

Re: multiline comments

>What is wrong with > if (0) { > } >(and of course teaching op builder not to build them in this case). Funny, I was going to mention that I always use #if 0 ... #endif in C for nesting, block comments. Which is rare anyway, rarer perhaps than this discussion would seem to mer

Re: multiline comments

> What is wrong with > > if (0) { > > } 1) what if the block contains syntax errors? 2) what if the bloack contains unmatched braces? 3) this is not easier to type or remember than the currently available workarounds.

Re: RFC: multiline comments

>This seems like an acceptable variation on what has been suggested so far. I >deally one would be able to safely block comment any large section of a Perl >6 script and not worry about any other block comments within (the outermost >block comment takes precedence). I still like this solution pro

Re: RFC: multiline comments

Michael Mathews wrote: > > So this should work in Perl 6 > > code here; > #< > # this is a single line comment > $foo = $a + $b #< here's an in-line comment ># + $c * $d; > ># > more code here; If starting in column 1 is going to be magic, you may as well make the magic char #, so: #<

RFC: Reimplement Warnings and Tainting as Pragmas

Wanted to get this out as an idea that could encompass lots of the concerns I'm seeing about warnings and such: =head1 TITLE Warnings and Tainting should be reimplemented as pragmas. =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 2 Aug 2000 Version: 1.0 Mailing-List: perl6-

Re: RFC: variable usage warnings

>The warning message "use of uninitialized value" should also >disappear, to be replaced with "use of undefined value", and the >warning for the purpose described in this RFC should be "use of >uninitialized variable C<$x>". What about if there's only an expr, not a variable? For example: p

Re: multiline comments

Buddha Buck <[EMAIL PROTECTED]> writes: > >The one concern I would raise about this is that a common use of multi-line >comments is to dyke out code. What is wrong with if (0) { } (and of course teaching op builder not to build them in this case). -- Nick Ing-Simmons

Re: RFC: multiline comments

Glenn Linderman wrote: > > > > qc( Here's a quick comment which actually contains > > qc( another comment ) > > within it > > ); > > This type of comment will not comment out arbitrary text. > In particular, it might have problems with text containing > mismatched (){}<>. This is alre

Re: RFC: multiline comments

Ted Ashton wrote > > 2) Also this proposition fails in one of my goals, which was to allow > > arbitrary nesting of multiline comments. I believe this would be true for > > any function based solution. > > Negative. If you use paired delimiters you're ok. > > qc( Here's a quick comment which actu

Re: RFC: Filehandle type-defining punctuation

Ted Ashton wrote: > Thus it was written in the epistle of Tom Christiansen, > > Nope. A filehandle is a singular whatzitz. It thus mandatory takes > > the singular prefix; to wit, $. What's next? Integer and float and > > complex and string and char and bits prefixes? > > (Weighing in with th

Re: RFC: multiline comments

Glenn Linderman wrote: >$foo = $a + $b #< can this be an in-line comment? ># + $c * $d; > > Note that with this scheme it would be possible to allow in-line comments to be > multi-line comments, or possible to prevent that. I'd vote in favor of keeping > in-line comments on a single line. >

Re: RFC: multiline comments

Ted Ashton wrote: > > 2) Also this proposition fails in one of my goals, which was to allow > > arbitrary nesting of multiline comments. I believe this would be true for > > any function based solution. > > Negative. If you use paired delimiters you're ok. > > qc( Here's a quick comment which ac

Re: Reduce [was: Re: Random items (old p5p issues)]

Graham Barr wrote: > > The upcoming Python (v2.0) introduces a builtin called zip() that does > > the same thing: > > > > for a,b,c in zip(aa,bb,cc): > > ... > > > > There are also question on how long the resulting list should be if > > @a, @b, @c is not of the same length. I think zip(

Re: RFC: multiline comments

Thus it was written in the epistle of Michael Mathews, > Ted Ashton wrote: > > The qc() > > proposal fits in well with the Perl "look-and-feel" and seems pretty > > comfortable to me. If there are concerns about obfuscatory potential, a > > use strict 'comments' could require that the qc( opening

Re: RFC: Filehandle type-defining punctuation

Thus it was written in the epistle of Tom Christiansen, > >Hearing no outright derision in response to my trial balloon, here it is as > >an RFC: > > >=head1 TITLE > > >Filehandles should use C<*> as a type prefix if typeglobs are eliminated. > > Nope. A filehandle is a singular whatzitz. It

Re: RFC: multiline comments

Edwin Wiles wrote: > On the other hand, the stated desire for this is for commenting out > blocks of code. That might be more achievable with (I forget the right > name for this) 'compile time directives' such as "#if", "#endif". We'd > have to use a different opening syntax, since # is already

Re: RFC: Filehandle type-defining punctuation

On Wed, Aug 02, 2000 at 11:46:15AM -0700, Peter Scott wrote: > =head1 TITLE > > Filehandles should use C<*> as a type prefix if typeglobs are eliminated. I could go for this, given the `if typeglobs are eliminated' caveat.

Re: RFC: Highlander Variables

Thus it was written in the epistle of Andy Wardley, > > $foo -> $foo > %foo -> $foo__hash > @foo -> $foo__list Andy, With all due respect, it appears that you are trading two characters for six with little to show for it. Currently, we have @array -- the array as a whole $ar

Re: date interface (was Re: perl6 requirements, on bootstrap)

Simon Cozens <[EMAIL PROTECTED]> writes: >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 rep

RFC: variable usage warnings

Hey, this RFC stuff is fun! =head1 TITLE variable usage warnings =head1 VERSION Maintainer: Steve Fink <[EMAIL PROTECTED]> for now Date: 2 Aug 2000 Version: 0 (unreleased) Mailing List: [EMAIL PROTECTED] Number: (unassigned) =head1 ABSTRACT "VARIABLE used only once: possible typo"

Re: Removing/fixing $[line noise here] variables

On Wed, Aug 02, 2000 at 03:34:56PM -0400, John Porter wrote: > Brust, Corwin wrote: > > I want perl's error (and warning) messages to be specific to each program I > > write. > > Isn't this covered by locales? Completely different beast. I don't claim to fully understand locales, but that's n

C# Language and Programmer's Reference (URL)

http://msdn.microsoft.com/library/default.asp?URL=/library/prelim/csref/vcor iCReference.htm

Re: RFC: lexical variables made default

Tad McClellan wrote: >or saveval()# indicates it is about _values_ > tempval() >or myval() # my _value_, not my(variable) >or even pushpop() # maybe not :-) pushval() -- John Porter

Re: RFC: lexical variables made default

On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote: > >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)) > Anything one chooses potentially con

Re: Removing/fixing $[line noise here] variables

>Isn't this covered by locales? Unicode and locales are immiscible. --tom

Re: RFC: Filehandle type-defining punctuation

>Hearing no outright derision in response to my trial balloon, here it is as >an RFC: >=head1 TITLE >Filehandles should use C<*> as a type prefix if typeglobs are eliminated. Nope. A filehandle is a singular whatzitz. It thus mandatory takes the singular prefix; to wit, $. What's next? Int

Re: DRAFT RFC: Enhanced Pack/Unpack

On Wed, 02 Aug 2000 12:22:09 -0700, Glenn Linderman wrote: > [ 'bar' => 'integer32', 'baz' => 'integer32', 'count' => 'integer32' ] > > [ 'var1' => 'int32', 'var2' => 'int16', 'var3' => 'int8' ] That doesn't reconsider BigEndian vs. LittleEndian, AKA pack/unpack 'N' vs. pack/unpack 'V'. --

Re: RFC: type inference

Steve Fink wrote: > There are many possible goals for any typing-related stuff we do. I'd > say the top three are: > > - compile-time warnings >- definitely unsafe operations >- probably unsafe operations > - runtime storage optimization > - runtime time optimization Yes. The last two ar

Perl already *is* strongly typed (was: RFC: Highlander Variables)

>We're not thinking like in C where every variable `should' be prefixed with >it's type, like p_var for a pointer to a variable or t_var for defining the >type for var. In perl I just LOVE the way $, @, % and & unambiguously defines >the type of the var. I just miss a prefix for formats (which wil

Re: RFC: multiline comments

Michael Mathews wrote: > > 2) Also this proposition fails in one of my goals, which was to allow > arbitrary nesting of multiline comments. I believe this would be true for > any function based solution. > > For example, this should be okay but I don't see how it could: > > 1qc/* > 2

Re: perl6 requirements

> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: >> Please explain what the utility of having unshared variables? I might >> as well just fork(). TC> The only sane situation is to have safety by default. Things should not TC> be shared unless you say they are. Err, I understood his c

Re: Removing/fixing $[line noise here] variables

Brust, Corwin wrote: > > messages.rfc - An RFC to discussing the wisdom of allowing run time error > and warning messages to be modified at run time > ... > I want perl's error (and warning) messages to be specific to each program I > write. Isn't this covered by locales? -- John Porter

Re: multiline comments

Peter Scott wrote: > At 02:53 PM 8/2/00 -0400, John Porter wrote: > >Perhaps a better way would be a change in the semantics of scalar > >literals in void context, to be silently ignored. > > No! It's a major typo/bug-catcher. Strange, my experience does not confirm that one whit. -- John Por

Re: perl 6 requirements

"Randal L. Schwartz" wrote: > Graham> sub def { my @a = (9,8,7); return @a; } > > That's not returning the array. That's returning a copy of the contents > of @a in a list context, and the number of elements of @a in a scalar > context, using the "@a" operator. You still haven't "returned the

Synopsis: C# article

From: Larry Wall [mailto:[EMAIL PROTECTED]] > > Here's another article that talks about a lot of the things we > *should* be thinking. In fact, it's possible this article should > be required reading for anyone who aspires to be a Perl designer. > > http://windows.oreilly.com/news/hejlsberg_0800.

[Fwd: New list charters]

> Whoa! I'm far from convinced that I have a strong enough CS background > to understand half of what'll go on on this list. I've already > indicated on-list that I'd rather leave this position for someone else, > if there is someone else. My $.02 worth ... It's been my experience that th

Re: DRAFT RFC: Enhanced Pack/Unpack

Edwin, This writeup certainly is a great first draft for this RFC. I'll have to track down those references. I was surprised by the read/write operations, but have no objection to them. New/get/set and the individual data member access functions are the critical pieces, as the I/O could be done

Re: multiline comments

At 02:53 PM 8/2/00 -0400, John Porter wrote: >Perhaps a better way would be a change in the semantics of scalar >literals in void context, to be silently ignored. No! It's a major typo/bug-catcher. -- Peter Scott Pacific Systems Design Technologies

Re: RFC: multiline comments

Ted Ashton wrote: > The qc() > proposal fits in well with the Perl "look-and-feel" and seems pretty > comfortable to me. If there are concerns about obfuscatory potential, a > use strict 'comments' could require that the qc( opening start in column one. > Further, if qc were flexible about delimi

Re: perl 6 requirements

What's wrong with do {}? (Added typing?) > "RLS" == Randal L Schwartz <[EMAIL PROTECTED]> writes: RLS> I use it a lot, in places where I want two expressions executed, RLS> especially as one part of "EXPR while EXPR" or "EXPR if EXPR". RLS> Yeah, I could use a do-block on either side, but

Re: multiline comments

Bart Lateur wrote: > > < This is comment! > And more... > END_OF_COMMENT > > Apart from the warning "Useless use of a constant in void context", it > works. Yes; but it was precisely that warning which I was intending to address. Perhaps a better way would be a change in the semantics of scala

development relationship of Perl 5 and Perl 6

Johan Vromans writes: : 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)? We will

Re: perl 6 requirements

> "RLS" == Randal L Schwartz <[EMAIL PROTECTED]> writes: Chaim> Then perhaps, just get rid of the list/array distinction? Make Chaim> everything an array? RLS> Because it's useful to have it the way it is. Please elaborate. I don't quite see why this distinction needs to be made. APL, Posts

Re: RFC: Filehandle type-defining punctuation

Peter Scott wrote: > Filehandles should use C<*> as a type prefix if typeglobs are eliminated. I missed previous discussion of this (if there was any), but it's an idea I've already thought about. It has my vote, fwiw. -- John Porter

Re: multiline comments

On Wed, 2 Aug 2000 12:51:10 -0400, John Porter 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... }; "Function"? Who needs a functi

Re: perl 6 requirements

As I said before. Let us get rid of the distinction. Here is Randal and Graham arguing about a 'fundamental' issue. I don't think this is fundamental to 'What is Perl'. This is a great question to stump someone on an interview. Ignoring this "push a list/comma seperated list context through a su

RFC: Filehandle type-defining punctuation

Hearing no outright derision in response to my trial balloon, here it is as an RFC: =head1 TITLE Filehandles should use C<*> as a type prefix if typeglobs are eliminated. =head1 VERSION Maintainer: Peter Scott <[EMAIL PROTECTED]> Date: 2 Aug 2000 Version: 1 Mailing List: perl6-la

Re: RFC: multiline comments

Ted Ashton wrote: > The qc() > proposal fits in well with the Perl "look-and-feel" and seems pretty > comfortable to me. If there are concerns about obfuscatory potential, a > use strict 'comments' could require that the qc( opening start in column one. I think qc() should be allowed to look l

Re: RFC for recursive regexps

In perl5, /(??{ $FOO })/ delays the interpolation of $FOO, so as to be able to have recursively defined regexps. Nat

RFC for recursive regexps

=head1 Title Recursion in regular expressions =head1 Abstract It would be useful to have part or all of a regular expression be recursive, for example when trying to match a string with properly-nested parentheses. =head1 Discussion Regexps long since gave up the pretense of being "regular".

Re: RFC: lexical variables made default

Peter Scott wrote: > Argh, you're giving me Pascal flashbacks. Nothing inherently wrong with that. > Keep 'em short. I think Keep Them Meaningful/Mnemonic should take precedence over Keep Them Short. > So you'd need something like use strict > 'declarations' which would require all variable

Re: RFC: Highlander Variables

John Porter writes: > > But perl's not any other language. Perl's fun. most other > > languages are not. > Perl5 is not going away. > Let's make a better language while we have the opportunity. Relax, you two. Better doesn't have to exclude fun. If you're dead set against highlander types, the

better subjects (was Re: what will be in Perl6 ?)

> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> If this article is going to inspire multiple threads, let's try to LW> give them unique subject names. Thanks. and in general, we need better message subjects. already i have seen threads fall into the one-subject-fits-all abyss of al

Re: what will be in Perl6 ?

Jonathan Scott Duff writes: : On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote: : > raptor writes: : > : http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html : > : > That's a good summary of what we've been thinking. Here's another : > article that talks about a lot of the

Re: what will be in Perl6 ?

On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote: > raptor writes: > : http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html > > That's a good summary of what we've been thinking. Here's another > article that talks about a lot of the things we *should* be thinking. > In fa

Re: RFC: lexical variables made default

At 11:57 AM 8/2/00 -0400, John Porter wrote: >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 coul

Re: what will be in Perl6 ?

raptor writes: : http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html That's a good summary of what we've been thinking. Here's another article that talks about a lot of the things we *should* be thinking. In fact, it's possible this article should be required reading for anyone who

Re: RFC: type inference

Ken Fox wrote: > > 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 sho

Re: RFC: Highlander Variables

H.Merijn Brand wrote: > > But perl's not any other language. Perl's fun. most other languages are not. Perl5 is not going away. Let's make a better language while we have the opportunity. -- John Porter

Re: RFC: Highlander Variables

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

Re: Why we're here

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

Re: Reduce [was: Re: Random items (old p5p issues)]

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 '

Re: RFC: Highlander Variables

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,

Re: RFC: Highlander Variables

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. >

Re: multiline comments

>It nice to be able to bounce on % in vi, too: >=#{ >comment >=#} You easy to do this already: =begin comment { =end comment } --tom

RE: What is Perl?

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

Re: DRAFT RFC: Enhanced Pack/Unpack

> 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

Re: RFC: Higher resolution time values

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

Re: multiline comments

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 <

Re: perl 6 requirements

> "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

Re: multiline comments

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

Re: Reduce [was: Re: Random items (old p5p issues)]

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.

Re: perl 6 requirements

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

Re: RFC: Highlander Variables

> "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

Re: Reduce [was: Re: Random items (old p5p issues)]

>sub mapf(&;\@\@\@\@\@\@\@\@\@) { Steal from lisp: map maap maaap mapp mappp maappp ... :-) --tom

Re: perl 6 requirements

> "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

<    1   2   3   >