Re: Really auto autoloaded modules
On Mon, Feb 05, 2001 at 11:04:06PM -0500, Dan Sugalski wrote: Granted, if this was all done with trusted servers it would be really neat, but... TANSTAATS. -- I used to be disgusted, now I find I'm just amused. -- Elvis Costello
Re: assign to magic name-of-function variable instead of return
David L. Nicol wrote:
sub DirectBubbleSort(){
my ($i,$t) = (-1,0);
while (++$i = $#$__){
$$__[$i] $$__[1+$i] and $t++ and @$__[$i,1+$i] = @$__[1+$i,$i];
};
$t and @$__ = DirectBubbleSort;
}
@SomeList = DirectBubbleSort; # instead of DirectBubbleSort(\@SomeList)
If I saw a module like this, I wouldn't use it ever! I think I would even
`undef' all my variables explicitly before using them as lvalues, just in
case... Serious, man, that is a sick mind!
And I don't see what the problem with DirectBubbleSort(\@SomeList) is. It's
rather explicit, and is very clear about what is done. Using a (\@)
prototype on DirectBubbleSort would be ok too, since its name says right
what it does and everybody likes some vanilla syntax. But making it
@SomeList = DirectBubbleSort is the most error-prone thing I see! Nobody
will get it right on first use...
- Branden
Re: Really auto autoloaded modules
On Tue, Feb 06, 2001 at 12:49:28AM +0100, Bart Lateur wrote:
On Mon, 05 Feb 2001 11:35:59 -0500, Dan Sugalski wrote:
use autoload { Bar = 'http://www.cpan.org/modules/Bar' },
{ Baz = 'ftp://my.local.domain/perl-modules/Baz', VERSION =
2 };
Very good idea indeed!!! Append the wishlist to add this module to perl6's
standard library!!!
Very *bad* idea. It sounds nice, but using a remote module without any sort
of control is just begging for trouble.
and even if the script contains the MD5s or some other key for the modules
it trusts, what stops me cracking the ftp server, and modifying the script
so that it has the MD5s of my new "improved" versions.
Why write your worm in vbscript when perl gives you language features to
let you do it as a 1 liner?
[as currently doing something like opening a socket, and feeding that on
stdin to a child perl to read as a script will take more lines and be
more obvious what you're up to. Probably. Old example on request]
I agree. Plus, it strikes me as asking for trouble. It sounds make-ish.
So every time you run a script, it could actually *upgrade* your module
behind your back, without you checking it!
Quite. It's brilliant. I don't even need to crack your script to get past
your firewall. I steal someone else's signing key, sign a new version of
a legitimate module you're already using, and make that module use autoload
whatever I wanted to run. World domination is mine...
But, this discussion gives me yet another idea. Think of a module,
somewhat like the B::* modules. This one could check your script, and
prevent perl from running it, but instead try to install any modules
that you're missing. The installation itself of the modules could be
handled by (an extension of) CPAN.pm. Of course, it shouldn't upgrade,
i.e. replace, any previously installed modules without your explicit
consent.
I think it would have to run some of the remotely loaded untrusted module
as it would need to execute all the script's BEGIN code, hence everything
in the module that runs during use, as http://www.cpan.org/modules/Bar
might in turn require more modules.
But hopefully this is in a safe compartment, with untrusted modules run
from the build tree by pushing @INC each time, and presumably
optionally interactive:
Module Bar wants Foo version 1.3 or greater.
Should I download this from http://www.cpan.org/modules/Foo and build it
[Y/n]?
On the other hand you could avoid running the untrusted module by
iteratively repeating the process. Go 1 finds you have Bar missing, so you
stop, download, build, test, check that you trust it, install it
Restart, go 2 finds that Bar would like Foo
[although modules ought to be good and get their dependencies right in
Makefile.PL]
and so on. But this has the disadvantage that you don't know how much
you're letting yourself in for (in terms of new modules) until you've
already started committing them to your installed tree.
Nicholas Clark
Re: assign to magic name-of-function variable instead of return
James Mastros wrote: On Mon, Feb 05, 2001 at 08:43:02PM +0100, [EMAIL PROTECTED] wrote: On Mon, Feb 05, 2001 at 11:46:48AM -0500, James Mastros wrote: By the time you get to the last line, you've already forgoten WTF you named the return variable. Eh, I don't think that bad memory, or a bad variable naming scheme justifies this new feature. A new feature doesn't need that much justification. And nobody is advocating getting rid of "return". Yes it does. Otherwise, we get even more bloated than now! - Branden
Re: a name for the currently executing sub
On Mon, Feb 05, 2001 at 11:15:41PM -0500, Dan Sugalski wrote: This isn't really what I'd consider a good thing, but raw memory access in perl would be convenient. There'll probably be a special type of reference that lets you do that. (Only needs a few changes to the vtable code, too) It's certainly possibly to read raw memory with suitable (ab)use of pack and unpack in perl (P and p) I can't remember if it's possible to write to raw memory, and I'm not currently on an operating system where I can test this sensibly. But it's not obvious, safe or portable. Nicholas Clark
Re: assign to magic name-of-function variable instead of return
[EMAIL PROTECTED] wrote: Hmmm. If there's such an "always" block, I'd like to see it on all blocks, including the continue [1]. But then, it becomes hard to figure out to which block the always belongs That's precisely why these things should be shoved inside rather than dangling off the end. JMHO. -- John Porter
Re: Really auto autoloaded modules
Simon Cozens wrote: Whether it's a good idea or a bad idea is largely irrelevant; the purpose of -language is to decide whether or not it should be possible. I think historically this has not been the case. But I suppose we could change the purpose of -language mid-stream... -- John Porter Ann wenno haddum billizac...
Re: Really auto autoloaded modules
At 08:44 AM 2/6/2001 +, Simon Cozens wrote: On Mon, Feb 05, 2001 at 11:04:06PM -0500, Dan Sugalski wrote: Granted, if this was all done with trusted servers it would be really neat, but... TANSTAATS. Cute, but not entirely true. There are an awful lot of servers off the internet that can be reasonably trusted, which is the frustrating part about the suggestion--for those, it'd be great. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Really auto autoloaded modules
At 08:44 AM 2/6/01 +, Simon Cozens wrote: On Mon, Feb 05, 2001 at 11:04:06PM -0500, Dan Sugalski wrote: Granted, if this was all done with trusted servers it would be really neat, but... TANSTAATS. Not even with the appropriate amount of PKI/X.509 hand-waving? -- Peter Scott Pacific Systems Design Technologies
Re: assign to magic name-of-function variable instead of return
John Porter wrote:
[EMAIL PROTECTED] wrote:
Hmmm. If there's such an "always" block, I'd like to see it on
all blocks, including the continue [1]. But then, it becomes
hard to figure out to which block the always belongs
That's precisely why these things should be shoved inside rather
than dangling off the end. JMHO.
I think "always" should be part of an explicit statement, such
as "try", not some implied property of block structure introduced
by a dangling clause (inside or outside).
Once you have an always clause, it has to be invoked during stack
unwinding caused by the raising of an exception. This means there
is an implied goto-on-exception pending throughout the scope
affected by the always clause. This is not like if/else, for, or
while, which are all marked up front, and only have explicit variant
flow control. It is like eval, but note that eval is marked up
front too.
Like eval, the beginning of the scope for non-local flow control
(such as always and catch) should be explicitly delimited, typically
by using a keyword like try. Consider the following two cases:
foreach ... { try { ... } catch { ... } finally { ... } }
try { foreach ... { ... } } catch { ... } finally { ... }
now take out the statement keyword and use magic dangling clauses:
foreach ... { { ... } catch { ... } finally { ... } }
{ foreach ... { ... } } catch { ... } finally { ... }
The signal to noise ratio has gone down, no?
In fact, the cross product of these cases and the alternatives for
dangling always block placement produce these four cases:
foreach ... { ... catch { ... } always { ... } }
{ foreach ... { ... } catch { ... } always { ... } }
foreach ... { ... } catch { ... } always { ... }
{ foreach ... { ... } } catch { ... } always { ... }
Now play the problem backwards. Say you run into one of the
cross-product constructs in some code. Is it clear to you what
the scope and semantics are? Is it clear when always applies
to the foreach block, and when it applies to the catch block,
and when it applies to the foreach statement?
What about the try/finally cases? It's pretty clear, IMHO,
that the catch and finally clauses apply to the try statement,
simply because try is a statement of which they are part. At that
point, the body of the try block and any previous catch or finally
blocks that are part of the same try statement are apparent. The
previous blocks are critical, because under various circumstances
blocks need to be triggered by exceptions raised in previous
blocks.
From a psychology of programming languages perspective, wrapping the
whole mechanism up into a statement per se provides the foundation
upon which we can attempt to avoid the conceptual disaster produced
by dangling clauses. Mixing up traditional sequential flow-control
constructs and non-local stack-unwinding flow-control constructs,
without clearly delimiting what you're doing, is (I think) a less
than optimal idea.
Remember that one of the main uses for catch and always clauses is
error handling (as in, close file if opened even if error during
processing thereof). I don't like language constructs that obfuscate
my attempts to get error handling right (such as they are) because
errors in error handling tend to make my code behave relatively poorly.
Yours, c, Tony Olekshy
PS: since we're completely off subject, can we continue this under
http:[EMAIL PROTECTED]/msg05604.html
