G.C as disqualifier (Flame-Bait) 
Author Message
 G.C as disqualifier (Flame-Bait)

A colleague of mine, working on Prolog implementation, asserted,
at lunch today, that programming languages that need built-in
garbage collection are useless as general programming languages.
He based his remarks on his own experiences in providing such
facilities for Prolog. He feels that any really practical lang-
uage must leave GC in the hands of the programmer. As builtin GC
seems to be an essential feature of practical functional languages,
I thought I'd try this idea out for size in this newsgroup ? Any
comments ?


Dept. of Computer Science, Trinity College, Dublin 2, IRELAND



Sat, 09 Sep 1995 22:52:52 GMT  
 G.C as disqualifier (Flame-Bait)

Quote:

>A colleague of mine, working on Prolog implementation, asserted,
>at lunch today, that programming languages that need built-in
>garbage collection are useless as general programming languages.
>He based his remarks on his own experiences in providing such
>facilities for Prolog. He feels that any really practical lang-
>uage must leave GC in the hands of the programmer. As builtin GC
>seems to be an essential feature of practical functional languages,
>I thought I'd try this idea out for size in this newsgroup ? Any
>comments ?

We really need to know WHY your colleague thinks that automatic GC is
useless in a general purpose language. I can think of two objections:

1) GC stops the execution at unpredictable times, making response
   erratic and hard time limits impossible to keep.

2) By knowing when the data is no longer useful, a programmer can
   dispose of it more efficiently than a general purpose automatic GC.

The first objection is valid enough, but applies only to real-time
programs, so only if you require a general purpose language to handle
real-time can you use this objection. Note that similar objections
apply to time-sharing operating systems like UNIX. The solution is
similar: you can allow the programmer to say that he doesn't want GC
while in a specific procedure. Of course, this requires sufficient
free store for that procedure in the heap. If a limit to the heap use
of such a procedure is imposed, this is no problem, as GC can be made
while there is still room in the heap. This corresponds exactly to the
usual limits to the time a procedure can block for interrupts.

The second objection supposes that the programmer can do better than
the compiler. This is similar to the eternal discussions about the
necessity to code in assembler for efficiency, and the answer is the
same: for small programs a good programmer can usually beat the
compiler, but the time required to do so for large programs makes it
useful to program in high-level languages even at the cost of somewhat
less efficient programs. And just as high-level programs are easier to
port to othet architectures, hand-coded GC may not be optimal over a
wide range of machines.




Sun, 10 Sep 1995 01:21:09 GMT  
 G.C as disqualifier (Flame-Bait)


|>
|> >A colleague of mine, working on Prolog implementation, asserted,
|> >at lunch today, that programming languages that need built-in
|> >garbage collection are useless as general programming languages.
|> >He based his remarks on his own experiences in providing such
|> >facilities for Prolog. He feels that any really practical lang-
|> >uage must leave GC in the hands of the programmer. As builtin GC
|> >seems to be an essential feature of practical functional languages,
|> >I thought I'd try this idea out for size in this newsgroup ? Any
|> >comments ?
|>
|> We really need to know WHY your colleague thinks that automatic GC is
|> useless in a general purpose language. I can think of two objections:
|>
|> 1) GC stops the execution at unpredictable times, making response
|>    erratic and hard time limits impossible to keep.
|>
|> 2) By knowing when the data is no longer useful, a programmer can
|>    dispose of it more efficiently than a general purpose automatic GC.
|>
[... stuff deleted ...]
|>

If you take specific GC techiques as e.g. compiling the calls to
get/free/copy memory-cells directly into the code the programs do
neither stop at unpredictable times (its just a bit more slowly) nor
the cells are freed too late (depends on the compiler). Maybe this
guy is just desperate about the success of such languages and is showing
this in such an ironical statement. I'd programmed years with programming
languages without GC and spend lots (most ;-) of the time to locate errors in my
own GC (allocate/deallocate) 'strategies' - core dumped - that is messin' around
with pointers. Nowadays I'm just happy about using a functional language without
these problems and I'm convinced that abstraction from the memory will
succeed at last.

--
o  O O o           |  Joern von Holten
 \/|/\/  .         |    Uni Bremen
  //\   Let please |



