Reference to Eiffel GC in Eric Raymond's new book 
Author Message
 Reference to Eiffel GC in Eric Raymond's new book

I was browsing through Eric Raymond's new book, The Art of UNIX
Programming, and came upon a reference to Eiffel and GC that appeared to be
incorrect.  I emailed him about it and he changed it to be more accurate,
but I think it is still subtly not quite right.  Here is part of my email,
with the relevant quote from his online book:

I noticed the following paragraph at the end of "Why Not C?" in Chapter
12:

The arguments against C and C++ apply with equal force to other
conventional compiled languages such as Pascal, Algol, PL/I, fortran,
and compiled Basic dialects. Despite occasional heroic efforts such as
Ada and the Eiffel/Sather family, the differences between conventional
languages remain superficial when set against their basic design decision
to leave memory management to the programmer. Though high-quality
open-source implementations of most languages ever written are available
under Unix, no other conventional languages remain in widespread use in
the Unix or Windows worlds; they have been abandoned in favor of C and
C++. Accordingly we will not survey them here.

Here are the parts he changed:
( http://www.*-*-*.com/ ~esr/writings/taoup/html/why_not_c.html#id2863367):

Despite occasional heroic efforts such as Ada and the Eiffel family, the
differences between conventional languages remain superficial when set
against their basic design decision to leave memory management to the
programmer[62].

[62] Most Eiffel and Sather implementations have garbage collection, but
the language standards do not mandate this; thus, an application could find
itself running in an environment where the facility is not present.

My question here has two parts: First, I think he may be correct that GC
is not mandated by the Eiffel language specification; but I'm not sure
about this - Anyone know for sure?  I did a quick, un-thorough, search on
google and did not find anything.

Second, even if he is technically correct, GC is so strongly emphasized in
Eiffel that almost all Eiffel programs are written with the assumption that
GC will be available and turned on.  It's a rare case where GC is not used
and for these cases GC would explicitly be turned off in the code.  Thus
the point he makes in the footnote, as far as I am aware, is not accurate
in the context of the real world.  Pratically speaking, an Eiffel application
would not find itself in an environment where GC is not present.  My
question is, assuming you (whoever responds) agree, can you come up
with a concise way of presenting this to Eric that will likely convince him
to change his document to fit the practical reality (preferably with some
supporting references/URLs)?

This is not a big deal, I suppose; but I think that the more accurate any
information generally available on Eiffel is, the more benefit there is
to the universe of software developers and software users, as well as to
the Eiffel community.  (If anyone is tempted to email Eric directly about
this, I think it may not be a good idea, since if several people end up
sending him mail, it could become a nuisance and encourage him to just
ignore us.  Just a suggestion.)
--
Jim Cochrane

[When responding by email, include the term non-spam in the subject line to
get through my spam filter.]



Wed, 27 Jul 2005 11:45:32 GMT  
 Reference to Eiffel GC in Eric Raymond's new book

Quote:

> [62] Most Eiffel and Sather implementations have garbage collection, but
> the language standards do not mandate this; thus, an application could find
> itself running in an environment where the facility is not present.

> My question here has two parts: First, I think he may be correct that GC
> is not mandated by the Eiffel language specification; but I'm not sure
> about this - Anyone know for sure?  I did a quick, un-thorough, search on
> google and did not find anything.

I'm sure it is mandatory. The ELKS standard contains a class MEMORY,
and there the interface to the GC is regulated. So any Eiffel compiler
must support this class. And BTW there is nothing in Eiffel for
explicitly freeing memory but overwriting dispose from MEMORY.

Quote:

> Second, even if he is technically correct, GC is so strongly emphasized in
> Eiffel that almost all Eiffel programs are written with the assumption that
> GC will be available and turned on.  It's a rare case where GC is not used
> and for these cases GC would explicitly be turned off in the code.  Thus
> the point he makes in the footnote, as far as I am aware, is not accurate
> in the context of the real world.  

It's IMHO superficial. Eiffel do have to have GC full stop. The fact
that you can disable it in SmallEiffel of course supports Erics view.

Regards
Friedrich



Wed, 27 Jul 2005 15:04:52 GMT  
 Reference to Eiffel GC in Eric Raymond's new book

Just a remark I forgot: In ETL are some chapters about creating
objects not none about destroying. Well if you do not have  way for
destroying objects how are they supposed to go away?

Friedrich



Wed, 27 Jul 2005 15:08:00 GMT  
 Reference to Eiffel GC in Eric Raymond's new book

Quote:


>> [62] Most Eiffel and Sather implementations have garbage collection, but
>> the language standards do not mandate this; thus, an application could find
>> itself running in an environment where the facility is not present.

>> My question here has two parts: First, I think he may be correct that GC
>> is not mandated by the Eiffel language specification; but I'm not sure
>> about this - Anyone know for sure?  I did a quick, un-thorough, search on
>> google and did not find anything.
>I'm sure it is mandatory. The ELKS standard contains a class MEMORY,
>and there the interface to the GC is regulated. So any Eiffel compiler
>must support this class. And BTW there is nothing in Eiffel for
>explicitly freeing memory but overwriting dispose from MEMORY.

Hi Friedrich.  Thanks for pointing that out.  However, I'm wondering if
this is strong enough "evidence" to convince Eric of that.  Is a compiler
implementation allowed to provide MEMORY, but not implement it fully,
for example, by implementing the 'collecting' query to always return false.
(In ISE 5.1 'collecting' indicates whether GC is on.  I'm not sure, though,
if this is part of the ELKS standard.)

Quote:

>> Second, even if he is technically correct, GC is so strongly emphasized in
>> Eiffel that almost all Eiffel programs are written with the assumption that
>> GC will be available and turned on.  It's a rare case where GC is not used
>> and for these cases GC would explicitly be turned off in the code.  Thus
>> the point he makes in the footnote, as far as I am aware, is not accurate
>> in the context of the real world.  
>It's IMHO superficial. Eiffel do have to have GC full stop. The fact
>that you can disable it in SmallEiffel of course supports Erics view.

>Regards
>Friedrich

--
Jim Cochrane

[When responding by email, include the term non-spam in the subject line to
get through my spam filter.]



Thu, 28 Jul 2005 14:06:40 GMT  
 Reference to Eiffel GC in Eric Raymond's new book
I believe it is pretty clear in every Eiffel developer's mind that GC is
part of the Eiffel definition. That's part of the reason why people use
Eiffel. If it can help I'll bring up the issue to ECMA in case it is not yet
clearly mentioned in the new forthcoming standard.

Manu

--
----------------------------------------------------------
Eiffel Software
805-685-1006
http://www.eiffel.com
Customer support: http://support.eiffel.com

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


Quote:


> >> [62] Most Eiffel and Sather implementations have garbage collection,
but
> >> the language standards do not mandate this; thus, an application could
find
> >> itself running in an environment where the facility is not present.

> >> My question here has two parts: First, I think he may be correct that
GC
> >> is not mandated by the Eiffel language specification; but I'm not sure
> >> about this - Anyone know for sure?  I did a quick, un-thorough, search
on
> >> google and did not find anything.
> >I'm sure it is mandatory. The ELKS standard contains a class MEMORY,
> >and there the interface to the GC is regulated. So any Eiffel compiler
> >must support this class. And BTW there is nothing in Eiffel for
> >explicitly freeing memory but overwriting dispose from MEMORY.

> Hi Friedrich.  Thanks for pointing that out.  However, I'm wondering if
> this is strong enough "evidence" to convince Eric of that.  Is a compiler
> implementation allowed to provide MEMORY, but not implement it fully,
> for example, by implementing the 'collecting' query to always return
false.
> (In ISE 5.1 'collecting' indicates whether GC is on.  I'm not sure,
though,
> if this is part of the ELKS standard.)

> >> Second, even if he is technically correct, GC is so strongly emphasized
in
> >> Eiffel that almost all Eiffel programs are written with the assumption
that
> >> GC will be available and turned on.  It's a rare case where GC is not
used
> >> and for these cases GC would explicitly be turned off in the code.
Thus
> >> the point he makes in the footnote, as far as I am aware, is not
accurate
> >> in the context of the real world.
> >It's IMHO superficial. Eiffel do have to have GC full stop. The fact
> >that you can disable it in SmallEiffel of course supports Erics view.

> >Regards
> >Friedrich

> --
> Jim Cochrane

> [When responding by email, include the term non-spam in the subject line
to
> get through my spam filter.]



Thu, 28 Jul 2005 14:29:08 GMT  
 Reference to Eiffel GC in Eric Raymond's new book

Quote:

> Hi Friedrich.  Thanks for pointing that out.  However, I'm wondering if
> this is strong enough "evidence" to convince Eric of that.  Is a compiler
> implementation allowed to provide MEMORY, but not implement it fully,
> for example, by implementing the 'collecting' query to always return
>false.

Yes that it possible and I pointed it out. But for me that is
superficial. I know that from all implementation just SmallEiffel can
be told to never garbage collect. So this is prove enough to say that
Eiffel can go away without GC.

Quote:
> (In ISE 5.1 'collecting' indicates whether GC is on.  I'm not sure, though,
> if this is part of the ELKS standard.)

See the ELKS standard e.g on
http://www.gobosoft.com/eiffel/nice/elks95/memory.html

collecting is part of the ELKS therfor must be supported by any Eiffel
compiler

second there is a feature collection_on too part of the Standard

third you do not have any chance to know how objects get their memory
(in a standard way), you do not even know how to free memory for
objects. -> Objects are supposed to get GCd

Any other intpretation is nitpicking.

Regards
Friedrich



Thu, 28 Jul 2005 15:28:56 GMT  
 Reference to Eiffel GC in Eric Raymond's new book

Quote:

> I believe it is pretty clear in every Eiffel developer's mind that GC is
> part of the Eiffel definition. That's part of the reason why people use
> Eiffel. If it can help I'll bring up the issue to ECMA in case it is not yet
> clearly mentioned in the new forthcoming standard.

The relevant section in ETL2 is 20.16 "Memory management" page 334-335.

--
Eric Bezault

http://www.gobosoft.com



Thu, 28 Jul 2005 18:01:47 GMT  
 Reference to Eiffel GC in Eric Raymond's new book

Quote:


> > I believe it is pretty clear in every Eiffel developer's mind that GC is
> > part of the Eiffel definition. That's part of the reason why people use
> > Eiffel. If it can help I'll bring up the issue to ECMA in case it is not yet
> > clearly mentioned in the new forthcoming standard.

> The relevant section in ETL2 is 20.16 "Memory management" page

334-335.
p. 335 4 paragraph:
Authors of Eiffel implementations are encouraged (although not
required) to provide a garbage collection mechanism ...

So this means an Eiffel could get away without GC!

Regards
Friedrich



Thu, 28 Jul 2005 19:35:11 GMT  
 Reference to Eiffel GC in Eric Raymond's new book

Quote:

> p. 335 4 paragraph:
> Authors of Eiffel implementations are encouraged (although not
> required) to provide a garbage collection mechanism ...

> So this means an Eiffel could get away without GC!

But only to compile programs that do not generate too much garbage,
because earlier in the same page it is said that it is too dangerous
to let the developers reclaim the memory.

So Eiffel is a garbage collected language, but it is allowed to
turn the GC off either partially or during the whole execution
of the program (in which case it is not necessary to provide a
GC mechanism at all).

--
Eric Bezault

http://www.gobosoft.com



Thu, 28 Jul 2005 19:56:42 GMT  
 Reference to Eiffel GC in Eric Raymond's new book
Quote:

>> So this means an Eiffel could get away without GC!
> But only to compile programs that do not generate too much garbage,
> because earlier in the same page it is said that it is too dangerous
> to let the developers reclaim the memory.
> So Eiffel is a garbage collected language, but it is allowed to
> turn the GC off either partially or during the whole execution
> of the program (in which case it is not necessary to provide a
> GC mechanism at all).

It is actually possible to have manual management of memory.

It is enought to use this ANY class and to call dispose when you want to
dispose an object.

indexing "[ Base class for projects who wants to handle manually %
         % their memory usage. If you use it, use with care and  %
         % compile without SmartEiffel Garbage collectior]"

