use less in perl6?
Yuval Kogman
hinting of tradeoff preferences. For example:
use less precision; # the default nums created in this scope are
# lower precision floats
use less cpu; # many places this can have a desired effect
use less memory; # especially in the underlying impls of
# structures
use less stuff; # might have a meaning for a library
Mostly I think it's a matter of just controlling the default parrot
PMC implementations underlying the structures. Aside from that there
might be some other, perhaps more global settings.
IMHO perl6 should allow some control over these. Here's where the
design comes in:
control over lexical scoped params, vs. application wide ones
granuality of control and it's coupling to parrot
control from the perspective of the user of a library - who is
responsible? how is that expressed? is it per context? per
object? per scope? globally scoped?
how is it future proofed? i'd like to tell a piddle impl i want
some behavior, and I'd like my program to exploit it if i
subsequently update the piddle implementation, and it suddenly
learns what i mean.
How should this stuff be expressed? 'use less' is cute, but i don't
think it really gets there.
Perhaps this interface, or it's principals should also allow
similarly controlled debugging/tracing. Usually when trying to look
inside a big app, you are only concerned about a specific part. I
think this is very analogeous to optimization hints:
sometimes you want to override it form the command line
sometimes you only want it to apply to calls from a certain
place
sometimes you want to enable it from within the code it applies
to, and sometimes outside of it
you often want a volume knob for this behavior
you want several instances of usage to not conflict
I'd like to see what the design team can do about this.
Ciao!
--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me groks YAML like the grasshopper: neeyah!!!!!!
Aaron Sherman
> Perl 6 has some more interesting capabilities for lexical scoped
> hinting of tradeoff preferences. For example:
>
> use less precision; # the default nums created in this scope are
> # lower precision floats
>
> use less cpu; # many places this can have a desired effect
> use less memory; # especially in the underlying impls of
> # structures
>
> use less stuff; # might have a meaning for a library
Hmmm.. I wonder what this would do:
use less syntax;
;-)
Matt Fowles
Back out the entire p6 grammar and put in lisp's instead...
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???
Herbert Snorrason
> On Wed, 30 Mar 2005 08:48:55 -0500, Aaron Sherman <a...@ajs.com> wrote:
> Back out the entire p6 grammar and put in lisp's instead...
--
Schwäche zeigen heißt verlieren;
härte heißt regieren.
- "Glas und Tränen", Megaherz
Larry Wall
: How should this stuff be expressed? 'use less' is cute, but i don't
: think it really gets there.
It's mostly there as a placeholder for all the "true pragmas" that
can be ignored if you don't understand them, an idea I originally
stole from Ada. We sort of got away from that notion in Perl 5,
but it'd be nice if we could have some way of recognizing hints that
can be ignored if unrecognized. That was the original intent of the
uppercase/lowercase distinction in "use", but we lost the distinction
somewhere along the way. At least we've gotten rid of "use overload".
Maybe we can reclaim the lowercase modules for futureproofed hinting,
or establish some other convention. I agree that "use less" ain't it.
: Perhaps this interface, or it's principals should also allow
: similarly controlled debugging/tracing. Usually when trying to look
: inside a big app, you are only concerned about a specific part. I
: think this is very analogeous to optimization hints:
:
: sometimes you want to override it form the command line
:
: sometimes you only want it to apply to calls from a certain
: place
:
: sometimes you want to enable it from within the code it applies
: to, and sometimes outside of it
:
: you often want a volume knob for this behavior
:
: you want several instances of usage to not conflict
:
: I'd like to see what the design team can do about this.
Welcome to the design team. Have at it. :-)
This problem seems to be a generalization of the earlier discussion
about turning warnings on or off in lexical vs dynamic scopes.
Larry