Sun, 10 Sep 1995 16:24:22 GMT  
 G.C as disqualifier (Flame-Bait)


   >A colleague of mine, working on Prolog implementation, asserted,
   >at lunch today, that programming languages that need built-in
   >garbage collection are useless as general programming languages.
   >He based his remarks on his own experiences in providing such
   >facilities for Prolog. He feels that any really practical lang-
   >uage must leave GC in the hands of the programmer. As builtin GC
   >seems to be an essential feature of practical functional languages,
   >I thought I'd try this idea out for size in this newsgroup ? Any
   >comments ?

   We really need to know WHY your colleague thinks that automatic GC is
   useless in a general purpose language. I can think of two objections:

   1) GC stops the execution at unpredictable times, making response
      erratic and hard time limits impossible to keep.

   2) By knowing when the data is no longer useful, a programmer can
      dispose of it more efficiently than a general purpose automatic GC.

   The first objection is valid enough, but applies only to real-time
   programs, so only if you require a general purpose language to handle
   real-time can you use this objection. Note that similar objections
   apply to time-sharing operating systems like UNIX. The solution is
   similar: you can allow the programmer to say that he doesn't want GC
   while in a specific procedure.

I don't agree and I think the above mentioned colleague is right.
Almost every interactive program is very hard to use with automatic
garbage collection. E.g. it is very annoying when GC occurs when you
drag the mouse to mark a region. I know, I know there are a number of
systems which avoid this sort of snags more or less but usually they
have to pay by sacrificing vaste amount of resources in memory.

For many comercial applications it is not acceptable if a program uses
more resources w.o. providing more functionality. There are
exceptions, like emacs which is used by many people although it is
inefficient. I believe that GC is a fundamental problem which
prevents the wider use of declarative languages. However, I think it
can be solved by providing more information at compile time, a
possible way would be to use 'linear types' as it was proposed by Phil
Wadler recently.

--

 Thorsten Altenkirch            And there's a hand, my trusty fiere,
 Laboratory for Foundations        And gie's a hand o' thine,
 of Computer Science            And we'll tak a right guid-willie waught
 University of Edinburgh           For auld lang syne!



Sun, 10 Sep 1995 21:35:32 GMT  
 G.C as disqualifier (Flame-Bait)


 >A colleague of mine, working on Prolog implementation, asserted,
 >at lunch today, that programming languages that need built-in
 >garbage collection are useless as general programming languages.
 >He based his remarks on his own experiences in providing such
 >facilities for Prolog. He feels that any really practical lang-
 >uage must leave GC in the hands of the programmer. As builtin GC
 >seems to be an essential feature of practical functional languages,
 >I thought I'd try this idea out for size in this newsgroup ? Any
 >comments ?

1. This kind of categorisation means that languages such as C and C++ are
   useless as GPLs, on the grounds that GC implementations also exist for
   these languages. Any language that allows dynamic allocation of memory
   will, in principle at least, require GC support at run-time.

2. Who said that a programming language has to deal with memory allocation?
   Yet this is the assumption being made by this colleague. PLs are about
   problem-stating/problem-solving - they should fit the nature of the
   class of problems they aim to address. So, Prolog, for example, has no
   business handling memory allocation in attempting to resolve logic
   queries.

It sounds like this colleague had a bad experience writing his garbage
collector and is consequently harbouring a grudge against languages that
use them. (Intention - humourous.)

Simon

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

Dept of Computer Science, University College London, London WC1E, England



Sun, 10 Sep 1995 21:29:34 GMT  
 G.C as disqualifier (Flame-Bait)

Quote:
(Thorsten Altenkirch) writes:

|> For many comercial applications it is not acceptable if a program uses
|> more resources w.o. providing more functionality. There are
|> exceptions, like emacs which is used by many people although it is
|> inefficient. I believe that GC is a fundamental problem which
|> prevents the wider use of declarative languages. However, I think it
|> can be solved by providing more information at compile time, a
|> possible way would be to use 'linear types' as it was proposed by Phil
|> Wadler recently.
|>
I don't know whether linear types were ever discussed on
comp.lang.functional. If so, I must have missed it. In any
case, could anyone give a pointer to this subject? (preferably
in electronic form)

Thanks in Advance,

Jan de Ruiter
Leiden University
Dpt. of Informatics for the Social Sciences



