Re: Perl, the new generation
On Fri 11 May 2001 16:31, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Fri, May 11, 2001 at 01:55:42AM +0100, Graham Barr wrote:
> > On Thu, May 10, 2001 at 07:40:04PM -0500, Jarkko Hietaniemi wrote:
> > > By far most of my use of typeglobs is making aliases, and then mostly
> > > for code:
> > >
> > > *color = \&colour;
> >
> > I would say that probably the most common use now for typeglobs is
> > from the IO:: modules. Which are created with gensym so they are
> > anonymous.
>
> Personally, I use typeglobs mostly to autogenerate repetitive methods
> without an autoloader:
>
> *method = $closure;
>
> but this should definately have a direct analogy in Perl 6 so I'm not
> worried.
I use it to check if formats exist, since there is no other way to do so
(except maybe an eval that dies :():
if (defined *{$::{$fmt}}{FORMAT}) {
local $~ = $fmt;
write;
}
but for perl6 it doesn't matter, cause formats will die anyway (even without
an eval :)
--
H.Merijn BrandAmsterdam Perl Mongers (http://www.amsterdam.pm.org/)
using perl-5.6.1, 5.7.1 & 629 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: [EMAIL PROTECTED]
http:[EMAIL PROTECTED]/ [EMAIL PROTECTED]
send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: What's up with %MY?
On Friday 07 September 2001 12:56 am, Ken Fox wrote: > "Bryan C. Warnock" wrote: > > Generically speaking, modules aren't going to be running amok and making > > a mess of your current lexical scope - they'll be introducing, possibily > > repointing, and then possibly deleting specific symbols > > How much do you want to pay for this feature? 10% slower code? 50% > slower? Do you want the feature at any price? Which feature? The introduction of new lexicals solely at compile time? We can do that now. I've already demonstrated that this is a solvable problem. Although, admittedly, I wouldn't suggest actually *implementing* my solution, I'm sure someone far more clever than I can come up with a viable one. > > I don't like run-time frobbing of the symbol table. Not even > precise tweaking. ;) I think it's in bad style and inconsistent with > the purpose of lexicals. *But* bad style isn't a good argument > and I wouldn't be pursuing this if it were just a style issue. But it clears up a *lot* of problems that were introduced with local. Much like perlfunc says... You really probably want to be using "my" instead, because "local" isn't what most people think of as "local". See the Private Variables via my() entry in the perlsub manpage for details. Lexicals were never about speed, they were about containership. A lot of Perl's magic and power, however, only work when centered around globals and locals. Muckings there, however, cause true "action at a distance" - what I change here for my benefit may screw something up way over there that I can't see. Allowing this to take place with lexicals reduces those risk factors - do your magic here and only here. > > The trouble lies in running the code. Lexicals used to be known at > compile time. Now they can change practically anywhere. It's like > using C and having *everything* be volatile. Except worse because > you don't even know the address where something is going to be. Lexicals being known at compile-time was a side-effect of the containership. Yes, we want lexicals to be fast. Containing behavior lexically is slightly more important, IMO. If it runs dog-slow, we won't do it. If it runs just a tad slower, we probably should. > > A simple solution would be to allow lexical scope editing at > compile time, but not run-time. Change a BEGIN block's caller() so > that it is the scope being compiled instead of main. This achieves > the majority of the benefits (lexical imports at compile time) > without any downside. Nope. Think 'require'. > > There are two other things that are easy to add. If the > compiler knew in advance which lexicals might dynamically change, > it could generate better code and not slow everything down. A > trait called ":volatile" or something. IMHO this would also > show intent to the people reading the code that something funny > might happen to the variable. (Macros or compile-time injected > lexicals could declare the :volatile trait, so I would imagine > that some pretty interesting packages could still be written.) Except that magic will probably be going on behind the scenes, so you don't know it's magically. Otherwise, you'd just assign whatever it was to the lexical variable and be done with it -- Bryan C. Warnock [EMAIL PROTECTED]
Re: What's up with %MY?
At 12:13 AM 9/7/2001 -0400, Ken Fox wrote: >Damian Conway wrote: > > "3, 1, 3" is the correct answer. > >That's what I thought. Dan's not going to be happy. ;) Well, it means a fetch by pad entry rather than use of a cached PMC pointer, but that's OK by me. I have a solution for this that I'm perfectly comfortable with, so I'm fine. Once we've worked out how things should behave, then we can get on with implementing it. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: LangSpec: Statements and Blocks
will the iterator variable be available in map, grep, join...etc...
I was also wondering if the join syntax be extended in a way that it can
support preffix and suffix... what i have in mind ... not necesary but :
#pair
join ($prefix => $suffix), @ary;
so :
my $select = join (qq{} => ''), @ary;
or is better to stay like this :
my $select;
map { $select .= qq{$_} } @ary;
=
iVAN
[EMAIL PROTECTED]
=
Re: LangSpec: Statements and Blocks
On Friday 07 September 2001 03:22 pm, raptor wrote:
> will the iterator variable be available in map, grep, join...etc...
Iterators haven't been defined yet, so it's hard to tell.
For map and grep, it's certainly feasible, depending on their implementation
- although neither are truly iterators.
For join, I don't see where you would access it.
>
> I was also wondering if the join syntax be extended in a way that it can
> support preffix and suffix... what i have in mind ... not necesary but :
> #pair
> join ($prefix => $suffix), @ary;
>
> so :
> my $select = join (qq{} => ''), @ary;
That's not really joining.
>
> or is better to stay like this :
> my $select;
> map { $select .= qq{$_} } @ary;
Definitely.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: LangSpec: Statements and Blocks
On Fri, Sep 07, 2001 at 10:22:49PM +0300, raptor wrote:
> I was also wondering if the join syntax be extended in a way that it can
> support preffix and suffix... what i have in mind ... not necesary but :
> #pair
> join ($prefix => $suffix), @ary;
>
> so :
> my $select = join (qq{} => ''), @ary;
That's a map if ever I saw one :-)
> or is better to stay like this :
> my $select;
> map { $select .= qq{$_} } @ary;
or
$select = join '', map { qq{$_} } @ary;
or
$select .= qq{$_} for @ary;
or when Perl gets reduce()
$select = reduce {
$_[0].qq{$_}
} '', @ary;
or whatever makes you happy.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
