Re: End-of-scope actions: Toward a hybrid approach.

[Simon Cozens]

On Tue, Feb 20, 2001 at 01:49:45AM -0500, [EMAIL PROTECTED] wrote:
> On Tue, Feb 20, 2001 at 02:14:52AM +, Simon Cozens wrote:
> > > Yes.  And the modules on CPAN that already do this are interesting too.
> > 
> > Oh, bother. Oh well, I've got builtinify (which was actually the point of the
> > exercise) and they haven't, so I'm happy. :)
> 
> Something like Function::Override then? 

Sort of. What I really wanted to do was to be able to say

sub foo { ... }
builtinify(foo);

package bar;
foo(); # Refers to main::foo
package baz;
foo(); # Refers to main::foo

(this is so that the forthcoming Safety::First module can produce exported
functions available throughout the program) which is easily done if you mess
with UNIVERSAL::AUTOLOAD, but what if the user has their own
UNIVERSAL::AUTOLOAD? You need to make sure your version runs first, optionally
passing on control to theirs, which you can to be adding a pre-hook. So I had
to implement pre-hooks. :)

> Want to merge implementations?

I'm open to offers. Take a look at S::V and tell me what you think.

-- 
Jenkinson's Law:
It won't work.

The Unlambda Programming Language

[Juanma Barranquero]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 19 Feb 2001 13:17:56 -0600, "David L. Nicol"
<[EMAIL PROTECTED]> wrote:

> "currying" used in a fascinating context: an experimental 
> language in which
> 
> http://www.eleves.ens.fr:8080/home/madore/programs/unlambda/#tut

In that vein, perhaps (the collective) you wants to visit the
Esoteric Languages' page of Cat's Eye Technologies:

http://www.catseye.mb.ca/

   /L/e/k/t/u

-BEGIN PGP SIGNATURE-
Version: PGPfreeware 6.5.8 for non-commercial use 

iQA/AwUBOpJ9Cv4C0a0jUw5YEQJFwgCfXc6USTxBcJHbf0vSagVu9ofNVL0AnjN/
TwaFtv8MxYM+mCFp87PlKChe
=0iQ+
-END PGP SIGNATURE-

Re: Things have paused... really?

[Simon Cozens]

On Tue, Feb 20, 2001 at 12:10:53PM -0600, Garrett Goebel wrote:
> o  Will experiences from Ruby be assimilated back into Perl? 
> 
> o  What impact will C# and .NET have on Perl 6? Don't forget
>Larry's required reading recommendation:  
>http://windows.oreilly.com/news/hejlsberg_0800.html
> 
> o  Where will the foreign function interface be heading?

The task and the art of language design is - I hate to use the word
"holistic", but, well - holistic. 

It's like, oh, I don't know, writing music. You can't do it in a vacuum -
everything you hear influences you. Everything feeds in - whether it was what
you thought sucked about your last piece, or what worked about your last
piece, or interesting techniques in something you've just heard, or maybe just
the style and "feeling" of a few composers you've been listening to recently. 

Culture matters a *lot*. If I spent a load of time in Canadia, I'd probably
start picking up a few Canadian idioms in my own speech. In that case of
speech, it's hard to avoid them; for language design, they only become
explicit by design. But they're still implicit influences.

So I think it's impossible that interesting things about Ruby, C#, Japanese,
and everything else out there would *not* be *an influence* to some degree. 

Language design is more fun than writing music because you can generalise the
good parts of your influences - if I ripped off one of Michael Nyman's vocal
lines, I'd be a plagiarist, but if I could find a way of ripping off the
*potential* to create vocal lines like his, then I've done something far more
valuable and interesting. (aside: Python is Mahler. Discuss.) So while we may
not end up doing things the way Ruby or Python does them, we'll certainly have
the ability to some something like them.

Or maybe we won't. There has to be some point to having other languages
around, after all. :)

-- 
What happens if a big asteroid hits the Earth?  Judging from realistic
simulations involving a sledge hammer and a common laboratory frog, we
can assume it will be pretty bad. - Dave Barry

