Warp wrote:
>     foo(a, bar(b, c), d, e)
> 
>   If you wrote that as a Haskell-style no-delimiters function call,
> I suppose it would look like:
> 
>     foo a bar b c d e

>   Exactly how does Haskell decide how many parameters 'bar' takes there
> (and consequently how many of the rest of the parameters are for 'foo')?

It's curried. Each function only takes one.

In your example, I'm pretty certain you *have* to have parens.

foo a (bar b c) d e

>   I can't even begin to imagine how you would write that using the
> "point syntax", seen in many examples posted by Andrew. Perhaps you
> use parentheses to enclose the 'bar' call?

Hmmmm. I don't know you can do it with "point syntax" either. I think 
the a . b . c syntax only works when the result of "c" is the one and 
only argument to "b", and the result of "b" is the one and only argument 
to "a".

So if you wanted a function that returns the sum of the lengths of a 
list of strings, you might write
     length . concat
or something, if "concat" was a function that took a list of strings and 
returned their concatenation.

>   There just is something about the Haskell paradigm and syntax that
> makes it confusing and hard to assimilate.

I think most of the powerful languages have syntax that's confusing and 
hard to assimilate. C and C++ are also very confusing in syntax. (For 
example, I can barely follow the reference-counting pointer code you 
posted, and that only because I am only trying to read it and not write 
it. :-)

Even Tcl, which has exactly 12 rules of syntax, winds up being confusing 
to newbies because it's *too* simple. LISP has too many parentheses, 
even tho the grammar is about 3 lines of BNF.

About the only languages that aren't confusing are the weak ones: BASIC, 
Pascal, etc.

If the language is powerful because it does a lot (like Ada or C++) you 
wind up with lots and lots of syntax and lots of rules about the 
interactions. If the language is powerful because it's simple and 
regular (like LISP or FORTH or Tcl or Haskell) then it's confusing 
because there's no *obvious* way to accomplish the powerful stuff you 
know the language is capable of. (Sort of like Go or Chess or something 
- simple rules but very unobvious combinations.)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Orchid XP v8 wrote:
> Warp wrote:
>>   Wouldn't it be simpler to do it like:
>>
>>     if(number == target) break;
>>     if(number < target) std::cout << "Too low.\n";
>>     else std::cout << "Too high.\n";
> 
> Mmm, I guess that would also work...

The pendant in me wants to have an actual condition as the argument to 
"while". :-)  Or at least

do {
   ....
} while (number != target);

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:

> The pendant in me wants to have an actual condition as the argument to 
> "while". :-)  Or at least
> 
> do {
>   ....
> } while (number != target);

Yeah - although that would require "number" to be declared outside the 
while loop so that it actually exists. ;-) More subtly, it would have to 
be initialised to a value that is guaranteed to not equal "target". Ooo, 
*that* could be a nasty bug to try to find...!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> Darren New wrote:
> 
>> The pendant in me wants to have an actual condition as the argument to 
>> "while". :-)  Or at least
>>
>> do {
>>   ....
>> } while (number != target);
> 
> Yeah - although that would require "number" to be declared outside the 
> while loop so that it actually exists. ;-)

Yes, I think so.

> More subtly, it would have to 
> be initialised to a value that is guaranteed to not equal "target". Ooo, 
> *that* could be a nasty bug to try to find...!

No, because you're using a "do while" instead of just a "while". That 
like "repeat until" in Pascal (except with a reversed boolean, of course).

And yes, you'd have to initialize the value, but that's all high-school 
programming type stuff. Probably the compiler at this point would warn 
you the variable isn't initialized.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Slime wrote:
>> I have a similar issue with stuff like
>>
>>   while (*x++ = *y++) {}
> 
> FYI, I have an issue with stuff like that too. C and C++ do make it easy to 
> write bad code. This is the second time you've mentioned that example, so I 
> assume someone once showed it to you and thought they were being clever. 
> They weren't! Or maybe it's just a popular example, because I was just 
> reading a book about coding style last night that gave that as a bad 
> example.

	The truth is that there is no shortage of programmers out there who 
write like this. I've literally read a C (or was it C++) book  that 
admitted it was obfuscated, and in the same breath suggesting that the 
reader should become accustomed to it because those constructs are common.

-- 
The meek shall inherit the dearth.


                     /\  /\               /\  /
                    /  \/  \ u e e n     /  \/  a w a z
                        >>>>>>mue### [at] nawazorg<<<<<<
                                    anl

Post a reply to this message

Warp wrote:

>   The above example code can thus be written as:
> 
>     while(true)
>     {
>         int value;
>         std::cin >> value; // Try to read an integer
>         if(std::cin.fail()) // If there was no integer in the input
>         {
>             std::cin.clear(); // Clear the error flags
>             std::string s;
>             std::cin >> s; // Read a string
>             if(!std::cin.good()) break;
>             std::cout << "The input was something else: " << s << "\n";
>         }
>         else
>         {
>             std::cout << "The input was an integer: " << value << "\n";
>         }
>     }
> 
>   Thus removing the need for stringstreams.

This doesn't appear to work. It waits for me to type a second token, and 
then works with that. (Either that or my program has some other random 
bug... If I ever figure out how to work VisualStudio's debugger I'll let 
you know!)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Sun, 21 Sep 2008 16:24:37 +0200, Darren New <dne### [at] sanrrcom> wrote:
> The pendant in me

Don't worry. It will come out naturally in a few days...



-- 
FE

Post a reply to this message

Fredrik Eriksson wrote:
> On Sun, 21 Sep 2008 16:24:37 +0200, Darren New <dne### [at] sanrrcom> wrote:
>> The pendant in me
> Don't worry. It will come out naturally in a few days...

Normally, complaining about spelling is silly. In this case, tho...

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> This doesn't appear to work. It waits for me to type a second token, and 
> then works with that.

  It works here. Did you try it with gcc?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Orchid XP v8 <voi### [at] devnull> wrote:
>> This doesn't appear to work. It waits for me to type a second token, and 
>> then works with that.
> 
>   It works here. Did you try it with gcc?

Just for completeness, yeah. Also didn't work. Unless I did something 
"else" wrong with the code as well...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message