Re: Hyphens vs. Underscores
chromatic <[EMAIL PROTECTED]> writes: >> Yet you have the choice of where to put your braces, even >> though the braces don't lend themselves to different tasks >> depending on whether you put them on a new line or not. > > You *don't* have the choice to use different types of > braces, though -- at least not by default. Right, but noone is asking for that. You also don't have the choice of writing your code backwards, but noone is asking for that either. The choice of using hyphens instead of underscores is neither universally undesired nor absurd. >> Is Perl 6 really in such a desperate need of new and more >> powerful features that issues of convenience are irrelevant? > > I see the proposal to treat - and _ as identical in identifiers as a > feature almost as useful as making identifiers case-insensitive. It might not be as useful --- after all, it just lets you raise those low-hanging bars in your names a few pixels --- but I think it is less problematic. I do think that case insensitivity is a desirable characteristic, but I am not sure how feasible it would be in the case of Perl 6. For example, it's good that BUILD and OUTER and all the other uppercased special things are distinctly named. If they were to be distinct under case insensitivity, they would need some sigil or something. > Heteronymity seems too dangerous to encourage by > supporting as a default. You may be right about this. I would be happy if the standard distribution came with a package that enabled the hyphenated identifiers syntax in the lexical block: use hyphenated_identifiers; Hopefully the name of that package won't actually have any underscores in it. -- Daniel Brockman <[EMAIL PROTECTED]>
Re: Hyphens vs. Underscores
On Thu, 2005-11-17 at 07:27 +0100, Daniel Brockman wrote: > Yet you have the choice of where to put your braces, even > though the braces don't lend themselves to different tasks > depending on whether you put them on a new line or not. You *don't* have the choice to use different types of braces, though -- at least not by default. > Is Perl 6 really in such a desperate need of new and more > powerful features that issues of convenience are irrelevant? I see the proposal to treat - and _ as identical in identifiers as a feature almost as useful as making identifiers case-insensitive. Heteronymity seems too dangerous to encourage by supporting as a default. -- c
Re: Hyphens vs. Underscores
Thank you for your considerate reply, Brent. > I see a few syntactic problems with this idea: the subtraction and > negation operators you already mentioned, Did I miss any problems related to those? > but also the fact that dashes are already used in package names to > indicate version and author (`class Foo::Bar-2.10-cpan:BRENTDAX;`). Hmm, I did not consider that. > I suspect that both of these problems will be more troublesome than > you might guess. > > But there's a philosophical problem too. This proposal is an instance > of what I'm going to call the "dimmer switch problem". [...] > Perl has a lot of different ways of doing things. But if you examine > the design, you'll realize that they aren't mere cosmetic > differences--each form lends itself to different tasks. Yet you have the choice of where to put your braces, even though the braces don't lend themselves to different tasks depending on whether you put them on a new line or not. 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"? But I see your point. If Perl started adding tons of syntactic dimmer swithes, that would certainly be a wrong turn for TMTOWTDI. (Luckily, Perl 6 has so many hidden switches that you could probably play with them forever and never get bored.) > A lot of the suggestions I see for Perl 6 are dimmer switches; they > add an option or two to better suit someone's tastes but don't add any > power to the language. I might far too humble to try to think of anything that could possibly add more power to such an enourmously powerful beast of a language. If not, then at least I know far too little about the language. Is Perl 6 really in such a desperate need of new and more powerful features that issues of convenience are irrelevant? > This is hardly the first case; the suggestion a long time > ago to use backtick as a subscript operator comes to mind, > but there have been many others. 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. > Car designers, of course, are stuck with the dimmer switch: they do > need to provide some way to provide this feature to their customers Do they, really? Can't they just settle on a standard dimmer setting that works well enough for everyone? > This feature can be added as grammar-modifying pragma. If you want > the hyphen, simply type something like `use hyphens;` and you can use > hyphenated identifiers in the surrounding scope. And unlike Ruby, > this will be easy to do unambiguously: just override the Perl 6 > grammar's identifier rule. All the edge cases will be resolved by the > longest token principle, so `foo-bar-baz` will be an identifier. Yes, it's very comforting to know that even if Perl 6 won't have this feature built in, it will be so amazingly easy to implement in a beautifully clean way. But what about class Foo::Bar-2.10-cpan:BRENTDAX? -- Daniel Brockman <[EMAIL PROTECTED]>
Re: Hyphens vs. Underscores
Daniel Brockman <[EMAIL PROTECTED]> wrote: > So what is my suggestion? Obviously disallowing underscores > and instead allowing hyphens would just replace one problem > with an even worse problem (not only would there still be > people who don't like hyphens, but it would alienate a large > portion of the user base). Therefore, to make the language > more appealing (i.e., less alienating) to the group of > people I am going to refer to as "Lispers", it's obvious > that both characters should be allowed. I see a few syntactic problems with this idea: the subtraction and negation operators you already mentioned, but also the fact that dashes are already used in package names to indicate version and author (`class Foo::Bar-2.10-cpan:BRENTDAX;`). I suspect that both of these problems will be more troublesome than you might guess. But there's a philosophical problem too. This proposal is an instance of what I'm going to call the "dimmer switch problem". In American cars at least, virtually every control on a car's dashboard has an immediate purpose and utility. There are steering controls (i.e. the wheel), cruise control settings, controls for exterior lights, controls for the radio and air conditioner, and so on; all of these need to be within easy reach of the driver, either because he needs them to safely operate the car or because he's likely to want to twiddle them while he's driving. And then there's the dimmer switch, used to control the brightness of the dashboard's lighting. This is not something the driver often changes, and it's not crucial to the car's operation. A driver will adjust it once if he bothers adjusting it at all. It's there solely because different people have different preferences for the brightness, and there's nowhere else to put it. Perl has a lot of different ways of doing things. But if you examine the design, you'll realize that they aren't mere cosmetic differences--each form lends itself to different tasks. For example, `for`` and `map` are functionally equivalent, but implementing a Schwartzian transform is much easier with `map`, and a large loop body is much easier to visually parse with `for`. A lot of the suggestions I see for Perl 6 are dimmer switches; they add an option or two to better suit someone's tastes but don't add any power to the language. This is hardly the first case; the suggestion a long time ago to use backtick as a subscript operator comes to mind, but there have been many others. Car designers, of course, are stuck with the dimmer switch: they do need to provide some way to provide this feature to their customers, and there are only so many ways to do it with a physical piece of plastic and vinyl. Language designers are luckier, though, and Perl 6 is better than most. This feature can be added as grammar-modifying pragma. If you want the hyphen, simply type something like `use hyphens;` and you can use hyphenated identifiers in the surrounding scope. And unlike Ruby, this will be easy to do unambiguously: just override the Perl 6 grammar's identifier rule. All the edge cases will be resolved by the longest token principle, so `foo-bar-baz` will be an identifier. -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker
Re: Hyphens vs. Underscores
On Thu, 2005-11-17 at 05:31 +0100, Daniel Brockman wrote: > This is a very valid concern, but the problem will not arise > unless people start mixing these two styles --- something > which is very obviously not a good idea. That doesn't mean that people will avoid it, by accident or on purpose. It's a serious concern worth more consideration than "just don't do it!" -- c
Re: Hyphens vs. Underscores
Sebastian,
> I like hyphens. They're easier to type and help
> prevent_me_from_Doing_This and generating errors because
> of case sensitivity.
>
> On the other hand, consistency of appearance may be a
> problem for some people. I often associate code with the
> way it looks on screen, not necessarily with what it does
> or says. Looking for some_code_like_this() in a place
> that uses some-code-like-this() might be troublesome.
I think that is a valid concern, but I don't think it is
very troublesome. I don't think it takes long for your eyes
to adapt when switching between hyphens and underscores.
I would certainly agree, however, that mixing two styles in
a single file or, to a lesser extent, a single source tree,
would be troublesome. Not so much for the human readability,
but for the automatic searchability.
If you are standing on this piece of code
sub foo-bar ($a, $b) { say "whatever, I don't care" }
and perform a search for `foo-bar', you probably are not
going to expect this code a few hundred lines down:
foo_bar("this example doesn't have a theme")
This is a very valid concern, but the problem will not arise
unless people start mixing these two styles --- something
which is very obviously not a good idea.
Besides, another couple of hundred lines down, you might
(but you probably won't) find the following code:
eval ("foo", "bar").join("_")
In the end, this is a "suit yourself" kind of problem.
--
Daniel Brockman <[EMAIL PROTECTED]>
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Re: Hyphens vs. Underscores
I like hyphens. They're easier to type and help
prevent_me_from_Doing_This and generating errors because of case
sensitivity.
On the other hand, consistency of appearance may be a problem for some
people. I often associate code with the way it looks on screen, not
necessarily with what it does or says. Looking for
some_code_like_this() in a place that uses some-code-like-this() might
be troublesome.
- sebastian
On 11/16/05, Daniel Brockman <[EMAIL PROTECTED]> wrote:
> I'm not a Lisp weenie. However, I have always preferred
> hyphens over underscores, and I have always preferred
> identifiers that use delimiters over camel-cased ones.
>
> I just think `foo-bar-baz' looks better than `foo_bar_baz'.
> Maybe it's the "lexical connotation" of hyphens from natural
> language (it joins words), or maybe it's that hyphens fall
> more or less on the center of gravity of an identifier,
> whereas underscores usually fall beneath the baseline,
> making it a purely typographical preference.
>
> Maybe it's that I like Lisp, Dylan, CSS, XSLT, or some other
> language in which hyphens are predominant. But I don't
> think that's it, because I like even more languages in which
> underscores are predominant. It's simply that I like the
> look of the identifiers better in Lisp.
>
> I realize that lots of people feel the same, only with the
> exact opposite viewpoint. It's purely a matter of taste.
>
> My brother just walked past my monitor, glanced through the
> above text and exclaimed, "Yeah, if Perl 6 allowed hyphens
> in identifiers, it would be, like, the ultimate language!"
>
> I don't mean to quote my beloved brother as an authority on
> this matter (quite to the contrary, I don't think there are
> any authorities, since it's a matter of taste). I just mean
> to illustrate that people do feel strongly about this issue.
> (And I don't need to tell you that aesthetic aspects play a
> serious role in deciding, if not whether a person is going
> to end up liking the language, then at least what their
> first impression is going to be.)
>
> So what is my suggestion? Obviously disallowing underscores
> and instead allowing hyphens would just replace one problem
> with an even worse problem (not only would there still be
> people who don't like hyphens, but it would alienate a large
> portion of the user base). Therefore, to make the language
> more appealing (i.e., less alienating) to the group of
> people I am going to refer to as "Lispers", it's obvious
> that both characters should be allowed.
>
> But simply adding hyphen as another character allowed in
> identifiers would only superficially solve the problem.
> To be sure, it would cause a new group of people, Lispers,
> to migrate to Perl 6, and might even case a few long-time
> users (any closet Lispers around?) to switch to hyphens.
> But it would also doom these two camps to forever remain at
> war with one another.
>
> This is because if you like underscores, you aren't going to
> want libraries to use to have hyphens all over the place.
> For one thing, it would be plain hell to have to remember
> which packages used underscores and which used hyphens.
>
> Therefore, my suggestion is to allow both characters, but
> have them mean the same thing. This concept caused some
> confusion on IRC, so let me provide a screenshot:
>
>sub foo-bar ($x) { say $x }
>foo_bar(42); # says 42
>
> (image courtesy of luqui on #perl6)
>
> If you think about it, this makes sense. Just as you are
> not forced to use the same indentation style as the authors
> of the libraries you use, you should be free to use whichever
> word-joiner (subtle hint not intended) you prefer.
>
> I did not invent this solution. "For convenience," as the
> modprobe(1) man page puts it, "there is no difference
> between _ and - in module names." As another example,
> GObject, the GTK+ object system, uses it to allow
>
>g_object_set (foo, "bar-baz") and
>
>g_object_set (foo, "bar_baz")
>
> as synonymous, which is particularly convenient since there
> are so many different language bindings for GObject.
> (I should --- since it is advantageous to my case --- point
> out that GObject uses hyphens internally.) There are probably
> other examples (if you can think of any, please tell).
>
> Anyway, if we can agree --- without considering the syntactical
> implications --- that it is desirable to make these characters
> synonymous, we have to look at the implications next.
>
> The first thing that comes to mind is that some people write
> binary minus without surrounding whitespace. Were this
> proposal to be accepted, those people would do best to
> change habits, lest they be bitten when they try to subtract
> the return value of a subroutine call from something.
>
> What about unary minus? I propose the following:
>
> -foo-bar === -(foo-bar) === -(foo_bar)
> _foo-bar === _foo-bar === _foo_bar
>
> That is, hyphen and underscore are
Hyphens vs. Underscores
I'm not a Lisp weenie. However, I have always preferred
hyphens over underscores, and I have always preferred
identifiers that use delimiters over camel-cased ones.
I just think `foo-bar-baz' looks better than `foo_bar_baz'.
Maybe it's the "lexical connotation" of hyphens from natural
language (it joins words), or maybe it's that hyphens fall
more or less on the center of gravity of an identifier,
whereas underscores usually fall beneath the baseline,
making it a purely typographical preference.
Maybe it's that I like Lisp, Dylan, CSS, XSLT, or some other
language in which hyphens are predominant. But I don't
think that's it, because I like even more languages in which
underscores are predominant. It's simply that I like the
look of the identifiers better in Lisp.
I realize that lots of people feel the same, only with the
exact opposite viewpoint. It's purely a matter of taste.
My brother just walked past my monitor, glanced through the
above text and exclaimed, "Yeah, if Perl 6 allowed hyphens
in identifiers, it would be, like, the ultimate language!"
I don't mean to quote my beloved brother as an authority on
this matter (quite to the contrary, I don't think there are
any authorities, since it's a matter of taste). I just mean
to illustrate that people do feel strongly about this issue.
(And I don't need to tell you that aesthetic aspects play a
serious role in deciding, if not whether a person is going
to end up liking the language, then at least what their
first impression is going to be.)
So what is my suggestion? Obviously disallowing underscores
and instead allowing hyphens would just replace one problem
with an even worse problem (not only would there still be
people who don't like hyphens, but it would alienate a large
portion of the user base). Therefore, to make the language
more appealing (i.e., less alienating) to the group of
people I am going to refer to as "Lispers", it's obvious
that both characters should be allowed.
But simply adding hyphen as another character allowed in
identifiers would only superficially solve the problem.
To be sure, it would cause a new group of people, Lispers,
to migrate to Perl 6, and might even case a few long-time
users (any closet Lispers around?) to switch to hyphens.
But it would also doom these two camps to forever remain at
war with one another.
This is because if you like underscores, you aren't going to
want libraries to use to have hyphens all over the place.
For one thing, it would be plain hell to have to remember
which packages used underscores and which used hyphens.
Therefore, my suggestion is to allow both characters, but
have them mean the same thing. This concept caused some
confusion on IRC, so let me provide a screenshot:
sub foo-bar ($x) { say $x }
foo_bar(42); # says 42
(image courtesy of luqui on #perl6)
If you think about it, this makes sense. Just as you are
not forced to use the same indentation style as the authors
of the libraries you use, you should be free to use whichever
word-joiner (subtle hint not intended) you prefer.
I did not invent this solution. "For convenience," as the
modprobe(1) man page puts it, "there is no difference
between _ and - in module names." As another example,
GObject, the GTK+ object system, uses it to allow
g_object_set (foo, "bar-baz") and
g_object_set (foo, "bar_baz")
as synonymous, which is particularly convenient since there
are so many different language bindings for GObject.
(I should --- since it is advantageous to my case --- point
out that GObject uses hyphens internally.) There are probably
other examples (if you can think of any, please tell).
Anyway, if we can agree --- without considering the syntactical
implications --- that it is desirable to make these characters
synonymous, we have to look at the implications next.
The first thing that comes to mind is that some people write
binary minus without surrounding whitespace. Were this
proposal to be accepted, those people would do best to
change habits, lest they be bitten when they try to subtract
the return value of a subroutine call from something.
What about unary minus? I propose the following:
-foo-bar === -(foo-bar) === -(foo_bar)
_foo-bar === _foo-bar === _foo_bar
That is, hyphen and underscore are synonymous in identifiers,
but an initial hyphen is not taken to be part of the identifier.
I'm not sure about postfix unary minus, however. You could
argue the case both ways (so please do that).
My gut feeling is that any postfix unary minus is doomed to
be confusing either way, so it might not matter.
Oh, by the way, I've been using hyphens in my Ruby
identifiers for some time now, and have not ran into any
serious problems. The problems I have ran into are related
to either the modified Ruby mode for Emacs, or to the kludgy
implementation --- I wrote a preprocessor that parses code
looking for identifiers. You can find that here:
Re: Error Laziness?
Luke Palmer wrote:
>There are two reasons I've posted to perl6-language this time. First
>of all, is this acceptable behavior? Is it okay to die before the
>arguments to an undefined sub are evaluated?
>
>
>
Something like:
widgetMethod new Widget;
The best argument I've got for forcing the args to define is that
AUTOfoo might define them for you. I'm not sure that a similar argument
involving a possible AUTObar might not invalidate it, though -- is there
a type-based or virtual AUTOfoo behavior?
>Second, consider this "is lazy" code:
>
>sub foo ($bar is lazy) {
>my $bref = \$bar;
>do_something($bref);
>}
>foo(42);
>
>This will evaluate $bar, even if it is not used in do_something.
>
Okay, why? I'd expect the reference-taking to come nowhere close to
evaluating $bar, and passing $bref either passes the reference (no
evaluation) or looks at the reference, realizes that it's basically
"lazy, too", and punts.
>In fact, this will evaluate $bar even if the do_something call is omitted
>altogether. This doesn't give you much control over the time of
>evaluation, and presumably if you're saying "is lazy", control is
>precisely what you want.
>
>
I don't think control so much as aversion. "is lazy" means don't
evaluate this if you can avoid evaluating this.
>I think we need more control. I think "is lazy" parameters should
>pass a thunk that needs to be call()ed:
>
>sub foo ($bar is lazy) {
>say $bar; # says something like Thunk(...)
>say $bar(); # evaluates parameter and prints it
>say $bar; # still says something like Thunk(...)
>say $bar(); # doesn't evaluate again, just fetches
>}
>
>Whaddaya think?
>
>
>
Erm, no. I think "is lazy" describes $bar, and that means I use $bar as
'$bar' and perl dances madly to avoid evaluating it.
Suppose for a moment that there were levels of laziness -- there aren't,
but just suppose:
$x is lazy('Network IO involved. Create temporary variables and/or
closures to avoid losing this value once evaluated.');
$y is lazy('Horribly costly. Perform algebraic substitution before
evaluating this.');
$z is lazy('Possibly infinitely expensive. Only evaluate if halting
problem solved.');
The syntax of the language shouldn't change here. If I say "print $x"
then I'm telling you that I want to pay the price. It's a debug
statement or whatever, but I want those MIPS to get burned right now.
There's not much other way around it. (Of course, if the lazy entity is
a sequence it might be legitimate to print [sequence starting 1, 2, 3
...] instead of all possibly-infinitely-many values.)
Adding "is lazy" shouldn't change the code below it. It should just
speed it up where possible.
I like the idea of $x.value being a thunk, so that math or what-not
could actually be carried as an expression.
So that:
sub foo($bar is rw is lazy)
{
$bar++;
}
Becomes
...{
$bar.value = \{ my &v = $bar.value; postfix:++(&v());};
}
But $x.toString(), unless otherwise overridden, needs to keep
dereferencing ...value.value.value until some kind of basic type falls out.
Perhaps you could enumerate the various aspects of "value"? Obviously
there's value() and toString() (or whatever it's called.) How many such
are there?
=Austin
