Path: utzoo!attcan!uunet!mcsun!ukc!icdoc!inmos!mph@lion.inmos.co.uk
From: mph@lion.inmos.co.uk (Mike Harrison)
Newsgroups: comp.lang.misc
Subject: Re: GOTO vs. pointer vs. assignment
Message-ID: <4910@ganymede.inmos.co.uk>
Date: 26 Mar 90 09:58:07 GMT
References: <5200059@m.cs.uiuc.edu> <14290@lambda.UUCP> <260adcad.4abe@polyslo.CalPoly.EDU>
Sender: news@inmos.co.uk
Reply-To: mph@inmos.co.uk (Mike Harrison)
Organization: INMOS Limited, Bristol, UK.
Lines: 70

In article <260adcad.4abe@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes:
> ...
>
>    Functional languages -  abstract beyond human comprehension :^)
>
Depends what you mean by human!

I know that I find the functional paradigm natural.

> ...                                        It seems to me that there is a
>benefit in assignment--it nails down a piece of data to a static structure
>so that the programmer has a chance to look at it and consider its role
>in the program.
>
If there is only a *single* assignment to any 'variable', it does that for
you but is still safe, in effect you are just given a local name to the value
of some expression. This does not require any change of state.

It is *changing* the value that is dangerous.


>I have only looked at ML a couple times (one assignment for a languages
>course). 

I'm not familiar with ML, but I know Hope and Miranda.


>mathematical background, as far as I can tell...  I have done some stuff
>in Lisp, and that is what I had to fall back on to do anything in ML.

Someone in news.groups discussing a proposal for comp.lang.fuctional, called
functional languages 'lambda calculus in drag', I think that sums it up nicely.

> ...                                           but I don't think that
>it can be said that the "safeness" of a language is the most important
>issue.

Of course it depends what you mean by safe, but I take it to mean eliminating
from the language all potential pitfalls which are not *absolutely* essential
for the satisfaction of the rquirements specification for the program.
Two points on this:

    - The domain of the application is relevant, I don't think I would be as
      concerned about the safety and correctness of an arcade game as I would 
      about that of the 'fly-by-wire' software of a wide-bodied airliner.

    - I think that language pitfalls are related to: 
         "The principle of minimum astonishment - the idea that (as far as can
          accomodated by other overiding requiremnets) a program statement will
          do what most experienced programmers would intuitively expect it to
          do"

      This implies that programming has cultural overtones - ie. if I wish to
      introduce some extremely novel feature in a programming language I must
      be very careful not to give it a syntax which makes it *appear* to be
      similar to some feature in a well known language, whose semantics it does
      not resemble at all.


Mike,






Michael P. Harrison - Software Group - Inmos Ltd. UK.
-----------------------------------------------------------
UK : mph@inmos.co.uk             with STANDARD_DISCLAIMERS;
US : mph@inmos.com               use  STANDARD_DISCLAIMERS;