Darren New <dne### [at] sanrrcom> wrote:
> I think Haskell is line oriented. Commands end at the end of lines. 

  What happens if the expression is very long? For example, a function
could take a large amount of parameters, all of which are long expressions
using long variable names.

  I think I'm starting to understand *why* Haskell people prefer using
short and cryptic variable names rather than long and clear ones: If they
did the latter, they would run out of space in their limited lines... :P

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I think Haskell is line oriented. Commands end at the end of lines. 
> 
>   What happens if the expression is very long? For example, a function
> could take a large amount of parameters, all of which are long expressions
> using long variable names.

Put each argument on a seperate line, indented further than the function 
name.

   foo
     arg1
     arg2
     arg3

>   I think I'm starting to understand *why* Haskell people prefer using
> short and cryptic variable names rather than long and clear ones: If they
> did the latter, they would run out of space in their limited lines... :P

Heh. Haskell programs *do* tend to end up with pretty long lines, that's 
for sure. ;-)

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

Post a reply to this message

Warp wrote:
>   What happens if the expression is very long? For example, a function
> could take a large amount of parameters, all of which are long expressions
> using long variable names.

I don't know. In Tcl, you put a backslash at the end of the line. Just 
like bash or anything else.

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

Post a reply to this message

>>   What happens if the expression is very long? For example, a function
>> could take a large amount of parameters, all of which are long 
>> expressions
>> using long variable names.
> 
> Put each argument on a seperate line, indented further than the function 
> name.

Or... make them local variables.

(That's more usually done if a certain subexpression is needed more than 
once - since, obviously, putting it in a variable makes it only evaluate 
once. But you can also use it to break things up - especially if what 
you're doing is complicated.)

   let
     thing1 = ...
     thing2 = ...
     thing3 = ...
   in foo thing1 thing2 thing3

Notice that, unlike in "normal" languages, let is an *expression*, but a 
*statement*, so it is valid absolutely anywhere an expression is valid. 
That includes absurd constructions like

   (let x = 5 in x) + (let y = 2 in y)

which just means "5 + 2".

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

Post a reply to this message

Nicolas Alvarez wrote:

> I understand the C++ one and the Haskell one looks like line noise.

OK, well how about this:



module Main where

import System.Random

main = do
   target <- randomRIO (1, 100)
   guess target

guess target = do
   putStr "Guess: "
   txt <- getLine
   let number = read txt :: Int

   case compare number target of
     LT -> do putStrLn "Too low.";  guess target
     GT -> do putStrLn "Too high."; guess target
     EQ -> do putStrLn "You win!"



Does that look like line noise to you? Or can you figure out what that does?

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

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> 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.

  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?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>     case(compare(number, target)) of
>   What would be wrong with a syntax like that?

All the functions in Haskell are curried. So it's really
   case (compare(number)(target)) of ...

But yes, this is exactly the kind of thing I have trouble with too, in 
these sorts of languages. Especially when it gets a little more complex 
and you get stuff like
    case bump . hither $ yo stuff of ...
or when people start writing binary functions that take values on both 
the left and the right (in SML, not Haskell) and giving them names like 
"o", with functions returning other functions composed by "o", which was 
apparently not unlike the "." in Haskell.

    this o that value
OK, so what's the precidence on that in ML? Yarg.

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

Post a reply to this message

On 20-Sep-08 20:31, Warp wrote:
> Orchid XP v8 <voi### [at] devnull> 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.
> 
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. Haskell 
apparently does not make such arbitrary and implementation driven 
distinctions. I think we can only applaud that.

Post a reply to this message

Orchid XP v8 a écrit :
>   putStr "Guess: "

>     LT -> do putStrLn "Too low.";  guess target
>     GT -> do putStrLn "Too high."; guess target
>     EQ -> do putStrLn "You win!"
> 
> Does that look like line noise to you? Or can you figure out what that 
> does?

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 one where the strings do not have to be somehow encoded of course ;-)

-- 
Vincent

Post a reply to this message

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

Knowing what's an argument and what's a function is also pretty 
important for understanding how a given line of code works. 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.

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

Post a reply to this message