Re: [Nomen-dev] Nomen status

[Denis <ji...@re...>]

Hi Brian

On Tuesday, November 5, 2002, at 04:32  pm, Brian Hurt wrote:

> On Tue, 5 Nov 2002, Denis wrote:
>
>> Hi Brian,
>>
>> Nice to hear from you again.
>>
>> I learnt CAML during my studies. Personally, that's not my cup of tea.
>> While type inference and program proofs are very useful, I just can't
>> enjoy writing functional programs.
>
> This is interesting.  What is it that you dislike about Caml?  (Ocaml is
> basically Caml light plus OO- if you don't like Caml, you won't like
> Ocaml).

What I don't like --at all-- is that everything is a branch of a tree 
that has tons of ramifications.
Let's take your example:

    let rev_list lst =
        let rec rev_list_int lst accum =
            match lst with
                [] -> accum
                | head :: tail -> rev_list_int tail (head :: accum)
        in
        rev_list_int lst []
    ;;

So here the root is on the first line (let rev_list lst =) --it is even 
probably the '=' sign, but I won't go into details.
Then you add a branch to declare 'rev_list_int', with its definition. 
Then you finish with the "in" (left branch), which defines the body of 
the function 'rev_list'.

While this structure helps  when doing proofs, IMO it's a pain in the 
a*s when you are programming. Some people like it, I don't. I like 
linear, block-based code.

Note that it is certainly possible to adapt the example above to linear, 
block-based programming:

define rev_list(lst)
{
     define recursive rev_list_int(lst, accum)
     {
        match(lst)
        {
           [] -> return accum;
           head :: tail -> return rev_list_int(tail, head :: accum);
        }
     }
     return rev_list_int(lst, []);
}

With this programming style, I could make sense of the code without 
banging my head on the walls. It doesn't look that much recursive any 
more (with the "return" statements, it doesn't even looks functional any 
more ;-) ).

Cheers,
-- Denis.

>
> I also admit to not much liking Lisp- it's hard for me to keep track the
> parens.  And the performance of Lisp sucks (still).  Ocaml has managed 
> to
> overcome both of these limitations, IMHO.  My main beefs at the moment 
> are
> with the shift-reduce conflicts (which grate on my nerves), and with the
> lack of really good design by contract capabilities (it has a C-like
> assert(), but that's all).
>
>>
>> That may have to do with the fact that most functional programming
>> languages inherit from Lisp syntax... The nearest that I came to a
>> functional language that I wanted to use is Lustre
>> (http://citeseer.nj.nec.com/halbwachs91synchronous.html).
>
> Thanks for the pointer.  Interesting concept- I think that parallelism
> will be more important going forward, with the commoditization of SMP
> architectures (AMD's Hammer processors will introduce desktop ccNUMA
> machines to the market) and SMT processors (Intel is making all Pentiums
> SMT circa 3GHz).
>
>>
>> If you have on your agenda creating a functional programming language
>> that keeps its distances with the Lisp tree structuration, I am
>> interested. If you are just thinking of extending OCAML, I wouldn't
>> follow you.
>
> I'm not sure what my agenda is at this point.  Which is why Nomen has 
> gone
> into deep hibernation.  Simply cleaning up the shift-reduce conflicts 
> and
> adding DBC isn't enough, IMHO, to make a new language worthwhile.  And
> then, beyond that, you have the problem of getting your new language
> accepted- which is a set of trials and tribulations above and beyond
> simply getting the language to work.
>
> Brian
>