Low level question 
Author Message
 Low level question

  I have this very amateurish interest in functional languages, and
hence this question is pretty simplistic considering the level
of expertise on programming languages in the group, hence I
hope any response will be simple.

  I've noticed quite a lot of functional languages around.  ML,
Hope, Miranda, Haskell (these are presumably typed functional
languages).   Now suppose I am some run of the mill programmer
who's familiarity lies in more conventional languages, but has
an interest in functional languages.  Here are some questions
I might pose:

   (1) Are the differences between these languages great?
       In other words, for some typical programming (say
       those found in a typical undergraduate course), what
       kind of questions should I ask myself for selecting
       a language, or are the languages so similar that
       anyone would do, and that the difficulties only
       arise in subtle areas which most programmers
       don't need to worry about.

   (2) Are there limitations of these languages in terms of
       support?  For example, LISP is probably the most
       widely used functional languages.  It's got a large
       number of built-in functions, and presumably some
       nice environments to work in, though I haven't seen
       a de{*filter*} around (whereas C de{*filter*}s are much more
       commonplace).  Do these newer languages have this
       support or is there some standout (like possibly ML?).

   (3) Are these languages meant to be used as research
       tools are or is there an aim to use it in everyday
       programming?  By research tools, I mean that it is
       used primarily to test out certain ideas in functional
       programming and hence may have some limitations for
       "practical" use (such as poor I/O).

   That should be enough.  These questions came to me when
I had acquired some books on functional programming.  One
book (Peyton-Jones) uses Miranda.  Another (Davie?) uses
Haskell.  I know there is another one that uses ML, and
I have one or two texts on ML.  With all these functional
languages out there,  I wanted to get a big picture of
what these languages are trying to achieve.  They seem
syntactically similar which is nice (i.e. ML programs
look like Haskell programs look like Miranda programs).

   Again, I should warn you that my knowledge of programming
languages is quite limited, and so more general answers
would be better.   Sorry for those who find this kind
of posting inconvenient.

   E-mail is preferred, though this group has few enough
articles that I can check back once in a while.  Thanks
in advance.

--
Charles Lin



Thu, 29 Dec 1994 14:11:22 GMT  
 Low level question

     I've noticed quite a lot of functional languages around. [...]
     Here are some questions I might pose:

      (1) Are the differences between these languages great? [...]

      (2) Are there limitations of these languages in terms of
          support? [...] [programming environment]

      (3) Are these languages meant to be used as research
          tools are or is there an aim to use it in everyday
          programming? [...]

The major differences among functional languages seem to be whether
they have eager or lazy evaluation, and whether they are strictly
functional, or mostly-functional with some imperative features.

The two main players and representatives seem to be SML (eager,
mostly-functional) and Haskell (lazy, strictly functional). Lisp might
also be considered a functional programming language, but most Lisp
programs that I have seen (that includes Scheme) are very imperative
in nature.

To me, SML seems to be closest to a "real-world" language among the
functional programming languages (this includes Lisp). It is a simple,
powerful language, and it seems to have made conservative, realistic
choices. I particularly like its type- and module system, both of
which support the organization and integration of large amounts of
code from diverse sources. On the downside, SML's syntax is a little
odd, and some important primitives have not been standardized yet
(like bit vectors, more specialized floating point operations, binary
I/O, and foreign function interfaces).

I view Haskell more as a research language. Lazy evaluation brings
with it a whole new set of complications (in areas such as I/O,
debugging, optimization) that I don't think have been adequately
addressed. The Haskell syntax manages to be even more baroque than
that of SML, and the module system is primitive compared to what SML
provides. Also, the type system is rather more complex without (to my
mind) a commensurate gain in functionality. The number system is
reminiscent of CommonLisp, which I have always found greatly inferior
to the much simpler number systems of languages like C, fortran and
SML. On the other hand, Haskell is probably a good testbed for ideas
about lazy evaluation and side-effect free programming.

Another strictly functional language that should be mentioned is
SISAL. In its niche, high-performance numerical computation, it is
probably the most mature language.

I have been using SML for developing and testing algorithms in
computer vision. I have found it to be a very useful tool.

                                        Thomas.



Fri, 30 Dec 1994 23:14:39 GMT  
 Low level question

Quote:

>       LISP is probably the most
>       widely used functional languages.  It's got a large
>       number of built-in functions, and presumably some
>       nice environments to work in, ...

>--
>Charles Lin


Lisp is NOT a functional language; it is an imperative language
with a strange concrete syntax.  Not only has Lisp got assignment,
it also has a GOTO.  When I say this to my Lisp-using friends, they
usually reply that you don't have to use those features of Lisp;
to which I reply:  (1) That a language is functional does not
depend on your style of programming; it's the fact that those features
are present in Lisp that makes it imperative.  (2) Modern Lisp
programming style is very different from what was common even ten years
ago and that is due to the influence of pure functional languages like
Miranda (tm).  (3) Is Pascal a functional language because you can avoid
using GOTOs and assignments most of the time?

Antoni Diller



Fri, 30 Dec 1994 21:48:20 GMT  
 Low level question


Quote:

>  >       LISP is probably the most
>  >       widely used functional languages.  It's got a large
[...]
>  >Charles Lin

>  Lisp is NOT a functional language; it is an imperative language
>  with a strange concrete syntax.  Not only has Lisp got assignment,
>  it also has a GOTO.  When I say this to my Lisp-using friends, they
>  usually reply that you don't have to use those features of Lisp;
>  to which I reply:  (1) That a language is functional does not
>  depend on your style of programming; it's the fact that those features
>  are present in Lisp that makes it imperative.  (2) Modern Lisp
>  programming style is very different from what was common even ten years
>  ago and that is due to the influence of pure functional languages like
>  Miranda (tm).  (3) Is Pascal a functional language because you can avoid
>  using GOTOs and assignments most of the time?

Do you think Pascal is less functional than, say, ML ? Real functional
languages are rare, and nobody uses them: people only talk about them,
or implement them, making absurd claims of efficiency.  Real
functional languages are a business in its own (that has nothing to do
with programming machines).

What really makes the difference between Pascal and ML is not ML being
functional when Pascal is not. Other differences are much more
important: modern, supposedly safe type system as opposed to an unsafe
and limited one, garbage collection, odd syntax invented by
mathematicians, strange talk on the modules side, etc. All this has
nothing to do with "functional vs non-functional".

        Vincent

- Show quoted text -

Quote:
>  Antoni Diller




Fri, 30 Dec 1994 20:46:56 GMT  
 Low level question

   Lisp is NOT a functional language; it is an imperative language
   with a strange concrete syntax.  Not only has Lisp got assignment,
   it also has a GOTO.

I don't think this is a very helpful comment and your remarks also
depend very much on the LISP dialect. SCHEME hasn't got GOTOs and if I
remember right neither has CommonLISP. Regarding assignments I may add
that ML has assignments but is usually considered as THE example of a
functional programming language.

I would prefer to say that they are all not purely functional.

Historically, I believe, the most essential feature of functional
programming languages is their support of higher order programming
("functions are first class citicens"). However, they share this
feature with other high level languages, nowadays.

T.

--
Thorsten Altenkirch

LFCS, Dept. of Computer Science    UUCP:  ..!mcvax!ukc!lfcs!alti

Edinburgh EH9 3JZ, UK.             Tel:   (+44 31) 650 51 38



Sat, 31 Dec 1994 05:41:48 GMT  
 Low level question

Quote:

>Do you think Pascal is less functional than, say, ML ? Real functional
>languages are rare, and nobody uses them: people only talk about them,
>or implement them, making absurd claims of efficiency.  Real
>functional languages are a business in its own (that has nothing to do
>with programming machines).

Good point.  Now that we've done a bit about formal semantics, abstract
machines, and even a few real machines, perhaps we should look at
programming and software engineering if the rest of the world is to be
convinced.  


Sat, 31 Dec 1994 07:08:30 GMT  
 Low level question


Quote:
Antoni Diller writes:
>>                Lisp is NOT a functional language; it is an imperative
>>                language with a strange concrete syntax.
>>                Not only has Lisp got assignment, it also has a GOTO.
>>                Lisp-using friends, reply that you don't have to use
>>                those features of Lisp; to which I reply:
>>                (1)     That a language is functional does not
>>                        depend on your style of programming;
>>                        it's the fact that those features are present
>>                        in Lisp that makes it imperative.

From a theoretical perspective this is true.

Quote:
>>                (2)     Modern Lisp programming style is very different
>>                        from what was common even ten years ago and
>>                        that is due to the influence of pure functional
>>                        languages like Miranda (tm).

Or did the idea of a purely functional language arise
when a visionary saw how much could be done in LISP
without causing side-effects?

Quote:
>>                (3)     Is Pascal a functional language because
>>                        you can avoid using GOTOs and assignments
>>                        most of the time?


Vincent Delacour adds:

Quote:
>    What really makes the difference between Pascal and ML
>    ... has nothing to do with "functional vs non-functional".

This is how I look at it:

A number of programming techniques and language constructs
have been developed which help us avoid relying on side-effects.
Instead of loops (which make no sense unless variable contents
are modified) we can use recursion.  Instead of using
arrays and large records (which are expensive to copy),
we can use heap-based lists and trees so that new structures
can share large parts of old ones.  We can keep memory management
transparant to the program by using automatic garbage collection,
instead of explicitly allocating or deallocating storage
(which is most definitely a side-effect).
Instead of using self-modifying code or confusing code with data,
we can use a language which treats procedures as objects.

A language that provides these features is facilitates
a functional (i.e. side-effect-free) programming style,
and in that sense may be called a functional programming language.
Lisp and ML fall into this category; Pascal does not.

A _pure_ functional programming language is more coercive,
in that the familiar side-effect laden alternatives
are deliberately omitted.  In these languages
we not only can program in a functional style,
but we can reason about such programs without
worrying whether the paradigm was ever violated.
The constructs of such a language have unusually simple
mathematical descriptions.

------------------------------------------

Tulane University       New Orleans, Louisiana  USA



Sat, 31 Dec 1994 22:54:12 GMT  
 Low level question

   Do you think Pascal is less functional than, say, ML ?

Yes. SML has a useful, strictly functional subset. Furthermore, it is
easy to ascertain whether a program sticks to this subset.  The same
cannot be said for Pascal.

   Real functional languages are rare, and nobody uses them: people
   only talk about them, or implement them, making absurd claims of
   efficiency.

No. Real functional languages need not be any less efficient that
imperative languages. Most of my programs written in SML are purely
functional, or, if they involve arrays, could be trivially expressed
in a functional language with version arrays, with minimal overhead.

The perception that functional programming languages are "inefficient"
is a simple consequence of the fact that large amounts of resources
have not been devoted to compiling them efficiently. If all the effort
that currently goes into C++ compiler development went into SML or
Haskell compiler development, you would find that the resulting
compilers generate code that is as good, if not better, than for
equivalent C++ code.

   What really makes the difference between Pascal and ML is not ML being
   functional when Pascal is not. Other differences are much more
   important: modern, supposedly safe type system as opposed to an unsafe
   and limited one, garbage collection, odd syntax invented by
   mathematicians, strange talk on the modules side, etc. All this has
   nothing to do with "functional vs non-functional".

The SML type system and module system are functionally superior to
most other type systems and module systems in existence. These aren't
abstract or esoteric differences, they are very concrete, very down to
earth.

You can see these advantages if you compare SML with a language like
C++. In terms of typing and module system, C++ tries to provide
approximately the same functionality as SML (namely, static type
checking, polymorphism, parameterized types, modules).

Unfortunately, C++ fails. In C++, parameterized types cannot be
checked when defined (only when used), the type system does not
guarantee the absence of runtime type errors, parameterized types can
realistically only be implemented by code duplication, and the module
system fails to allow the programmer to do those things that a module
system is there for: allow the programmer to avoid and resolve name
conflicts.