class ANY
inherit GENERAL
feature -- Memory handling
   free is
      require malloced: not is_expanded_type -- the memory must be allocated
      do
         c_free(to_pointer)
      end
   c_free (pointer: POINTER) is
      require malloced: not is_expanded_type -- the memory must be allocated
      external "C inline" alias "free ($pointer)"
end -- ANY

I do agree it is not an Eiffelish practise, and it gives headaches to the
programmers and the users, but it is still possible.

        Paolo Redaelli



Thu, 28 Jul 2005 21:14:06 GMT  
 Reference to Eiffel GC in Eric Raymond's new book

Quote:

> It is actually possible to have manual management of memory.

Of course, if a GC can to it, a developer can do it as well. After
all the GC has been implemented by developers in the first place.
But this means that you know how objects are created in memory. So
you have to know how the runtime of your Eiffel compiler works.
You're not an Eiffel programmer anymore, but an Eiffel implementor.
So I still believe that the Eiffel language (i.e. from the point
of view of the programmers) is a garbage collected language.

Quote:
> It is enought to use this ANY class and to call dispose when you want to
> dispose an object.

> indexing "[ Base class for projects who wants to handle manually %
>          % their memory usage. If you use it, use with care and  %
>          % compile without SmartEiffel Garbage collectior]"

