Yesterday, this came into existence:

http://tryhaskell.org/

It gives you a window with a command prompt. Type any valid Haskell 
expression and it'll execute it and display the result (and the type 
signature of the result).

There used to be another site like this powered by LambdaBot, but it 
stopped working years ago. Finally we have a working site again.

Of course, it's still alpha quality. The command history is screwier 
than a squirrel. I/O operations fail with a perplexing error message. 
(OK, there's no obvious way for I/O operations to work - and we don't 
want random Internet users deleting files off the server! - but the 
error could be better.) Most seriously, you can only enter 1-liners. You 
can't define variables and then use them later; the entire thing you 
want to execute must be a single, giant, line.

Actually, I have a question. How is a site like this even physically 
possible in the first place? How can you send a request to the server 
and receive a response without reloading the entire page? I've seen 
several sites do this, but I have no idea how it's possible.

Anyway, the site has a small (OK tiny) tutorial which will teach you 
about 0.1% of Haskell. (Type "help" to start it.) Here's a few cryptic 
1-liners for producing "interesting" results:

product [1..100]
(Calculate 100!, which is really, really big by the way.)

let f = 1 : 1 : zipWith (+) f (tail f) in f
(Infinite list of Fibonacci numbers.)

let p = [1] : map (\r -> zipWith (+) ([0] ++ r) (r ++ [0])) p in p
(Infinite Pascal's triangle.)

scanl (*) 1 [1..]
(Infinite list of factorials.)

[ (x,y) | x <- ['A'..'Z'], y <- [1..10] ]
(Cartesian product of two lists.)

filterM (const [True, False]) "ABC"
(All sublists of a list.)

Obviously the "infinite" results get truncated to be finite. Also if you 
ask the server to do anything really slow, it terminates the calculation 
after a second or so and just says "terminated".

Post a reply to this message

Invisible wrote:
> Actually, I have a question. How is a site like this even physically 
> possible in the first place? How can you send a request to the server 
> and receive a response without reloading the entire page? 

The term you're looking for is AJAX, which is a method of programming web 
pages that uses the XMLHttpRequest function. If you understand generally how 
XMLHttpRequest works, you'll understand how this works.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

>> Actually, I have a question. How is a site like this even physically 
>> possible in the first place? How can you send a request to the server 
>> and receive a response without reloading the entire page? 
> 
> The term you're looking for is AJAX, which is a method of programming 
> web pages that uses the XMLHttpRequest function. If you understand 
> generally how XMLHttpRequest works, you'll understand how this works.

Right, so... if I'm understanding this right, XMLHttpRequest allows a 
mere script to instruct the browser to send an HTTP request, and return 
the body of the response as data, which the script can then further 
manipulate? (Rather than, say, just nagivating to another page, in which 
case the script can't process the data because the script won't even 
*exist* any mroe...)

I had no idea that you can actually do that...

(Then again, Wikipedia's example code seems to show JavaScript doing 
exception handling too, which I had no idea was possible.)

Post a reply to this message

Invisible wrote:

> Right, so... if I'm understanding this right, XMLHttpRequest allows a 
> mere script to instruct the browser to send an HTTP request, and return 
> the body of the response as data, which the script can then further 
> manipulate?

http://www.w3.org/TR/XMLHttpRequest/#the-xmlhttprequest-interface

Seems reasonably clear...

Post a reply to this message

> http://tryhaskell.org/

The tutorial was good up until step 7, then the line:

> let villain = (28,"chirs") in fst villain

Made no sense at all.  I get it returns 28, but it's confusing what's going 
on, why the need for a variable (I assume villain is a variable name?).  I 
would have thought that writing 'fst (28,"chirs")' would be the thing to do 
to return 28? (I guess that fst returns the first element of a list?)

A lot of guessing and confusing on my part without much explanation...

Post a reply to this message

scott wrote:
>> http://tryhaskell.org/
> 
> The tutorial was good up until step 7, then the line:
> 
>> let villain = (28,"chirs") in fst villain
> 
> Made no sense at all.

I agree. Several concepts introduced at once without much explanation.

(Apparently the author also agrees, and is looking at trying to do 
better...)

Post a reply to this message

Invisible wrote:
> Right, so... if I'm understanding this right, XMLHttpRequest allows a 
> mere script to instruct the browser to send an HTTP request, and return 
> the body of the response as data, which the script can then further 
> manipulate? (Rather than, say, just nagivating to another page, in which 
> case the script can't process the data because the script won't even 
> *exist* any mroe...)

Exactly, yes.

> I had no idea that you can actually do that...

Well, there ya go. MS actually invented that technique with ActiveX for 
their Outlook web thing, and everyone else picked up on it and turned it 
into a standard.

> (Then again, Wikipedia's example code seems to show JavaScript doing 
> exception handling too, which I had no idea was possible.)

Huh. I don't remember ever doing that, but I guess if the browser can tell 
you about errors, then there's probably some way to catch them.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

Darren New wrote:

>> I had no idea that you can actually do that...
> 
> Well, there ya go. MS actually invented that technique with ActiveX for 
> their Outlook web thing, and everyone else picked up on it and turned it 
> into a standard.

Looking at the W3C standard spec, there seems to be *huge* abouts of 
tricky processing and non-obvious behaviour which strongly looks as if 
it's only there for backwards compatibility (i.e., because this is the 
ad hoc way the first implementation happened to do it).

Man, web stuff is messy...

Post a reply to this message

Invisible wrote:
> ad hoc way the first implementation happened to do it).

Yeah. You want to know who started the browser wars? Look at your agent 
string. :-)

There are also a lot of standards that got changed in subtle ways that broke 
a lot of stuff, because the first spec was basically "here's how we do it." 
For example, Netscape said "Here's how we do cookies.  Yadda yadda only save 
20 per site yadda yadda."  IE did the same thing.  W3C comes along and makes 
a standard that says any number of cookies per site. Lots of web sites that 
for some stupid reason depended on only having 20 cookies fail with 
W3C-compliant browsers, continuing to work with IE *because* MS won't follow 
the standards and instead wants the web pages to work right for their 
customers, even when the pages on the server are stupidly coded. Launch 
complaining in 3... 2... 1....

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I had no idea that you can actually do that...

  You clearly haven't used gmail.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> I had no idea that you can actually do that...
> 
>   You clearly haven't used gmail.

Indeed. But I have, at least, heard of it. ;-)

Post a reply to this message

> Right, so... if I'm understanding this right, XMLHttpRequest allows a mere 
> script to instruct the browser to send an HTTP request, and return the 
> body of the response as data, which the script can then further 
> manipulate?

What happens when the user presses the back button after such a process? 
Can the script intercept this and provide its own "back" functionality?

I've definitely got annoyed by some sites where you hit the back button and 
it takes you to a site you were looking at 10 minutes ago, because all the 
things you've been doing on this site haven't actually loaded a new page...

Post a reply to this message

scott wrote:

> I've definitely got annoyed by some sites where you hit the back button 
> and it takes you to a site you were looking at 10 minutes ago, because 
> all the things you've been doing on this site haven't actually loaded a 
> new page...

Yeah, this is a lot of fun.

The other one is "JavaScript links". You know, where the "link" isn't 
actually a hyperlink, it executes some JavaScript, which then tells the 
browser to change URL. And because it's scripted, you can't Ctrl+click 
to open the URL in a new window. (Or if you do, the existing window 
changes URL anyway, so you *still* don't have the original page. At 
least you can usually use the browser history to go back a page though.)

And then there's the links which pop up a "window" over the current 
page. You know the kind - the whole page goes grey and a funky little 
box appears over the top of it, and you can't do anything with the rest 
of the page until you dismiss the box. (Modal dialogs suck for a reason!)

Lots of shopping sites like to take you to a completely different page 
as soon as you've bought something, which also tends to thwart any 
attempt to used tabbed browsing to nagivate around. You've got a page of 
items, but as soon as you buy one, the page goes away. Great. Now I have 
to somehow navigate back to where I just was...

Post a reply to this message

Invisible wrote:

> Seems reasonably clear...

Hmm, I wonder if I could use this to implement distributed MVC, like in 
my Final Year Project, but without requiring a custom client.

Of course, as far as I can tell, I need a real web server to even 
experiment with this stuff, so...

Post a reply to this message

scott wrote:
> The tutorial was good up until step 7.

Hmm, maybe I should write my own?



 > 2 + 2
That was easy, eh?

 > 2 + 3 * 4
The usual operator precedence rules apply.

 > (2 + 3) * 4
You can override operator precedence manually in the usual way.

 > sqrt 144
This is a function call. (Notice the lack of brackets!)

 > div 10 3
This is a 2-argument function. (Again, notice the lack of any brackets.) 
It performs integer division (i.e., division to the nearest whole number.)

 > 10 / 3
Does the same calculation, but with floating-point arithmetic.

 > 10 `div` 3
This does the same thing as the first one, but it looks more natural. 
The backticks work for any 2-argument function.

 > sin 1 + cos 1
This is sin(1) + cos(2).

 > sin (1 + cos 1)
This does a different calculation.

 > sin -1
This gives an error, because it thinks you mean "sin - 1", which is 
invalid. (Yes, we all think it's very annoying.)

 > sin (-1)
This works properly.

 > "This is a string."

 > 'X'
This is a single character.

 > "X"
This is a string that only contains 1 character.

 > ""
This is an empty string.

 > [8, 3, 11, 2]
This is a list of numbers.

 > ['X', 'Y', 'Z']
This is a list of characters. Note that a string *is* a list of characters!

 > ['X', 3]
A list can contain elements of any type, but all elements must be of 
*the same* type. This example is therefore invalid. (Nice clear error 
message, eh?)

 > sort [8, 3, 11, 2]
 > reverse [8, 3, 11, 2]
 > sum [8, 3, 11, 2]
 > 3 `elem` [8, 3, 11, 2]
 > 4 `elem` [8, 3, 11, 2]
Haskell has many, many list functions.

 > [1, 2, 3] ++ [4, 5, 6]
This joins two lists together.

 > [1..10]
This is a shorthand for writing lists.

 > sum [1..100]
Add up these numbers.

 > product [1..100]
Multiply these numbers. (Notice that even though the answer is huge, 
Haskell computes it exactly.)

 > take 3 [5,4,6,3,7,2,8,1,9]
Get the first 3 elements.

 > drop 3 [5,4,6,3,7,2,8,1,9]
Remove the first 3 elements.

 > [5,4,6,3,7,2,8,1,9] !! 5
Get the 6th element. (The first element is index zero, not index one!)

 > filter odd [5,4,6,3,7,2,8,1,9]
Filter a list according to a condition.

 > filter (> 5) [5,4,6,3,7,2,8,1,9]
Filter with a different condition.

 > map (*2) [5,4,6,3,7,2,8,1,9]
Double all the numbers in the list.

 > map toUpper "This is a string."
Since strings are just lists that contain characters, all list functions 
work on strings.

 > sin
You can't print this out, so you get an error.

 > :t sin
This tells the interpretter to only print the type signature, not 
*execute* the code. (This is an interpretter command, not a Haskell 
command.)

 > (5, 'x')
This is a "tuple". Tuples can contain any number of elements, and they 
can be of different types. Their main use is in returning several 
results from a single function call.

 > partition odd [5,4,6,3,7,2,8,1,9]
This splits the list into two lists, containing odd and not-odd numbers. 
The lists are returned as a size-2 tuple.

 > :t fst
Take a look at this type signature. Can you figure out what it means?

 > fst (5, 'x')
Did that do what you expected?

 > let x = 5 in x + 1
This is how you define local variables. (The interpretter unfortunately 
doesn't let you define things and then use them later. Everything has to 
go into a single giant let-expression.)

 > let x = 5; y = 8 in x + y
This is how you define multiple variables.

 > iterate (*2) 1
This starts with 1, and applies the "times two" function to it over and 
over again, creating an infinite list of results. (Again, the 
interpretter doesn't display the whole thing.)

 > let factorial n = product [1..n] in factorial 6
This is how you define a new function. (Normally it wouldn't be a local 
variable, but the interpretter unfortunately doesn't allow top-level 
definitions.)

 > :t (+1)
This is a function that adds one to a number.

 > :t (*2)
This is a function that multiplies a number by two.

 > :t (+1) . (*2)
The "." operator takes two functions and combines them together. Here 
we've made a function that takes a number, multiplies it by two and then 
adds one. (Note carefully the order - RIGHT TO LEFT!)

 > map ((+1) . (*2)) [1..10]
Apply this function to a list of numbers.

 > :t div
This is a 2-argument function that does integer division.

 > :t div 10
This is not a syntax error. It's a 1-argument function. WTF?

 > :t div 10 5
This is a calculation that produces a number.

 > div 10 5
This divides 10 by 5.

 > map (div 10) [1..10]
See if you can work out what's going on.



OK, I'm going to stop now...

Post a reply to this message

Invisible wrote:
> Of course, as far as I can tell, I need a real web server to even 
> experiment with this stuff, so...

You have a real web server.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

scott wrote:
> Can the script intercept this and provide its own "back" functionality?

GIYFT!

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

>> Of course, as far as I can tell, I need a real web server to even 
>> experiment with this stuff, so...
> 
> You have a real web server.

I do, but it can only serve static HTML. (Plus it's quite a lot of work 
continually logging into the web interface to re-upload your files every 
time you edit 1 line of code.)

I think to try this out properly I'd have to set up a local Apache VM or 
something. (This requires me figuring out how the hell to set up 
Apache.) Alternatively, I could just write a trivial Haskell webserver 
that will log what requests the browser is sending in response to by code...

Post a reply to this message

> Hmm, maybe I should write my own?

It's very useful for an absolute beginner, these are the things you need to 
know that a lot of tutorials assume you somehow magically know already.

> > :t fst
> Take a look at this type signature. Can you figure out what it means?
>
> > fst (5, 'x')
> Did that do what you expected?

Well it seems to return the first item from a tuple.

Is it just a shorthand for "take 1"?

Ah no, it seems those list operators don't work with tuples :-(

> > let x = 5 in x + 1
> This is how you define local variables. (The interpretter unfortunately 
> doesn't let you define things and then use them later. Everything has to 
> go into a single giant let-expression.)

So this means "let x = 5 in (the following expression)..."

Now Step 7 in the original tutorial makes sense :-)

> OK, I'm going to stop now...

OK I need to download the compiler if I am to actually learn any of this...

Post a reply to this message

Invisible wrote:
> I do, but it can only serve static HTML. 

Uh, no. Every major OS comes with a real web server.

Now, if what you mean is "I don't have my own computer", then that's a 
different question.

> (Plus it's quite a lot of work 
> continually logging into the web interface to re-upload your files every 
> time you edit 1 line of code.)

Unless you're using an IDE, yes. ;-)

> I think to try this out properly I'd have to set up a local Apache VM or 
> something. (This requires me figuring out how the hell to set up 
> Apache.) 

Depoending on your OS and distribution, this can be pretty trivial.

But if you're actually going to get into AJAX programming, you're going to 
have to learn more than you can by asking people here to explain it to you. ;-)

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

scott wrote:
>> Hmm, maybe I should write my own?
> 
> It's very useful for an absolute beginner, these are the things you need 
> to know that a lot of tutorials assume you somehow magically know already.

The hard thing about writing a tutorial is that by the time you're 
experienced enough to be an authority on the language, half the stuff 
that trips newbies up is so utterly "obvious" to you that you forget to 
even mention it. (Plus you're all excited and you want to jabber 
incoherently about the cool stuff, not the dry old "this is how you 
escape a newline character".)

>> > :t fst
>> Take a look at this type signature. Can you figure out what it means?
>>
>> > fst (5, 'x')
>> Did that do what you expected?
> 
> Well it seems to return the first item from a tuple.
> 
> Is it just a shorthand for "take 1"?
> 
> Ah no, it seems those list operators don't work with tuples :-(

It's all in the type signature.

[Int] means a list of integers. It can contain any possible number of 
integers (including zero or infinity). [Char] means a list of characters.

Tuples, on the other hand, have a different type for each size, and each 
combination of element types. For example, (5, 'x') is of type (Int, 
Char), but (5, 'x', False) is of type (Int, Char, Bool). As far as the 
type system is concerned, these two types are completely unrelated.

Because of this, you cannot write a function that works on any possible 
size of tuple. It's impossible. (You can write a *method* that works for 
any size of tuple that you've manually written a definition for, but 
that's about it.)

In truth, if you're using tuples bigger than about three or four 
elements, you really ought to define a custom type for this stuff 
instead of relying on tuples. Tuples are really for simple, quick things 
like returning multiple results from a function, or for key/value pairs. 
Stuff like that.

...and this whole explanation is a good example of the kind of thing 
that's hard to explain in an interactive tutorial. ;-)

> So this means "let x = 5 in (the following expression)..."

Indeed yes.

> Now Step 7 in the original tutorial makes sense :-)

Yeah. It's simple, it's just explained badly...

>> OK, I'm going to stop now...
> 
> OK I need to download the compiler if I am to actually learn any of this...

I can talk some more if you want?

But yes, this (alpha) web thingy lacks several important features:

- You can't define things and refer to them later. Each expression is 
processed independently.

- You can't write multi-line definitions.

- You can't do I/O. (And the error message if you try is cryptic to say 
the least!)

- You can't use all of the standard Haskell libraries, just the handful 
the interpretter offers.

In a real Haskell interpretter, you can usually do stuff like

 > let factorial n = product [1..n]
 > let choose n k = (factorial n) / (factorial k * factorial (n - k))
 > choose 3 5

In the online interpretter, you'd have to do

 > let factorial n = product [1..n]; choose n k = (factorial n) / 
(factorial k * factorial (n - k)) in choose 3 5

This, coupled with the horrifyingly buggy command history, is just no 
fun at all.

Are you actually interested enough to want to play with it more?

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> I do, but it can only serve static HTML. 
> 
> Uh, no. Every major OS comes with a real web server.

Really?

> But if you're actually going to get into AJAX programming, you're going 
> to have to learn more than you can by asking people here to explain it 
> to you. ;-)

No, I'd just like to see if I can do a small proof-of-concept thing and 
make it work. ;-) Let's face it, DOM is way too hard in the first place...

Post a reply to this message

Invisible wrote:
> No, I'd just like to see if I can do a small proof-of-concept thing and 
> make it work. ;-) Let's face it, DOM is way too hard in the first place...

Then take static files and request them via xmlhttprequest. That's how I do it.

Make up files text1.txt text2.txt text3.txt and so on, then write a loop in 
javascript to sleep a few seconds, xmlhttprequest the next file in the list, 
and when it shows up take the data and populate a DOM element with it. It works.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

Invisible wrote:
> But yes, this (alpha) web thingy lacks several important features:
> 
> - You can't define things and refer to them later. Each expression is
> processed independently.
> 
> - You can't write multi-line definitions.
> 
> - You can't do I/O. (And the error message if you try is cryptic to say
> the least!)
> 
> - You can't use all of the standard Haskell libraries, just the handful
> the interpretter offers.

They seriously should steal features from http://tryruby.org/

- You can define variables and refer to them later. Example, type a=1, press 
Enter, then type a+a.

- You can write multi-line definitions. Try this one:

5.times {
    print "Hello"
}

When it parses the first line, it will notice the statement is incomplete 
and let you continue it.

- You can do I/O (fake filesystem). The whole chapter 4 of the tutorial is 
about I/O and file handling.

- You can do HTML and see the results via a custom library made for the 
tutorial. Try:

require "popup"
Popup.make {
   h1 "Hello world"
   p "foo"
}

Post a reply to this message

Nicolas Alvarez wrote:

> They seriously should steal features from http://tryruby.org/

Well, the page even *mentions* Try Ruby.

I guess the guy just hasn't written the code yet... A few days ago, ":t" 
didn't work. And now it does. (Annoyingly, GHCi uses ":t" as an 
abbreviation for ":type", but the website doesn't accept ":type", only 
":t".)

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

Post a reply to this message

> The hard thing about writing a tutorial is that by the time you're 
> experienced enough to be an authority on the language, half the stuff that 
> trips newbies up is so utterly "obvious" to you that you forget to even 
> mention it.

Exactly.

> In truth, if you're using tuples bigger than about three or four elements, 
> you really ought to define a custom type for this stuff instead of relying 
> on tuples.

OK.  I take it a custom type is a bit like a struct in C-type languages, in 
that it can hold any number of different types?

> I can talk some more if you want?

Once you know a few basic things I think it's best to move on to simple 
examples (small multi-line samples, not those artificial ones needed for the 
web).

> > let factorial n = product [1..n]
> > let choose n k = (factorial n) / (factorial k * factorial (n - k))
> > choose 3 5

Exactly.  Even I can work out from that one how functions are defined now 
:-)

BTW what would happen if I typed "choose 3 (-5)" instead?

I'm just trying to think of a subject for a good example ... how about a 
card game?  Firstly how would you represent the cards (tuple or custom type 
for the suit/value?).  Then I assume you would just create a list of "Cards" 
to represent a group of cards that someone was holding (say 5 cards).  How 
would you then check to see if any two cards in that list were the same 
value, or all the same suit, etc?

> Are you actually interested enough to want to play with it more?

I was interested enough in J to learn how to use it to write a mandelbrot in 
1-line :-)  Haskell should be a doddle - at least you stand to pick up bits 
and pieces based on English, rather than just almost random single 
characters for everything!

Post a reply to this message

>> The hard thing about writing a tutorial is that by the time you're 
>> experienced enough to be an authority on the language, half the stuff 
>> that trips newbies up is so utterly "obvious" to you that you forget 
>> to even mention it.
> 
> Exactly.

This is one of the hardest things about technical writing - and one of 
the things I most often see done wrong. Search around the Internet a 
bit, and you'll find Haskellers writing things like "a monad is just a 
monoid in the category of endofunctors - what's the problem?" like 
normal human beings have any clue WTF that means. (I have *some* clue, 
but the category theory definition of a monad doesn't even begin to 
explain why it's useful in computer programming.)

>> In truth, if you're using tuples bigger than about three or four 
>> elements, you really ought to define a custom type for this stuff 
>> instead of relying on tuples.
> 
> OK.  I take it a custom type is a bit like a struct in C-type languages, 
> in that it can hold any number of different types?

It can be. The neat thing about Haskell is that it has "algebraic data 
types". These can be like a struct or a record or whatever you want to 
call it. Or they can be like an enumeration. OR THEY CAN BE BOTH!

(I guess this is what C would call a "union". But it's type-safe. You 
cannot accidentally access a field that does not exist. Or use the wrong 
field type.)

>> I can talk some more if you want?
> 
> Once you know a few basic things I think it's best to move on to simple 
> examples (small multi-line samples, not those artificial ones needed for 
> the web).

Some things are easiest to explain by example. Like, some concepts are 
so extremely abstract that without an example, it's difficult to 
comprehend what's going on. Other things are quite tricky to demonstrate 
with examples; you end up needing to use examples which are either 
extremely complex, or very contrived. In depends what you're trying to 
demonstrate.

I think for general familiarity with a programming language, lots of 
small examples is probably the way forward.

>> > let factorial n = product [1..n]
>> > let choose n k = (factorial n) / (factorial k * factorial (n - k))
>> > choose 3 5
> 
> Exactly.  Even I can work out from that one how functions are defined 
> now :-)

Well, yeah, there is that too. ;-)

> BTW what would happen if I typed "choose 3 (-5)" instead?

Well, it would execute

   (factorial 3) / (factorial (-5) * factorial (3 + 5))

Given the above definition of factorial,

   factorial (-5) = product [1..-5] = product [] = 1

Which I'm guessing means that choose gives the wrong answer.

(I also just realised that that should probably be integer division, 
since choose is only supposed to work with integer inputs and yield 
integer outputs...)

> I'm just trying to think of a subject for a good example ... how about a 
> card game?  Firstly how would you represent the cards (tuple or custom 
> type for the suit/value?).

At the most basic level, you can always use tuples and code numbers. But 
why do that, when the language has extensive support for a better way?

The idiomatic way would probably be to do something like

   data Suit = Diamonds | Hearts | Clubs | Spades

   data Number =
     Ace | Two | Three | Four | Five | Six | Seven | Eight | Nine | Ten |
     Jack | Queen | King

   data Card = Card Suit Number

So Suit and Number are enumerations, and Card is a record with two 
fields. The record syntax is probably the most perplexing part. I'm 
using positional fields - which is common when there are very few fields 
- but you can also use named fields:

   data Card = Card {suit :: Suit, numer :: Numer}

I should probably have thrown it into the tutorial, but "thing :: type" 
is how you write explicit type signatures in Haskell. And you can do

 > 5 :: Int
 > 5 :: Double
 > 5 :: Rational
 > 5 :: Word64
 > 5 :: Complex Float

Unlike Java, "5" can represent any possible numeric type. Usually 
Haskell deduces which type you want automatically (or makes it 
polymorphic). The web interpretter seems to default to 
arbitrary-precision integers - which is reasonable.

(Similarly, "5.3" is any fractional type - Float, Double, Rational, etc.)

> Then I assume you would just create a list 
> of "Cards" to represent a group of cards that someone was holding (say 5 
> cards).

Sure, that'll work. Other representations are possible.

> How would you then check to see if any two cards in that list 
> were the same value, or all the same suit, etc?

By default, you can't compare values. That's because it's possible to 
define how to do comparison. (E.g., your data structure might have 
several equivilent representations for the same thing, and you want 
these different representations to be considered "the same".) However, 
in the common case that you just want to do a vanilla structural 
comparison, you just add "deriving Eq" to the end of the type definition.

Once you do that, you can write things like Hearts == Clubs (which is 
obviously going to give you "false"). (By a similar arrangement, you can 
auto-define comparison as well. The compiler uses the order you listed 
the values in. Might be useful for deciding which card is "higher".)

Now, if you've used named fields, then "suit" and "number" are not only 
field names, but also implicitly-defined functions that take a Card and 
return the appropriate field. So "suit card1" tells you the suit of 
whatever is in card1.

Are all the cards the same suit?
   length (group (map suit cards)) == 1
(This could be inefficient if "cards" is huge, but for a hand of 5 or 7 
cards, it should be fine.)

First, you extract a list of suits. Then you group this list into a list 
of sublists, such that each sublist contains only identical suits. If 
*all* the suits are the same, clearly you will have exactly 1 sublist.

(Equally clearly, if you have 1000 cards, alternating between Clubs and 
Spades, you will get a list with 1000 1-element sublists, which length 
will have to completely traverse before giving you an answer.)

You can use pattern matching to solve the inefficiency, but due to the 
limitations of the web interpretter, it's bloody awkward to demonstrate 
pattern matching. So I haven't shown that to you yet.

>> Are you actually interested enough to want to play with it more?
> 
> I was interested enough in J to learn how to use it to write a 
> mandelbrot in 1-line :-)  Haskell should be a doddle - at least you 
> stand to pick up bits and pieces based on English, rather than just 
> almost random single characters for everything!

LOL! OK, well if you put it that way...

Although even Haskell has a few "interesting" symbol choices. ">>=" 
leaps to mind, but you might also mention "$", "&&&", ":" and so on.

Post a reply to this message

>> BTW what would happen if I typed "choose 3 (-5)" instead?
>
> Well, it would execute
>
>   (factorial 3) / (factorial (-5) * factorial (3 + 5))
>
> Given the above definition of factorial,
>
>   factorial (-5) = product [1..-5] = product [] = 1
>
> Which I'm guessing means that choose gives the wrong answer.

So what's the preferred way to cope with runtime "errors" like that? (I 
don't know if there is a technical term for such kind of errors that don't 
actually make an error, if you know what I mean).  I suspect in a lot of 
case some very low nested function detects an error, and needs to signify 
this to a much higher level calling function (eg a "ParseFile" or 
"ParseLine" function or something).

> So Suit and Number are enumerations, and Card is a record with two fields. 
> The record syntax is probably the most perplexing part. I'm using 
> positional fields - which is common when there are very few fields - but 
> you can also use named fields:
>
>   data Card = Card {suit :: Suit, numer :: Numer}

OK, so I could also do something like:

data myRecord = myRecord {age :: Int, height :: Double, weight :: Double}

> Are all the cards the same suit?
>   length (group (map suit cards)) == 1
> (This could be inefficient if "cards" is huge, but for a hand of 5 or 7 
> cards, it should be fine.)
>
> First, you extract a list of suits.

So in my example, if I had a list of myRecords, then "age MyList" would 
return a list of ages?

> Then you group this list into a list of sublists, such that each sublist 
> contains only identical suits.

What does the "map" do?  Clearly I need to download the proper 
interpretter/compiler to answer these questions myself with a bit of playing 
around :-)

OK so after Googling Haskell, implementations, GHC, go to the GHC page, 
latest release, "STOP!" they recommend I get the Haskell Platorm instead, oh 
goody a .exe installer link :-)  I'll let you know in 54 MB time how I get 
on...

> LOL! OK, well if you put it that way...

Thing is it's very rare that I find myself wanting to write something that 
*I* think would be easier/faster with a language like Haskell.  But as I 
don't really know much about the language, I'm not a very good judge.

You're also quite good a writing tutorials, you should definitely write a 
book.  Haskell for Imperative Programmers.  :-)

Post a reply to this message

>>> BTW what would happen if I typed "choose 3 (-5)" instead?
>>
>> Well, it would execute
>>
>>   (factorial 3) / (factorial (-5) * factorial (3 + 5))
>>
>> Given the above definition of factorial,
>>
>>   factorial (-5) = product [1..-5] = product [] = 1
>>
>> Which I'm guessing means that choose gives the wrong answer.
> 
> So what's the preferred way to cope with runtime "errors" like that? (I 
> don't know if there is a technical term for such kind of errors that 
> don't actually make an error, if you know what I mean).

The correct thing to do here would be

   choose n k
     | n < 0     = error "choose: negative n"
     | k < 0     = error "choose: negative k"
     | k > n     = 0 -- According to Wikipedia.
     | otherwise = (factorial n) `div` (factorial k * factorial (n - k))

(You would also define it to accept only unsigned integers as arguments, 
which neatly does away with most of the error checking.)

> I suspect in a 
> lot of case some very low nested function detects an error, and needs to 
> signify this to a much higher level calling function (eg a "ParseFile" 
> or "ParseLine" function or something).

The standard idiom in Haskell is this:

- If it's a program bug, use the "error" function. In particular, if a 
function is called with invalid arguments, this is probably a bug in the 
caller.

- If it's a routine, expected occurrance, return a data structure which 
indicates success or failure. For example, a parse failure is totally to 
be expected, so we need to explicitly handle it. The error is returned 
"as data". (This is where the "error monad" comes in...)

The "error" function, technically speaking, throws an exception. Other 
actions (generally only I/O operations) may also throw exceptions, and 
Haskell has the usual exception-catching machinery. (Although things 
like "catch" are library functions, not language constructs.)

> OK, so I could also do something like:
> 
> data myRecord = myRecord {age :: Int, height :: Double, weight :: Double}

Yes, that'll work.

(Actually, I'm lying. The type name MUST begin with a capital letter. 
This IS enforced by the compiler.)

The catch: Each field name is also a function name. Therefore, no two 
types can have fields with the same name. (At least, not in the same 
scope. Obviously types defined in different files can.) This restriction 
becomes quite tedious at times.

>> Are all the cards the same suit?
>>   length (group (map suit cards)) == 1
>> (This could be inefficient if "cards" is huge, but for a hand of 5 or 
>> 7 cards, it should be fine.)
>>
>> First, you extract a list of suits.
> 
> So in my example, if I had a list of myRecords, then "age MyList" would 
> return a list of ages?

No. "map age mylist" would though. You need "map" to apply "age" to 
every element of the list.

(And variable names MUST begin with a lowercase letter. The compiler 
will complain if they don't.)

> What does the "map" do?

See above. ;-)

> OK so after Googling Haskell, implementations, GHC, go to the GHC page, 
> latest release, "STOP!" they recommend I get the Haskell Platorm 
> instead, oh goody a .exe installer link :-)  I'll let you know in 54 MB 
> time how I get on...

Yes, it's... a tad large. It *does* contain a complete copy of GCC, gas, 
ld, perl.exe (?!) and a big suite of precompiled libraries, with HTML 
documentation, a profiler, a debugger...

Background: Installing GHC used to give you a complete environment. But 
the GHC guys don't want to maintain a complete environment, they want to 
maintain GHC. So now the Haskell Platform exists, and the HP guys work 
on HP, so the GHC guys can focus on just GHC. The idea is that HP will 
grow to provide more stuff. Currently there's not actually much 
difference. Follow all that?

Oh, and yes, GHC has *always* been big. You just want to play with 
Haskell, but what you're downloading has all sorts of bells and whistles 
that you won't use. There's a powerful parser library, cutting-edge 
parallel processing technology, a complete OpenGL binding, POSIX 
bindings, cross-platform filename processing... need I continue?

> Thing is it's very rare that I find myself wanting to write something 
> that *I* think would be easier/faster with a language like Haskell.

Well, yes, it completely depends on the kind of code you want to write. 
If you want to write, say, a computer game, Haskell probably isn't the 
best choice. In C or C++, you can probably just download a game engine 
and start coding. In Haskell... there's an OpenGL binding? I guess that 
helps? But it's going to take a loooong time to get to a full-featured 
game from there!

Personally, I tend to write crazy algorithm stuff. Haskell is great for 
that, even if performance is a little unpredictable.

> But 
> as I don't really know much about the language, I'm not a very good judge.

Well, yeah. That's kind of what's exciting about the web interpretter, 
unfinished as it is. Now anybody can play with Haskell and do basic 
stuff without... waiting for a 60+ MB download. ;-)

> You're also quite good a writing tutorials, you should definitely write 
> a book.  Haskell for Imperative Programmers.  :-)

Heh. I've attempted to write *several* Haskell introductions. Roughly 
once every 2 months I start writing a new one. They never get finished.

Trouble is, lots of Haskell's features depend on Haskell's other 
features, so... where do you start? Which thing do you explain first? I 
write an example, and then I go "oh crap, that uses X, I haven't even 
mentioned that yet. Bugger!"

It's not complicated, it's just difficult to decide where to begin.

But thanks for your encouragement. Go take a look at the other thing I 
just posted. ;-)

Post a reply to this message

Invisible wrote:

> Of course, it's still alpha quality.

Strike a light... It seems the bit "alpha" sticker has gone. And the 
command history seems to work properly now. Neat...

Post a reply to this message

Invisible wrote:

> Yes, it's... a tad large. It *does* contain a complete copy of GCC, gas, 
> ld, perl.exe (?!) and a big suite of precompiled libraries, with HTML 
> documentation, a profiler, a debugger...

I guess it's a bit like downloading and installing VisualStudio just so 
you can write a Hello World program in C++... It'll do it, but it's kind 
of overkill. ;-)

Post a reply to this message

>   data Suit = Diamonds | Hearts | Clubs | Spades
> 
>   data Number =
>     Ace | Two | Three | Four | Five | Six | Seven | Eight | Nine | Ten |
>     Jack | Queen | King
> 
>   data Card = Card Suit Number

I get "parse error on input 'data'" for all those.

Guess I'm missing some #include or whatever it's called.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Invisible wrote:

> > Of course, it's still alpha quality.

> Strike a light... It seems the bit "alpha" sticker has gone. And the 
> command history seems to work properly now. Neat...

  Now it's only v0.01 beta?-)

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
>>   data Suit = Diamonds | Hearts | Clubs | Spades
>>
>>   data Number =
>>     Ace | Two | Three | Four | Five | Six | Seven | Eight | Nine | Ten |
>>     Jack | Queen | King
>>
>>   data Card = Card Suit Number
> 
> I get "parse error on input 'data'" for all those.
> 
> Guess I'm missing some #include or whatever it's called.

Which way are you trying to execute this?

If you're trying to enter them interactively, don't. It doesn't work. ;-)

The GHC interactive interpretter ("GHCi") allows you to define variables 
and use them later, but doesn't allow any other kinds of definitions 
interactively.

If you write this stuff in a file and save it as, say, "Cards.hs", you 
should be able to double-click that file and have GHCi automatically 
open up and load it. You can then write expressions involving these types.

(Probably the next problem you'll trip over is that the types aren't 
printable...)

Post a reply to this message

>> Strike a light... It seems the bit "alpha" sticker has gone. And the 
>> command history seems to work properly now. Neat...
> 
>   Now it's only v0.01 beta?-)

But that's the wonderful thing about OSS, isn't it? It never actually 
reaches release 1.0. :-D

Post a reply to this message

> But that's the wonderful thing about OSS, isn't it? It never actually 
> reaches release 1.0. :-D

Just like a progress bar in Windows:

ProgressBar1.Value = 1 - exp(time)

Post a reply to this message

Invisible wrote:
> Strike a light... It seems the bit "alpha" sticker has gone. 

Technically, if it was available for download, it's already beta. But I 
guess that nomenclature already went out the window a few years ago.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

scott wrote:
>> But that's the wonderful thing about OSS, isn't it? It never actually 
>> reaches release 1.0. :-D
> 
> Just like a progress bar in Windows:
> 
> ProgressBar1.Value = 1 - exp(time)

Hey, at least OSS version numbers don't (usually) go backwards. :-P

Post a reply to this message

>> ProgressBar1.Value = 1 - exp(time)
> 
> Hey, at least OSS version numbers don't (usually) go backwards. :-P

Jsut checking you were awake :-)

Of course that should be 1-exp(-time)

Post a reply to this message

scott wrote:
>>> ProgressBar1.Value = 1 - exp(time)
>>
>> Hey, at least OSS version numbers don't (usually) go backwards. :-P
> 
> Jsut checking you were awake :-)
> 
> Of course that should be 1-exp(-time)

LOL! I didn't even notice that...

But Windows progress bars do, in fact, go both forwards and backwards, 
seemingly at random. ;-)

Post a reply to this message

> But Windows progress bars do, in fact, go both forwards and backwards, 
> seemingly at random. ;-)

The best is when it gets to 99 or 100% and then *starts again* at 0% !

Post a reply to this message

scott wrote:
>> But Windows progress bars do, in fact, go both forwards and backwards, 
>> seemingly at random. ;-)
> 
> The best is when it gets to 99 or 100% and then *starts again* at 0% !

Or when it goes from 0% to 100% in about 0.1 seconds, and then sits at 
100% for 25 minutes... Yeah, that's real useful, guys.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > But Windows progress bars do, in fact, go both forwards and backwards, 
> > seemingly at random. ;-)

> The best is when it gets to 99 or 100% and then *starts again* at 0% !

  There actually are some programmers out there (even pros) who have actually
not understood the idea of the progress bar. They seem to think it's something
akin go the spinning wheel which is often used when the total time is unknown
(ie. the spinning wheel simply indicates that something is being done, but
the program has no way of knowing how much will be done).

  Other programmers (sadly a lot of them) understand the purpose of the
progress bar, but they don't understand how it should be used so that it's
actually informative to the user. The most typical error is that if the
task done by the program consists of dozens of sub-tasks (such as eg.
installing a dozen of files), the progress bar is used to indicate the
progress of each individual subtask instead of using it to indicate the
overall progress. Thus the progress bar becomes useless (and more akin to
the spinning wheel).

  More competent programmers (or program designers) will put *two* progress
bars in the UI: One to indicate the progress of the sub-task and the other
to indicate overall progress. That's a whole lot more informative (although
the sub-task progress bar is not so useful if each sub-task is very fast to
perform, but more useful if they are slowish operations).

  Of course even then there's room for incompetence: For example, a progress
bar that updates too rarely and makes big jumps, or which pauses for too
long at the beginning or the end (nothing is more confusing than having
the overall progress bar at 100%, but the program still doing things for
several tens of seconds). Of course depending on the task in hand it may
be quite difficult programmatically to update the progress bar smoothly,
but still...

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   There actually are some programmers out there (even pros) who have actually
> not understood the idea of the progress bar. They seem to think it's something
> akin go the spinning wheel which is often used when the total time is unknown

Yes, some programs just have some kind of wheel that lets you know that 
it's doing *something*, even if it can't estimate how long it will take. 
Which is fine - the problem comes when they make it look like it's a 
"progress" indication, when in fact it isn't.

> The most typical error is that if the
> task done by the program consists of dozens of sub-tasks 
> the progress bar is used to indicate the
> progress of each individual subtask instead of using it to indicate the
> overall progress. Thus the progress bar becomes useless.

Indeed.

>   More competent programmers (or program designers) will put *two* progress
> bars in the UI: One to indicate the progress of the sub-task and the other
> to indicate overall progress. That's a whole lot more informative.

Yes. Although it still sometimes has the problem that some subtasks are 
extremely fast, while others are insanely slow. Still, it does at least 
provide a monotonically-increasing bar which fills up when the task is 
done. It's just harder to estimate time remaining.

(Don't even get me started on "estimated time remaining"...)

>   Of course even then there's room for incompetence: For example, a progress
> bar that updates too rarely and makes big jumps, or which pauses for too
> long at the beginning or the end.

Yeah, I hate that!

> Of course depending on the task in hand it may
> be quite difficult programmatically to update the progress bar smoothly,
> but still...

If you can't estimate progress in a meaningful way, don't pretend that 
you can. ;-)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> If you can't estimate progress in a meaningful way, don't pretend that 
> you can. ;-)

  I actually had that problem with a puzzle solver I had to make for our
first iPhone game. (There's a glimpse of it here:
http://gamesandinnovation.com/2010/02/10/hopido-design-post-mortem/ )

  The problem was that when the puzzle was large enough, the progress
would often advance like
0% -> 0.000001% -> 0.000002% -> ... -> 0.000158% -> 2.026041% -> 2.026042%
-> 5.0% -> 80.0% -> 100%, or similar. Just putting the percentage on
screen was not informative at all, no matter what I tried. (Often the
percentage would look like the program had halted completely because it
changed only so little that it would have required like 8 decimals to
show the change.)

  What I ended up doing instead was to show the current search path as
lines of changing colors over the puzzle, updating a few times per second.
Doesn't tell you much about the progress, but shows clearly that the
program is doing something.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> If you can't estimate progress in a meaningful way, don't pretend that 
>> you can. ;-)
> 
>   What I ended up doing instead was to show the current search path as
> lines of changing colors over the puzzle, updating a few times per second.
> Doesn't tell you much about the progress, but shows clearly that the
> program is doing something.

Right. And IMHO, that would be a correct solution. It makes it clear 
that something is happening, without giving the user inaccurate progress 
indications.

Post a reply to this message

Warp wrote:
> (ie. the spinning wheel simply indicates that something is being done, but
> the program has no way of knowing how much will be done).

Not in Windows!  :-)   Try turning of the remote computer while you're 
copying files to it with Explorer.  Do you think those fluttering pages stop 
flying from one folder to the other? NooooOOOoooo...

> the overall progress bar at 100%, but the program still doing things for
> several tens of seconds). 

I will say I've seen this happen when the flush() call at the end actually 
takes 30 to 90 seconds.  Once you figure out what's going on, it's not that 
bad, tho.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

scott wrote:

> Clearly I need to download the proper 
> interpretter/compiler to answer these questions myself with a bit of 
> playing around :-)
> 
> OK so after Googling Haskell, implementations, GHC, go to the GHC page, 
> latest release, "STOP!" they recommend I get the Haskell Platorm 
> instead, oh goody a .exe installer link :-)  I'll let you know in 54 MB 
> time how I get on...

...so how did you get on?

Post a reply to this message

> ...so how did you get on?

Other things came up ... I'm easily distracted...

Specifically, I wrote a simple graphical n-body gravity simulator (I *love* 
C# and XNA) to explain a couple of things to my girlfriend, I've been 
working on the GUI for my program to download and display tracks from my GPS 
unit, and the Formula 1 season started :-)

Post a reply to this message

scott wrote:
>> ...so how did you get on?
> 
> Other things came up ... I'm easily distracted...

Heh, figures. ;-)

> Specifically, I wrote a simple graphical n-body gravity simulator (I 
> *love* C# and XNA) to explain a couple of things to my girlfriend,

That's *advanced*, right there! o_O

I'm pretty sure if I tried to explain the rules of gravitation to a 
girl, I wouldn't _have_ a girlfriend for very long...

(So much for "the gravity of love", eh?)

> I've 
> been working on the GUI for my program to download and display tracks 
> from my GPS unit, and the Formula 1 season started :-)

Oh. Another F1 fan...

Heh, oh well. I was expecting the reply to be "I can't think of anything 
that Haskell would be useful for". ;-)

Post a reply to this message