Re: perl6storm #0050
John Porter [EMAIL PROTECTED] writes: Piers Cawley wrote: You know, I'm trying to see what's annoying about all those parentheses in the lisp function and what do you know, I can't see anything wrong. Okay, so it's not Perl syntax, but it's still clear what's going on. Yes, but it's hard to read. We could argue this back and forth, but I don't think that was hard to read. Sure you need to know lisp to understand it, but the same could be said of *any* programming language. -- Piers
Re: perl6storm #0050
Buddha Buck wrote: While Perl -lets- every function be well prototyped, it doesn't -require- every function to be well prototyped. Because of this, it might be well nigh impossible to eliminate all ambiguity to the compiler. Well, right. Clearly, in those cases, you can expect to need parens sometimes. -- John Porter Jetzt schalten wir das Radio an. Aus dem Lautsprecher klingt es dann...
Re: perl6storm #0050
On 26 Sep 2000, Johan Vromans wrote: Philip Newton [EMAIL PROTECTED] writes: so fewer "cluttering" parentheses are needed to make things readable while still being correct. By the same reasoning, you can reduce the use of curlies by using indentation to define block structure. What an idea! I wonder why no language has tried this before. Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: perl6storm #0050
On 26 Sep 2000, Johan Vromans wrote: Philip Newton [EMAIL PROTECTED] writes: so fewer "cluttering" parentheses are needed to make things readable while still being correct. Since when do parentheses make things less readable? Each parenthesis is one "token". The more tokens you need to process, to more you need to think. (Especially if there is little whitespace, but to some extent also if not.) What is your definition of readable? "I know it when I see it". I don't have a definition that I can put in words. But it probably involves whitespace between tokens and the number of tokens. Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: perl6storm #0050
Robert Mathews [EMAIL PROTECTED] writes: Simon Cozens wrote: (defun Schwartzian (func list) (mapcar (lambda (x) (car x)) (sort (mapcar (lambda (x) (cons x (funcall func x))) list ) (lambda (x y) ( (cdr x) (cdr y))) ) ) ) Maybe you'd prefer this: defun Schwartzian func list mapcar lambda x car x sort mapcar lambda x cons x funcall func x list lambda x y cdr x cdr y I know which I'd rather read. Ok, you've proved that lisp doesn't make sense without all those annoying parentheses. You know, I'm trying to see what's annoying about all those parentheses in the lisp function and what do you know, I can't see anything wrong. Okay, so it's not Perl syntax, but it's still clear what's going on.
Re: perl6storm #0050
* Philip Newton ([EMAIL PROTECTED]) [27 Sep 2000 19:54]:
On 26 Sep 2000, Johan Vromans wrote:
[...]
By the same reasoning, you can reduce the use of curlies by using
indentation to define block structure.
What an idea! I wonder why no language has tried this before.
I realise you're being sarcastic here, but my serious reply is "because
it reduces readability".
It forces the concept that all statements are equal.
Do you really want to see:
@sorted = sort
$b cmp $a
@lines;
Hmm. Not entirely sure how that indenting went. Let's try again:
@sorted = sort
$b cmp $a
@lines;
Maybe:
@sorted = sort
$b cmp $a
@lines;
I know!
@sorted = sort { $b cmp $a } @lines;
Works brilliantly!
People are probably thinking "no: just for for() while() and so on."
I'm thinking "consistency is the key to everything, including my tomato
soup". Do it one place, it should be eligible everywhere.
And maybe I want to write simple accesors like:
sub title { $_[0]-{'title'} }
Not as clear as
sub title
{
my $self = shift;
return $self-{'title'};
}
But clearer than
sub title
my $self = shift;
return $self-{'title'};
Which really needs something to end it with (such as 'endsub') otherwise
for more complicated routines it is hard to see where your function is
ending. Those { } do have more than just a syntactic use. They provide a
visual aid to the delineation of blocks.
Anyway. That was my irrelevant rant for the day. Erm. I'll go away now.
cheers,
--
iain truskett, aka Koschei.http://eh.org/~koschei/
You know you are addicted to coffee if...
7 Your eyes stay open when you sneeze.
Re: perl6storm #0050
On Wed, Sep 27, 2000 at 09:52:57AM +0100, Piers Cawley wrote: You know, I'm trying to see what's annoying about all those parentheses in the lisp function and what do you know, I can't see anything wrong. Okay, so it's not Perl syntax, but it's still clear what's going on. I'd go further than that. It's clear what's going on for a number of reasons. Firstly, you know the language. Secondly, you know what it's trying to do because the function and the variables are well named. Thirdly, I used whitespace and indentation to make the various levels apparent - that's why I removed the whitespace on the second example. There are many other tricks for making code readable, and whether or not the language supports bracketing or, indeed, any other feature is more or less irrelevant to all of them. You can write clear code in any language, if you take the time; you can write Python in any language, if you want. Readability is a programmer feature, not a language feature. -- "There is no statute of limitations on stupidity." -- Randomly produced by a computer program called Markov3.
Re: perl6storm #0050
Simon Cozens [EMAIL PROTECTED] writes: Readability is a programmer feature, not a language feature. The most important optimization a programmer can make is to optimize for understanding. -- Piers
RE: perl6storm #0050
On Wednesday, September 27, 2000 10:21 AM, John Porter [SMTP:[EMAIL PROTECTED]] wrote: Philip Newton wrote: On 26 Sep 2000, Johan Vromans wrote: By the same reasoning, you can reduce the use of curlies by using indentation to define block structure. What an idea! I wonder why no language has tried this before. It's a question of what the language allows vs. what it requires. Perl is nice because it allows you to write in (nearly) any style you want -- lots of parens, no whitespace... Requiring the use of parens is about as un-perl-like as requiring indentation to denote blocks. Although I have no interest in saying anything supportive of this idea, I think it would be dreadfully funny if Python suddenly lost its primary point of advocacy against the Perl language just because we allowed (not required) blocks by indentation. Maybe then they'd stop invading perl5-advocacy. ;-)) But no thanks: pass. (Is that sys.pass() or language.pass()?)
Re: perl6storm #0050
Piers Cawley wrote: You know, I'm trying to see what's annoying about all those parentheses in the lisp function and what do you know, I can't see anything wrong. Okay, so it's not Perl syntax, but it's still clear what's going on. Yes, but it's hard to read. Lisp requires parens, because it has no precedence rules. (Well, hardly any). It has (almost) no other syntax. This is the situation we would like to avoid in perl. By letting every operator have well-defined precedence, and every be function well prototyped, there should never be any ambiguity (to the compiler, at least) as to what is meant, even with no parens. Ideally, anyway. -- John Porter Aus des Weltalls ferne funken Radiosterne.
Re: perl6storm #0050
Simon Cozens wrote: Readability is a programmer feature, not a language feature. Right. Parens, and other devices for "readability", are there for the user to use, if she chooses. Perl is not about forcing a certain style. -- John Porter Aus des Weltalls ferne funken Radiosterne.
Re: perl6storm #0050
On Wed, Sep 27, 2000 at 03:35:39PM -0400, John Porter wrote: Yes, but it's hard to read. Lisp requires parens, because it has no precedence rules. (Well, hardly any). It has (almost) no other syntax. This is the situation we would like to avoid in perl. By letting every operator have well-defined precedence, and every be function well prototyped, there should never be any ambiguity (to the compiler, at least) as to what is meant, even with no parens. Ideally, anyway. Perl is English-like. And sometimes in English parentheses *are* necessary to increase both meaning and readability, as your own message proves. -- The PROPER way to handle HTML postings is to cancel the article, then hire a hitman to kill the poster, his wife and kids, and fuck his dog and smash his computer into little bits. Anything more is just extremism. - Paul Tomblin, in the monastery.
Re: perl6storm #0050
Simon Cozens wrote: Perl is English-like. And sometimes in English parentheses *are* necessary to increase both meaning and readability, as your own message proves. That's rather disingenuous, since perl does not use parens for the same purpose English does. Parens are necessary in a programming language to override the default precedence. (Wouldn't it be nice if we used them in English for that. Alas.) "Meaning" is not "increased". Whether readability is enhanced is debatable. I tend to think not. -- John Porter Aus des Weltalls ferne funken Radiosterne.
Re: perl6storm #0050
At 03:35 PM 9/27/00 -0400, John Porter wrote: Piers Cawley wrote: You know, I'm trying to see what's annoying about all those parentheses in the lisp function and what do you know, I can't see anything wrong. Okay, so it's not Perl syntax, but it's still clear what's going on. Yes, but it's hard to read. Lisp requires parens, because it has no precedence rules. (Well, hardly any). It has (almost) no other syntax. This is the situation we would like to avoid in perl. By letting every operator have well-defined precedence, and every be function well prototyped, there should never be any ambiguity (to the compiler, at least) as to what is meant, even with no parens. Ideally, anyway. While Perl -lets- every function be well prototyped, it doesn't -require- every function to be well prototyped. Because of this, it might be well nigh impossible to eliminate all ambiguity to the compiler. -- John Porter Aus des Weltalls ferne funken Radiosterne.
Re: perl6storm #0050
Philip Newton [EMAIL PROTECTED] writes: so fewer "cluttering" parentheses are needed to make things readable while still being correct. Since when do parentheses make things less readable? What is your definition of readable? -- Johan
Re: perl6storm #0050
Philip Newton [EMAIL PROTECTED] writes: so fewer "cluttering" parentheses are needed to make things readable while still being correct. By the same reasoning, you can reduce the use of curlies by using indentation to define block structure. -- Johan
Re: perl6storm #0050
On Tue, Sep 26, 2000 at 02:06:47PM -0400, John Porter wrote: Since when do parentheses make things less readable? Can you say "lisp"? "lisp". (defun Schwartzian (func list) (mapcar (lambda (x) (car x)) (sort (mapcar (lambda (x) (cons x (funcall func x))) list ) (lambda (x y) ( (cdr x) (cdr y))) ) ) ) Maybe you'd prefer this: defun Schwartzian func list mapcar lambda x car x sort mapcar lambda x cons x funcall func x list lambda x y cdr x cdr y I know which I'd rather read. -- God gave man two ears and one tongue so that we listen twice as much as we speak. -- Arab proverb
Re: perl6storm #0050
Simon Cozens wrote: (defun Schwartzian (func list) (mapcar (lambda (x) (car x)) (sort (mapcar (lambda (x) (cons x (funcall func x))) list ) (lambda (x y) ( (cdr x) (cdr y))) ) ) ) Maybe you'd prefer this: defun Schwartzian func list mapcar lambda x car x sort mapcar lambda x cons x funcall func x list lambda x y cdr x cdr y I know which I'd rather read. Ok, you've proved that lisp doesn't make sense without all those annoying parentheses. Congratulations. Fortunately, perl isn't lisp. Why does removing the parens force you to jam everything together on two lines? The only reason I can think of is that you're using some fancy autoindenting lisp editor. Fortunately, perl doesn't force you to use a special editor just to tame the obvious shortcomings of the language syntax. Perl *lets* you include parentheses, or not, whichever makes the code easier to read. Yeah, you can write ugly or broken code by leaving too many out. So? -- Robert Mathews Software Engineer Excite@Home
Re: perl6storm #0050
Simon Cozens wrote: Maybe you'd prefer this: defun Schwartzian func list mapcar lambda x car x sort mapcar lambda x cons x funcall func x list lambda x y cdr x cdr y What happened to the newlines? Also, "no parens" is not the only alternative to having parens. Other punctiation is available. One of the improvements ML makes over Lisp is the use of different bracketers to signify semantically different kinds of lists. -- John Porter Aus des Weltalls ferne funken Radiosterne.
Re: perl6storm #0050
On Tue, Sep 26, 2000 at 12:43:07PM -0700, Robert Mathews wrote: Ok, you've proved that lisp doesn't make sense without all those annoying parentheses. Congratulations. Fortunately, perl isn't lisp. Correct, John bringing lisp into the discussion *was* a canard. -- Writing software is more fun than working.
Re: perl6storm #0050
On Sat, 23 Sep 2000, raptor wrote: On Thu, 21 Sep 2000, Tom Christiansen wrote: =item perl6storm #0050 Radical notion: consider removing precedence. Wrong precedence makes people miserable. What if we have these 2 rules or no rules AND we can set manualy the precedence of all operators... as in PROLOG (op(precedencePriority,associativity!,operator)). I think this would be very unwise. Whenever adding a feature, we need to ask if the power granted outweighs the potential pitfalls created; in this case, I don't think it does. The potential problems of being able to assign precedence as you see fit (talk about action at a distance!) are enormous, and it does not seem to lend the same kind of elegant power that, for example, Damian's HOFs do. Dave
perl6storm #0050
On Thu, 21 Sep 2000, Tom Christiansen wrote: =item perl6storm #0050 Radical notion: consider removing precedence. Wrong precedence makes people miserable. (Some people already suggest that Perl only has two precedence rules: (1) multiplication and division come before addition and subtraction, and (2) parenthesize everything else.) This would make Perl more like Lisp, I suppose. But it would make code less ambiguous, probaly at the cost of readability. Arguably, some (most?) of the precedence levels already work the way people expect them to (for example, == binds more tightly than || or ), so fewer "cluttering" parentheses are needed to make things readable while still being correct. Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: perl6storm #0050
On Thu, 21 Sep 2000, Tom Christiansen wrote: =item perl6storm #0050 Radical notion: consider removing precedence. Wrong precedence makes people miserable. (Some people already suggest that Perl only has two precedence rules: (1) multiplication and division come before addition and subtraction, and (2) parenthesize everything else.) This would make Perl more like Lisp, I suppose. But it would make code less ambiguous, probaly at the cost of readability. Arguably, some (most?) of the precedence levels already work the way people expect them to (for example, == binds more tightly than || or ), so fewer "cluttering" parentheses are needed to make things readable while still being correct. What if we have these 2 rules or no rules AND we can set manualy the precedence of all operators... as in PROLOG (op(precedencePriority,associativity!,operator)). This way older scripts will still work , and for the new scripts any can decide ambiguousity or readability is more important!! = iVAN [EMAIL PROTECTED] =
