>> If you want a point, you say Point 3 7. Which, as you say, rather gives
>> away the fact that it's a Point value. But how about saying "True"?
>> That's of type Bool, but you didn't write that in your expression.
>> Similarly, when you write
>>
>>     Branch (Leaf 3) (Leaf 7)
>>
>> you didn't say anywhere that this is of type Tree Int, did you? The
>> compiler infers this automatically.
>
> it infers from unique names relating to a type like those sprinkled everywhere
> in the code.  Think about it... :)

For monomorphic expressions, sure. You do tend to end up sprinkling 
these things around. But that's really no different to (say) Java having 
"new Foo()", "new Bar()" etc sprinkled everywhere. [Except that you 
don't have to uselessly duplicate it in the variable declarations as well!]

The polymorphic code, the stuff that works for any type, is mostly 
devoid of this kind of stuff.

>> Not so in Haskell. If you want to add two numbers, you use (+). It's
>> polymorphic like that.
>
> yes, + in Lisp is polymorphic over numbers, be it float or integer.  fl+ or fx+
> are performance-geared optimizations.

Now, see, in Haskell you'd just write a type signature that fixes the 
expression to one specific type, and the compiler does the rest. 
Typically you only need to fix it in one place too.

> I still think simple declaration of a variable as of a given type would be
> better than sprinkling code with operators/names that force expressions into a
> given type.

And I still think it requires a lot less "sprinkling" than you seem to 
think.

>> All I know is that every time I've used a dynamically-typed language,
>> I've spent 90% of my time fixing type errors - errors which *could* have
>> and *should* have been caught automatically by the machine, but I have
>> ended up catching them myself, by hand. Yuck!
>
> only you could do that in a language "without types" :p

Oh, it *has* types, it's just that it only checks them when it's about 
to use them. Which means that a tiny number of programs are accepted 
that might otherwise be rejected, and a vast number of programs are 
accepted that crash as soon as you run them - or worse...

> I don't have a trouble providing arguments of the right types to functions, but
> I must confess I've been flamed already by typos in the code only detected at
> runtime. :p
>
> Thankfully, the real nice thing about development with a REPL is that you can do
> fine-grained iterative development:  write little expressions, test them, put
> them into a function, repeat.   You write and test at the same time.

And this is significantly easier with pure code. :-P

> Shame that
> haskell's REPL is very limited and doesn't allow for full type definitions and
> such.

Now that _is_ a shame. It seems such a pointless and arbitrary 
limitation, IMHO.

>> More like "without automatic bracket match, it's impossible to produce
>> code which is even syntactically correct". It wouldn't be so bad, but it
>> seems all Lisp programmers habitually indent their code incorrectly.
>
> Lisp
> experts have long developed a code style that makes brackets virtually invisible
> by hiding them to the rightmost end.

...which is worrying, given that the brackets are fundamental to the 
language syntax, and moving them around slightly radically transforms 
the entire meaning of an expression.

>> I can see how having a language where everything is a list is
>> technically quite a nice idea. It's simple and elegant. Unfortunately,
>> the language as a whole seems to be messy and inconsistent. Too much
>> backwards compatibility, too much muddled thinking. Still, I guess it
>> was the first attempt...
>
> There is quite a lot of backwards compatibility in CL, that's for sure:

I dislike backwards compatibility. Even Haskell has too much of that.

> I'm specially annoyed at the car/cdr family of operators so dear to old Lispers.

Yes, that's specifically the single most annoying part I came across. I 
imagine entire flamewars have been fought over that one...

>> Sure, functions are first-class. But it lacks purity.
>
> like I said, aside from Haskell, no other language goes that far to ensure a
> pure, side-effect-free mystical environment.

IMHO, this is why Haskell is superior to every other language.

>> It also doesn't
>> appear to place any emphasis at all on coding in a vaguely functional
>> style - not in the language design nor the standard libraries.
>
> if you're talking about Common Lisp you're right:  it's a very imperative
> version of Lisp.  Scheme was in part developed in the 70's as a functional
> rework of the original Lisp principles.

No wonder they hate each other! ;-)

>> And Clean doesn't count because...?
>
> because it is even more obscure than haskell itself?

Funny, people seem to have heard of Clean. And OCaml. And Erlang. And 
Lisp. And even Prolog. And yet, nobody seems to have ever heard of 
Haskell...

>> To me, "new syntax" means that I can write something that doesn't look
>> like the host language. From what little I've seen, a Lisp DSL just
>> looks like Lisp.
>
> true.  We actually consider that a benefit. ;)

What, that you can define a new syntax which is identical to the 
existing one? Why bother?

>> And a Haskell expression consists of some combination of exactly 6 (go
>> count them) structures.
>
> nobody codes haskell without such sugar.

And? I'm talking about the ease with which you can programmatically 
construct expressions using Template Haskell. The fact that the entire 
language is 6 constructs makes that real easy.

> that's for sure is a gain of all functional programming languages:  creating
> larger things from the composition of a few core functions.

Amen.

>>> (iterate (pf * 2) 0)
>>
>> Yes, that's just as succinct as (*2). Oh, wait...
>
> it is as succint as you can get without having to alter the parser to allow for
> special syntax and corner cases here and there.  Simpler design. :)

...and if you language already supports it, you don't need to alter the 
parser. ;-)

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

Post a reply to this message