From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10a146,a03ae7f4e53958e1 X-Google-Attributes: gid10a146,public X-Google-Thread: fac41,a03ae7f4e53958e1 X-Google-Attributes: gidfac41,public X-Google-Thread: 114809,a03ae7f4e53958e1 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,8775b19e3c68a5dc X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,a03ae7f4e53958e1 X-Google-Attributes: gid1014db,public X-Google-Thread: 1094ba,a03ae7f4e53958e1 X-Google-Attributes: gid1094ba,public X-Google-Thread: fa0ae,a03ae7f4e53958e1 X-Google-Attributes: gidfa0ae,public X-Google-Thread: 109fba,a03ae7f4e53958e1 X-Google-Attributes: gid109fba,public From: bill@cafe.net (Kaz Kylheku) Subject: Re: Which language pays most? Smalltalk, not C++ nor Java. Date: 1997/12/29 Message-ID: <688u1a$j7d$1@brie.direct.ca>#1/1 X-Deja-AN: 311103654 References: <199712121931.LAA25389@sirius.infonex.com> <34A50CAA.54AA@netup.cl> <34A7B45C.403B@min.net> Organization: Internet Direct Reply-To: kaz@cafe.net Newsgroups: comp.lang.fortran,comp.lang.c,comp.lang.c++,comp.lang.eiffel,comp.lang.java.programmer,comp.lang.smalltalk,comp.lang.perl.misc,comp.lang.ada,comp.edu Date: 1997-12-29T00:00:00+00:00 List-Id: In article <34A7B45C.403B@min.net>, John Porter wrote: >Robert Dewar wrote: >> OK, so your compiler can compile memfoo without compiling. Wunderbar! But >> that does NOT mean that you can actually go ahead and call a routine memfoo >> if the standard forbids it. To do so would be incompetent programming. > >So now a "language" is not defined by the compiler -- or even by the >preprocessor+compiler+linker+etc, as some have it... >I am forbidden by a piece of paper from calling a function 'memfoo'! That piece of paper, as you say, doesn't forbid any such thing! It merely states that all bets are off if you do that, because the identifier belongs to a reserved name space. What is important is not what the paper forbids, but what it allows! It allows an actual implementation to forbid you from calling an external function by a reserved name. What's worse, it allows an implementation to behave unpredictably. Go ahead! Break the rules! Ignore the paper! You will look foolish in the end.