Re: Don't tell me what I can't do!
Trey Harris writes:
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 Cuse 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 Cour would permit code using the module to run
with Cuse strict.
(For example, a package that had string constants defined as
subroutines like Csub ERRCODE() { ERRCODE } would behave
differently than one that assumed barewords would work, but both might
use identical examples of Cmoose ERRCODE in their perldocs.)
Gotcha. So a user of the latter module could put the error codes in
quotes to keep with Cuse 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 Cno 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 Cuse 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 Cuse 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
Re: Don't tell me what I can't do!
In a message dated Wed, 4 Oct 2006, Smylers writes:
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 Cuse 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 Csub ERRCODE() { ERRCODE } would
behave differently than one that assumed barewords would work, but both
might use identical examples of Cmoose 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 Cuse 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 Cuse
warnings is an improvement over C-w, because it lets the author of
each bit of code have control over it.
Yes indeed.
Trey
Re: Don't tell me what I can't do!
Trey Harris writes: 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 BD 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 Cuse 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 Cuse warnings is an improvement over C-w, because it lets the author of each bit of code have control over it. Smylers
Re: Don't tell me what I can't do!
On Wed, Oct 04, 2006 at 12:43:04PM -0700, chromatic wrote: On Wednesday 04 October 2006 12:09, jesse wrote: 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. 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 --
Re: Don't tell me what I can't do!
On Wed, Oct 04, 2006 at 01:04:45PM -0700, chromatic wrote: On Wednesday 04 October 2006 12:48, jesse wrote: 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. Ah. Then I'm in violent agreement. Excellent. -- c --
Re: Don't tell me what I can't do!
chromatic wrote:
jesse wrote:
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.
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
Re: Don't tell me what I can't do!
On Tuesday 03 October 2006 10:06, Aaron Sherman wrote: 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 BD 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
Re: Don't tell me what I can't do!
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 BD 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 BD 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
Re: Don't tell me what I can't do!
On Wed, Oct 04, 2006 at 12:50:16AM -0700, chromatic wrote: On Tuesday 03 October 2006 10:06, Aaron Sherman wrote: 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 BD 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. That's really a pity. I'd very much like the rope to be able to build 'strict::with::pride' like toolsto 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
Re: Don't tell me what I can't do!
On Wednesday 04 October 2006 01:05, jesse wrote: 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
Re: Don't tell me what I can't do!
On Wednesday 04 October 2006 12:09, jesse wrote: 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
Re: Don't tell me what I can't do!
On Wednesday 04 October 2006 12:48, jesse wrote: 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
Re: Don't tell me what I can't do!
On Wed, Oct 04, 2006 at 12:01:22PM -0700, chromatic wrote: On Wednesday 04 October 2006 01:05, jesse wrote: 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. 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 --
Re: Don't tell me what I can't do!
In a message dated Wed, 4 Oct 2006, jesse writes: 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. 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? 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
Re: Don't tell me what I can't do!
On Wednesday 04 October 2006 13:25, Trey Harris wrote: 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
Re: Don't tell me what I can't do!
Trey Harris wrote: 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. ;)
Re: Don't tell me what I can't do!
chromatic wrote: On Monday 02 October 2006 12:32, Jonathan Lang wrote: 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. 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.
Re: Don't tell me what I can't do!
On 10/2/06, Jonathan Lang [EMAIL PROTECTED] 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;
Re: Don't tell me what I can't do!
On Oct 2, 2006, at 10:26 AM, jerry gay wrote:
On 10/2/06, Jonathan Lang [EMAIL PROTECTED] 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;
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.
Re: Don't tell me what I can't do!
jerry gay wrote: 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
Re: Don't tell me what I can't do!
On 2 Oct 2006, at 17:48, Jonathan Lang wrote: 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
Re: Don't tell me what I can't do!
jerry gay writes: On 10/2/06, Jonathan Lang [EMAIL PROTECTED] 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; 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
Re: Don't tell me what I can't do!
Smylers wrote: 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 cimport 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.
Re: Don't tell me what I can't do!
Dave Whipp wrote: Smylers wrote: 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 cimport 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. 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
Re: Don't tell me what I can't do!
Jonathan Lang wrote: 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).
Re: Don't tell me what I can't do!
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. 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
Re: Don't tell me what I can't do!
Jonathan Lang wrote: 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. 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. 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.
Re: Don't tell me what I can't do!
On Mon, Oct 02, 2006 at 02:01:34PM -0700, Jonathan Lang wrote: : 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
Re: Don't tell me what I can't do!
On 10/2/06, Jonathan Lang [EMAIL PROTECTED] 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? 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
Re: Don't tell me what I can't do!
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;
Re: Don't tell me what I can't do!
On 10/2/06, Aaron Sherman [EMAIL PROTECTED] wrote: 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; you're so twelve hours ago... :) 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
