Craig Brozefsky <cr...@red-bean.com> writes: > step...@dino.dnsalias.com (Stephen J. Bevan) writes: > > I worked on a Java project where various programs used one or more of > > the following standard features of Java: threads, servlets, JDBC, > > sockets (plain and SSL), non-blocking IO, crypto/certificates, CORBA > > interface, logging, LDAP interface, native language interface and GUI.
> > While I don't doubt that it is a lot of work to add all the standard > > things that Common Lisp has to Scheme (CLOS alone is a huge amount of > > work if you wanted to implement it in all its detail), I also think > > you are underestimating the work it would take to add to Common Lisp > > all the standard things (such as the *subset* above) that are in Java.
> I understand what you say is missing, but in my personal experience > with CL I have not found that to be a real critical issue. I found > that the parts that people commonly identify as missing from CL, > threads, servlets, JDBC, CORBA, LDAP, GUI are either not really > missing, or are not difficult to comprehend and then implement in some > fashion properly tailored to my needs as opposed to a "least common > denominator" standard.
I agree. However, that is a separate issue to the one I was addressing.
> Benjamin Simon <b...@atom.amazingmedia.com> writes: >> >>>>> "MA" == Marco Antoniotti <marc...@cs.nyu.edu> writes: >> MA> Sure, In Scheme you define things like DEFSTRUCT (and/or >> MA> define-record dependeing on your SIDJ - Scheme Implementation Du >> MA> Jour), MAKE-ARRAY (multidimensional) DEFCLASS etc etc.
>> SICP [1] describes using objects, and doesn't require any of these >> constructs.
> The fact that SICP does not require this constructs does not mean > that they are useless. Tape and Read/Write heads do not require > these objects either, yet they give you the full power of Common > Lisp.
> Essentially SICP (as far as I remember and unless the latest > editions amemded it) cannot even define `force' on `streams' since > it assumes a Scheme that does not have `define-syntax'. That does > not mean that `force' is useless.
SICP doesn't comment on continuations, either, so I would not be particularly inclined to draw many conclusions.
As far as I can see, the purpose of SICP is to use a pretty limited subset of Scheme to teach about computer science.
A message that rings out pretty clearly is that the fact that so much can be taught with so few abstractions. Note that it never mentions arrays, or "structures/records," either.
Its main commentary on OO is actually fairly cautionary, in a footnote that warns that OO isn't nearly what it's billed to be.
>> >> In scheme, objects are just regular functions -- I don't see why you >> >> can't create them (or use an already created object system)
>> MA> Exactly my point. Move over to Common Lisp, use "an already >> MA> created object system" and be done with it.
If it's in an accepted SRFI, then it's an at least moderately portable extension.
>> I'm not suggesting you should. I'm just suggesting that saying that >> you can't use objects is in Scheme is a silly thing to say and >> untrue. You might not like the object systems, but they do exist.
> I am not questioning the existence of N different object systems in > your SIDJ. I am questioning the use of a language that forces you > to re-implement - unportably - every single bit that you already > have - portably - in CL.
Entertainingly enough, most of the MOP implementations in use in Scheme have, as one of the co-authors, one of the co-authors of _The Art of the Meta Object Protocol_.
There _are_ multiple implementations, much as there are CLOS implementations that don't conform to MOP. Many of the object implementations are based on the same code base, much as many CLOS implementations are based on PCL.
Is it all joy and perfection? Things seldom are. The graphics options for CL have a tendancy to be painful to make work, too. No easy answers... -- (concatenate 'string "cbbrowne" "@acm.org") http://www.ntlug.org/~cbbrowne/rdbms.html "...Deep Hack Mode--that mysterious and frightening state of consciousness where Mortal Users fear to tread." -- Matt Welsh
>> > The fact that SICP does not require this constructs does not mean that >> > they are useless. Tape and Read/Write heads do not require these >> > objects either, yet they give you the full power of Common Lisp.
>> SICP is not a "how to use Scheme" book, but rather a "how to think >> about how to program computers" book.
> I never said that. SICP is one of the most wonderful books about > programming in general out there. I still have to see antoher that > covers as much ground with the same depth. (Well, I suppose there are > a few).
But you sure seem to be pointing at it as an example of "all that is in Scheme."
If anything, it uses a _faint_ subset of Scheme: one that makes R*RS look _powerful_. No strings, no macros, no call/cc, no arrays, no syntax-lists, no, well, "lots of things."
>> It doesn't mention call/cc either, but this is not because the >> authors of SICP think call/cc is unimportant.
Christopher Browne <cbbro...@acm.org> writes: > If anything, it uses a _faint_ subset of Scheme: one that makes R*RS > look _powerful_. No strings, no macros, no call/cc, no arrays, no > syntax-lists, no, well, "lots of things."
Indeed! One of the underlying foundations of CS education at MIT is that CS education is *not* about teaching languages.
There's a saying there: "Pascal is a useful language for only one thing: teaching Pascal." The point of 6.001 is not to teach Scheme, it's to teach programming. Scheme is a good language (surely not the only one, of course) in which the language can get out of the damn way and the student can learn something about computer programs.
> > > > > > malloc (and friends) and free are library functions. you won't find > > > > > > free in in the language spec either (at least if you exclude the > > > > > > standard library). so based on your argumentation C is a "garbage > > > > > > collected language"
> > > > > The C standard library is part of its specification. You will certainly > > > > > find malloc and free in the ISO C99 standard.
> > > > But, there are very few requirements on what they actually do. > > > > An implementaton can get away with something along the lines of > > > > void free(void*ptr) { } > > > > which defines free to do nothing.
> > > What it actually says is
> > > # #include <stdlib.h> > > > # void free(void *ptr); > > > # > > > # Description > > > # > > > # The *free* function causes the space pointed to by ptr to be > > > # deallocated, that is, made available for further allocation. If > > > # ptr is a null pointer, no action occurs. Otherwise, if the > > > # argument does not match a pointer earlier returned by the > > > # calloc, malloc, or realloc function, or if the space has been > > > # deallocated by a call to free or realloc, the behavior is > > > # undefined.
> > > which is more than nothing, if you ask me. It's in 7.20.3, which > > > is titled ``Memory management functions''.
> > Where does it say what it means to be "available for allocation"?
> In Webster's dictionary, among others.
Sorry, Erann, but I highly doubt that a definition of this phrase good enough to stand up to the rigor of PL semantics can be found in Webster's.
The fact is that it is highly unspecified under which conditions memory "returned" to the allocator via "free" will be dished out again by a subsequent allocation. An allocator that makes memory "avaliable" but then "chooses" to always return fresh memory anyway, ignoring all that "available" memory returned via "free", would probably not violate the letter (although perhaps the spirit) of the C standard.
> > > Brian Palmer <bpal...@leland.stanford.edu> writes:
> > > > An implementaton can get away with something along the lines of > > > > void free(void*ptr) { } > > > > which defines free to do nothing.
> > > What it actually says is
> > > # #include <stdlib.h> > > > # void free(void *ptr); > > > # > > > # Description > > > # > > > # The *free* function causes the space pointed to by ptr to be > > > # deallocated, that is, made available for further allocation. If > > > # ptr is a null pointer, no action occurs. Otherwise, if the > > > # argument does not match a pointer earlier returned by the > > > # calloc, malloc, or realloc function, or if the space has been > > > # deallocated by a call to free or realloc, the behavior is > > > # undefined.
> > > which is more than nothing, if you ask me. It's in 7.20.3, which > > > is titled ``Memory management functions''.
> > Where does it say what it means to be "available for allocation"?
> Nowhere, I think. The authors of the C standard (and other standards) > generally assume that their document isn't read by people whose goal > it is to implement the worst possible C compiler permitted by the > spec.
Sure. But this does not mean that the above paragraph says "more than nothing". It simply means that the C standard seems to rely on unwritten assumptions on what would be a "worst possible" implementation. In fact, I can think of many things that would make a C implementation even worse, so just ruling out "worst possible" would not nail down what "free" has to do. Or are you saying that the authors of the C standard generally assume the "best possible C compiler permitted by the spec"? I didn't think so.
> For the same reason, it is unnecessary to mention that a Lisp > implementation better had a garbage collector. IIRC, The Definition > of Standard ML doesn't make that requirement, either.
That is right. And some ML implementations get away with having (well almost) no garbage collector. (They are not the worst either.)
> > > Where does it say what it means to be "available for allocation"?
> > Nowhere, I think. The authors of the C standard (and other standards) > > generally assume that their document isn't read by people whose goal > > it is to implement the worst possible C compiler permitted by the > > spec.
> Sure. But this does not mean that the above paragraph says "more > than nothing". It simply means that the C standard seems to rely on > unwritten assumptions on what would be a "worst possible" > implementation.
That's right. It does not even try to be a mathematical document with mathematical rigor as, e.g. the ML definition. There are lots of questions about C you could ask that not even the people in comp.std.c are able to give a definite answer to (or at least agree on one ;-). It just isn't written for mathematicians who haven't learned that there are compromises in the real world. Rather, if the next C standard was written in DS, I'd expect people other than you or me who like to read such things to become very upset :-) (And I guess I wouldn't like it, either. Mathematically defining this complicated language would probably be much too wordy).
You can have very long debates about whether an expression like
p = p->q = NULL;
invokes undefined behavior or not, but C programmers don't really care, nor do implementors, nor do I: You do something reasonable, with the standard as a guide. I'd see at first glance that this expression is somewhat questionable, so, as a programmer, I'd not use it. As an implementor, I'd make it work, anyway. Debating about whether the standard explicitly allows or disallows this is a funny recreational exercise, but not more. There will always be questions like this (about C).
> In fact, I can think of many things that would make a C > implementation even worse, so just ruling out "worst possible" would > not nail down what "free" has to do. Or are you saying that the > authors of the C standard generally assume the "best possible C > compiler permitted by the spec"? I didn't think so.
No, but they assume ``something reasonable'', I'd say :-)
> > For the same reason, it is unnecessary to mention that a Lisp > > implementation better had a garbage collector. IIRC, The Definition > > of Standard ML doesn't make that requirement, either.
> That is right. And some ML implementations get away with having (well > almost) no garbage collector. (They are not the worst either.)
Let's say they're almost lacking :-)
Regards, -- Nils Goesche "Don't ask for whom the <CTRL-G> tolls."
Discussion subject changed to "Standards and deliberately silly implementation (was Re: Question on using Scheme on Large Projects)" by Michael Sullivan
Nils Goesche <car...@cartan.de> wrote: > You can have very long debates about whether an expression like > p = p->q = NULL; > invokes undefined behavior or not, but C programmers don't really > care, nor do implementors, nor do I: You do something reasonable, with > the standard as a guide. I'd see at first glance that this expression > is somewhat questionable, so, as a programmer, I'd not use it. As an > implementor, I'd make it work, anyway. Debating about whether the > standard explicitly allows or disallows this is a funny recreational > exercise, but not more. There will always be questions like this > (about C).
Personally, I have this odd little morbid fantasy about a C compiler that actually inserts code to dial the red phone any time unquestionably undefined behavior is invoked.
Michael, "I don't think you should do that, Dave"
-- Michael Sullivan Business Card Express of CT Thermographers to the Trade Cheshire, CT mich...@bcect.com
>> You can have very long debates about whether an expression like
>> p = p->q = NULL;
>> invokes undefined behavior or not, but C programmers don't really >> care, nor do implementors, nor do I: You do something reasonable, with >> the standard as a guide. I'd see at first glance that this expression >> is somewhat questionable, so, as a programmer, I'd not use it. As an >> implementor, I'd make it work, anyway. Debating about whether the >> standard explicitly allows or disallows this is a funny recreational >> exercise, but not more. There will always be questions like this >> (about C).
> Personally, I have this odd little morbid fantasy about a C compiler > that actually inserts code to dial the red phone any time unquestionably > undefined behavior is invoked.
I always like to point out the "electrodes in somebody's chair" scenario, myself.
It doesn't have to be a _big_ shock; it doesn't much matter who it is that _gets_ shocked, whether the programmer, user, some manager, or a cute furry bunny sitting in a cage. None are likely to be particularly palatable.
I normally bring up the scenario in a design meeting, when someone says "that'll never happen" about some condition that I notice.
"OK, if that condition can't happen, then it's OK for me to put code in that does absolutely heinous things if it does, right?"
They usually back off, at that point... -- (concatenate 'string "chris" "@cbbrowne.com") http://www3.sympatico.ca/cbbrowne/nonrdbms.html Rules of the Evil Overlord #173. "Although it would provide amusement, I will not confess to the hero's rival that I was the one who committed the heinous act for which he blames the hero." <http://www.eviloverlord.com/>
* Matthias Blume wrote: > Or are you saying that the > authors of the C standard generally assume the "best possible C > compiler permitted by the spec"? I didn't think so.
No, however they probably assume that a number of implementations will appear and the ones that are obviously crappy will either die out or get better. Curiously that is what seems to happen in practice, as anyone who compares, say, gcc, with some of (all of?) the pcc variants will tell you.
> > > Where does it say what it means to be "available for allocation"?
> > In Webster's dictionary, among others.
> Sorry, Erann, but I highly doubt that a definition of this phrase good > enough to stand up to the rigor of PL semantics can be found in > Webster's.
Sorry, Matthias, but your doubt is irrelevant. Whenever you write anything in English (as the C standard is) the semantics bottom out in the dictionary. You may not like it, but that's the way it is.
> The fact is that it is highly unspecified under which conditions > memory "returned" to the allocator via "free" will be dished out again > by a subsequent allocation. An allocator that makes memory > "avaliable" but then "chooses" to always return fresh memory anyway, > ignoring all that "available" memory returned via "free", would > probably not violate the letter (although perhaps the spirit) of the C > standard.
Unless you have an infinite amount of memory it would violate both the letter and the spirit, because it would eventually run out of fresh memory, at which point it would have no choice but to allocate free'd memory. If it didn't then that memory would not be "available", in violation of the standard.
There is nothing in either the letter of the spirit of the standard that requires the following function to return 1:
In article <gat-1508021417410...@192.168.1.52>, g...@jpl.nasa.gov (Erann Gat) writes:
> ... > Unless you have an infinite amount of memory it would violate both the > letter and the spirit, because it would eventually run out of fresh > memory, at which point it would have no choice but to allocate free'd > memory. If it didn't then that memory would not be "available", in > violation of the standard.
in that case any implementation of malloc/free that doesn't include a compacting garbage collector violates both the letter and the spirit of the C standard
> ... > but both the letter and the spirit of the standard require this snippet to > run forever (assuming no multiprocessing):
> void f() { > void *p; > while (1) { > p = malloc(10); > if (!p) return; > free(p); > } > }
* Hartmann Schaffer wrote: > void f( ) { > void *p1, *p2; > for( ; ; ) { > p1= malloc(10); > p2= malloc(15); > free(p1); > if(!p) return; } > will run out of memory at a point when almost half the available > memory is still free
If you have an allocator which allocates sequentially, it might, yes (assuming !p is !p2). If you have an allocator which, for instance, allocates chunks of 10 or smaller from 0 and ones of 11 or higher from high memory, this will not be true. In other words, don't be silly.
In article <3d5c4...@news.sentex.net>, h...@heaven.nirvananet (Hartmann
Schaffer) wrote: > In article <gat-1508021417410...@192.168.1.52>, > g...@jpl.nasa.gov (Erann Gat) writes: > > ... > > Unless you have an infinite amount of memory it would violate both the > > letter and the spirit, because it would eventually run out of fresh > > memory, at which point it would have no choice but to allocate free'd > > memory. If it didn't then that memory would not be "available", in > > violation of the standard.
> in that case any implementation of malloc/free that doesn't include a > compacting garbage collector violates both the letter and the spirit > of the C standard
[Code snipped]
No. This is just an oblique way of saying that C suffers from heap fragmentation, which is not news. All those freed 10-byte memory blocks are (or at least should be per the standard) still "available" to fill requests of size <= 10.
> don't use malice as an explanation when stupidity suffices
> > > > Where does it say what it means to be "available for allocation"?
> > > In Webster's dictionary, among others.
> > Sorry, Erann, but I highly doubt that a definition of this phrase good > > enough to stand up to the rigor of PL semantics can be found in > > Webster's.
> Sorry, Matthias, but your doubt is irrelevant. Whenever you write > anything in English (as the C standard is) the semantics bottom out in the > dictionary. You may not like it, but that's the way it is.
That's the problem with all semantics that are being specified in English: they are inherently ambiguous.
> > The fact is that it is highly unspecified under which conditions > > memory "returned" to the allocator via "free" will be dished out again > > by a subsequent allocation. An allocator that makes memory > > "avaliable" but then "chooses" to always return fresh memory anyway, > > ignoring all that "available" memory returned via "free", would > > probably not violate the letter (although perhaps the spirit) of the C > > standard.
> Unless you have an infinite amount of memory it would violate both the > letter and the spirit, because it would eventually run out of fresh > memory, at which point it would have no choice but to allocate free'd > memory. If it didn't then that memory would not be "available", in > violation of the standard.
That it false. "Available" could also mean that there is at least one allocation/deallocation sequence that causes the memory in question to be reused for allocation. But that one sequence does not have to be any of the ones that your program uses. In fact, there are many C programs that will eventually run out of memory using typical malloc/free implementations even though the malloc request that ends up failing asks for no more memory than what is currently "available". In fact, in typical flat address spaces, allocation of n bytes can fail even though Omega(n^2) bytes are "available". (Work it out!)
> There is nothing in either the letter of the spirit of the standard that > requires the following function to return 1:
IIRC, this program is in violation of the standard.
> but both the letter and the spirit of the standard require this snippet to > run forever (assuming no multiprocessing): > void f() { > void *p; > while (1) { > p = malloc(10); > if (!p) return; > free(p); > } > }
> E.
I very highly doubt that the letter of the standard requires this. (Otherwise, prove it!)
> > will run out of memory at a point when almost half the available > > memory is still free
> If you have an allocator which allocates sequentially, it might, yes > (assuming !p is !p2). If you have an allocator which, for instance, > allocates chunks of 10 or smaller from 0 and ones of 11 or higher from > high memory, this will not be true. In other words, don't be silly.
But Hartmann's first allocator is certainly a valid one according to the C standard. So what's your point?
* Matthias Blume wrote: > But Hartmann's first allocator is certainly a valid one according to > the C standard. So what's your point?
He said `... will run out of memory at a point ...' when he should have said either `... might run out of memory at a point ...' or `assuming an allocator with the following characteristics ... this program will run out of memory at a point ...'. So his statement was just false as it stood.
I'm beginning to think that cll has been invaded by aliens. Are you small and green with aerials on your head?
Matthias Blume <matth...@shimizu-blume.com> writes: > by a subsequent allocation. An allocator that makes memory > "avaliable" but then "chooses" to always return fresh memory anyway, > ignoring all that "available" memory returned via "free", would > probably not violate the letter (although perhaps the spirit) of the C > standard.
Possibly not even the spirit. On a machine that supports virtual memory, we could malloc, free, then malloc again and get what looks like fresh storage (at a different virtual address) that came from the same physical bank of chips that we were previously using. The program would have no way to tell it wasn't fresh, and we're still not "leaking memory in free"
For that matter, suppose malloc() calls mmap() and free() calls munmap(). Chances are that everything you allocate will the same physical pageful of zeroes anyway until you start wriing to it. How do you tell whether this is happening? Why do you need to?
I am deliberately ignoring the additional fun that can be had here from considering the effects of a hierarchical memory system (cache, dram, disk-based vm). Exercise for the reader ...
> > > Sorry, Erann, but I highly doubt that a definition of this phrase good > > > enough to stand up to the rigor of PL semantics can be found in > > > Webster's.
> > Sorry, Matthias, but your doubt is irrelevant. Whenever you write > > anything in English (as the C standard is) the semantics bottom out in the > > dictionary. You may not like it, but that's the way it is.
> That's the problem with all semantics that are being specified in > English: they are inherently ambiguous.
Yes, that's right. But it doesn't matter.
> > Unless you have an infinite amount of memory it would violate both the > > letter and the spirit, because it would eventually run out of fresh > > memory, at which point it would have no choice but to allocate free'd > > memory. If it didn't then that memory would not be "available", in > > violation of the standard.
> That it false. "Available" could also mean that there is at least one > allocation/deallocation sequence that causes the memory in question to > be reused for allocation. But that one sequence does not have to be > any of the ones that your program uses. In fact, there are many C > programs that will eventually run out of memory using typical > malloc/free implementations even though the malloc request that ends > up failing asks for no more memory than what is currently "available". > In fact, in typical flat address spaces, allocation of n bytes can fail > even though Omega(n^2) bytes are "available". (Work it out!)
That's right, too. But it doesn't matter, either.
> > There is nothing in either the letter of the spirit of the standard that > > requires the following function to return 1:
> IIRC, this program is in violation of the standard.
That's right, too, and it does matter :-) In this case, it is pretty easy to derive from the standard that the behavior of return p1 == p2; is undefined (although this statement sounds somewhat funny).
> > but both the letter and the spirit of the standard require this snippet to > > run forever (assuming no multiprocessing): > > void f() { > > void *p; > > while (1) { > > p = malloc(10); > > if (!p) return; > > free(p); > > } > > }
> I very highly doubt that the letter of the standard requires this. > (Otherwise, prove it!)
You're right, it doesn't require it, but it doesn't matter again.
You can't use the standard quotation in question to derive definite answers like this, that's right. But that doesn't mean that the snippet is meaningless.
You remind me of a mathematician reading a physics textbook or paper with the eyes of a mathematician. Whenever he sees that some physicist differentiates a function, his first thought is ``where did he say this function is differentiable?''. When the physicist differentiates again, he asks ``where did he say it was even C^2''? If the physicist computes the Fourier transform of a function he asks ``Wow, there are a million different spaces with a Fourier transform, which one is he using? Jeez, now he is assuming the inverse transformation can be applied; what a freak. Is he working in L^2? Ah, apparently he thinks he can exchange the limes and the integral sign. Enough now, I'll write him a letter explaining in all detail why all of his theories stink, and will make sure to provide him with counterexamples for /every single step/ he does in this paper! That will teach him a lesson!''
Unfortunately, the physicist will not appreciate the helpful letter. Actually, there is no problem at all with the physicist's mathematics. There /is/ a problem with the understanding of our /mathematician/, who hasn't understood that this physicist is not doing mathematics but physics. His /objectives/ are totally different. Using mathematics is only a means for him to achieve his real goal, which is to derive statements about the real world. Of course he is aware of the fact that mathematicians can come up with freaky counterexamples for lots of things, but his pragmatic reply is:
``Jeez, just make some _reasonable assumptions_ about my functions that rule out your stupid monster examples and try to understand what I am actually driving at!''
And this is exactly what reasonable mathematicians do who aren't utterly ignorant w.r.t. physics and the real world in general: They are aware of the fact that physicists simply aren't interested in writing mathematical papers. So, as it is nevertheless interesting what physicists do mathematically, there is a branch of mathematics that tries to find those ``reasonable assumptions'' that would render the physicist's mathematics correct even to our mathematician's eye. Often, whole new mathematical theories have to be invented to make it work. Sometimes, these new theories even prove useful to physicists, and they'll use them, too, in the future (usually after one or two generations).
So, saying ``The C standard sucks because it is full of ambiguities and even relies on something as wishy-washy as natural language.'' not only means getting on everybody's nerves by stating a triviality everybody knows, it is neither helpful to anybody nor constructive in any way. Yes, if theorists like you find out ways how to write standards for real-world languages that are less ambigious, without being as impenetrable for non-mathematicians as the SML definition, people will gladly accept them. But if that requires to use totally different languages whose major design goal is to produce neatly looking denotational or whatever semantics, people wouldn't be as happy anymore ;-)
Regards, -- Nils Goesche "Don't ask for whom the <CTRL-G> tolls."
> > > > > Where does it say what it means to be "available for allocation"?
> > > > In Webster's dictionary, among others.
> > > Sorry, Erann, but I highly doubt that a definition of this phrase good > > > enough to stand up to the rigor of PL semantics can be found in > > > Webster's.
> > Sorry, Matthias, but your doubt is irrelevant. Whenever you write > > anything in English (as the C standard is) the semantics bottom out in the > > dictionary. You may not like it, but that's the way it is.
> That's the problem with all semantics that are being specified in > English: they are inherently ambiguous.
Perhaps, but asking "where does it say what 'available' means?" is a rather oblique way of making that point.
Response #1: English specifications are not *inherently* ambiguous since mathematical specifications can be rendered in English.
Repsonse #2: mathematical specifications are also inherently ambigious. See David Deutch "The Fabric of Reality" chapter 10.
> > > The fact is that it is highly unspecified under which conditions > > > memory "returned" to the allocator via "free" will be dished out again > > > by a subsequent allocation. An allocator that makes memory > > > "avaliable" but then "chooses" to always return fresh memory anyway, > > > ignoring all that "available" memory returned via "free", would > > > probably not violate the letter (although perhaps the spirit) of the C > > > standard.
> > Unless you have an infinite amount of memory it would violate both the > > letter and the spirit, because it would eventually run out of fresh > > memory, at which point it would have no choice but to allocate free'd > > memory. If it didn't then that memory would not be "available", in > > violation of the standard.
> That it false. "Available" could also mean that there is at least one > allocation/deallocation sequence that causes the memory in question to > be reused for allocation.
No it couldn't. And that's a rather cheeky claim to make when by your own admission you haven't even bothered to read what the standard (the dictionary in this case) has to say about it.
> In fact, there are many C > programs that will eventually run out of memory using typical > malloc/free implementations even though the malloc request that ends > up failing asks for no more memory than what is currently "available". > In fact, in typical flat address spaces, allocation of n bytes can fail > even though Omega(n^2) bytes are "available". (Work it out!)
You are simply making the observation (again, obliquely) that heaps can fragment. So what? Everyone knows this.
> > There is nothing in either the letter of the spirit of the standard that > > requires the following function to return 1:
> IIRC, this program is in violation of the standard.
You know, Matthias, I make it a point to read everything you post to c.l.l. and c.l.s. because 99% of the time what you have to say is worthwhile and I learn a lot. But in this case I am becoming convinced that you don't really have a point to make here and are just intentionally being a jerk. This is legal C++ code, and it takes no great leap of the imagination to render it into legal C.
> I very highly doubt that the letter of the standard requires this. > (Otherwise, prove it!)
It's an informal standard so I can't "prove" anything about it in the way that you probably mean here. But again, your doubt is irrelevant. The way you "prove" this is to write a malloc/free implementation that doesn't have this property and see if people accept it. The semantics of informal standards (like natural language) are determined by consensus. Within the community of C programmers there is consensus on this point. I can't prove this, but if you go talk to C programmers (and I mean C programmers, not wise-guy ML programmers who just happen to know C) you will find that it is so.
BTW, there's a fine illustration of the slipperiness of even formal standards in a recent thread on c.l.s. that you yourself were involved in regarding the semantics of (call/cc (lambda (c) (0 (c 1)))). The formal semantics say unambiguously (once you go through the considerable trouble to work it out) that the value of this expression in Scheme is 1. Nonetheless, many Scheme implementations signal an error. The debate over which of these behaviors is "correct" raged on for weeks and was never resolved.
* Nils Goesche wrote: > Unfortunately, the physicist will not appreciate the helpful letter. > Actually, there is no problem at all with the physicist's > mathematics. There /is/ a problem with the understanding of our > /mathematician/, who hasn't understood that this physicist is not > doing mathematics but physics. His /objectives/ are totally > different. Using mathematics is only a means for him to achieve his > real goal, which is to derive statements about the real world. Of > course he is aware of the fact that mathematicians can come up with > freaky counterexamples for lots of things, but his pragmatic reply is: > ``Jeez, just make some _reasonable assumptions_ about my functions > that rule out your stupid monster examples and try to understand what > I am actually driving at!''
This is one of the best articles I've read in cll for a long time. Sometimes even threads as dire as this one will result in gems like this: thanks.
Everyone who cares about programming should understand the culture that drives physics, and why it is so brilliantly successful. C and Common Lisp are both languages defined the physics way, and it's a *good* way of defining language. Of course it's not the only way (no one claims it is), but the formal semantics way of defining languages is *definitely* not the only way, despite what it's adherents might think, and it's also not empirically a very successful way.
There's a story about theoretical physicists, who can be read here as almost-mathematicians:
A theoretical physicist was asked to compute the stability of an ordinary, four-legged table. He rapidly arrived at preliminary results concerning the stability of zero- and one-legged tables, and of those with an infinite number of legs. He spent the rest of his life trying to arrive at a general result for the stability of a table with an arbitrary, finite number of legs.
(of course, the mathematician would have been stressing about whether the infinite number of legs was countable or not.)
* Matthias Blume | That's the problem with all semantics that are being specified in | English: they are inherently ambiguous.
No, that is not the problem. If they were /inherently/ ambiguous, that would imply that the writer meant several things at the same time. Such is normally not the case with specifications, which are neither poetry nor puns. That only one things is meant is pretty darn obvious. Therefore, the ambiguity is found in the reader's intent to find it.
What we cannot do, is write such that nobody, given enough energy, could not find that it could also mean something other than what you intended. Some people on news make this a sport, thinking that it shows their intellectual prowess to first find the intended meaning and then hunt for a second meaning that would be idiotic to hold, in order to pretend that this is the writer's fault. Be advised that you are up against one such semantic game artist.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
* Nils Goesche wrote: > Unfortunately, the physicist will not appreciate the helpful letter. > Actually, there is no problem at all with the physicist's > mathematics. There /is/ a problem with the understanding of our > /mathematician/, who hasn't understood that this physicist is not > doing mathematics but physics. His /objectives/ are totally > different. Using mathematics is only a means for him to achieve his > real goal, which is to derive statements about the real world. Of > course he is aware of the fact that mathematicians can come up with > freaky counterexamples for lots of things, but his pragmatic reply is: > ``Jeez, just make some _reasonable assumptions_ about my functions > that rule out your stupid monster examples and try to understand what > I am actually driving at!''
This is one of the best articles I've read in cll for a long time. Sometimes even threads as dire as this one will result in gems like this: thanks.
Everyone who cares about programming should understand the culture that drives physics, and why it is so brilliantly successful. C and Common Lisp are both languages defined the physics way, and it's a *good* way of defining language. Of course it's not the only way (no one claims it is), but the formal semantics way of defining languages is *definitely* not the only way, despite what its adherents might think, and it's also not empirically a very successful way.
There's a story about theoretical physicists, who can be read here as almost-mathematicians:
A theoretical physicist was asked to compute the stability of an ordinary, four-legged table. He rapidly arrived at preliminary results concerning the stability of zero- and one-legged tables, and of those with an infinite number of legs. He spent the rest of his life trying to arrive at a general result for the stability of a table with an arbitrary, finite number of legs.
(of course, the mathematician would have been stressing about whether the infinite number of legs was countable or not.)
