"Michael Maraist" <[EMAIL PROTECTED]> writes:
[...]
> First, the current debugger allows multi-lines if you use "\" at the end of
> the line ( a la C ).
Thanks. TomC also pointed this out. I still don't like it, though.
(But it will be added to the next revision).
Take a look at what sh will
> > This is the kind of thing that keeps Perl instructors in business...
>And Perl out of businesses :-(
>More than anything I think the inability to write C DWIMishly
>argues that we need it built-in. But we also need a *very* careful design
>of the semantics.
I'd like to see from this measu
I'll be brief because windows just crashed on me.
First, the current debugger allows multi-lines if you use "\" at the end of
the line ( a la C ).
Second, lexically scoped variables will dissapear on subsequent debugger
lines since their scope is wrapped in an eval. For the most part, the
debug
> This is the kind of thing that keeps Perl instructors in business...
And Perl out of businesses :-(
More than anything I think the inability to write C DWIMishly
argues that we need it built-in. But we also need a *very* careful design
of the semantics.
Damian
Buddha Buck wrote:
> At 05:35 PM 8/31/00 +, David L. Nicol wrote:
> >Buddha Buck wrote:
> > > > The array
> > > > syntax would also be useful in multi-dimensional arrays.
> > >
> > > That is if multi-dimensional arrays are implemented as lists-of-lists,
> > > which they might not be.
> >
> >Ev
>The most serious obstacle to easy interaction is the impossibility of
>typing multiple line commands to a Perl debugger (see below).
% man perldebug
...
Multiline commands
If you want to enter a multi-line command, such as
a subroutine definition with
On Thu, 31 Aug 2000, David L. Nicol wrote:
> We're talking about making a faster Perl. C's syntax requires enough
> clarity to compile to something quick. it is a very short hop from
> my dog $spot;
> to
> dog spot;
What about the second version would result in faster execution? D
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl should support an interactive mode.
=head1 VERSION
Maintainer: Ariel Scolnicov <[EMAIL PROTECTED]>
Date: 31 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 184
Status: Developin
"David L. Nicol" wrote:
>
> my dog $spot;
> to
> dog spot;
>
> If we only allow this where enough info is available to allocate dog-sized
> pieces of memory directly, Perl can blaze through the code that deals with
> dogs.
I don't see what barewords gain us here. Who says that
Sam Tregar wrote:
>
> On Thu, 31 Aug 2000, David L. Nicol wrote:
> > run-time efficiency
>
> C doesn't get run-time efficiency from its syntax, so we can't really
> expect to get anything here. It gets it from its compilation
> architecture. If you want to build a Perl frontend for GCC
At 11:46 PM 8/31/00 +0200, Bart Lateur wrote:
>On Fri, 1 Sep 2000 07:27:24 +1100 (EST), Damian Conway wrote:
>
> > > > And has anyone pointed out that C is just:
> > > >
> > > > sub list {@_}
> > >
> > > Um no. I would expect it to be
> > >
> > > sub list { @_[0..$#_] }
> >
> >It's
On Thu, 31 Aug 2000 13:36:10 -0600, Tom Christiansen wrote:
>>I'm not arguing in favor of the tr/// hack specifically, but
>>gosh, wouldn't it be nice if there were a thwack() builtin that
>>stripped leading and trailing spaces?
>
>No. People should learn intrinsic mechanisms with which they c
On Fri, 1 Sep 2000 07:27:24 +1100 (EST), Damian Conway wrote:
> > > And has anyone pointed out that C is just:
> > >
> > > sub list {@_}
> >
> > Um no. I would expect it to be
> >
> > sub list { @_[0..$#_] }
>
>It's too early in the morning.
>The subtlety here escapes me
Nathan Wiger wrote:
>
> Well, it just stacks arguments on the end, even with open-ended
> prototypes:
>
>@a =~ my_user_sub($arg); # @a = my_user_sub($arg, @a)
What it means is, you can't prototype the thingy that could be
expected on the LHS of the =~, when function is open-ended,
because i
Graham Barr wrote:
> On Thu, Aug 31, 2000 at 03:55:28PM +1100, Damian Conway wrote:
> > And has anyone pointed out that C is just:
> >
> > sub list {@_}
>
> Um no. I would expect it to be
>
> sub list { @_[0..$#_] }
According to my quickie tests, both have the desired effect
(supplying l
Dan Sugalski wrote:
> I expect we'd want to have some sort of heavy-duty regex optimizer, then,
> to detect common prefixes and subexpressions and suchlike things, otherwise
> we end up with a rather monstrous alternation sequence...
We need a regex merge function too -- then we could write macro
Peter Scott wrote:
>
> >Having the
> >indices in one place saves a lot of characters. Compare
> >
> > $r->{{qw(a b c d e f g h)}}
> >
> >versus
> >
> > $r->{a}->{b}->{c}->{d}->{e}->{f}->{g}->{h}
>
> But I would compare it to
>
> $r->{a}{b}{c}{d}{e}{f}{g}{h}
>
> which is
> > And has anyone pointed out that C is just:
> >
> > sub list {@_}
>
> Um no. I would expect it to be
>
> sub list { @_[0..$#_] }
It's too early in the morning.
The subtlety here escapes me.
Damian
>I'm not arguing in favor of the tr/// hack specifically, but
>gosh, wouldn't it be nice if there were a thwack() builtin that
>stripped leading and trailing spaces?
No. People should learn intrinsic mechanisms with which they can
construct infinitely many beautiful and powerful effects. This
TomC wrote:
>In general, getting folks to write
>
>s/^\s+//s;
>s/\s+$//s; # XXX: \z
>
>is a *good* think.
Why?
Removing leading/trailing whitespace is a tremendously frequently-
performed task. Perl gives you -l on the command line to strip
newlines on input and add them on output, sim
>How would you do:
># Writer insists on blank line between paragraphs, first line indented.
># Publisher insists on one paragraph/line, first word ALL CAPS.
Step 1: Fire the lame publisher. I'm serious. It's amazing
what people tolerate. Some things aren't worth the pane.
>{
>local $/ =
>tr///l # Translate only _l_eading characters matching.
>tr///t # Translate only _t_railing characters matching.
>With "Only leading" I mean translate from start/end until you find a
>character not matching. Then you can do nifty things such as:
>tr/\w//dlt # Trim all leading & tra
On Thu, Aug 31, 2000 at 02:52:10PM -0400, Buddha Buck wrote:
> How would you do:
>
> # Writer insists on blank line between paragraphs, first line indented.
> # Publisher insists on one paragraph/line, first word ALL CAPS.
> {
> local $/ = ""; #slurp paragraph at a time.
> while () {
>
At 01:35 PM 8/31/00 -0500, Jonathan Scott Duff wrote:
>On Thu, Aug 31, 2000 at 07:59:31PM +0200, Dan Zetterstrom wrote:
> > Why not use the "function" we already got, tr? Something like:
> >
> > tr///l # Translate only _l_eading characters matching.
> > tr///t # Translate only _t_raili
On Thu, Aug 31, 2000 at 07:59:31PM +0200, Dan Zetterstrom wrote:
> Why not use the "function" we already got, tr? Something like:
>
> tr///l # Translate only _l_eading characters matching.
> tr///t # Translate only _t_railing characters matching.
>
> With "Only leading" I mean transla
On Thu, 31 Aug 2000 19:59:31 +0200, you wrotc:
>tr/\w//dlt # Trim all leading & trailing whitespace from $_
>
Eh, scratch that. Too much caffeine i guess.
tr/\n\r\t //dlt; # Trim some whitespace.
-DZ
--
Tell me your dreams and I will crush them.
At 05:35 PM 8/31/00 +, David L. Nicol wrote:
>Buddha Buck wrote:
> > > The array
> > > syntax would also be useful in multi-dimensional arrays.
> >
> > That is if multi-dimensional arrays are implemented as lists-of-lists,
> > which they might not be.
>
>Even if they aren't implemented as lol,
On Thu, 31 Aug 2000 09:41:37 -0400 (EDT), you wrotc:
>Nathan Wiger wrote:
>>In a very cool email, Bryan Warnock talked about half a dozen different
>>chop-like functions that are useful but not in core:
>>
>>http://www.mail-archive.com/perl6-language@perl.org/msg01522.html
>>
>>I think chop, cham
[redirected to perl6-language]
Tom Christiansen wrote:
>
> Note the difference between
>
> my $var = func();
>
> and
>
> my($var) = func();
>
> Those are completely different in that they call func() in scalar
> and list contexts. Why? Because of hte presence or absence of (),
> of
On Thu, Aug 31, 2000 at 03:55:28PM +1100, Damian Conway wrote:
> And has anyone pointed out that C is just:
>
> sub list {@_}
Um no. I would expect it to be
sub list { @_[0..$#_] }
Graham.
Perl6 RFC Librarian wrote:
> arsenal. The constructs are:
>
> $ref->[[LIST]]
> $ref->{{LIST}}
>
> The proposed respective meanings:
>
> $ref->[$elem[0]]->[$elem[1]}->[...]->[$elem[-1]]
> $ref->{$elem[0]}->{$elem[1]}->{...}->{$elem[-1]}
why not just use single
Eric Roode writes:
> Useful functions all, no doubt. But I would lobby heavily for a new
> set of names -- ones that can be remembered! Quick -- which trims
> leading spaces, champ, chump, or chimp?
My favourite: chafe().
Nat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A Perl frontend to GCC would make my life wonderful. Who would I talk
to about that? I'm not about to pretend that I have any idea how to
do that.
- --Dave
- -> -Original Message-
- -> From: Sam Tregar [mailto:[EMAIL PROTECTED]]
- -> Sent: T
On Thu, 31 Aug 2000, David L. Nicol wrote:
> Perl looks, and AFAIK has always looked, like "C plus lune noise" to
> many people.
I think Perl looks like "C plus moon noise" to former C programmers. I
imagine some people see it and think "Csh plus Awk noise". Perl is a lot
more than C-with-scal
David Corbin wrote:
> A C JIT is an interesting idea.
>
> I think that a project works best when it has a set of goals (I haven't
> seen one yet really for Perl 6). Unless this is one of the goals, I can
> easily see how this could become a serious distraction to what I
> perceive as the like
>Next, what subset of the set-theory should be implemented. Obviously you
>refer to the basic and / or / xor, but in real practice, the other operators
>can be very useful. Chaining operators (especially with array-based-sets)
>can be a performance nightmare.
Unless you use bitwise operators on
John Porter wrote:
>
> Not familiar with indirect object notation?
Insulting non-argument. I'm not replying to it.
> Who was it that suggested changing the m// operator to the match()
> function, and the s/// operator to the subst() function?
That would be me.
> I suppose I could have propos
> More functions from set theory to manipulate arrays
>
> I'd like to use these functions in this way :
>
> @c = union (@a, @b);
> # wich is different from @c = (@a, @b) because union do not duplicate
> same elements
>
> @c = intersection (@a, @b);
> @c = diff(@a, @b);
>
Elements of this ar
Jerrad Pierce wrote:
>
> That would be my hope too, but as I mentioned, it is seeming somewhat unlikely.
I don't think so. There's lots of proposals out there right now, but
only a very few actually break backwards compatibility. Plus, Larry's
not going to make Perl 6 look like, as Tom would say
> >We already have a trailing if statement, so this argument is edgy, at
> >best.
>
> Your brain/eye can look one statement. It's evil and wrong to make
> it look infinite statements forward. How can you pretend those are
> the same?
Well, I think trailing statements already have only limited
>> Since everyone seems intent on breaking backward compatibility
>I don't think this is at all true, but I also don't think the overall
you seem to have ignored the paranthetical clause
>idea of a Perl5 module is necessarily a bad one.
>However, my hope would be that we do Perl 6 smoothly enough
On Wed, Aug 30, 2000 at 10:58:45PM -0700, Nathan Wiger wrote:
> We already have a trailing if statement, so this argument is edgy, at
> best. The only thing that it can't do is easily span multiple lines and
> expressions. Any reason why not other than style? Seems like the obvious
> extension.
Nathan Wiger wrote:
> > If =~ allowed "indirect object" notation as -> does, then we could write
> >
> > s $str (pat){rep};
> > and
> > for ( grok %db /Name/$name/g ) {
>
> Yeah, but I'm not sure what those are supposed to do.
Not familiar with indirect object notation?
How ab
Nathan Wiger wrote:
>In a very cool email, Bryan Warnock talked about half a dozen different
>chop-like functions that are useful but not in core:
>
>http://www.mail-archive.com/perl6-language@perl.org/msg01522.html
>
>I think chop, champ, chip, and friends should be available via the
>
> use St
On Wed, Aug 30, 2000 at 04:34:50PM -0600, Nathan Torkington wrote:
> I wouldn't go that far. It might say something about the difference
> between proposals made as rhetorical devices ("yes, but if that's the
> case then you should be getting rid of X, Y, and Z!"). Really, though,
> I think it's
My first reaction was "NOOO!!" we'll break too much code!
Now, I'm not so sure. Nearly always, chomp() is what is called for;
how often *do* you need to chop off the last character of a string?
And, as someone else pointed out, why not the first character?
"Al" wrote:
>I would actualy lik
Tom Christiansen writes:
> Look closer: do { ... } while does not require the reader to
> scan down to find out the condition *BEFORE* the loop is
> entered. With an if, it does.
I believe what he's saying is that do { ... } requires the reader to
scan down far enough to see if there is a whil
"David L. Nicol" wrote:
>
> Dan Sugalski wrote:
>
> > I do want to have a set of C/XS/whatever sources as part of the test suite
> > as well--right now perl's test suite only tests the language, and I think
> > we should also test the HLL interface we present, as it's just as
> > important in so
In message <[EMAIL PROTECTED]>
Nathan Torkington <[EMAIL PROTECTED]> wrote:
> Tom Hughes writes:
> > I must admit it had never occurred to me that somebody might
> > deliberately use keys or values to achieve that, but I guess
> > somebody might be relying on it without realising it.
>
In message <[EMAIL PROTECTED]>
Jerrad Pierce <[EMAIL PROTECTED]> wrote:
> >As far as I can tell reset %x currently tries to reset any
> >variables which start with either % or x even though no variable
> >can start with %...
>
> ~/perl
> ${"%percent"} = "Quoth the raven";
> print ${"%pe
50 matches
Mail list logo
