>> What compiler are you using?
>
> GCC, on Linux, running under QEMU. (Because it's what I have to hand.)


Huh. Crazy that it wouldn't give at least a warning for that. Maybe there's 
a switch to give more picky warnings?

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

> 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.

That code tries to do too much at once and is difficult to understand. If 
you made a small mistake while writing it, it wouldn't be immediately 
obvious that there's a problem with the logic. It's bad code. Its only use 
is to help you understand operator precedence and the behavior of the 
different operators. It's very possible to write code that does the same 
thing in a clearer way.

C and C++ just require responsibility. =)

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

> To me, all that tricky slight of hand with "break" and "continue" seems 
> far less clear then just directly saying exactly what you want to happen, 
> as the Haskell version does.

You can eliminate the "continue" in your example if you write it like this:

    if ( cmd == "^" )
        break;
    else if ( cmd == "+" )
        Add(stack);
    else if ( cmd == "-" )
        Sub(stack);
    else
        stack.push_back(1);


As for the break, it could just as easily be a 'return' like in the haskell 
code, if you didn't want to print "exit" or if you brought the loop into its 
own function.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

On 20-Sep-08 21:30, Darren New wrote:
> andrel wrote:
>> why would want you distinguish reserved words, variables and functions?
>> In C(++) they might be implemented quite differently, that does not 
>> mean however that are fundamentally different on a conceptual level.
> 
> I'm pretty sure "reserved words" are conceptually quite different from 
> variables, yes. 

Indeed, but only if you assume you have a language that makes that 
distinction. It is not a concept that is inherently a part of any 
language. Maths does not have 'reserved words'. I.e. for the casual 
observer things like '=' and '+' looks as though they are universally 
defined and understood the same way. In practice even these are 
sometimes redefined to suit a specific field or application in a way 
that may even go deeper than overloading. Many operators are also 
'reserved words' in certain subfields and not existent in others. If you 
want to model a language on the way mathematics is used, defining 
'reserved words' is something you might want to leave out.

> Unless you're talking about an extensible language like 
> LISP or FORTH or Tcl, the reserved words let you do things that you 
> can't do with functions and variables, and vice versa.

I think that FORTH introduced me to the idea that it makes sense to 
introduce user level control flow mechanisms.

> Knowing what's an argument and what's a function is also pretty 
> important for understanding how a given line of code works. 

Again absolutely true, for a imperative language. In lambda calculus and 
any functional language derived from that this distinction make no sense 
at all.

> If you can't 
> look at the code and figure out which function bodies get evaluated, it 
> makes it really rough to work out what's going on, even in a functional 
> language.

I don't think so. If you have an entity called current_temperature it 
should not matter if that is derived by looking at a specific memory 
location (a variable), by looking at an index in a circular buffer 
(array) or by doing something more complicated like calling a function 
of generating an interrupt. OK, it does matter sometimes but only in an 
implementation. It should not have any influence on understanding the 
code conceptually.


I think you understood that my mean reason for my response was that Warp 
is looking with imperative spectacles to lines of code in a functional 
language and desperately trying to force it into his own mindframe. Then 
again, he might just be pulling Andy's legs. I know he does that 
sometimes and I have not followed the entire thread.

Post a reply to this message

>>> What compiler are you using?
>> GCC, on Linux, running under QEMU. (Because it's what I have to hand.)
> 
> 
> Huh. Crazy that it wouldn't give at least a warning for that. Maybe there's 
> a switch to give more picky warnings?

Yeah. -Wall. Apparently.

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

Post a reply to this message

Warp wrote:

>   Now you'll have to implement the same program in C++. ;)

Yes. That'll be harder, of course - I don't know the standard library 
for C++ inside-out yet. ;-)



I know you probably won't care, but take a look at this:

   http://haskell.org/hoogle/

Now, suppose I want a function that takes a String and turns it into an 
Integer. If you type in

   String -> Integer

and hit the search button, the very first result is

   Prelude.read :: (Read a) => String -> a
   (base)

Which tells you that the "Prelude" module (implicitly imported by all 
Haskell modules) contains a function named "read", which will transform 
a String into any type "a" that is a memory of the "Read" class. (And it 
turns out that *all* the basic types are members of this class.)

Similarly, suppose I want to, say, discover whether a given list 
contains a specified element. Well, the function that does that is 
obviously going to take two arguments - a list, and a thing to find. 
Slightly less obviously, you can only do this for types that can be 
compared. In Haskell, that means types that belong to the 
cryptically-named "Eq" class. So we have

   (Eq x) => [x] -> x -> Bool

A quick search, and we get

   Prelude.elem :: (Eq a) => a -> [a] -> Bool
   (base)

Notice how the arguments are actually the other way round, but the 
search still found the function. (You can also search by name - useful 
if you find yourself asking something like "dude, WTF is 'nub' supposed 
to be?!")

You might not care about Haskell, but you gotta admit all of this is 
pretty neat, eh?



Now, the question is... is there a similar resource for C++? Because for 
starters, the first thing I'm gonna want to know is how to choose a 
random number in C++. ;-) (Altough I dare say for *that*, a simple 
Google search will probably answer...)

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

Post a reply to this message

Warp wrote:

>>    case compare number target of
> 
>   I think this line illustrates well what I wrote earlier. Just a list
> of whitespace-sepaated words. No delimiters, no hints about what might be
> a reserved keyword, what might be a variable, what might be a function.

Fair point.

The following are reserved keywords in Haskell:

   module, where, import, qualified, hiding, as, case, of, let, in, 
data, type, newtype, class, instance, deriving, do

I'm pretty sure that's the complete list. I count 17 reserved words. (A 
quick Google search indicates that C++ has roughly 90 of 'em.) If you 
see any of these words, it's a keyword.

(It's actually kinda irritating that "in" and "as" are keywords; these 
would make convinient variable names from time to time, e.g., handles 
named "in" and "out". But, alas, no...)

>   I'm no at all sure how that should be parsed. Could it, perhaps, be
> something like:
> 
>     case(compare(number, target)) of
> 
>   What would be wrong with a syntax like that?

You can write

   case (compare number target) of

if you prefer. This is completely valid syntax.

Now, if it was pretty-printed like THIS:

   http://hpaste.org/10565

you wouldn't be as confused. (?) If you have some kind of text editor 
with syntax-hilighting, this isn't an issue. (I don't know anything 
about Emacs, but I imagine it can't be hard to program it so that just 
the 17 words above print in a different colour...)

As for why functions aren't called like foo(x, y, z) like in C... that's 
due to function currying. In Haskell, you say "foo x y z" because then 
you can write "foo x y" to mean a function that just accepts "z". (Or 
just "foo x" for one that accepts "y" and "z", or "foo" for the function 
itself, or whatever.)

Note that you *can* write foo (x, y, z) in Haskell, because "(x, y, z)" 
is what Haskell calls a "tuple". This has a different type though. (It's 
like the difference between calling a C++ function with an array verses 
a vector. Same concept, different implementation - and type.) This is a 
so-called "uncurried function", and they aren't used much.

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

Post a reply to this message

Vincent Le Chevalier wrote:

> Honestly just from the strings that are being printed one can guess what 
> this program is meant to be doing... Should be true of any language. 

Well, you'd hope so, yes... ;-)

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

Post a reply to this message

Orchid XP v8 wrote:

> The following are reserved keywords in Haskell:
> 
>   module, where, import, qualified, hiding, as, case, of, let, in, data, 
> type, newtype, class, instance, deriving, do
> 
> I'm pretty sure that's the complete list. I count 17 reserved words.

WRONG! It's actually 21. I forget if/then/else, and apparently "default" 
is a keyword...? (Ah, yes. The Haskell '98 Language Report explains that 
this very obscure keyword is for adjusting the type defaulting 
mechanism. As if you'd want to...)

> (I don't know anything 
> about Emacs, but I imagine it can't be hard to program it so that just 
> the 17 words above print in a different colour...)

Apparently it's already been done. (SUPRISE!)

http://www.iro.umontreal.ca/~monnier/elisp/#haskell-mode

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

Post a reply to this message

Orchid XP v8 wrote:
> Nicolas Alvarez wrote:
> 
>> I understand the C++ one and the Haskell one looks like line noise.
> 
> Uh-huh, and let me guess: You already know how to read and write C++
> fluently, but you know nothing about Haskell yet? :-P

Correct.

> Seriously, I am constantly baffled by statements like this.

But you used to say the same in the opposite direction. "That C++ looks SO
unreadable, yet I fully understand this mess of a haskell program".

Post a reply to this message