These are very concrete shortcomings, resulting in very concrete
problems, such as undiagnosed runtime type errors, very cumbersome
code for certain problems, limited code reuse, and huge executables.

(Incidentally, while I am not particularly enamoured with SML syntax,
I think it is no worse than the syntax of languages not "invented by
mathematicians", such as Pascal, FORTRAN and C. In fact, SML syntax,
for better or for worse (for worse, if you ask me), is closely modeled
after Pascal syntax.)

                                        Thomas.



Sun, 01 Jan 1995 05:57:23 GMT  
 Low level question


[...]
   No. Real functional languages need not be any less efficient that
   imperative languages. [...]

At least on a limited class of programs, I agree. However, they are in
practice. My point on "absurd claims of efficiency" was on the
implementations, not on the languages. About the languages, I would
rather talk of "absurd claims of usefulness", which I think is at the
root of the implementations' inefficiencies: for most of it, the
functional programming world is not planted in reality, but in
paradox: just look at all these marvellous abstract machines, they are
not abstractions of the real machines, but abstractions of their own,
gratuitous. Read these papers discussing with such delight weird
"optimizations" within these abstract machines, where the so-called
optimization only removes a half-ton of inefficiency from a ton of
inefficiency directly attributable to the abstract machine itself!

The functional style of programming is IMHO, real cake. I like it and
practice it. I think it's a good thing to promote it, because it is
most of the time good style. However, as you would have guessed from
the above, I think it does not need to be promoted on the ground of
slogans and paradox.

        Vincent



Sun, 01 Jan 1995 02:11:15 GMT  
 Low level question

   The perception that functional programming languages are "inefficient"
   is a simple consequence of the fact that large amounts of resources
   have not been devoted to compiling them efficiently. If all the effort
   that currently goes into C++ compiler development went into SML or
   Haskell compiler development, you would find that the resulting
   compilers generate code that is as good, if not better, than for
   equivalent C++ code.

This is a statement of religious belief, I take it?




Sun, 01 Jan 1995 04:19:20 GMT  
 Low level question

[many pertinent comments...]

Quote:
>This is how I look at it:
[...]
>Instead of using
>arrays and large records (which are expensive to copy),
>we can use heap-based lists and trees so that new structures
>can share large parts of old ones.
[...]
>A language that provides these features facilitates
                                ^^^^^^^^
>a functional (i.e. side-effect-free) programming style,
>and in that sense may be called a functional programming language.

Excuse me, but making programs that use arrays and large records
unbearably slow is *not* a feature!

Referential transparency *is* a feature, but compiler should produce
code that implements your pure functional code using destructive assignment.
(Does anybody out there have a compiler that actually *does* this?)

--

This .signature VIRUS is a self-referential statement that is true - but
you will only be able to consistently believe it if you copy it to your own
.signature file!



Sun, 01 Jan 1995 04:31:22 GMT  
 Low level question

   Thanks for all the responses both on e-mail and by posting.  This
seems to have generated a good number of posts.  I can't say I understand
everything, but it has been informative.

   My original reason for posting was the sheer number of functional
