![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> Sure. In that case, it makes a difference - and so you'd better decide
> which one you actually meant. But remember, Haskell's string concat
> operator is (++), not (+).
Well, better example: If the operator is * and the elements are matrices.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Invisible <voi### [at] dev null> wrote:
>> Sure. In that case, it makes a difference - and so you'd better decide
>> which one you actually meant. But remember, Haskell's string concat
>> operator is (++), not (+).
>
> Well, better example: If the operator is * and the elements are matrices.
Yes. In that case, you'd better be really clear about which way you
actually meant.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> Sure. But taking a solid, flexible and simple infrastructure and making
> it complex and convoluted isn't such a hot idea.
The secret is to have something in the infrastructure that lets you hide the
convoluted complexity, whether that be LISP macros or Tcl upvar or C++
templates. Otherwise, you get Java.
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible escreveu:
> nemesis wrote:
>> If I'm not wrong, core Haskell is about as clean and simple as plain
>> Scheme, both based on lambda calculus. Building upon solid, flexible
>> and simple infrastructure is not a bad idea.
>
> Sure. But taking a solid, flexible and simple infrastructure and making
> it complex and convoluted isn't such a hot idea.
By simple of course we mean things that twist and bend the minds of
common, mortal programmers. We're just abstracting that a step further. ;)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |