Orchid XP v8 wrote:
> [Checking the language standard document, it's actually defined as two 
> lines, because it gives a type signature as well.]

So is mine.  The others had nothing to do with compose.

>> Oh, *I* know.
> 
> Right. Sure. Because you're super-human. :-P

No, I just know what I'm doing and consider type errors too primary and 
trivial next to logic errors.

> In Haskell, you can't *have* runtime type mismatches. :-P

True.  Sorry.  It's a type system error message from verifying a type 
mismatch is happening.  It is helpful.

Of course, it's also a pain in the butt when it gets in the way:

Prelude> let statusLine fruits = if fruits>1 then fruits else "No more 
fruits"
<interactive>:1:34:
     No instance for (Num [Char])
       arising from the literal `1' at <interactive>:1:34
     Possible fix: add an instance declaration for (Num [Char])
     In the second argument of `(>)', namely `1'
     In the predicate expression: fruits > 1
     In the expression: if fruits > 1 then fruits else "No more fruits"

I used a quick hack to try to get around it:
Prelude> let self x = x
Prelude> let statusLine fruits = if fruits>1 then self statusLine fruits 
else "No more fruits"

So far, so good.  The compiler didn't do its job. ;)

But, then:
Prelude> print statusLine 3

<interactive>:1:0:
     Couldn't match expected type `t1 -> t'
            against inferred type `IO ()'
     In the expression: print statusLine 3
     In the definition of `it': it = print statusLine 3

I tried to group it with parenthesis then:
Prelude> print (statusLine 3)
"

Weird!  It output that single double quote and froze.  I had to 
interrupt it.

Lesson here:  sometimes the compiler not only gets in your way but also 
doesn't do its job as supposed.


Oh, and BTW:

Prelude> filter odd [1,2,3,4,5]
[1,3,5]

weird, huh? :P

>> In Scheme/Python/Ruby, the interpreter just don't care and it's all up 
>> to you.
> 
> Exactly. If you make a mistake, it's your fault, and the interpreter 
> gives you no help at all to fix it.

It gives you a nice call stack trace. :)

Seriously though, Common Lisp is king in this respect.  Some of its most 
well-known implementations' runtime systems allow for a quick debug of 
what's going on in an app, correcting, compiling and even patching it 
while the system is still running.  Yes, no need for reboots.

> Does that mean that automated systems for catching problems are a waste 
> of time? Again, no.

Not at all.

> For writing small, simple things on the fly, something vague and 
> unstructured is probably the best way to go. (This is why scripting 
> languages exist.)

Exactly.  Dynamic languages fit the bill whenever specifications are 
vague and prone to much change.  Like, every real world system I've 
worked with, except they were in horribly asinine straightjacket 
languages that penalized changes.

> Personally, I don't tend to write that kind of code.

But it was the kind of which the OP was asking about.

Post a reply to this message