> class ANY
> inherit GENERAL
> feature -- Memory handling
>    free is
>       require malloced: not is_expanded_type -- the memory must be allocated
>       do
>          c_free(to_pointer)
>       end
>    c_free (pointer: POINTER) is
>       require malloced: not is_expanded_type -- the memory must be allocated
>       external "C inline" alias "free ($pointer)"
> end -- ANY

Here you made the assumption that `to_pointer' (which is not
standard Eiffel BTW) returns a pointer to a malloc'ated memory
space. But this is not necessarily the case: the object's
memory may be part of a bigger allocated memory chunk. Unless
you stop being an Eiffel programmer and put your Eiffel implementor's
hat in order to dive into the runtime source code of your Eiffel
compiler to understand how objects are created, you cannot rely
on the code above.

--
Eric Bezault

http://www.gobosoft.com



Thu, 28 Jul 2005 21:34:05 GMT  
 Reference to Eiffel GC in Eric Raymond's new book

Quote:


> > The relevant section in ETL2 is 20.16 "Memory management" page
> 334-335.
> p. 335 4 paragraph:
> Authors of Eiffel implementations are encouraged (although not
> required) to provide a garbage collection mechanism ...

> So this means an Eiffel could get away without GC!

Not in any practical sense: nobody would use such an Eiffel
implementation.  It's like saying that an Eiffel could "get away" with
allocating 10 million bits for each integer variable -- true, but not in
a practical sense.

I don't see how *any* language could *require* GC in any formal sense.
How could you write a test case that distinguishes between "this
implementation doesn't do GC" and "this implementation does GC, but it
runs out of memory anyway"?

I think we say "Lisp is a GC'ed language" in an informal sense, meaning
all Lisp implementations support GC, and it is likely that all future
Lisp implementations will also.

I think it's fair to put Eiffel in the same category as Lisp, in this
regard.

I think Meyer is just being honest when he says "encouraged (although
not required)" -- he is admitting that there is no formal way to
*require* GC.  At least, not without nailing down the memory usage rules
far more tightly than any language actually does.

- Bob



Fri, 29 Jul 2005 03:54:14 GMT  
 Reference to Eiffel GC in Eric Raymond's new book

Quote:



>> > I believe it is pretty clear in every Eiffel developer's mind that GC is
>> > part of the Eiffel definition. That's part of the reason why people use
>> > Eiffel. If it can help I'll bring up the issue to ECMA in case it is not yet
>> > clearly mentioned in the new forthcoming standard.

>> The relevant section in ETL2 is 20.16 "Memory management" page
>334-335.
>p. 335 4 paragraph:
>Authors of Eiffel implementations are encouraged (although not
>required) to provide a garbage collection mechanism ...

Yes, that's the smoking gun (sorry abuot that) that Eric can use to support
his footnote that GC is not mandatory with Eiffel.

So how do we convince him that, despite the formal definition, essentially
all Eiffel programmers assume correctly that they can write their code with
a fully functional GC mechanism and that it will be portable to any
platform for which their compiler is available (and if they code strictly
to the ELKS standard, to any platform for which any of the modern Eiffel
compilers are available)?

In other words, how can we convince him that, in practice, GC is
mandatory with Eiffel?  There are some good arguments in other posts here;
perhaps I should just point him to the newsgroup thread.  He may be too
busy to read it, though.

Quote:

>So this means an Eiffel could get away without GC!

>Regards
>Friedrich

--
Jim Cochrane

[When responding by email, include the term non-spam in the subject line to
get through my spam filter.]



Fri, 29 Jul 2005 05:41:02 GMT  
 Reference to Eiffel GC in Eric Raymond's new book

Quote:

> So how do we convince him that, despite the formal definition, essentially
> all Eiffel programmers assume correctly that they can write their code with
> a fully functional GC mechanism and that it will be portable to any
> platform for which their compiler is available (and if they code strictly
> to the ELKS standard, to any platform for which any of the modern Eiffel
> compilers are available)?

You could point out that his footnote applies equally to Lisp and
Smalltalk and Java and every other language that has GC.

- Bob



Fri, 29 Jul 2005 06:05:23 GMT  
 Reference to Eiffel GC in Eric Raymond's new book

Quote:

> Yes, that's the smoking gun (sorry abuot that) that Eric can use to support
> his footnote that GC is not mandatory with Eiffel.

> So how do we convince him that, despite the formal definition, essentially
> all Eiffel programmers assume correctly that they can write their code with
> a fully functional GC mechanism and that it will be portable to any
> platform for which their compiler is available (and if they code strictly
> to the ELKS standard, to any platform for which any of the modern Eiffel
> compilers are available)?

I have shown you some things about it before. What do you dislike
about them?

Friedrich



Fri, 29 Jul 2005 14:07:30 GMT  
 
 [ 22 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Eric S. Raymond's newest writings

2. Unix's Zoo of Languages (Eric Raymond)

3. Eric S. Raymond mentions Ruby but ...

4. new Eiffel book: it's out!

5. Book announcement - Eiffel Reference Manual

6. Raymond Smullyan's EFS and the Formalization of Combinatory Logic

7. New Book: "Python Essential Reference"

8. New editions of reference books

9. New to eiffel, compilers & books

10. New book - O-O Programming in Eiffel (Thomas/Weedon)

11. new Eiffel book: OOPIE

12. >new Eiffel book

 

 
Powered by phpBB® Forum Software