Re: Haskell infix syntax
On 07/03/11 01:01, Caligo wrote: On Sun, Mar 6, 2011 at 12:24 PM, Peter Alexander peter.alexander.au http://peter.alexander.au@gmail.com http://gmail.com wrote: On 6/03/11 4:22 PM, bearophile wrote: So I think it's not worth adding to D. But if you don't agree... talk. Bye, bearophile I agree. It would be nice in some situations (like cross and dot products for vectors), but otherwise it's unnecessary and just adds confusion in exchange for a tiny but of convenience in a handful of scenarios. With C++, for example, Eigen uses expression templates. How does one do expression templates in D? Could someone rewrite this http://en.wikipedia.org/wiki/Expression_templates this D? How does one do expression templates in D? Same basic idea but it should be a lot saner because D metaprograming isn't a Turing tar pit like with C++. The return type of your function is a template encoding in types of the inputs. So you could define an + operator that has a return type of opBinary(RHS,+,LHS) Or similar. The type of RHS and LHS could be other opBinary instansiations or a leaf time. Sooner or later you've got something that looks like a parse tree and you can process that at compile time using CTFE and then mixin the result. Heck, you might even be able to do something crazy like flatten the tree and re-parse and thus screw with the operator precedence or run your own specialized compiler backend and output inline asm. Trouble is, each time I feel motivated to give this a go I run into compiler bugs. Hopefully things will get better soon.
Re: Haskell infix syntax
On 2011-03-07 01:10, Jonathan M Davis wrote:
On Sunday 06 March 2011 10:03:05 Tomek Sowiński wrote:
bearophile bearophile napisał:
Haskell is full of function calls, so the Haskell designers have
used/invented several different ways to avoid some parenthesys in the
code.
From what I've seen if you remove some parenthesis well, in the right
places, the resulting code is less noisy, more readable, and it has less
chances to contain a bug (because syntax noise is a good place for bugs
to hide).
One of the ways used to remove some parenthesys is a standard syntax
that's optionally usable on any dyadic function (function with two
arguments):
sum a b = a + b
sum 1 5 == 1 `sum` 5
The `name` syntax is just a different way to call a regular function with
two arguments.
In Haskell there is also a way to assign an arbitrary precedence and
associativity to such infix operators, but some Haskell programmers
argue that too much syntax sugar gives troubles (
http://www.haskell.org/haskellwiki/Use_of_infix_operators ).
In D the back tick has a different meaning, and even if in D you use a
different syntax, like just a $ prefix, I don't know how much good this
syntax is for D:
int sum(int x, int y) { return x + y; }
int s = sum(1, sum(5, sum(6, sum(10, 30;
Equals to (associativity of $ is fixed like this):
int s = 1 $sum 5 $sum 6 $sum 10 $sum 30;
So I think it's not worth adding to D.
I vaguely recall someone mentioned infixablility by naming convention.
int _add_(int x, int y);
int s = 1 _add_ 5 _add_ 10;
As a feature of its own, it's just sugar. But if introducing infix
operators were contingent on banishing classic operator overloading, then
it is worthwhile.
LOL. And _what_ benefit would banishing classic operator overloading have? A
function named add could be abused in _exactly_ the same ways that + can be.
You could implement operator overloading without any special
cases/support in the language, like Scala does. In Scala
3 + 4
Is syntax sugar for:
3.+(4)
It's possible because of the following three reasons:
* Everything is an object
* Method names can contain other characters than A-Za-z_
* The infix syntax discussed in this thread
Implementing operator overloading like this also allows you to add new
operators and not just overloading existing ones.
--
/Jacob Carlborg
Re: Haskell infix syntax
On 03/07/2011 02:05 PM, Jacob Carlborg wrote:
You could implement operator overloading without any special cases/support in
the language, like Scala does. In Scala
3 + 4
Is syntax sugar for:
3.+(4)
It's possible because of the following three reasons:
* Everything is an object
* Method names can contain other characters than A-Za-z_
* The infix syntax discussed in this thread
Implementing operator overloading like this also allows you to add new
operators and not just overloading existing ones.
We could give a standard name to each character in an allowed class, so that
x !%# y
maps to
x.opBangPercentHash(y);
;-)
Another solution is to specify operators in method defs:
X opBangPercentHash as !%# (X y) {...}
Or even use them directly there:
X !%# (X y) {...}
possibly with an annotation to warn the parser:
@operator X !%# (X y) {...}
In any case, /this/ is not a big deal to manage in symbol tables, since an
operator is just a string like (any other) name. The big deal is to map such
features to builtin types, I guess (which are not object types).
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Haskell infix syntax
On Mar 7, 11 21:44, spir wrote:
On 03/07/2011 02:05 PM, Jacob Carlborg wrote:
You could implement operator overloading without any special
cases/support in
the language, like Scala does. In Scala
3 + 4
Is syntax sugar for:
3.+(4)
It's possible because of the following three reasons:
* Everything is an object
* Method names can contain other characters than A-Za-z_
* The infix syntax discussed in this thread
Implementing operator overloading like this also allows you to add new
operators and not just overloading existing ones.
We could give a standard name to each character in an allowed class, so
that
x !%# y
maps to
x.opBangPercentHash(y);
;-)
The current opBinary syntax already allows this ;)
Bar opBinary(string op:!%#)(Foo y) const {
...
}
Another solution is to specify operators in method defs:
X opBangPercentHash as !%# (X y) {...}
Or even use them directly there:
X !%# (X y) {...}
possibly with an annotation to warn the parser:
@operator X !%# (X y) {...}
In any case, /this/ is not a big deal to manage in symbol tables, since
an operator is just a string like (any other) name. The big deal is to
map such features to builtin types, I guess (which are not object types).
The big deal is it makes parsing more difficult (precedence and
associativity need to be determined) with no significant benefit.
Denis
Re: Haskell infix syntax
bearophile bearophileh...@lycos.com wrote: Simen kjaeraas: This is basically already possible in D: I suggest you to stop using the single underscore as identifier. And I suggest you stop being bothered about example code that's meant to illustrate a point rather than be production-ready. -- Simen
Re: Haskell infix syntax
On 3/7/11 5:05 AM, Jacob Carlborg wrote:
On 2011-03-07 01:10, Jonathan M Davis wrote:
On Sunday 06 March 2011 10:03:05 Tomek Sowiński wrote:
bearophile bearophile napisał:
Haskell is full of function calls, so the Haskell designers have
used/invented several different ways to avoid some parenthesys in the
code.
From what I've seen if you remove some parenthesis well, in the right
places, the resulting code is less noisy, more readable, and it has
less
chances to contain a bug (because syntax noise is a good place for bugs
to hide).
One of the ways used to remove some parenthesys is a standard syntax
that's optionally usable on any dyadic function (function with two
arguments):
sum a b = a + b
sum 1 5 == 1 `sum` 5
The `name` syntax is just a different way to call a regular function
with
two arguments.
In Haskell there is also a way to assign an arbitrary precedence and
associativity to such infix operators, but some Haskell programmers
argue that too much syntax sugar gives troubles (
http://www.haskell.org/haskellwiki/Use_of_infix_operators ).
In D the back tick has a different meaning, and even if in D you use a
different syntax, like just a $ prefix, I don't know how much good this
syntax is for D:
int sum(int x, int y) { return x + y; }
int s = sum(1, sum(5, sum(6, sum(10, 30;
Equals to (associativity of $ is fixed like this):
int s = 1 $sum 5 $sum 6 $sum 10 $sum 30;
So I think it's not worth adding to D.
I vaguely recall someone mentioned infixablility by naming convention.
int _add_(int x, int y);
int s = 1 _add_ 5 _add_ 10;
As a feature of its own, it's just sugar. But if introducing infix
operators were contingent on banishing classic operator overloading,
then
it is worthwhile.
LOL. And _what_ benefit would banishing classic operator overloading
have? A
function named add could be abused in _exactly_ the same ways that +
can be.
You could implement operator overloading without any special
cases/support in the language, like Scala does. In Scala
3 + 4
Is syntax sugar for:
3.+(4)
It's possible because of the following three reasons:
* Everything is an object
* Method names can contain other characters than A-Za-z_
* The infix syntax discussed in this thread
Implementing operator overloading like this also allows you to add new
operators and not just overloading existing ones.
How about precedence?
Andrei
Re: Haskell infix syntax
On Mar 8, 11 05:13, Andrei Alexandrescu wrote: How about precedence? They're not changeable[1] AFAIK. OTOH, Haskell have the infix[rl]? declarations to allow users to customize the precedence (within a limited range of levels) and associativity of an operator. Ref: [1] http://stackoverflow.com/questions/2922347/operator-precedence-in-scala
Re: Haskell infix syntax
On 2011-03-07 22:13, Andrei Alexandrescu wrote:
On 3/7/11 5:05 AM, Jacob Carlborg wrote:
On 2011-03-07 01:10, Jonathan M Davis wrote:
On Sunday 06 March 2011 10:03:05 Tomek Sowiński wrote:
bearophile bearophile napisał:
Haskell is full of function calls, so the Haskell designers have
used/invented several different ways to avoid some parenthesys in the
code.
From what I've seen if you remove some parenthesis well, in the right
places, the resulting code is less noisy, more readable, and it has
less
chances to contain a bug (because syntax noise is a good place for
bugs
to hide).
One of the ways used to remove some parenthesys is a standard syntax
that's optionally usable on any dyadic function (function with two
arguments):
sum a b = a + b
sum 1 5 == 1 `sum` 5
The `name` syntax is just a different way to call a regular function
with
two arguments.
In Haskell there is also a way to assign an arbitrary precedence and
associativity to such infix operators, but some Haskell programmers
argue that too much syntax sugar gives troubles (
http://www.haskell.org/haskellwiki/Use_of_infix_operators ).
In D the back tick has a different meaning, and even if in D you use a
different syntax, like just a $ prefix, I don't know how much good
this
syntax is for D:
int sum(int x, int y) { return x + y; }
int s = sum(1, sum(5, sum(6, sum(10, 30;
Equals to (associativity of $ is fixed like this):
int s = 1 $sum 5 $sum 6 $sum 10 $sum 30;
So I think it's not worth adding to D.
I vaguely recall someone mentioned infixablility by naming convention.
int _add_(int x, int y);
int s = 1 _add_ 5 _add_ 10;
As a feature of its own, it's just sugar. But if introducing infix
operators were contingent on banishing classic operator overloading,
then
it is worthwhile.
LOL. And _what_ benefit would banishing classic operator overloading
have? A
function named add could be abused in _exactly_ the same ways that +
can be.
You could implement operator overloading without any special
cases/support in the language, like Scala does. In Scala
3 + 4
Is syntax sugar for:
3.+(4)
It's possible because of the following three reasons:
* Everything is an object
* Method names can contain other characters than A-Za-z_
* The infix syntax discussed in this thread
Implementing operator overloading like this also allows you to add new
operators and not just overloading existing ones.
How about precedence?
Andrei
It's basically determined by the first character in the name of the
method. Associativity it determined by the last character in the name,
if it ends with a colon it's right associative, otherwise left.
Have a look at: http://www.scala-lang.org/docu/files/ScalaReference.pdf
6.12.3 InfixOperations
--
/Jacob Carlborg
Re: Haskell infix syntax
Jonathan M Davis napisał: As a feature of its own, it's just sugar. But if introducing infix operators were contingent on banishing classic operator overloading, then it is worthwhile. LOL. And _what_ benefit would banishing classic operator overloading have? I've worked on a financial system written in Java which used BigDecimal extensively. And, of course, I LOLed at that. But after having spent time with the code, a few benefits surfaced. It was clear which function was user-implemented. Displaying the docs by mousing over was nice too (outside the IDE grepping 'add' is easier than '+'). And above all, no abuse whatsoever. It all didn't outweigh the loss in terseness of syntax but did make up for some of it. I'm bringing up this case because it's extremely in favour of operator overloading. Java is not big on number crunching and BigDecimal is one of the few spots on the vast programming landscape where overloaded operators make sense. And yet, the final verdict was: it doesn't suck. A function named add could be abused in _exactly_ the same ways that + can be. There's far less incentive for abuse as there's no illusory mathematical elegance to pursue. The main benefit that infix syntax would provide would be if you had a variety of mathematical functions beyond what the built in operators give you, and you want to be able to treat them the same way. Whether classic operator overloading exists or not is irrelevant. That's mixing vect1 + vect2 with vect1 `dot` vect2. I'd rather see them treated the same way. Regardless, I don't think that adding infix syntax to the language is worth it. D is already pretty complicated and _definitely_ more complicated than most languages out there. One of the major complaints of C++ is how complicated it is. We don't want to be adding extra complexity to the language without the benefit outweighing that complexity, and I don't think that it's at all clear that it does in this case. I agree. Hence the idea of trading operator overloading for infixing. The added complexity is zero, if not less. As as KennyTM~ pointed out, if UFCS is ever implemented, it gives you most of the benefit of this anyway, and there are already a lot of people around here interested in UFCS. So, I find it _far_ more likely that UFCS gets implemented than an infix function call syntax. I also think it is more probable. -- Tomek
Re: Haskell infix syntax
Caligo napisał: With C++, for example, Eigen uses expression templates. How does one do expression templates in D? Could someone rewrite this http://en.wikipedia.org/wiki/Expression_templates this D? You may look at my approach for QuantLibD. http://dsource.org/projects/quantlibd/browser/ql/math/matrix.d Mind you, project suspended. -- Tomek
Haskell infix syntax
Haskell is full of function calls, so the Haskell designers have used/invented
several different ways to avoid some parenthesys in the code.
From what I've seen if you remove some parenthesis well, in the right places,
the resulting code is less noisy, more readable, and it has less chances to
contain a bug (because syntax noise is a good place for bugs to hide).
One of the ways used to remove some parenthesys is a standard syntax that's
optionally usable on any dyadic function (function with two arguments):
sum a b = a + b
sum 1 5 == 1 `sum` 5
The `name` syntax is just a different way to call a regular function with two
arguments.
In Haskell there is also a way to assign an arbitrary precedence and
associativity to such infix operators, but some Haskell programmers argue that
too much syntax sugar gives troubles (
http://www.haskell.org/haskellwiki/Use_of_infix_operators ).
In D the back tick has a different meaning, and even if in D you use a
different syntax, like just a $ prefix, I don't know how much good this syntax
is for D:
int sum(int x, int y) { return x + y; }
int s = sum(1, sum(5, sum(6, sum(10, 30;
Equals to (associativity of $ is fixed like this):
int s = 1 $sum 5 $sum 6 $sum 10 $sum 30;
So I think it's not worth adding to D.
Bye,
bearophile
Re: Haskell infix syntax
So I think it's not worth adding to D. But if you don't agree... talk. Bye, bearophile
Re: Haskell infix syntax
On Mar 7, 11 00:18, bearophile wrote:
Haskell is full of function calls, so the Haskell designers have used/invented
several different ways to avoid some parenthesys in the code.
From what I've seen if you remove some parenthesis well, in the right places,
the resulting code is less noisy, more readable, and it has less chances to
contain a bug (because syntax noise is a good place for bugs to hide).
One of the ways used to remove some parenthesys is a standard syntax that's
optionally usable on any dyadic function (function with two arguments):
sum a b = a + b
sum 1 5 == 1 `sum` 5
The `name` syntax is just a different way to call a regular function with two
arguments.
In Haskell there is also a way to assign an arbitrary precedence and
associativity to such infix operators, but some Haskell programmers argue that
too much syntax sugar gives troubles (
http://www.haskell.org/haskellwiki/Use_of_infix_operators ).
In D the back tick has a different meaning, and even if in D you use a
different syntax, like just a $ prefix, I don't know how much good this syntax
is for D:
int sum(int x, int y) { return x + y; }
int s = sum(1, sum(5, sum(6, sum(10, 30;
Equals to (associativity of $ is fixed like this):
int s = 1 $sum 5 $sum 6 $sum 10 $sum 30;
So I think it's not worth adding to D.
Bye,
bearophile
If we had UFCS this could be written as,
int s = 1.sum(5.sum(6.sum(10.sum(30;
or, knowing sum is associative,
int s = 1.sum(5).sum(6).sum(10).sum(30);
Re: Haskell infix syntax
KennyTM~: If we had UFCS this could be written as, UFCS is a huge hack that I hope to never see in D :-) Compared to it, the bad-looking $infix syntax I've just shown is tidy and safe. Bye, bearophile
Re: Haskell infix syntax
bearophile: UFCS is a huge hack that I hope to never see in D :-) How is it a hack? I can understand there being implementation problems that can make it undesirable to add, but calling it hack? It's one of the most elegant syntax proposals I've ever seen! It unifies objects and other functions in syntax. It improves encapsulation by giving full support to non-member functions. It improves modularity for the same reason. With ufcs, there'd be no desire to add useless members due to object syntax. Everything is equal - easy extensibility, better protection, cleaner interfaces. It's the opposite of a hack.
Re: Haskell infix syntax
bearophile bearophileh...@lycos.com wrote:
So I think it's not worth adding to D.
But if you don't agree... talk.
This is basically already possible in D:
struct InfixOperator( alias fn ) {
auto opBinaryRight( string op : /, T )( T lhs ) {
struct crazy {
T value;
auto opBinary( string op : /, U )( U rhs ) {
return fn( rhs, value );
}
}
return crazy(lhs);
}
}
@property auto _( alias fn )( ) {
return InfixOperator!fn( );
}
T add( T )( T a, T b ) {
return a + b;
}
unittest {
assert( 2 /_!add/ 3 == 5 );
}
--
Simen
Re: Haskell infix syntax
Simen kjaeraas simen.kja...@gmail.com wrote: This is basically already possible in D: Please do note that this was intended more as a challenge to myself than as a legitimate Good Idea. -- Simen
Re: Haskell infix syntax
Simen kjaeraas:
This is basically already possible in D:
I suggest you to stop using the single underscore as identifier.
unittest {
assert( 2 /_!add/ 3 == 5 );
}
OK. Now let's go back to Haskell :-)
Thank you for your answer,
bye,
bearophile
Re: Haskell infix syntax
bearophile bearophile napisał:
Haskell is full of function calls, so the Haskell designers have
used/invented several different ways to avoid some parenthesys in the code.
From what I've seen if you remove some parenthesis well, in the right places,
the resulting code is less noisy, more readable, and it has less chances to
contain a bug (because syntax noise is a good place for bugs to hide).
One of the ways used to remove some parenthesys is a standard syntax that's
optionally usable on any dyadic function (function with two arguments):
sum a b = a + b
sum 1 5 == 1 `sum` 5
The `name` syntax is just a different way to call a regular function with two
arguments.
In Haskell there is also a way to assign an arbitrary precedence and
associativity to such infix operators, but some Haskell programmers argue
that too much syntax sugar gives troubles (
http://www.haskell.org/haskellwiki/Use_of_infix_operators ).
In D the back tick has a different meaning, and even if in D you use a
different syntax, like just a $ prefix, I don't know how much good this
syntax is for D:
int sum(int x, int y) { return x + y; }
int s = sum(1, sum(5, sum(6, sum(10, 30;
Equals to (associativity of $ is fixed like this):
int s = 1 $sum 5 $sum 6 $sum 10 $sum 30;
So I think it's not worth adding to D.
I vaguely recall someone mentioned infixablility by naming convention.
int _add_(int x, int y);
int s = 1 _add_ 5 _add_ 10;
As a feature of its own, it's just sugar. But if introducing infix operators
were contingent on banishing classic operator overloading, then it is
worthwhile.
--
Tomek
Re: Haskell infix syntax
On Sunday 06 March 2011 09:34:07 Adam D. Ruppe wrote: bearophile: UFCS is a huge hack that I hope to never see in D :-) How is it a hack? I can understand there being implementation problems that can make it undesirable to add, but calling it hack? It's one of the most elegant syntax proposals I've ever seen! It unifies objects and other functions in syntax. It improves encapsulation by giving full support to non-member functions. It improves modularity for the same reason. With ufcs, there'd be no desire to add useless members due to object syntax. Everything is equal - easy extensibility, better protection, cleaner interfaces. It's the opposite of a hack. It is _not_ a hack. Whether it's desirable or not is another matter, but it is _not_ a hack. And really, the term hack is very imprecise and often subjective. It's the sort of accusation that pretty much kills any legitimate debate. It's generally unsupportable and subjective, so it adds nothing to the debate, but it has such a stink about it that it tends to make people avoid whatever was declared to be a hack. Sure, you still have lots of parens with UFCS, but you _do_ get the argument order that Bearophile was looking for. And while I've generally found the idea of using UFCS with primitives to be pointless, this is actually an example where it's _useful_ with primitives. No, UFCS is not a hack. Its implementation has enough problems due to ambiguities and the like that it may never make it into the language even if pretty much everyone would _like_ it in the language, but it's not a hack. - Jonathan M Davis P.S. Entertainingly enough, www.merriam-webster.com's definition for hack doesn't make it look bad at all: a usually creative solution to a computer hardware or programming problem or limitation It makes me wonder if the usage of the word (and thus its common meaning) has shifted over time or if the poor non-techy, dictionary folk just plain got it wrong. The hacker's dictionary definition makes it look more like the typical usage, but even it is a bit of a mixed bag in that respect: 1. /n./ Originally, a quick job that produces what is needed, but not well. 2. /n./ An incredibly good, and perhaps very time-consuming, piece of work that produces exactly what is needed.
Re: Haskell infix syntax
On Sunday 06 March 2011 10:03:05 Tomek Sowiński wrote:
bearophile bearophile napisał:
Haskell is full of function calls, so the Haskell designers have
used/invented several different ways to avoid some parenthesys in the
code.
From what I've seen if you remove some parenthesis well, in the right
places, the resulting code is less noisy, more readable, and it has less
chances to contain a bug (because syntax noise is a good place for bugs
to hide).
One of the ways used to remove some parenthesys is a standard syntax
that's optionally usable on any dyadic function (function with two
arguments):
sum a b = a + b
sum 1 5 == 1 `sum` 5
The `name` syntax is just a different way to call a regular function with
two arguments.
In Haskell there is also a way to assign an arbitrary precedence and
associativity to such infix operators, but some Haskell programmers
argue that too much syntax sugar gives troubles (
http://www.haskell.org/haskellwiki/Use_of_infix_operators ).
In D the back tick has a different meaning, and even if in D you use a
different syntax, like just a $ prefix, I don't know how much good this
syntax is for D:
int sum(int x, int y) { return x + y; }
int s = sum(1, sum(5, sum(6, sum(10, 30;
Equals to (associativity of $ is fixed like this):
int s = 1 $sum 5 $sum 6 $sum 10 $sum 30;
So I think it's not worth adding to D.
I vaguely recall someone mentioned infixablility by naming convention.
int _add_(int x, int y);
int s = 1 _add_ 5 _add_ 10;
As a feature of its own, it's just sugar. But if introducing infix
operators were contingent on banishing classic operator overloading, then
it is worthwhile.
LOL. And _what_ benefit would banishing classic operator overloading have? A
function named add could be abused in _exactly_ the same ways that + can be.
The main benefit that infix syntax would provide would be if you had a variety
of
mathematical functions beyond what the built in operators give you, and you
want
to be able to treat them the same way. Whether classic operator overloading
exists or not is irrelevant.
Regardless, I don't think that adding infix syntax to the language is worth it.
D
is already pretty complicated and _definitely_ more complicated than most
languages out there. One of the major complaints of C++ is how complicated it
is. We don't want to be adding extra complexity to the language without the
benefit outweighing that complexity, and I don't think that it's at all clear
that it does in this case. As as KennyTM~ pointed out, if UFCS is ever
implemented, it gives you most of the benefit of this anyway, and there are
already a lot of people around here interested in UFCS. So, I find it _far_
more
likely that UFCS gets implemented than an infix function call syntax.
- Jonathan M Davis
Re: Haskell infix syntax
Jonathan M Davis: And really, the term hack is very imprecise and often subjective. It's the sort of accusation that pretty much kills any legitimate debate. You are right, sorry for using a so subjective term. I will avoid it. Bye, bearophile
Re: Haskell infix syntax
On 3/6/11 6:04 PM, Jonathan M Davis wrote: On Sunday 06 March 2011 09:34:07 Adam D. Ruppe wrote: bearophile: UFCS is a huge hack that I hope to never see in D :-) How is it a hack? I can understand there being implementation problems that can make it undesirable to add, but calling it hack? It's one of the most elegant syntax proposals I've ever seen! It unifies objects and other functions in syntax. It improves encapsulation by giving full support to non-member functions. It improves modularity for the same reason. With ufcs, there'd be no desire to add useless members due to object syntax. Everything is equal - easy extensibility, better protection, cleaner interfaces. It's the opposite of a hack. It is _not_ a hack. Whether it's desirable or not is another matter, but it is _not_ a hack. And really, the term hack is very imprecise and often subjective. It's the sort of accusation that pretty much kills any legitimate debate. It's generally unsupportable and subjective, so it adds nothing to the debate, but it has such a stink about it that it tends to make people avoid whatever was declared to be a hack. I set out to write a post with pretty much the same message. During our long discussions about D2 at the Kahili coffee shop, one of us would occasionally affix that label to one idea or another (often in an attempt to make I don't like it seem stronger). It was very jarring. Andrei