Mon, 11 Sep 1995 03:07:25 GMT  
 G.C as disqualifier (Flame-Bait)

   [in response to Andrew Butterfield]

   We really need to know WHY your colleague thinks that automatic GC is
   useless in a general purpose language. I can think of two objections:

   1) GC stops the execution at unpredictable times, making response
      erratic and hard time limits impossible to keep.

   2) By knowing when the data is no longer useful, a programmer can
      dispose of it more efficiently than a general purpose automatic GC.

   The first objection is valid enough, but applies only to real-time
   programs, so only if you require a general purpose language to handle
   real-time can you use this objection. [...]

Actually the first objection is not valid as stated, because GC
algorithms exist which obey hard time limits. These are known as
`real-time GC' algorithms, and are one of the main fields of research
in GC (others are concurrent and distributed GC). For instance, a
colleague of mine at CMU is working on a new real-time GC algorithm
which can guarantee pause times of less than 15 ms. (this bound can be
made smaller by doing GC more frequently). If this bound is not good
enough for some specific tight piece of code, one can pre-allocate
storage for that code (this is often done by operating systems, which
after all also have non-zero memory management time).

   The second objection supposes that the programmer can do better than
   the compiler. This is similar to the eternal discussions about the
   necessity to code in assembler for efficiency [...]

Actually it's less accurate even than that. Studies have shown that a
large fraction of the bugs in production-size C packages are storage
management bugs: space leaks, dangling pointers, and false sharing. In
other words, not only do programmers do worse than compilers and
GC, they can't even do well enough to write reliable code. GC is the
best way to make one's storage management reliable, and the evidence
is that it is the _only_ way to make it reliable in large systems.




Mon, 11 Sep 1995 04:14:28 GMT  
 G.C as disqualifier (Flame-Bait)

Quote:

>Almost every interactive program is very hard to use with automatic
>garbage collection. E.g. it is very annoying when GC occurs when you
>drag the mouse to mark a region. I know, I know there are a number of
>systems which avoid this sort of snags more or less but usually they
>have to pay by sacrificing vaste amount of resources in memory.

Excuse me, but this is nonsens. Stopping is not an inherent problem
of GC, but of some GC schemes. Avoiding stops with this schemes does
not necessarily vaste memory resources.

Automatic GC is not as efficient - in space and time - as tricky
manual can be, of course. Nevertheless, many real-world systems can
live with automatic GC (come to mind: TCP/IP mbufs, data structures of
the UNIX kernel).

Quote:
>For many comercial applications it is not acceptable if a program uses
>more resources w.o. providing more functionality.

The conclusion is accepted, but the premise was wrong.

Quote:
>There are
>exceptions, like emacs which is used by many people although it is
>inefficient.

emacs wouldn't be used by all this people if they wouldn't regard it
as efficient enough. This is an ancient story: go for a cup of coffee,
while emacs says "please wait, garbage collecting ...". The story
belongs to workstations 10 years or older.

Quote:
>I believe that GC is a fundamental problem which
>prevents the wider use of declarative languages. However, I think it
>can be solved by providing more information at compile time, a
>possible way would be to use 'linear types' as it was proposed by Phil
>Wadler recently.

GC is indeed a very interesting problem in the course of compiling
declarative languages. Unfortunately, the concept of garbage
collecting co-routines running independendly beside the mutators (mark
& scan, copying, generational) widely used and accepted as the ultimo
ratio in the scene impede the further investigation of the problem.
Intelligent automatic GC must be fused with the programs code and
specialized for a particular piece of code, just as the programer
manually does.

Linear types are perhaps an interesting concept on the language level,
to forbid unintentional multiple copys of data objects through the
type system. The information provided by linear types for the coder,
however, can be obtained in many cases through suitable program
analysis. So, in my opinion, it is not very wise to sell linear types
with this argument.

--
Wolfgang Grieskamp    Freilich ist es seltsam, die Erde nicht mehr zu bewohnen,



Mon, 11 Sep 1995 09:06:27 GMT  
 G.C as disqualifier (Flame-Bait)

Quote:

>Almost every interactive program is very hard to use with automatic
>garbage collection. E.g. it is very annoying when GC occurs when you
>drag the mouse to mark a region. I know, I know there are a number of
>systems which avoid this sort of snags more or less but usually they
>have to pay by sacrificing vaste amount of resources in memory.

  It saddens me to see very frequently in this group a big-mouth knoww-it-all
pops up and says something like:

  Garbage collection isn't any good, it takes too long.

  Recursion isn't any good, iteration is better.

  Currying isn't any use, nobody understands it anyway.

The whole point of research into functional programming and programming
languages in general is to resolve these points. It's as if I went to a
half-built basketball stadium and said "what a stupid idea, it's got no roof,
it'll get all wet when it rains". Perhaps there would be fewer flame wars here
if people realised that researchers are trying to solve problems, not shove
them down your neck and tell you it's good for you. But wait, this isn't the
end. After this mob has been through and identified some very interesting
research areas as being utter crap, we get other morons along who say:

  Why do you {*filter*}y academics sit around all day writing silly little papers.
  Functional programming is a silly idea anyway, none of it even works
  properly.

Well, I am honoured to exist in the same world as people so wise that they can
tell from the very outstart that functional programming will come to nothing.
Perhaps they can tell the first group that it doesn't matter that any
particular aspect of functional programming doesn't work, and shut them up.
But I am left wondering why we are all wasting our time...

John, wallowing in a dead-end research topic.
"Basketball's a stupid game, you can't even hit home runs. Pretty soon
everyone will see that and Shaquille O'Neil will be sweeping glass all the
time."



Mon, 11 Sep 1995 14:20:40 GMT  
 G.C as disqualifier (Flame-Bait)

Quote:
>I don't know whether linear types were ever discussed on
>comp.lang.functional. If so, I must have missed it. In any
>case, could anyone give a pointer to this subject? (preferably
>in electronic form)

  They were discussed, and I have several articles stored in my wais database
whose source is also included below. In general I keep everything which looks
productive.

John
---
(:source
   :version  3
   :ip-address "137.219.17.4"
   :ip-name "coral.cs.jcu.edu.au"
   :tcp-port 8000
   :database-name "Func-Prog-Abstracts"
   :cost 0.00
   :cost-unit :free


Keywords: help intro introduction info information computer science technical
          reports functional programming

This is a small collection of computer science technical reports, abstracts
and papers gathered from ftp sites etc. all over the world. Due to space
considerations, I am limiting it to functional programming, my area of
interest, and papers produced by the department (which may or may not be
related to functional programming).

Comments, problems etc to the maintainer above.
"
)
---
From comp.lang.functional Mon Oct  5 09:34:47 1992
Path: marlin.jcu.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!spool.mu.edu!olivea!uun
et!mcsun!sunic!kth.se!dentex.tds.kth.se!kff

Newsgroups: comp.lang.functional
Subject: Re: Unique types etc.
Keywords: Unique types, linear types, linear logic

Date: 2 Oct 92 08:33:00 GMT



Organization: Royal Institute of Technology, Stockholm, Sweden
Lines: 19
Nntp-Posting-Host: dentex.tds.kth.se
Status: OR

Hello!

Unique types seem related, if not identical, to what Phil Wadler
calls "linear types". His (and others) work is (as far as I know)
based on Girard's linear logic, in which assumptions must be used
exactly once. Thus the type checker guarantees that variables with
linear types are used exactly once. The major application so far
seems to have been the array update problem (guaranteeing that
arrays are used in such a way that array update can safely be
implemented without copying).

So, are unique types the same as linear types?

Curious cheers,

                   Karl-Filip

------------------------------------------------------------
Make the frequent case fast, and the fast case frequent!
---
This file fetched from ftp.dcs.glasgow.ac.uk:pub/glasgow-fp/papers 22/4/92
==========================================================================
File README:
pub/glasgow-fp/papers
~~~~~~~~~~~~~~~~~~~~~

This directory contains public Glasgow FP papers.

The file PAPER_LIST has a complete, up-to-date list of the GRASP
project papers in this directory.  At present, this is:

Summary Title                                   File
=============                                   ====

"GRASP Abstracts, 1990-1992"                    90andAfter.dvi

"The Essence of Functional Programming"         essence-of-fp.dvi

"A Futurebus Interface"                         futurebus-interface.dvi
"Unboxed Values" (FPCA 91)                      unboxed-values.dvi
"Is There a Use for Linear Logic?"              use-for-linear-logic.dvi

"Profiling Scheduling Experiments"              grip-scheduling.ps
"A Parallel Transaction Manager"                grip-database.ps
"Spineless Tagless G-Machine"                   spineless-tagless-gmachine.dvi
"Comprehending Monads"                          comprehending-monads.dvi

"Linear Types can Change the World!"           linear-types-can-change-the-world.dvi
"Type Classes in Haskell"                       type-classes-in-haskell.dvi
"A Static Semantics for Haskell"                static-semantics.dvi

"There's no Substitute for Linear Logic"        no-subst-for-linear-logic.dvi
---
From comp.lang.functional Fri Oct  2 09:56:48 1992
Newsgroups: comp.lang.functional
Path: marlin.jcu.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!uunet!mcsun!sun4nl!wn1.sci.kun.nl!cs.kun.nl!leonp

Subject: Unique types etc.


Organization: University of Nijmegen, The Netherlands
Date: Thu, 1 Oct 1992 13:44:27 GMT
Lines: 102
Status: OR

A while ago I posted a reaction on a discussion about
things that are difficult to do with functional programming
languages. I briefly mentioned Unique types.
I got some reactions on my post so I decided to write
a short follow up, to tell something about unique types
and to give some references where one can find more information.
I'll use Concurrent Clean syntax here, though it wil
be easy readible for anybody with no experience in Clean.
I use Clean because UNQ types are implemented in Clean
and because I'm working on an implementation of a portable IO system
using Concurrent Clean and UNQ types.

Consider the following very simple example:
We have an abstract type Clock that represents the system clock.
This abstract type can be used together with a function GetTime that
delivers the time of day:

ABSTYPE
:: Clock;

RULE == function
:: GetTime Clock -> Time;

We can now write programs that access the system clock:
:: F Clock -> BOOL;
   F clock
   -> TRUE, IF Ontime clock; == ontime is some alarm function etc.
   -> FALSE

Now consider the function G:
:: G Clock -> ...;
   G clock -> .....GetTime clock ...... GetTime clock;

Somehere in its body G calls GetTime twice with the clock argument.
But since Clock represents the system timer and both the 'GetTime clock'
applications will not be executed at the same time they will not
deliver the same time. And therefore GetTime is not referentially transparent
i.e. not functional.
That's why we introduce a UNQ type predicate in our language that
enforces that the reference count of clock can be at most one.

ABSTYPE
:: UNQ Clock

RULE
:: GetTime Clock -> (Clock, Time);  

The next function will now be wrong:
:: G Clock -> ....
   G clock -> .... GetTime clock .... GetTime clock;

because the reference count of clock can be only one.
We should rewrite G as:
:: G Clock -> ....
   G clock -> ..... time1 ..... time2,
              (clock', time1): GetTime clock,
              (clock'', time2): GetTime clock';

We now have time1 and time2 with the correct values, yet it remains
referentially transparent and therefore functional.

The UNQ predicate is an extension of the type checker in Clean
and whenever a reference count of an object is >1 than
a compile time error is generated!

UNQ types van be usefull in many cased:
- doing unique file io
- other kinds of io
- in situ updating of lists or arrays
etc.

In the Concurrent Clean systems UNQ types are used at the moment
for files and IOStates, the latter is used for programming complex
windowing systems in functional languages.

More information about unique types can be found in:
* Concurrent Clean Language Manual - version 0.8.
  technical report no. 92-18 august 1992,
  Department of Informatics,
  Faculty of Mathematics and Informatica,
  University of Nijmegen, The Netherlands
  (available for anonymous ftp together with the concurrent clean package)

This manual also contains literature references.

The Concurrent Clean system is available for anonymous ftp
ftp to ftp.cs.kun.nl
in directory pub/Clean

There are version of Clean 0.8 for Mac, Sun3 and Sun4
for the Mac version there is also a nice IO library
(which is described in the manual) that allows advanced gui
programming. This same library is currently being worked on
for Sun4/XWindows/OpenLook systems.

Leon Pillich
University of Nijmegen, Holland

-------------------------------------------------------------
 Life is what's happening when you're making other plans ...
                                      John Lennon



Mon, 11 Sep 1995 16:21:10 GMT  
 
 [ 31 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. GC as disqualifier (Flame-Bait)

2. Interesting, Was: Mac vs PC FLAME BAIT Par EXELENCE

3. FLAME BAIT!

4. Objects for ANS Forth FLAME BAIT!

5. Not really a flame-bait

6. Warning: Flame Bait

7. Microsoft Flame Bait

8. Window Systems and Forth (was: Mac vs PC FLAME BAIT Par EXELENCE)

9. Ichibah flames, and flames out over, Ada 9X

10. GC, and objects finalization (was: GC,again)

11. GC and Aging, GC and Allocator Surveys available

12. To GC or not to GC?

 

 
Powered by phpBB® Forum Software