Things have paused... really?

[Garrett Goebel]

From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 07:20 PM 2/19/2001 -0800, Edward Peschko wrote:
> >
> >The RFC project should be ongoing and more adaptive.
> 
> It's my understanding that this is, in fact, the plan. The 
> only reason things have paused (and it is a pause, not a
> stop) is that we're waiting for Larry to take what's been
> done so far and build something resembling a coherent base
> we can implement. After that's done then we'll have
> something to work from, which is a good thing.

This is perhaps the 3rd recent "waiting for Larry" comment posted in the
last week. I don't mind waiting... good things take time. But this mushroom
_is_ curious to hear if anyone has got wind of the current state of affairs?

I'm particularly curious to hear what if any ideas Larry will be
contributing beyond the herculean task of digesting, regurgitating, and
whipping Perl 5 + 361 RFC's of varying quality into a language
specification.

o  Will experiences from Ruby be assimilated back into Perl? 

o  What impact will C# and .NET have on Perl 6? Don't forget
   Larry's required reading recommendation:  
   http://windows.oreilly.com/news/hejlsberg_0800.html

o  Where will the foreign function interface be heading?

From: Larry Wall [mailto:[EMAIL PROTECTED]] 2000-11-01 7:06 PM
>
> The hope is to extend Perl's subroutine declaration
> syntax (via types and attributes) to the point where
> a "forward" declaration in Perl of a C, Java, or C#
> routine can supply all the glue information formerly
> supplied by XS.  While this will undoubtedly give us
> some rather strange looking Perl, I'd rather look at
> potentially strange Perl than certainly strange XS.

Re: Closures and default lexical-scope for subs

[Peter Scott]

At 05:27 PM 2/19/01 +, Piers Cawley wrote:
>Peter Scott <[EMAIL PROTECTED]> writes:
> > I don't want to DWIM this.  Would it be so bad to have to type
> >
> >  GetOptions (foo => \my ($foo),
> >  bar => \my $bar);
>
>If you're really all for maintainability, then surely you mean:
>
>GetOptions (foo => \my ($foo),
>bar => \my ($bar));
>
>otherwise some dumb hacker (eg. You, two weeks later) could come to
>add annother pair of args by sticking C<, baz => \my $baz> into the
>args list...

Yup, yup.

> >  tie my ($shoe) => $tring;
> >
> > if we made 'my' consistent with all other functions that take lists
> > (yes-I-know-it's-not-a-function)?
>
>Do you not *care* how ugly you're making something that was once
>compact, expressive and elegant?

Of course I care.  I just weighed the advantage (consistency, intuitiveness 
in the case of my $a, $b, $c which is far more common than either of the 
above) against the disadvantage and decided it was worth it, on 
balance.  Subscribers to different value systems may have different results.

>And if it's not a function then WTF
>do you want to make it look like one, potentially sowing more
>confusion.

I'd be happy to retract my position if someone would take the thing out of 
perlfunc then.  I'd really also like to see a more definitive description 
than "language construct" at the same time.
--
Peter Scott
Pacific Systems Design Technologies

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[Stephen P. Potter]

Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]> whispered
:
| Yep; the perl manpage has said, since time immemorial, that 
| the fact that -w was not on by default is a BUG.

I don't know that I would say time immemorial.  It wasn't in the man for
4.036.  I can only find man pages back to 5.002 right now, so I can't
check any earlier than that in the 5 tree.  However, it was meant to be
(more than) slightly tongue-in-cheek.

-spp

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[Bryan C . Warnock]

On Tuesday 20 February 2001 14:45, Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]> 
whispered
> :
> | Yep; the perl manpage has said, since time immemorial, that 
> | the fact that -w was not on by default is a BUG.
> 
> I don't know that I would say time immemorial.  It wasn't in the man for
> 4.036.  I can only find man pages back to 5.002 right now, so I can't
> check any earlier than that in the 5 tree.  However, it was meant to be
> (more than) slightly tongue-in-cheek.

And there's a difference between warnings originating because something has 
gone wrong and those originating because I'm doing something particularly 
perlish.  Unfortunately, -w doesn't (and probably can't) tell the 
difference.



A friend of mine was attempting to install some commercial program (a D&D 
character generator, IIRC) on a Windows box - one that didn't have a sound 
card.  It wouldn't run.  It always crashed while trying to talk to the 
sound card.  He procured someone else's laptop to do a demo install, and it 
ran fine - there are open and close window sound effects, and this 
voice-over guy that gives instructions.  The first instruction given in the 
setup box? If you'd like to turn off the voice, click this box.  Nothing 
else is sound dependent.  Somehow I think there's a lesson to be learned 
here.


-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[John Porter]

Bryan C. Warnock wrote:
> 
> And there's a difference between warnings originating because something has 
> gone wrong and those originating because I'm doing something particularly 
> perlish.  Unfortunately, -w doesn't (and probably can't) tell the 
> difference.

Can you give me an example of the former?
I can't think of any off the top of my head.

-- 
John Porter

Re: End-of-scope actions: Background.

[Graham Barr]

On Tue, Feb 20, 2001 at 03:49:13AM +, Simon Cozens wrote:
> On Mon, Feb 12, 2001 at 01:58:35PM -0700, Tony Olekshy wrote:
> > Hi, it's me again, the guy who won't shut up about exception handling.
> > I'm trying,
> 
> I'm catching.

And I'm thowing (up :)

Graham.

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[Bryan C . Warnock]

On Tuesday 20 February 2001 16:03, John Porter wrote:
> Bryan C. Warnock wrote:
> > 
> > And there's a difference between warnings originating because something 
has 
> > gone wrong and those originating because I'm doing something 
particularly 
> > perlish.  Unfortunately, -w doesn't (and probably can't) tell the 
> > difference.
> 
> Can you give me an example of the former?
> I can't think of any off the top of my head.

Scalar value @foo[$bar] better written as $foo[$bar], for one.

