 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> In the case alternatives, the line end *is* the delimiter. So if you
> were to "change only the spacing" then you could actually CHANGE THE
> MEANING of the program! (In fact, likely, cause it to no longer
> compile.) This is different from "curly bracket languages" where you use
> "{", "}" to delimit blocks, and ";" as a seperator. In Haskell,
> generally a newline is a seperator, and indentation delimits blocks.
>
> So, this works:
>
> case foo of
> 1 -> bar1
> 2 -> bar2
> 3 -> bar3
>
> If the expressions are a bit bigger, you can say
>
> case foo of
> 1 ->
> very_long_thing_1
> 2 ->
> very_long_thing_2
> 3 ->
> very_long_thing_3
>
> And if they're really long, you can say
>
> case foo of
> 1 ->
> multiline1
> multiline2
> multiline3
> 2 ->
> another_block_1
> another_block_2
> 3 ->
> yet_another_block
>
> or some such. The case expression itself ends when we get to something
> less indented.
Just like Python, then :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Does that look like line noise to you? Or can you figure out what that
> does?
Looks understandable, but what the hell does 'guess' do??
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] dev null> wrote:
> Because for starters, the first thing I'm gonna want to know is how to
> choose a random number in C++. ;-)
C++ itself doesn't have a random number library (something which will
be fixed in the next C++ standard), but <cstdlib> does have a rand()
function. Rather unusually for a C function, the usage of rand() is
simple and safe: You simply call it, and it returns a random integer
value between 0 and RAND_MAX.
A simple way of getting a value so that 0 <= value < n, is:
int value = std::rand() % n;
Of course it will always return the same values every time you run the
program. If you want it to return different values, you'll have to seed
it with a clock value. Again, no time functions in C++, but the C versions
are also unusually easy and safe to use (at least in this case). Include
<ctime> and then you can seed the rng at the beginning of your program:
std::srand(std::time(0));
And by the way, no, this will probably not work correctly:
int value = std::rand() * n / RAND_MAX;
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> Indeed, but only if you assume you have a language that makes that
> distinction.
That's what I said.
> 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.
Correct. Except that given the programming language, reserved words are
fundamentally different from functions or variables. That's why they're
reserved.
Kind of like parens in math - once you decide you have a grouping
operator that's written ( ), you really can't use it to define functions
called ( and ).
The confusion, I think, is that you think maths doesn't have reserved
words. It does. They're just outside of the maths.
For example, the "summation function" is kind of the same as the for
loop: start variable and value below the sigma, stop value above the
sigma, expression to evaluate to the right of the sigma. The reserved
words, in this case, is the English sentence I just wrote describing the
functionality.
Unfortunately, to communicate with the computer about how a compiler
works, we need to speak something other than English. That's where the
reserved words come in. They're a way for the compiler writer to let the
compiler user communicate with the compiler. They are part of the syntax
of a language that is implicit in the rules for evaluating the
functions, just like (A^A)->C you can do a production to find that A->C
because of the rules of pattern matching and substitution. It's
virtually impossible (or even utterly impossible) to formalize the
productions you use in your formalization.
> want to model a language on the way mathematics is used, defining
> 'reserved words' is something you might want to leave out.
Granted. But Haskell doesn't model a language on the way mathematics is
used. It models a language on one particular mathematics. The reserved
words are a syntactic shortcut for a much larger lambda expression, just
like "193" is a syntactic shortcut for a big long string of bits in a
turing machine.
>> 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.
Except that Haskell is obviously beyond lambda calculus in its
implementation and meaning. See any of Andrew's postings about writing
"2+2" in lambda calculus.
>> 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.
Sure. And if you have an entity called "o" or "+" or "case" or "start"?
> 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.
I wouldn't go that far, but yes. But if you have a language that defines
complex syntax (which Haskell does a little and C++ does a lot) and you
can't even parse the syntax tree because you can't distinguish reserved
words from variables or functions, then you must admit it's going to be
difficult to read the code. Indeed, if you can't even tell where one
expression ends and another starts, it can be very difficult to
understand the code.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Orchid XP v8 wrote:
>> In Haskell,
>> generally a newline is a seperator, and indentation delimits blocks.
>
> Just like Python, then :)
Probably. ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Looks understandable, but what the hell does 'guess' do??
What, you can't guess?
*rimshot*
Sorry, couldn't resist that... ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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!"
>
> Now you'll have to implement the same program in C++. ;)
This appears to work:
#include <iostream>
#include <sstream>
#include <cstdlib>
#include <ctime>
void guess(const int target)
{
while (true)
{
std::cout << "Guess: ";
std::string txt;
std::cin >> txt;
std::istringstream iss(txt);
int number;
iss >> number;
if (number < target) {std::cout << "Too low." << std::endl; continue;}
if (number > target) {std::cout << "Too high." << std::endl; continue;}
break;
}
std::cout << "You win!" << std::endl;
}
int main()
{
std::srand(std::time(0));
const int target = std::rand() % 99 + 1;
guess(target);
}
A few missing semicolons, a few missing std:: qualifiers, and then it
basically ran first time.
(It is unclear to me whether I could have thrown in a few more "const"
keywords, but for such a short example it probably doesn't matter.)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> 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.
More like, "it's the only bit of C that I know". (I'd use an example of
printf() or something, but first I'd have to find an example that's
actually *correct*...)
Both C and C++ are positively *bursting* with features that are subtle,
counter-intuitive and cryptic. This isn't exactly news. C++ at least
appears to be something of an improvement in this regard...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> 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".
Beauty is in the eye of the beholder?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> std::string txt;
> std::cin >> txt;
> std::istringstream iss(txt);
> int number;
> iss >> number;
I think you misunderstood the reason to use stringstreams. Recycling the
user input through the stringstream above is basically a no-op (except that
it's needlessly inefficient). You could have read the value directly from
std::cin:
int number
std::cin >> number;
Why I suggested using stringstreams in your original program was because
you wanted to read either a string or an integer. This can be done by
reading a string, and then trying to parse it as an integer with a
stringstream (which also allows you to check if the parsing succeeded).
However, here you are simply always reading an integer. There's no need
to use stringstreams.
> if (number < target) {std::cout << "Too low." << std::endl; continue;}
> if (number > target) {std::cout << "Too high." << std::endl; continue;}
> break;
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";
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
