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=3.8 required=5.0 tests=BAYES_00,INVALID_MSGID, RATWARE_MS_HASH,RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public From: "Vassili Bykov" Subject: Re: Exceptions as objects (was Re: What is wrong with OO ?) Date: 1997/02/07 Message-ID: <01bc1513$e030fcc0$752d54c7@vbykov.hip.cam.org>#1/1 X-Deja-AN: 215115019 references: <5acjtn$5uj@news3.digex.net> <32dd9fc8.262114963@news.sprynet.com> <5cu43v$jkn@nntpa.cb.lucent.com> <5d93d3$nhs$1@goanna.cs.rmit.edu.au> <5dds5b$gcs@mulga.cs.mu.OZ.AU> <01bc14ab$3ce476e0$752d54c7@vbykov.hip.cam.org> <5def36$rjd@mulga.cs.mu.OZ.AU> organization: Communications Accessibles Montreal, Quebec Canada newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-02-07T00:00:00+00:00 List-Id: Fergus Henderson wrote in article <5def36$rjd@mulga.cs.mu.OZ.AU>... > "Vassili Bykov" writes: > > [...] > >Control constructs cannot *in principle* be a part of the standard library. > > Sure they can. Consider tcl, for example. Oops, sorry I jumped it--in the post I replied to, Kenneth Almquist was talking about Ada and C++ so I assumed "regular" languages with applicative-order evaluation. In these, they cannot because functions always evaluate arguments. For control constructs you would either need lazy as in Haskell or syntactially transparent delayed as in Smalltalk evaluation. (Or... hmm... weird? as in Tcl. :-) > >(Unless you take Lisp or Scheme and consider macros as part of the > >library--which, strictly speaking, they are not). > > Why aren't they? What *in principle* reason is there why they can't be? Because macros are AST (or token stream, in lesser languages) transformation rules known to the compiler. Libraries are collections of machine (or virtual machine) code blocks to be called by the application program. In other words, macros extend the compiler while library routines extend the apllication program. That's the "strictly speaking" reason I meant. I didn't mean to be dense--I said that only because if we extend the meaning of "standard library" to include standard macros always known to the compiler then what is the difference between "part of the library" and "part of the language"? --Vassili