(But you probably would have thought of that if I had said something better 
than "something has gone wrong" which doesn't describe the above at all.  
I'm sorry, a completely horrible phrasing of what I was trying to say - 
I'll take me out back and shoot me now.)

I'll try this again - the difference between a perceived user error, and a 
misused perl construct.  The above error reflects an inability to 
distinguish between mulitple typos: either $foo or a list index.

If part of Perl's breeding is autovivication and interpretation of undef as 
0 or "" in the appropriate context, why should Perl bitch at me if I use it 
as such?  Why should I have to ask permission to do so?

I would rather say, and I think it would be more perlish to say, "I'm not 
feeling particularly perly today, can you check for anything clever, cause 
if there is, chances are it's a mistake."


-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[Bart Lateur]

On Tue, 20 Feb 2001 16:31:35 -0500, Bryan C. Warnock wrote:

>Scalar value @foo[$bar] better written as $foo[$bar], for one.

I agree on this one (hash slices too), if this expression is in list
context. There is no error in

@r = map { blah } @foo{$bar};

-- 
Bart.

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[John Porter]

What it boils down to is, warnings are for perl to tell you
when you probably made a logic error, based on the perl code
it sees.  What some people might think is merely unperlish
code, others might say is "horribly wrong".

-- 
John Porter

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[Edward Peschko]

On Tue, Feb 20, 2001 at 08:33:50PM -0500, Bryan C. Warnock wrote:
> On Tuesday 20 February 2001 19:34, Edward Peschko wrote:
> 
> > Well, for one, your example is ill-considered. You are going to get 
> > autovivification saying:
> 
> The two ideas were disjoint.  The example wasn't an example of autoviv.

well, I was thinking you were saying @foo[$bar] = 100;

> > Hence I'd say that @foo[$bar] has NO INTRINSIC VALUE whatsoever.
> 
> Correct, which is why I could care less if Perl warns me about it.

right, but which is the higher cost? 10 experienced people being inconvenienced
because they see a message they can easily avoid, or 1 people learning the
language not getting the benefits that they would otherwise get by seeing it.

If perl is squawking to you about something, it usually is because you've got
a misconception of some kind. In this case, the misconception is that something
like:

if (@tmp[1,4] == @tmp[2,5])
{
}

will work.

> > Second, with the keyword empty (if it comes to pass) the reasons for 
> > interpretation of undef as 0 and "" go away. Right now, things are a PITA 
> > to get empty values:
> > 
> > my ($a, $b, $c, $d, $e) = ('') x 5;
> 
> I *like* the interpretation of undef as 0 and "".  It's useful.  Sometimes.
> Sometimes it's not.  And that's fine.  

No that's NOT fine. It leads to 'find the needle in the haystack' sort of 
problems. If you get 1450 'use of undef value' errors, they are all useless.

If you get 10 of them, and you know that the only time you are going to get
'use of undef value' errors, they are very valuable. And how valuable they 
are grows as the size of your project increases.

> There's no reason in the world why that should replace undef -> 0 and "".

See above.

> > Or how about "I'm feeling particularly lazy today, I think I'll sleep in. 
> Lets
> > worry about any mistakes I might make another day."
> 
> Well, Laziness is One of the Three.

Exactly. Perl lets you be as lazy as you want. It just shouldn't do it by 
default, because warnings and strict are great teaching tools.

> Let me rephrase.
> Perl shouldn't bitch at me for valid perl.

'-q'.

Ed

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[Bryan C . Warnock]

On Tuesday 20 February 2001 22:03, Edward Peschko wrote:

> > I *like* the interpretation of undef as 0 and "".  It's useful.  
Sometimes.
> > Sometimes it's not.  And that's fine.  
> 
> No that's NOT fine. It leads to 'find the needle in the haystack' sort of 
> problems. If you get 1450 'use of undef value' errors, they are all 
useless.
> 
> If you get 10 of them, and you know that the only time you are going to 
get
> 'use of undef value' errors, they are very valuable. And how valuable 
they 
> are grows as the size of your project increases.
> 
> > There's no reason in the world why that should replace undef -> 0 and 
"".
> 
> See above.
> 
> > > Or how about "I'm feeling particularly lazy today, I think I'll sleep 
in. 
> > Lets
> > > worry about any mistakes I might make another day."
> > 
> > Well, Laziness is One of the Three.
> 
> Exactly. Perl lets you be as lazy as you want. It just shouldn't do it by 
> default, because warnings and strict are great teaching tools.
> 
> > Let me rephrase.
> > Perl shouldn't bitch at me for valid perl.
> 
> '-q'.

None of that is the point.
I don't disagree that having loads of warnings are a good thing.
I don't disagree that having strict parsing rules, variable declarations, 
and the ilk are a good thing.
There is no technical reason why warnings and strictness can't be the 
default.

You with me so far?  Everything you have said is perfectly valid, and if we 
were designing a brand-spanking new language, I might be arguing *for* you.
But we're not, we're tweaking Perl.  Perl, remember that language?  The 
language that advertised all the above laziness?  That the above laziness 
was part of its drawing power?

This isn't an addition to the language that you're talking about - it's 
changing some of the fundamental behavior of the language.  It's saying 
that no longer is Perl a loose, powerful language - oh, you want B&D? well, 
we can do that for you too - but rather that Perl is just another 
conventional programming language, (although if you flip this switch, 
you'll get its old, horrible behavior.) 

Sure, it will be easier to learn - it had better be, because 
*e-v-e-r-y-o-n-e* is going to have to learn it.  Again.

Look, most folks are probably sick of us going round and around about this, 
so I'll sum up my position.

1. There is no technical reason why warnings and strict can't be on by 
default, why undef must be able to promote to 0 or "", or just about any 
other feature a computer language can have.  No technical reason.  It may 
break some things, but those things can be fixed in their own right.

2. There are many non-technical reasons not to change codified behavior.  
This is why the last serious revamp of English spelling and grammar rules 
were aborted by the publication of the dictionary, why Americans adamantly 
refuse any doings with the metric system (except the 2 liter bottle), and 
why sports fans hate the instant replay.  To change what some consider the 
philosophical essence of Perl is akin to a bait-and-switch, and I, for one, 
would feel cheated, (and if you'll allow me to wax melodramatic, betrayed).

3. While the argument is internal to us, I will remain steadfast in my 
stance against any arbitrary, widespread reversal of the language.

4. Should the Perl cabal deem that, for Perl to improve, it *must* undergo 
these radical changes, I will, to the best of my meager abilities, attempt 
to implement them.

My position may seem a bit extreme - after all, didn't I, in the second 
RFC, attempt to autoprint statements in a void context?  I started in the 
middle of the road, but as arguments like this have continued, I've moved 
wy to the minimalist's side.  Hey, overhaul Perl to your heart's 
content so that you're able to do x, y, and z; just so long as Perl itself 
doesn't do x, y, and z.
 
-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[Edward Peschko]

> This isn't an addition to the language that you're talking about - it's 
> changing some of the fundamental behavior of the language.  It's saying 
> that no longer is Perl a loose, powerful language - oh, you want B&D? well, 
> we can do that for you too - but rather that Perl is just another 
> conventional programming language, (although if you flip this switch, 
> you'll get its old, horrible behavior.) 

I never said it was its 'old horrible' behaviour. We've got to stop thinking
about this as a religious issue. I have no qualms with people using something
like '-q', hell, I'll use it myself. The only thing is that it has a 
*huge cost*, this laxness by default. And the cost is not only technical:

1) diminished reputation.
2) misconceptions on news groups, mailing lists
3) wasted time, frustrations from users saying perl is 'quirky'
4) poorer quality of 3rd party modules, persistent bugs in them.
5) -w as pariah, ignored warnings.

