"Don't tell me what I can't do!"
Jonathan Lang
effect of including syntax that forbids otherwise valid code from
being used. First was during the discussion about coming up with a
way to program by contract, where the poster suggested that a means of
saying "any declaration of method 'm' that doesn't conform to this
signature should be illegal"; the second was in a recent thread
concerning roles where a poster commented that he'd like to be able to
declare in role 'A' that anything composing it should be forbidden
from composing role 'B' also.
I'm not used to programming styles where a programmer intentionally
and explicitly forbids the use of otherwise perfectly legal code. Is
there really a market for this sort of thing?
--
Jonathan "Dataweaver" Lang
Jerry Gay
> I'm not used to programming styles where a programmer intentionally
> and explicitly forbids the use of otherwise perfectly legal code. Is
> there really a market for this sort of thing?
>
Craig DeForest
The advantage of "use strict" is that it is purely advisory. If
you're about to do something
sleazy and you know it, you can always use the escape hatch of "{no
strict; ... }".
Any such restrictions that a coder places on future users of his code
or template should also be
advisory. One big advantage of Perl 5 is that there is an advisory
class structure that can
be overridden in cases of extreme need, even when the original coder
clearly intended that you
never override the interface. (an example is DBI, which wraps its
objects up inside tied hashes simply to prevent access to the inside
by less-than-determined coders)
Restrictions are useful for code style control, but mainly as
markers: "Here be dragons", or whatever. For the case of someone who
wants that (Jonathan's words) "any declaration of method 'm' that
doesn't conform to this signature should be illegal", it should be
possible for the method coder to override that restriction by taking
some explicit action in the source. Otherwise we'll have the
programming equivalent of evil no-fast-forward previews on DVDs.
Jonathan Lang
> Jonathan Lang wrote:
> > I'm not used to programming styles where a programmer intentionally
> > and explicitly forbids the use of otherwise perfectly legal code. Is
> > there really a market for this sort of thing?
>
> use strict;
Hmm... granted. But that does tend to sidestep the main thrust of my
question.
The examples I gave involved specific roles or routines being
forbidden from use in certain situations; my gut instinct is that if
you don't think that it's appropriate to use a particular role or
routine somewhere, you should simply not use it there; I can't see why
you'd want the compiler or runtime to enforce not using it there.
--
Jonathan "Dataweaver" Lang
Andy Armstrong
> The examples I gave involved specific roles or routines being
> forbidden from use in certain situations; my gut instinct is that if
> you don't think that it's appropriate to use a particular role or
> routine somewhere, you should simply not use it there; I can't see why
> you'd want the compiler or runtime to enforce not using it there.
Some of the discussion you're referring to reminded me of 'final' in
Java. Declaring a class 'final' means it can't be subclassed. In Java
there are two reasons for that - optimisation and security.
java.lang.String is final so the compiler and runtime can optimise
string operations without worrying about handling String subclasses -
i.e. it allows knowledge of java.lang.String's interface to hard
coded into the compiler / runtime.
The security angle is that it prevents the creation of subclasses
that can circumvent security restrictions in the base class.
I wonder if some of the debate here was informed by the perception
that 'final' is a valuable feature in Java whereas actually it's a
hacky bodge to solve a couple of language design problems?
--
Andy Armstrong, hexten.net
Smylers
That's different: it's _you_ that's forbidding things that are otherwise
legal in your code; you can choose whether to do it or not.
Jonathan's examples were all of _somebody else_ forbidding you from
doing otherwise-legal things; you have this imposed on you without
choice.
Smylers
Dave Whipp
>>use strict;
>
> That's different: it's _you_ that's forbidding things that are otherwise
> legal in your code; you can choose whether to do it or not.
Which suggests that the people wanting to specify the restrictions are
actually asking for a way to specify additional strictures for users of
their modules, which are still controlled by /[use|no] strict/. While it
is true that any module is free to implement its c<import> method to
allow its users to specify a level of strictness, it would be nice to
abstract this type of thing into the "use strict" mechanism.
Jonathan Lang
Before we start talking about how such a thing might be implemented,
I'd like to see a solid argument in favor of implementing it at all.
What benefit can be derived by letting a module specify additional
strictures for its users? Ditto for a role placing restrictions on
the classes that do it.
--
Jonathan "Dataweaver" Lang
Dave Whipp
> Before we start talking about how such a thing might be implemented,
> I'd like to see a solid argument in favor of implementing it at all.
> What benefit can be derived by letting a module specify additional
> strictures for its users? Ditto for a role placing restrictions on
> the classes that do it.
Or we could view it purely in terms of the design of the core "strict"
and "warnings" modules: is it better to implement them as centralised
rulesets, or as a distributed mechanism by which "core" modules can
register module-specific strictures/warnings/diagnostics. If it makes
sense for the core strictures to be decentralized, then the ability for
non-core modules to make use of the same mechanism comes almost for free
(and therefore it doesn't need much justification beyond the fact that
some people think it might be a nice toy to use, abuse, and generally
experiment with).
Jonathan Lang
> Or we could view it purely in terms of the design of the core "strict"
> and "warnings" modules: is it better to implement them as centralised
> rulesets, or as a distributed mechanism by which "core" modules can
> register module-specific strictures/warnings/diagnostics.
Question: if module A uses strict, and module B uses module A, does
module B effectively use strict? I hope not.
I was under the impression that pragmas are local to the package in
which they're declared. If that's the case, then pragmas will not
work for allowing one module to impose restrictions on another unless
there's a way to export pragmas.
--
Jonathan "Dataweaver" Lang
Dave Whipp
I think your hopes are fulfilled: stricness is not transitive. However,
that's not what I was suggesting. What I was suggesting was that if
Module A uses "strict", and Module A uses something from Module B, then
Module B should be able to do additional checks (at either runtime or
compile time) based on the strictness of its caller. For example I might
write:
use strict;
my Date $date = "29 February 2001";
and get a compile time error (or perhaps warning); but without the "use
strict" the Date module might interpret the string (which comes from
it's caller) as "1 March 2001".
Larry Wall
: Dave Whipp wrote:
: >Or we could view it purely in terms of the design of the core "strict"
: >and "warnings" modules: is it better to implement them as centralised
: >rulesets, or as a distributed mechanism by which "core" modules can
: >register module-specific strictures/warnings/diagnostics.
:
: Question: if module A uses strict, and module B uses module A, does
: module B effectively use strict? I hope not.
:
: I was under the impression that pragmas are local to the package in
: which they're declared.
Yes, pragmas (and indeed all imports) are lexically scoped by default, but...
: If that's the case, then pragmas will not
: work for allowing one module to impose restrictions on another unless
: there's a way to export pragmas.
...S01 also very plainly says:
It must be possible to write policy metamodules that invoke other
modules on the user's behalf.
The point is, a single "use" statement can turn Perl 6 into any other
language, and the main point of that other language might even be to
tell you what you can't do.
You might say that every Perl 6 program is guaranteed to be written in
Standard Perl 6--but only up till the first "use". From that point,
Perl 6 is a family of languages, the definition of which can only
be as accurate as our naming system. (Which is why module names now
include version and authority.) The sequence of use statements defines
the language just as a URL defines a location in cyberspace.
Larry
Luke Palmer
> and explicitly forbids the use of otherwise perfectly legal code. Is
> there really a market for this sort of thing?
This reminds me of the endless student "proofs" that trisect the angle
using euclidean geometry; i.e. the fact that people won't accept that
you can prove something is impossible.
The same philosophy applies here: if you don't allow code that forbids
other code from doing something, then you are forbidding code from
doing something, violating your own principle.
However, all this philosophical gobbledygook doesn't mean much in the
real world.
Another interesting note is that you could consider a policy-based
object model to be forbidding certain code. But I prefer to think of
it as a more accurate definition: "you are not a hatter unless the
hats you make are hats".
Luke
Chromatic
> Before we start talking about how such a thing might be implemented,
> I'd like to see a solid argument in favor of implementing it at all.
> What benefit can be derived by letting a module specify additional
> strictures for its users? Ditto for a role placing restrictions on
> the classes that do it.
Benefit #1: incompetent programmers who really really need to write
mission-critical code (the ones that the Java designers apparently had in
mind) now have only a million ways to write terrible code.
Uh, that's it.
-- c
Aaron Sherman
> I'm not used to programming styles where a programmer intentionally
> and explicitly forbids the use of otherwise perfectly legal code. Is
> there really a market for this sort of thing?
>
use strict;
Jerry Gay
http://groups.google.com/group/perl.perl6.language/tree/browse_frm/thread/56eeca9620d8c054/7f1d0eae0add6e96?rnum=1&_done=%2Fgroup%2Fperl.perl6.language%2Fbrowse_frm%2Fthread%2F56eeca9620d8c054%2F7f1d0eae0add6e96%3Ftvc%3D1%26#doc_fef40e484e8b3acf
or http://xrl.us/r2nz
~jerry
Aaron Sherman
First of all, sorry for replying to the earliest message in this thread
last night with what was obviously a redundant message. I was skimming
mail last night.
Second, I think everyone needs to grab some fresh air and relax. Perl
will be Perl when we're done. Everyone's agreed on that, and it's not
going to change.
The proposal that I made, and others that have been making are attempts
to allow certain types of programming paradigms. This is a good thing,
and plays well into the inclusiveness of Perl.
Would there be such tools used in the core libraries? Maybe, maybe not,
we could discuss that. If they were implemented in the core libraries
would there be a universal "no bondage" flag that shut them off?
Probably, since that's something that Perl tends to like doing.
Now, Larry has asked that we focus on getting 6.0 out the door, and let
details like this set until there's some clarity of implementation. I
think that's a great idea, mostly because there are bigger fish to fry
right now.
Chromatic
> Would there be such tools used in the core libraries? Maybe, maybe not,
> we could discuss that. If they were implemented in the core libraries
> would there be a universal "no bondage" flag that shut them off?
> Probably, since that's something that Perl tends to like doing.
The assumption I remember from the design meetings was always "No library
designer has the knowledge or the right to tell me how fast or strict my
program has to run." Whatever B&D you do in the privacy of your own modules
is fine, but if it leaks out past encapsulation boundaries, expect that
somewhere you might offend community standards.
In my opinion,Perl 6 should spell "no bondage":
#!/usr/bin/perl6
-- c
Trey Harris
> The assumption I remember from the design meetings was always "No library
> designer has the knowledge or the right to tell me how fast or strict my
> program has to run." Whatever B&D you do in the privacy of your own modules
> is fine, but if it leaks out past encapsulation boundaries, expect that
> somewhere you might offend community standards.
Yes, but by the same token, no library designer should force you to be
*less* strict than you wish to. I remember not so many years ago when
there were a lot of modules floating around that required you to do "no
strict" of various flavors in order to use them. I still run across
modules that need "no warnings". (I won't name names, because some of
their authors post to this list ;)
It should at the very least be *possible* to write modules that can be
used in every level of strictness from one-liners to
every-possible-stricture, everything-typed, everything-contracted systems.
If it's fairly easy to do, so much the better--there's a better chance
that you won't have to fork somebody else's module to get it to work with
the level of B&D you want.
As for the core--in DBC, which is what started this thread in the first
place, the compiler and runtime do various correctness inferences based on
contracts. If you call some code that doesn't have a contract, you can
either blow up, or you can just assert that the code you're calling is
correct--at which point you can no longer guarantee your own contract.
It's not a stricture that can be lexically toggled off and on like a
pragma.
So if Perl 6 is going to support DBC, the core needs to support DBC too.
Nobody is forcing you to use DBC in order to use the core modules, though.
In fact, most DBC systems I'm aware of run in production with
contract-checking turned off; the checks are for testing and debugging.
So even DBC programs themselves have to be able to run at a lower level of
strictness.
> In my opinion,Perl 6 should spell "no bondage":
>
> #!/usr/bin/perl6
No, it should spell "no more, or less, bondage than you want".
Trey
Jesse
That's really a pity. I'd very much like the rope to be able to build
'strict::with::pride' like tools....to say nothing of being able to
build my own private 'taint'.
One of the things that many shops have defected from Perl to Java for
is the additional handcuffs that Java provides for less-than-experienced
developers. Giving me the power to control what my team, or folks using
my language variant, do could be a huge win.
But hey, if you don't want to use those libraries, that's cool.
-j
Chromatic
> One of the things that many shops have defected from Perl to Java for
> is the additional handcuffs that Java provides for less-than-experienced
> developers. Giving me the power to control what my team, or folks using
> my language variant, do could be a huge win.
The point is that the person writing the program decides which handcuffs or
costumes all of the code has to wear, not the person writing the libraries.
If you want to set a policy for your organization, that's fine. It is just
Not Okay for me or anyone to write a module right now that dictates exactly
the strictness of every program written in the next twenty years that uses
it.
-- c
Chromatic
> Perhaps I'm misunderstanding what you mean by "person writing the
> program" and "person writing the libraries." In fact, I've _gotta_
> be. I'd like to be able to put my strictures in a library rather than
> forcing them into the main body of a program. Are you saying
> you don't want to let people do this?
Let me rephrase. Libraries and modules can be as strict or as lax as they
like, but the program *using* those libraries and modules should always be
able to override those strictures. If you write a class in a library and
declare it as closed, that's fine -- but any program that uses the class
should always have the option of saying "Nope, not closed. I need to do
something with it."
It's the person *using* the libraries and modules and classes who knows how
strict they need to be, how closed they need to be, and how optimized they
need to be. If any of those policies are irreversible--if they leak out of
libraries and modules and classes--then there is a problem.
-- c
Jesse
So, you're in favor of Perl 6 not having a "use strict;"? Or are you in
favor of there being only one true strict?
Perhaps I'm misunderstanding what you mean by "person writing the
program" and "person writing the libraries." In fact, I've _gotta_
be. I'd like to be able to put my strictures in a library rather than
forcing them into the main body of a program. Are you saying
you don't want to let people do this?
Jesse
> -- c
>
--
Chromatic
> Ok. So, I think what you're saying is that it's not a matter of "don't let
> people write libraries that add strictures to code that uses those modules"
> but a matter of "perl should always give you enough rope to turn off any
> stricture imposed on you by external code."
>
> Do I have that right?
Yes. You might also add "... or enable further strictures", but that sounds
like what I was trying to say.
-- c
Trey Harris
> On Wed, Oct 04, 2006 at 12:01:22PM -0700, chromatic wrote:
>> The point is that the person writing the program decides which handcuffs or
>> costumes all of the code has to wear, not the person writing the libraries.
>> If you want to set a policy for your organization, that's fine. It is just
>> Not Okay for me or anyone to write a module right now that dictates exactly
>> the strictness of every program written in the next twenty years that uses
>> it.
>
> program" and "person writing the libraries." In fact, I've _gotta_
> be. I'd like to be able to put my strictures in a library rather than
> forcing them into the main body of a program. Are you saying
> you don't want to let people do this?
I read it as "yes, you *can* put strictures on the using code into a
library, though I wouldn't do it and would say that any module that does
so shouldn't be released on CPAN for general use. But even if you can do
that, you *must* always be able to turn the strictures back off."
chromatic, is that a fair paraphrase?
I don't have any problem with that sentiment--if I were you and needed to
enforce some style on other programmers who work with me, I'd just tell
them to use my library and not unuse it. It's a human problem, not a
technical one, if they insist on unusing it by nefarious means.
That philosophy doesn't present any problems with DBC checks, which as I
mentioned before probably have to handled as a program-global flag rather
than as a lexical pragma anyway. (I'm toying with the notion of
"jurisdictions" that packages could subscribe to across which a set of
contracts would be enforceable, allowing them to do DBC while still using
or being used by code out in some other lawless jurisdiction. Code that
doesn't explicitly join some jurisdiction would by default be lawless,
thus living by the philosophy chromatic's espousing. I think that could
be made to work, though jurisdictions would have to be at a package, not
scope, level. I need to think about it more, though.)
Trey
Chromatic
> I read it as "yes, you *can* put strictures on the using code into a
> library, though I wouldn't do it and would say that any module that does
> so shouldn't be released on CPAN for general use. But even if you can do
> that, you *must* always be able to turn the strictures back off."
> chromatic, is that a fair paraphrase?
Yes.
> I don't have any problem with that sentiment--if I were you and needed to
> enforce some style on other programmers who work with me, I'd just tell
> them to use my library and not unuse it. It's a human problem, not a
> technical one, if they insist on unusing it by nefarious means.
Very much so. It seems silly to put up barriers such that clever people have
to use ugly and hackish tricks to do clever things while attempting to use
technology to solve the social problem of other people doing really bad
things. If you violate my first law of software development ("Don't hire
monkeys!"), then you should at least follow its corollary ("Train your
monkeys well and watch them very carefully. Note how unfulfilling your life
is for violating the first law.").
> That philosophy doesn't present any problems with DBC checks, which as I
> mentioned before probably have to handled as a program-global flag rather
> than as a lexical pragma anyway. (I'm toying with the notion of
> "jurisdictions" that packages could subscribe to across which a set of
> contracts would be enforceable, allowing them to do DBC while still using
> or being used by code out in some other lawless jurisdiction. Code that
> doesn't explicitly join some jurisdiction would by default be lawless,
> thus living by the philosophy chromatic's espousing. I think that could
> be made to work, though jurisdictions would have to be at a package, not
> scope, level. I need to think about it more, though.)
That sort of thing ought to be quite possible, but the less work we spend on
giving people the illusion that this discipline is inescapable and perfectly
capable, the more time we'll have to tell them how to avoid hiring monkeys,
which actually fixes more problems in software development than anything else
I've ever seen.
-- c
Aaron Sherman
> I read it as "yes, you *can* put strictures on the using code into a
> library, though I wouldn't do it and would say that any module that does
> so shouldn't be released on CPAN for general use. ..."
Hey, I have an idea. Let's write a module that enforces that!
Seriously, I think you're all getting way too wound up about this. No
one is going to force you to eat your peas. ;)
Jesse
Ok. So, I think what you're saying is that it's not a matter of "don't let
people write libraries that add strictures to code that uses those modules"
but a matter of "perl should always give you enough rope to turn off any
stricture imposed on you by external code."
Do I have that right?
>
> -- c
>
--
Jesse
Ah. Then I'm in violent agreement. Excellent.
> -- c
>
--
Jonathan Lang
Consider the following idea, bearing in mind that chromatic will
probably consider it to be a waste of time and that we shouldn't hold
up the release of p6 in order to develop it even if it's deemed
acceptable:
A 'policy' is a thing which places restrictions on what the programmer
can do. Policies can be named or anonymous. Named policies can be
exported. A module that exports policies is also known as a contract.
As a means of making this easier, a 'contract' trait exists for
modules which applies the 'export' trait to all policies found within.
Proper use of policies is to define them in a contract, then import
them into the appropriate lexical scope with 'use' - this lets you
deport them later (using 'no') when you no longer want their
restrictions.
Example:
module strict is contract;
policy vars { ... }; # Handwavium for the definition of a policy
named 'vars'.
...
# EOF
# somewhere in another module:
use strict; # imposes all of strict's policies on this lexical scope.
...
{
no strict <vars>; # rescinds the 'vars' policy within this codeblock.
...
}
AFAICT, this can't be done using the current toolkit, as there's
nothing akin to policy definition. Compared to that, adding a
'contract' trait is trivial.
Alternatively, contracts could be promoted to the same level as
classes and modules, with a keyword of their own and an additional
requirement that policy definition must occur within a contract.
You'd still make use of a policy by importing it from a contract where
appropriate, and all that would change in the above example would be
that the first line would change to "contract strict;" Another
benefit of this approach is that it might be possible to say that a
contract is exempt from its own policies; you have to import policies
from a contract in order for them to take effect. This keeps contract
writers from having to abide by the policies that they're writing
while they write them.
--
Jonathan "Dataweaver" Lang
Smylers
> In a message dated Wed, 4 Oct 2006, chromatic writes:
>
> > The assumption I remember from the design meetings was always "No
> > library designer has the knowledge or the right to tell me how fast
> > or strict my program has to run." Whatever B&D you do in the
> > privacy of your own modules is fine, but if it leaks out past
> > encapsulation boundaries, expect that somewhere you might offend
> > community standards.
>
> Yes, but by the same token, no library designer should force you to be
> *less* strict than you wish to.
Sure.
> I remember not so many years ago when there were a lot of modules
> floating around that required you to do "no strict" of various flavors
> in order to use them.
Really? How?
> I still run across modules that need "no warnings". (I won't name
> names, because some of their authors post to this list ;)
Again, I can't see how. If you use C<use warnings> in your program then
it is lexically scoped and only affects your code, not that of other
files you load in.
C<-w> does affect all files, but that's one of the reasons why C<use
warnings> is an improvement over C<-w>, because it lets the author of
each bit of code have control over it.
Smylers
Trey Harris
> Trey Harris writes:
>> I remember not so many years ago when there were a lot of modules
>> floating around that required you to do "no strict" of various flavors
>> in order to use them.
>
> Really? How?
I wrote imprecisely. Not to "use" them in the sense of C<use Package>,
but "use" in the sense of make use of them as described in the perldoc's
synopsis--usually by dint of requiring undeclared package variables,
barewords, or symbolic refs. Alias is one example, there were others.
You could always work around, but the docs assumed you had strictures
turned off, so you were left to your own devices to determine what
internal implementation decision was leading to problems operating under
your level of stricture. (For example, a package that had string
constants defined as subroutines like C<sub ERRCODE() { "ERRCODE" }> would
behave differently than one that assumed barewords would work, but both
might use identical examples of C<moose ERRCODE> in their perldocs.)
>> I still run across modules that need "no warnings". (I won't name
>> names, because some of their authors post to this list ;)
>
> Again, I can't see how. If you use C<use warnings> in your program then
> it is lexically scoped and only affects your code, not that of other
> files you load in.
Again, I meant in code use, not in just loading--uninitialized value
warnings being the main culprit there.
> C<-w> does affect all files, but that's one of the reasons why C<use
> warnings> is an improvement over C<-w>, because it lets the author of
> each bit of code have control over it.
Yes indeed.
Trey
Smylers
> In a message dated Wed, 4 Oct 2006, Smylers writes:
>
> > Trey Harris writes: T
> >
> > > I remember not so many years ago when there were a lot of modules
> > > floating around that required you to do "no strict" of various
> > > flavors in order to use them.
> >
> > Really? How?
>
> I wrote imprecisely. Not to "use" them in the sense of C<use Package>,
> but "use" in the sense of make use of them as described in the perldoc's
> synopsis
No, your words were fine -- you successfully conveyed that meaning but
was still puzzled by it.
> --usually by dint of requiring undeclared package variables,
> barewords,
How can a module require undelcared package variables? Surely a module
simply requires package variables, then it's up to you whether you
declare them or not?
> or symbolic refs.
I hadn't thought of that. Have you got an example of that? I'm still a
little surprised to hear there were "a lot of modules floating around"
doing this sort of thing.
> Alias is one example, there were others.
I've never used Alias, but from looking at its synposis I'd've thought
that judicious use of C<our> would permit code using the module to run
with C<use strict>.
> (For example, a package that had string constants defined as
> subroutines like C<sub ERRCODE() { "ERRCODE" }> would behave
> differently than one that assumed barewords would work, but both might
> use identical examples of C<moose ERRCODE> in their perldocs.)
Gotcha. So a user of the latter module could put the error codes in
quotes to keep with C<use strict>, it's just that the module docs didn't
make this clear? That sounds more like a documentation glitch than a
module which requires you to use C<no strict>.
> > > I still run across modules that need "no warnings". (I won't name
> > > names, because some of their authors post to this list ;)
> >
> > Again, I can't see how. If you use C<use warnings> in your program then
> > it is lexically scoped and only affects your code, not that of other
> > files you load in.
>
> Again, I meant in code use,
Sure.
> not in just loading--uninitialized value warnings being the main
> culprit there.
But any variable that I define I can initialize to prevent that warning
being emitted by my code. And since C<use warnings> is lexical, it
doesn't matter what the module's code does, that won't emit warnings
just because I've enabled them in my code that uses the module.
Smylers