(or those claiming to be functional) languages around.  I was wondering
if any of them had really stood out, and for what reason.   Were
the languages only slightly different from one another so that
a typical imperative style programmer trying to learn one of
these languages would not have to worry about which one he or she
chose?   If the languages were similar enough, then my followup
questions were aimed to discover what resources these languages
had around to make them easier to use.  Items such as de{*filter*}s
would be nice, or certainly if one could get a compiler easily
enough.

    Well, let me continue along my line of questioning.

    (1) I have a general idea of the differences between lazy and
        eager evaluation (Miranda and Haskell being examples of
        the first, and ML being an example of the latter).  This
        general idea being that ML evaluates all arguments prior
        to using them in the function while MIranda or Haskell
        only evaluates when necessary.

        Question: Does this make a big difference to the typical
                  programmer or are the differences minor and the
                  programmer just has to be aware of how expressions
                  are evaluated, but that it doesn't really affect
                  how one programs?   Putting it another way, it
                  seems that in recent years, there's been a push
                  to lazy evaluation.  What's the reason?

    (2) Another question is perhaps simpler.  It seems the idea
        of side effects is considered evil (or closely akin) in
        the functional programming community, and yet the majority
        of programmers learn languages that have side effects.
        Before continuing, let me quickly say what I think side
        effects mean.  Functional programming seems to say that
        a function should be calculated solely from its inputs.
        It should not require the use of global variables,
        nor should it do anything in its calculation that
        leaves some kind of structure of variable around.  I.e.,
        a function should only create some object or value as
        an output, and nothing else.

        Question:  Why are side effects bad?  The main reason I've
                   heard is the difficulty in reasoning about
                   programs using languages that have side effects.
                   What is it about programming in functional
                   languages that makes it better?

    (3) It seems that most functional programming languages
        are now typed (as opposed to LISP, the not-quite-a
        functional-language language).  Why has this been the
        case?  I presume it's just a nicer idea to find the
        type errors during compile time rather than run time, and
        that it's easier to reason about such programs.  Anyone
        have other reasons why there doesn't seem to be untyped
        functional languages (or is it that I just haven't been
        looking) coming out?

    (4) Finally, what is the functional programming community's
        view on so-called decalrative languages or logic
        programming?   My general impression is that there has
        been more focus on functional languages rather than
        declarative languages (I'm almost afraid to say that
        Prolog is a declarative language with the response I
        got on LISP as a functional language, and I'm sure people
        will say that is is not really a logic-based language either).

   I should mention that my first experience with "functional programming"
came with learning LISP, and that I had heard about ML mainly as
the language that some folks were using in the Nuprl project
(headed by Prof. Robert Constable) and since then have been trying
to figure out information about ML and other similar languages.
A lot of my questions have to do with trying to find out
why spending the time learning some language like ML would be
worth it.   I found I liked Lisp quite a lot since it seemed
so different from anything I had programmed in before, but there was
some buzz about how great ML was, and so I wanted to figure what
was going on about that.   If some people have anecdotes or
opinions on how they feel functional programming has changed their
programming for the better, I'd be interested in listening to them.

   Again, you can either e-mail responses or post them.  I appreciate
all the nice people who have spent time helping me out.

--
   ______    __    __   ___  ____
  / ____ \  |  |  |__| |   \ |  |    Charles Lin

 | |        |  |  |  | |  |\    |  
 | |     _  |  |  |__| |__| \___|    University of Maryland
 | \____/ | |  |____                 "I hate big sigs." -- Moo
  \______/  \_______|



Sun, 01 Jan 1995 04:56:27 GMT  
 Low level question

[asks questions about eager vs lazy evaluation, and the difference it
makes to the typical programmer]

The answer is quite simple: the typical programmer doesn't use lazy
languages. Look around you. There's no typical programmer using that.

The push for lazy programming does not concern programming, but
publishing papers in quite close circles, without much evaluation from
the rest of the CS community, and going to dedicated conferences on
very high-class topics. If you want to be smart and have fun, just do
that.

I suppose you may want to ask questions about continuations now:
there's much going on in that direction too...  there's a serious
_push_ on continuations these days...(on the other hand reflective
towers seem to be low, maybe it's not a real hit anymore... should ask
a specialist <;^)

I'd like to ask you a question, too: why do you ask all that ? what
are you searching for ? If you really want to know if all this stuff
(lazy, pure functional mambo, etc) is of any real interest, I bet you
can make up your mind yourself with a few minutes of reflection (;-):
just try to sort out facts from slogans. As for ML, I think that
(apart from the curios syntax), the advantages of programming in such
a language are also quite obvious.

        Vincent