In order to get the big, big, win. warnings have to be on by default, and they
have to be intuitive and easy enough to use by being on by default. 

If that means we clean up both warnings (getting rid of some of the sillier 
ones) and the method of using warnings up unto the point that they are flexible
enough *to* be included by default, well that's the price we will have to 
pay in order for it to work.

If it means that we turn on warnings && strict on by default and give it a 
'trial run' to get the perl community's feedback, get their positive feedback
and iterate that means we do that. Unlike most other changes that we decide
on, this one is *undoable*. If it doesn't work, and there is a big rebellion,
well, it doesn't work and there is a big rebellion. We say it was a noble 
experiment and move on. But if it *does* work, then great. 

There's no reason to feel betrayed - its a simple experiment: I think that this
is doable, and will help a lot. You think its not doable for cultural reasons.
Good - then let the culture decide. But don't sell it short until you've seen
it done. The least we get out of it is a cleaner, better warnings model and 
a 

Its all a matter of attitude, of selling people that its a good idea by not
forcing it down their throats but by presenting them with something and asking
them to use it, and getting their *opinion* on it. 

As for innovation, I really don't know of any language that helps users by 
pointing out potential mistakes...

And that's the last *I'm* going to say on the subject. I'm better off writing
RFC's...

Ed

Re: State of PDD 0

[Ask Bjoern Hansen]

On Tue, 20 Feb 2001, Bryan C. Warnock wrote:

> On Tuesday 20 February 2001 17:38, Ask Bjoern Hansen wrote:
> > 
> > I have created perl6-announce-pdd. Mail [EMAIL PROTECTED]
> > for clues.
> > 
> > How should the submission process work? As for the RFC's?
> 
> Can you confirm the actual submission address?  Are we using perl-pdd? And 
> did we want to make this Perl 6 specific, or Perl generic (like perl-qa is)?

Notify [EMAIL PROTECTED] after sending the (unnumbered) PDD to
perl6-internals and I will add it to the list.

Will be changed when the PDD traffic gets higher.


  - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day,