Re: Hyphens vs. Underscores
> "DB" == Daniel Brockman <[EMAIL PROTECTED]> writes: DB> You may be right about this. I would be happy if the DB> standard distribution came with a package that enabled the DB> hyphenated identifiers syntax in the lexical block: DB>use hyphenated_identifiers; DB> Hopefully the name of that package won't actually have DB> any underscores in it. this idea would need to be worked out in much greater detail. there are many different identifiers in perl. would all of them be subject to this change? how would a global work if some other module refered to it using underscores but your module used hyphens? would your pragma just do a compile time translation of - to _ when inside identifiers? what about in eval or symrefs? would the translation be done at runtime then? how could that be handled in a lexical way if the foo-name is passed to another module which hadn't used the pragma? or would all symbol lookups just tr/-/_/ beforehand? but that can't be easily controlled in a lexical scope. and i know how you feel about wanting - vs. _ but i have it the other way around. i much prefer _ since it maked the words more readable as _ sorta disappears in the baseline. but then i hate list too so that influences me a trifle. :) but the sickest thing i have done is to remap _ to - and back inside emacs. this was so typing -> is done with both keys shifted and i typed that too often. also that made writing foo_bar easier. so my brain has to swap then when inside emacs vs everywhere else. makes for some odd homicidal twitching sometimes (especially when anyone else dares to type into my emacs :). anyhow, my main point is that IMO this has too many problems with both syntax and unknown semantics that are sure to make some large fraction of us very mad. perl has its style and that it _ for word separation. the evil studly caps is used for module names only (where it does seem to work better than _ would. or maybe we are just so used to it by now). trying to change that in a scoped way will only cause pain somewhere else. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Hyphens vs. Underscores
Uri Guttman <[EMAIL PROTECTED]> writes: > this idea would need to be worked out in much greater detail. there are > many different identifiers in perl. would all of them be subject to this > change? how would a global work if some other module refered to it using > underscores but your module used hyphens? would your pragma just do a > compile time translation of - to _ when inside identifiers? Yes, that's what it would do. (Actually, my Ruby preprocessor removes hyphens it finds in identifiers that start with an uppercase character and contain at least one lowercase character, to allow Foo-Bar as a synonym for FooBar.) > what about in eval or symrefs? would the translation be done at runtime > then? how could that be handled in a lexical way if the foo-name is > passed to another module which hadn't used the pragma? or would all > symbol lookups just tr/-/_/ beforehand? but that can't be easily > controlled in a lexical scope. That problem is not specific to this feature. For any package that changes the syntax, you can ask "what about eval?" So... what *about* eval? :-) > and i know how you feel about wanting - vs. _ but i have it the other > way around. i much prefer _ since it maked the words more readable as _ > sorta disappears in the baseline. but then i hate list too so that > influences me a trifle. :) I guess it depends on whether you see it as a separator or a joiner. You could say that hyphens join words, but underscores separate them. > but the sickest thing i have done is to remap _ to - and back inside > emacs. this was so typing -> is done with both keys shifted and i typed > that too often. also that made writing foo_bar easier. Hmm, that's an interesting hack. :-) > so my brain has to swap then when inside emacs vs everywhere else. > makes for some odd homicidal twitching sometimes (especially when anyone > else dares to type into my emacs :). Ha! Like you're ever going to go anywhere outside of Emacs... > anyhow, my main point is that IMO this has too many problems with both > syntax and unknown semantics that are sure to make some large fraction > of us very mad. perl has its style and that it _ for word separation. I agree, of course, that if this can't be done well, then it shouldn't be done at all. Well, at least then it shouldn't be put in the standard distribution. :-) > the evil studly caps is used for module names only (where it does seem > to work better than _ would. or maybe we are just so used to it by now). I've come to prefer Foo-Bar-Baz for class and module names. Having used that style for a while, I don't see any good reason to write them smashed together. > trying to change that in a scoped way will only cause pain > somewhere else. If so, then that is a symptom of a wider problem. I mean, wasn't Perl 6 supposed to make this kind of hack a breeze? -- Daniel Brockman <[EMAIL PROTECTED]>
Re: Hyphens vs. Underscores
> No sane person would put their braces in different places in > different parts of their code, so why don't we just say, > "from now on, you must use brace style X"? Have you never seen code that's been worked on by several people with differing tastes in brace positioning and no coding standard? Have you never copied a chunk of code from one place to another 'temporarily' without adjusting the indentation (though, admittedly, most editors will do it for you)? People *do* mix brace and indentation styles in the same file, and it is ugly when it happens, but it doesn't change the meaning of the program. -- Stop the infinite loop, I want to get off! http://surreal.istic.org/ Paraphernalia/Never hides your broken bones,/ And I don't know why you'd want to try:/ It's plain to see you're on your own.-- Paul Simon The documentation that can be written is not the true documentation.
RE: Hyphens vs. Underscores
On Wed, 16 Nov 2005, Daniel Brockman wrote: > No offense to whoever made that suggestion, but I think there are far > more people out there with a developed taste for hyphenated > identifiers than there are people with a thing for using backticks as > subscript operators. > > Do you see the difference? I'm trying to cater to an actually existing > and in many cases strong preference. No offense either, but if you are suggesting that @a[$i-1] + @a[$i+1] should be interpreted as @a[$i_1] + @a[$i+1] then I think it is pretty obvious why this is a really bad idea. Cheers, -Jan
Re: Hyphens vs. Underscores
Jan, > No offense either, but if you are suggesting that > > @a[$i-1] + @a[$i+1] > > should be interpreted as > > @a[$i_1] + @a[$i+1] > > then I think it is pretty obvious why this is a really bad idea. That's a very good example. I think I'm going to have to change my mind and agree that it should not be the default. (Some will say I should have thought this through before making the suggestion, but the thing is that I *did* think it through. Just comes to show how poorly I think.) Further, the package that makes hyphens identical to underscores should probably warn about $i+1 and $i*1. I would still use that package, and your example doesn't bother me personally. I would never write $i-1 or $i+1. But I wouldn't want to be the one to have to reply to all the complaints about the unintuitive meaning of @a[$i-1] + @a[$i+1]. -- Daniel Brockman <[EMAIL PROTECTED]>
Re: Hyphens vs. Underscores
On Thu, Nov 17, 2005 at 10:56:27AM +0100, Daniel Brockman wrote: : That problem is not specific to this feature. For any package : that changes the syntax, you can ask "what about eval?" : : So... what *about* eval? :-) Always parses with the parser in effect at that point, the same one you'd get if you asked for $?PARSER. : > trying to change that in a scoped way will only cause pain : > somewhere else. : : If so, then that is a symptom of a wider problem. I mean, : wasn't Perl 6 supposed to make this kind of hack a breeze? Sure, but you still have to deal with the consequences of your choices. You can still be tried for murder even if you only ever kill people on Tuesday. Perl 6 is just trying to make it easier for you to kill people on Tuesday without accidentally killing people on Saturday. Larry
Re: Test Case: Complex Numbers
HaloO, Jonathan Lang wrote: Complex numbers come in two representations: rectilinear coordinates and polar coordinates: I think there's also the Riemanian two angle form of the complex number sphere with r = 0.5 around (0,0,0.5) touching the plane at the origin (0,0) and reaching up to (0,0,1) in space. But admittedly the resulting math is that of projective space. Then there is the classic fact that you should make e.g. role Complex an intentional supertype of Num while the class Complex needs a wider extensional type with the added imaginary part in one form or another. As Luke pointed out, a plain role/class pair might not be enough to model the structural properties of the communalities and differences of Num and Complex. We need to define a family of related types that manage the different interpretations of a 2-tupel of Nums while sharing the underlying data layout---not to mention to be compatible with more generic vector stuff like the scalar product. Another idea is to model nums to have a directional bit where the polar complex have a full range angle. --
Private behavior in roles
In http://perlmonks.org/?node_id=509413 (in response to
http://perlmonks.org/?node_id=509256), Rob Kinyon wrote that in his
understanding of Perl 6 Roles, anything a role can do the class "doing"
the role should also be able to do.
Is this correct? I'm getting bitten with Class::Trait because some of
my traits import helper functions and constants from other packages.
The classes implementing the traits should *not* care about how the
trait does something, but those functions and constants are getting
flattened into my classes and this has been causing all sorts of
problems.
For the time being, I have rewritten all of my traits to not import
anything in the trait namespace, but I intend to modify Class trait so
each method can be defined thusly:
sub some_method : Public { ... }
In the original traits definition, as I understood them, a trait should
specify what it requires *and* what it provides. Are Perl 6 roles
really going to blindly export everything they contain? This seems a
serious mistake. I didn't see anything addressing this issue in
http://www.perl.com/pub/a/2004/04/16/a12.html?page=12
Cheers,
Ovid
--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Renaming grep
Hi all, I think that grep should be renamed to something English and more, well, semantic. 'Filter' comes to mind as a suggestion. I realise there's a lot of cultural background (from Unix and Perl 5) that favours 'grep', but I think it's more important to name the language elements consistently (the right kind of consistency, I hope). It's also possible to retain 'grep' as an alias (or add the new name as an alias), but generally I've found having the same thing with multiple names doesn't help at all (I'm looking at you, Ruby). -- Ilmari Vacklin <[EMAIL PROTECTED]>
Fwd: Renaming grep
Drat, thought I was sending this to the list: Begin forwarded message: On Nov 17, 2005, at 8:31 PM, Ilmari Vacklin wrote: Hi all, I think that grep should be renamed to something English and more, well, semantic. 'Filter' comes to mind as a suggestion. I realise there's a lot of cultural background (from Unix and Perl 5) that favours 'grep', but I think it's more important to name the language elements consistently (the right kind of consistency, I hope). 'sift' is the same number of characters as 'grep'. It's something of a bikeshed to me whether this rename is implemented or not, though. --Dks
=>'s autoquoted identifiers
Greetings to everyone. I'm wondering about the => operator, which
still "autoquotes" its first arguement if it's bare, a la barewords.
Synopsis 1 says:
But => still autoquotes any bare identifier to its immediate left
(horizontal whitespace allowed but not comments). The identifier is
not subject to keyword or even macro interpretation. If you say:
$x = do {
call_something();
if => 1;
}
then $x ends up containing the pair ("if" => 1). Always. (Unlike in
Perl 5, where version numbers didn't autoquote.)
[end quote]
But what does that mean for =>'s signature? What type would be its
first parameter? Would you call it "&infix:{'=>'}:(Bareword | Any,
Any)" or something like that? And in any case, would you be able to
use this autoquoting in or as a sub, operator, type, etc.?
Thanks,
Joshua Choi
Re: =>'s autoquoted identifiers
On 11/17/05, Joshua Choi <[EMAIL PROTECTED]> wrote:
> But what does that mean for =>'s signature? What type would be its
> first parameter? Would you call it "&infix:{'=>'}:(Bareword | Any,
> Any)" or something like that? And in any case, would you be able to
> use this autoquoting in or as a sub, operator, type, etc.?
I think => gets special treatment from the parser; i.e. it is
undeclarable. It's probably not even declarable as a macro, since it
needs to look behind itself for what to quote.
And I think this is okay. For some reason, we are not satisfied if
"if" is undeclarable, but => being so is fine. I can't put my finger
on why I feel this way, though.
Luke