Sat, 31 Dec 1994 23:20:41 GMT  
 Low level question
]    Well, let me continue along my line of questioning.
]
]    (1) I have a general idea of the differences between lazy and
]        eager evaluation (Miranda and Haskell being examples of
]        the first, and ML being an example of the latter).  This
]        general idea being that ML evaluates all arguments prior
]        to using them in the function while MIranda or Haskell
]        only evaluates when necessary.
]
]        Question: Does this make a big difference to the typical
]                  programmer or are the differences minor and the
]                  programmer just has to be aware of how expressions
]                  are evaluated, but that it doesn't really affect
]                  how one programs?   Putting it another way, it
]                  seems that in recent years, there's been a push
]                  to lazy evaluation.  What's the reason?
]

Yes, it makes a _profound_ difference on your style of programming.

A lazy language is capable of talking about infinite structures in very
natural ways. For example, in Haskell, you can generate the list of
Fibonacci numbers using:

        fib = 1 : 1 : [ a + b | (a,b) <- zip fib (tail fib) ]

fib is an infinitely long list. The reason that its computation can
halt, is because it only computes the section of the list that you
use. The list _is_ infinite, but no element of the list is computed
until it's needed.

In a strict language, you couldn't write a program that generated the
entire list of fib numbers. You could only write a program that could
generate a specific fib, or the fibs upto a specific fib.

Lazy program also lets you use certain idioms. For example, look at the
following function:

        test :: Bool -> real -> real
        test True y = y
        test False y = 0

In a lazy language, you can say:
        test False 2/0

and it will return 0. If you ran it in a struct language, it would get
a divide by zero error.

]        Question:  Why are side effects bad?  The main reason I've
]                   heard is the difficulty in reasoning about
]                   programs using languages that have side effects.
]                   What is it about programming in functional
]                   languages that makes it better?
]

Side affects make programs hard to analyze. You got that right. What
makes imperative programs so hard to analyze is the side affects. Take
them away, and things immediately get better. The advantage of
functional languages in this respect is _not_ really anything they
have; it's what they DON'T have. They don't have side affects. And, as
a direct result of that, all functions are referrentially transparent.
You know _exactly_ what a function means, without knowing anything
about what happens on the inside of other functions. The function is
completely self-contained and immune to affects from the outside.

]    (3) It seems that most functional programming languages
]        are now typed (as opposed to LISP, the not-quite-a
]        functional-language language).  Why has this been the
]        case?  I presume it's just a nicer idea to find the
]        type errors during compile time rather than run time, and
]        that it's easier to reason about such programs.  Anyone
]        have other reasons why there doesn't seem to be untyped
]        functional languages (or is it that I just haven't been
]        looking) coming out?

Two answers:

        1> Lisp is already written. It works. The people who need that
          kind of language are very happy with lisp. Generally, if they
          need something different, they're happiest with a variant of
          lisp. There are _dozens_ of lisp variants being worked on.
          There's no reason to invent a totally new weak-typed
          language - what about it would be different from Lisp or
          Scheme?

        2> The kind of type systems used in functional language add
          an enourmous of expressiveness to the languages. They're
          incredibly useful in the kinds of programs that can be
          naturally written in a functional style. If something is so good,
          why would you leave it out?

          It's sort of like why all imperative languages have loops.
          Why would you ever write a language that didn't include them?

I'm not at all up on Logic languages, so I'll leave your last question
for someone else.

        <MC>

--
|| Mark Craig Carroll: <MC>     ||"Don't ever think that you can't
|| Univ of Delaware, Dept of CIS||    change the past
|| Grad Student/Labstaff Hacker ||       or the future"



Sun, 01 Jan 1995 08:23:11 GMT  
 
 [ 99 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7]

 Relevant Pages 

1. low level question

2. Low level question again...

3. os low-level question

4. Really Low Low Low Level Stuff.

5. Another low level question & about an old book

6. High Level ASM and Low Level ASM

7. Low-level non VISA serial communication question: LV5.1 NT4.0

8. Low level file I/O question

9. Low level format on track-0 Question...

10. Low-level socket-close question.

11. Low-level socket programming

12. Low level programming.

 

 
Powered by phpBB® Forum Software