day@grand.UUCP (Dave Yost) (10/15/88)
The USENIX C++ Conference is coming up next week. As the person who instigated the first USENIX C++ Conference/Workshop last year, and, in its early stages, this conference, I want to tell you why last June I bowed out of my involvement with the upcoming conference. I pulled away from the C++ conferences because I became disenchanted with C++. I used to be enthusiastic about C++ because it offered new and wonderful expressive power in the form of object-oriented programming features with the implication that by providing these features as extensions to C, we can easily build on what we already know and ease into new power. Sounds nice, but it doesn't seem to work that way. C++ continues to amaze me with how hairy and complex it is. I want a higher level language that is easy to read, relieves me of details, and lets me get on with the problem level. I don't see C++ answering that desire. Yes, strongly-typed object orientation seems like the right direction, but it can be a lot nicer than C++. --dave yost
crovella@sunybcs.uucp (Mark Crovella) (10/17/88)
In article <441@grand.UUCP> day@grand.UUCP (Dave Yost) writes: > >[...] I pulled away from the C++ >conferences because I became disenchanted with C++. > >[...] C++ continues to amaze me with how hairy and >complex it is. I want a higher level language that >is easy to read, relieves me of details, and lets >me get on with the problem level. I don't see C++ >answering that desire. > >Yes, strongly-typed object orientation seems like >the right direction, but it can be a lot nicer than >C++. > > --dave yost Dave's observations are on target; however, I am not sure that his conclusions necessarily follow. Our experience with C++ on a medium sized project (5000 lines) is that (a) most of the expected benefits of object orientation *do* accrue and (b) a number of new problems crop up. These problems are primarily associated with readability and comprehesibility. For example: 1. It can take a while to determine which virtual function will be invoked when the class hierarchy is deep. 2. Constructor and destructor side-effects can be confusing, e.g., when unrelated to the class itself. These are minor points, but the overall result seems to be a perception that the language is a bit "hairy". As for Dave's conclusion (i.e., a disassociation between himself and C++), I think that in large part this may not be the fault of C++, but rather in the toolset we use and in the orientation we have to programming in C++. The problems we have had using C++ would be well solved through the use of a more comprehensive programming environment for the language. I propose a discussion of the necessary, appropriate, and/or ideal tools and techniques for C++ programming. For example, a tool to resolve virtual function scoping dynamically. A "Flavor Inspector" -- a class examination tool. An object inspector. A dynamic debugger which runs C++ interpretively. etc. The questions Dave raises are important -- I think it would be interesting to hear people's views on them. Mark Crovella "Reflect, ponder, excogitate, reply." - J.Joyce uucp: ..!{ames,boulder,decvax,rutgers}!sunybcs!crovella internet: crovella@cs.buffalo.edu bitnet: crovella@sunybcs.bitnet
wetter@cit-vax.Caltech.Edu (Pierce T. Wetter) (10/18/88)
What most OOL that I've used desperatly need is an object X-refer, espcially a graphic one. Even in my own code its often difficult to remember what is a subclass of what. That is what makes OO code so difficult to read in some cases. Pierce
ttey@mulga.oz (YEO Tee Thiam Eric) (10/18/88)
in article <2010@cs.Buffalo.EDU>, crovella@sunybcs.uucp (Mark Crovella) says: > These are minor points, but the overall result seems to be a perception > that the language is a bit "hairy". I agree. I strongly believe that a language should be as simple as possible for 2 reasons: (a) a compiler/preprocessor can easily be constructed and possibly proven correct, (b) it is easier to formalise the semantics of the language and remove ambiguity. In the case of C++, the syntax of the language is, in my opinion, too complicated. It is so complex that it has been said that to parse C++ correctly, a recursive decent parser with an infinite look ahead and some heuristics is required (I believed it was mentioned in some documentation for GNU G++). > As for Dave's conclusion (i.e., a disassociation between himself and C++), > I think that in large part this may not be the fault of C++, but rather > in the toolset we use and in the orientation we have to programming in C++. > The problems we have had using C++ would be well solved through the use > of a more comprehensive programming environment for the language. > > I propose a discussion of the necessary, appropriate, and/or ideal > tools and techniques for C++ programming. > For example, a tool to resolve virtual function scoping dynamically. > A "Flavor Inspector" -- a class examination tool. An object inspector. > A dynamic debugger which runs C++ interpretively. etc. > > The questions Dave raises are important -- I think it would be interesting > to hear people's views on them. A good programming environment similar to that of Smalltalk would certainly be nice. (Much feasibility studies need to be done on this since C++ is a static language compared to Smalltalk.) However, I generally found that when programming in C++, people tend to be carried away with object-orientedness of the language; using derived classes, etc, etc at every opportunity to model things that are better left as structures. Object-oriented programming is a paradigm. We are now finding more and more ways of using this paradigm to model our problems. C++ helps in acheiving this but it is by no means the best and only way of programming. I believe that the essence of object- oriented programming is in choosing what to be modelled as objects and what to be treated as pure data structure. Eric Yeo
jnp@calmasd.GE.COM (John Pantone) (10/18/88)
(Dave Yost) writes: >[...] I pulled away from the C++ >conferences because I became disenchanted with C++. >[...] C++ continues to amaze me with how hairy and >complex it is. >[...] Yes, strongly-typed object orientation seems like >the right direction, but it can be a lot nicer than >C++. (Mark Crovella) writes: >Dave's observations are on target; >... >The questions Dave raises are important -- I think it would be interesting >to hear people's views on them. Sorry Mark, I can't agree - Dave's comments seem naive to me, not important. I would absolutely love to have a nickle for each new programmer who completely missed the point of C and by implication C++. The unmatched expressiveness and flexibility of C and C++ are, at once, their greatest asset and their greatest drawback. C and its extension C++ allow for extremely compact and powerful code, while extracting care and deliberation from the programmer. Simplified (read less expressive) syntax and strong (read less flexible) typing are fine, as far as they go, but they are no "better" and surely are less powerful than the relatively low-level C and C++ languages. There is no point in C/C++ bashing - if you can't stand the heat, get out of the kitchen - there are higher-level languages which will cater to your needs. -- These opinions are solely mine and in no way reflect those of my employer. John M. Pantone @ GE/Calma R&D, 9805 Scranton Rd., San Diego, CA 92121 ...{ucbvax|decvax}!sdcsvax!calmasd!jnp jnp@calmasd.GE.COM GEnie: J.PANTONE
robert@pvab.UUCP (Robert Claeson) (10/19/88)
In article <441@grand.UUCP>, day@grand.UUCP (Dave Yost) writes: > Yes, strongly-typed object orientation seems like > the right direction, but it can be a lot nicer than > C++. Funny, I had the same feelings and read Bertrand Meyer's book about Eiffel. Seems to me like one of the best oo languages available today. -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden Tel: +46 758-202 50 Fax: +46 758-197 20 Email: robert@pvab.se (soon rclaeson@erbe.se)
halldors@paul.rutgers.edu (Magnus M Halldorsson) (10/19/88)
In article <3006@mulga.oz> ttey@mulga.oz (YEO Tee Thiam Eric) writes: > In the case of > C++, the syntax of the language is, in my opinion, too complicated. > It is so complex that it has been said that to parse C++ correctly, > a recursive decent parser with an infinite look ahead ... The syntax of C++ is not *complicated*. It isn't really any more difficult to understand than plain C, however, it is somewhat harder to parse. The complexity is in the semantics: No longer func() a single function, but could refer to any one of zillion, confused by class hierarchy, inheritance rules and coercions. A sixpack of tools to handle such trivia would be useful. Magnus
baud@gt-eedsp.UUCP (Kurt Baudendistel) (10/19/88)
In article <3006@mulga.oz> ttey@mulga.oz (YEO Tee Thiam Eric) writes: >It is so complex that it has been said that to parse C++ correctly, >a recursive decent parser with an infinite look ahead and some >heuristics is required (I believed it was mentioned in some >documentation for GNU G++). interestingly enough, the g++ documentation states that [t]he design of the C++ programming language did not take into account the usefulness of being able to specify that language using an LALR(1) grammar. As a resut, in order to correctly parse it, one needs a look-ahead lexical analyzer (with infinite lookahead), and a recursive descent parser, guided by some good heuristics. which supports this conjecture. however, the documentation goes on to state that ... in providing such a grammar [LALR(1) as g++ actually does], some syntactic forms were lost, most notably old-style C function declarations and occasionally function parameters which are declared longhand to be pointers to functions are not recognized properly. the forms that need to be modified are standard c forms, but c++ was designed to be c compatible. there's the rub. with all of this c++ bashing, what is my alternative (realistically) for a programming langugage that provides the c++ power of abstraction and the efficiency of c? -- Kurt Baudendistel [GRA McClellan] Georgia Tech, School of Electrical Engineering, Atlanta, GA 30332 USENET: ...!{allegra,hplabs,ihnp4,ulysses}!gatech!gt-eedsp!baud INTERNET: gt-eedsp!baud@gatech.edu
mjj@acornrc.UUCP (Mick Jordan) (10/20/88)
In article <441@grand.UUCP> day@grand.UUCP (Dave Yost) writes: > >Sounds nice, but it doesn't seem to work that >way. C++ continues to amaze me with how hairy and >complex it is. I want a higher level language that >is easy to read, relieves me of details, and lets >me get on with the problem level. I don't see C++ >answering that desire. > >Yes, strongly-typed object orientation seems like >the right direction, but it can be a lot nicer than >C++. > > --dave yost (To avoid controversy I didn't originally post this here, but in case Dave is not alone, here is a possible alternative to C++.) Modula-3 Announcement The following (long) message contains the Acknowledgments, Overview and References from the Modula-3 Report (hence the copyright notice). It should provide adequate information on what Modula-3 is and how it came about. Copies of the report are available from either DEC Systems Research Center, 130 Lytton Ave, Palo Alto California 93401 or Olivetti Research Center, 2882 Sand Hill Road, Menlo Park California 94025. E-mail requests are acceptable to src-reports@decwrl or librarian@orc.olivetti.com. Olivetti Research Center is currently doing an exploratory implementation of the language. This comprises a compiler front-end, AST-based interpreter and debugger, and a code-generator which generates C. This is implemented in a mixture of Modula-2+, C and IDL and runs on a Sun-3. We expect to finish this phase in a month or so. There are no plans for distribution at present (it would be strictly for evaluation and on an as-is basis) but we are interested in measuring the level of interest. --Mick Jordan (mjj@orc.olivetti.com, mjj@acornrc.uucp) ----------------------------cut here---------------------------------------- Copyright 1988 Digital Equipment Corporation, Ing. C. Olivetti and C., SpA. This work may not be copied or reproduced in whole or in part for any commercial purpose. Permission to photocopy in whole or in part without payment of fee is granted for nonprofit educational and research purposes provided that all such copies include the following: a notice that such copying is by permission of the Systems Research Center of Digital Equipment Corporation in Palo Alto, California and the Olivetti Research Center of Ing. C. Olivetti and C., SpA in Menlo Park, California; an acknowledgment of the authors and individual contributors to the work; and all applicable portions of the copyright notice. All rights reserved. The right to implement or use the Modula-3 language is unrestricted. Acknowledgments Modula-3 was designed by Luca Cardelli, Jim Donahue, Mick Jordan, Bill Kalsow, and Greg Nelson, as a joint project by the Digital Systems Research Center and the Olivetti Research Center. Paul Rovner made many contributions as a founding member of the design committee, but cannot be held responsible for the final product. Our starting point was Modula-2+, which was designed by Paul Rovner, Roy Levin, John Wick, Andrew Birrell, Butler Lampson, and Garret Swart. We benefited from the ruthlessly complete description of Modula-2+ provided in Mary-Claire van Leunen's Modula-2+ User's Manual. Niklaus Wirth made valuable suggestions and inspired us with the courage to throw things out. He also designed Modula-2, the starting point of our starting point. We thank the following people for their helpful feedback: Bob Ayers, Andrew Black, David Chase, Dan Craft, Hans Eberle, John Ellis, Jim Horning, Mike Kupfer, Butler Lampson, Lyle Ramshaw, Eric Roberts, Ed Satterthwaite, Jorge Stolfi, and Garret Swart. This report was written by Lucille Glassman and Greg Nelson, under the watchful supervision of the whole committee. 1. Overview Modula-3 descends from Mesa [8], Modula-2 [12], Cedar [5], and Modula-2+ [9, 10]. It also resembles its cousins Object Pascal [11], Oberon [13], and Euclid [6]. Since these languages already have more raw material than fits comfortably into a readable fifty-page language definition, which we were determined to produce, we didn't need to be inventive. On the contrary, we had to leave many good ideas out. One of our main goals was to provide safety from unchecked runtime errors---forbidden operations that invalidate an invariant of the runtime system and lead to an unpredictable computation. A classic unchecked runtime error is to free a record to which active references remain. To avoid this danger, Modula-3 follows Cedar, Modula-2+, and Oberon by automatically freeing unreachable records. To allow both garbage collection and low-level systems programming, Modula-3 provides both traced and untraced references. Another well-known unchecked runtime error is to assign to the tag of a variant record in a way that subverts the type system. Distinguishing subversive assignments from benign assignments in the language definition is error-prone and arbitrary. The objects and classes first introduced by Simula [2] and adopted in Oberon and Object Pascal are more general than variant records, and they are safe, so we have discarded variant records and adopted objects. In Modula-3, all objects are references. Generally the lowest levels of a system cannot be programmed with complete safety. Neither the compiler nor the runtime system can check the validity of a bus address for an IO controller, nor can they limit the ensuing havoc if it is invalid. This presents the language designer with a dilemma. If he holds out for safety, then low level code will have to be programmed in another language. But if he adopts unsafe features, then his safety guarantee becomes void everywhere. In this area we have followed the lead of Cedar and Modula-2+ by adopting a small number of unsafe features that are allowed only in modules that are explicitly labeled unsafe. In a safe module, the compiler guarantees the absence of unchecked runtime errors; in an unsafe module, it is the programmer's responsibility to avoid them. From Mesa and Modula-2 we adopted modules, which are separate program units with explicit interfaces, and abstract (or opaque) types, which hide the representation of a type from client modules that use the type. In Modula-3, as in some implementations of Modula-2, variables with opaque types must be references. If the hidden representation changes but the interface remains the same, client modules will not need to be reprogrammed, or even recompiled. From Modula-2+ we adopted exceptions and threads. An exception exits all procedure call levels between the point at which it is "raised" and the point at which it is "handled". Exceptions are a good way to handle any runtime error that is not necessarily fatal. The alternative is to use error return codes, but this has the drawback that programmers don't consistently test for them. In the Unix/C world, the frequency with which programs omit tests for error returns has become something of a standing joke. Instead of breaking at an error, too many programs continue on their unpredictable way. Raising an exception is a better approach, since it will stop the computation unless there is an explicit handler for it. A thread is a "light-weight process". The threads interface provides a simplified version of the Mesa extensions to Hoare's monitors [1, 3, 7]. Waiting, signaling, and locking a monitor have Hoare's semantics, but the requirement that a monitored data structure be an entire module is relaxed: it can be an individual record or any set of variables instead. The programmer is responsible for acquiring the appropriate lock before accessing the monitored data. 1.1. Common notions A Modula-3 program specifies a computation that acts on a sequence of digital components called locations. A variable is a set of locations that represents a mathematical value according to a convention determined by the variable's type. If a value can be represented by some variable of type T, then we say that the value is a member of T and T contains the value. Assignability and type compatibility are defined in terms of a single syntactically-specified subtype relation with the property that if T is a subtype of U, then every member T is a member of U. An identifier is a symbol declared as a name for a variable, type, procedure, etc. The region of the program over which a declaration applies is called the scope of the declaration. Scopes can be nested. The meaning of an identifier is determined by the smallest enclosing scope in which the identifier is declared. An expression specifies a computation that produces a value or variable. Every expression has a statically-determined type, which contains every value that can be produced by the expression. In particular, literals have types; for example, the type of "6" is INTEGER (not [6..6]). Expressions whose values can be determined statically are called constant expressions. Expressions that produce variables are called designators. The type of a designator is the type of the variable it produces. A designator is writable if it can be used in contexts that require mutable variables and readonly otherwise. Every expression has a unique type, but a value can be a member of many types. For example, 6 is a member of both [0 .. 9] and INTEGER. Thus the phrase "type of x" means "type of the expression x", while "x is a member of T" means "the value of x is a member of T". But there is one case in which one of the types that contain a value is distinguished: when a traced reference or object is allocated it is tagged with a type, which we call the allocated type of the reference value. The type denoted by a type name never changes at runtime, and is usually determined at compile time. But a type name can be opaque in a scope, which means that it denotes a reference type with an unknown referent type. A type name that is not opaque is concrete. A concrete type is determined at compile time (except for the referent types of opaque types that occur within it). Types are distinct until proven identical. For example, variables with types T and U would not be assignable in a scope where T and U are both opaque, but would be assignable in any scope where T and U are identified with the same concrete type. A type is empty if it contains no values. For example, [1..0] is an empty type. Empty types can be used to build non-empty types (for example, SET OF [1..0], which is not empty because it contains the empty set). It is illegal to declare a variable of an empty type. A static error is an error that the implementation must detect before program execution. Violations of the language definition are static errors unless they are explicitly classified as runtime errors. A checked runtime error is an error that the implementation must detect and report at runtime. The method for reporting such errors is implementation-dependent. (If the implementation maps them into exceptions, then a program could handle these exceptions and continue.) An unchecked runtime error is an error that is not guaranteed to be detected, and can cause the subsequent behavior of the computation to be arbitrary. Unchecked runtime errors can occur only in unsafe modules. 1.2. Required interfaces An implementation of Modula-3 must include implementations of the interfaces Text, Thread, Word, and Fmt. The first three provide elementary operations on text strings, concurrent threads of control, and "words", which represent bit vectors or unsigned integers. The Fmt interface provides procedures for formatting numbers and other data as text. The full name of an entity is the name of its interface followed by a dot and its name in that interface. The principal type in an interface is usually named T. Thus Text.T is the type for text strings, Thread.T is the type for threads, and Word.T is the type for words. References [1] A.D. Birrell, J.V. Guttag, J.J. Horning, R. Levin. Synchronization Primitives for a Multiprocessor: A Formal Specification. Operating Systems Review 21(5), November 1987. Also published as SRC Research Report 20, August 1987. [2] Graham M. Birtwistle, Ole-Johan Dahl, Bjorn Myhrhaug, and Kristen Nygaard. Simula Begin. Auerbach, Philadelphia PA, 1973. [3] C.A.R. Hoare. Monitors: An Operating System Structuring Concept. Communications of the ACM 17(10), October 1974. [4] Daniel Jackson and Jim Horning. The Modula-2+ Text Interface. Unpublished manuscript available from Jim Horning at SRC. [5] Butler W. Lampson. A Description of the Cedar Language. Technical Report CSL-83-15, Xerox Palo Alto Research Center, December 1983. [6] Butler W. Lampson, James J. Horning, Ralph L. London, James G. Mitchell, and Gerald J. Popek. Report on the Programming Language Euclid. Technical Report CSL-81-12, Xerox Palo Alto Research Center, October 1981. [7] Butler W. Lampson and David D. Redell. Experience with Processes and Monitors in Mesa. Communications of the ACM 23(2), February 1980. [8] James G. Mitchell, William Maybury, and Richard Sweet. Mesa Language Manual. Technical Report CSL-78-1, Xerox Palo Alto Research Center, February 1978. [9] Paul Rovner, Roy Levin, and John Wick. On Extending Modula-2 For Building Large, Integrated Systems. Technical Report 3, Digital Systems Research Center, January 1985. [10] Paul Rovner. Extending Modula-2 to Build Large, Integrated Systems. IEEE Software 3(6), November 1986. [11] Larry Tesler, Apple Computers. Object Pascal Report. Structured Language World 9(3), 1985. [12] Niklaus Wirth. Programming in Modula-2. Springer-Verlag, Third Edition, 1985. [13] N. Wirth. From Modula to Oberon and The Programming Language Oberon. Technical Report 82, Institut fur Informatik, ETH Zurich, September 1987.
exodus@mfgfoc.uucp (Greg Onufer) (10/20/88)
From article <535@gt-eedsp.UUCP>, by baud@gt-eedsp.UUCP (Kurt Baudendistel): > with all of this c++ bashing, what > is my alternative (realistically) for a programming langugage that provides > the c++ power of abstraction and the efficiency of c? I called the original poster to ask him a few questions... one of them being the question stated above.... Apparently the answer is Eiffel. I still have the materials on Eiffel that I received at Usenix in SF... Looks good. Too expensive for me to try though. --Greg
shankar@hpclscu.HP.COM (Shankar Unni) (10/22/88)
an LALR(1) grammar. As a resut, in order to correctly parse it,
one needs a look-ahead lexical analyzer (with infinite lookahead),
and a recursive descent parser, guided by some good heuristics.
You don't necessarily need an infinite-lookahead lexical analyzer or
heuristics or anything, if you can do one thing in the lexer: recognize
typedef names IMMEDIATELY, and use a different token for typedef names.
Right away, you have a grammar which can easily be made LALR(1). The trick
is to do the typedef recognition. This needs some smarts in the parser. A
YACC grammar for C can, for instance, store the names of identifiers in
typedef declarations in some scoped table (naturally, it also has to do
some scope manipulation..), and the lexer can look up an identifier in this
table. The scoping is necessary because typedef names can be overriden by
variable declarations inside nested blocks, and the parser must understand
this.
And this is not necessarily complex or slow. It can be done quite
efficiently if a certain amount of care goes into the design.
--
Shankar ("do you want fast or correct :-)")daveb@gonzo.UUCP (Dave Brower) (10/23/88)
In article <328@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes: >Funny, I had the same feelings and read Bertrand Meyer's book about >Eiffel. Seems to me like one of the best oo languages available today. With the (possible) exception of Ada, the main thing that gets people to move towards a new language is the availability of a cheap workable implementation. C came with your Unix system, C++ has the cheap site license and a free G++. Eiffel, which looks interesting, has one implementation, a real-priced commericial product. The same is basically true of Euclid, which 5 years ago looked as interesting as Modula-2. Modula-3, for which we've just seen some propaganda, is also not available. AT&T did a very smart thing with c++, getting a seed implementation out cheaply to build a core user base. Others might take a lesson. -dB
mball@cod.NOSC.MIL (Michael S. Ball) (10/24/88)
In article <Oct.19.01.36.36.1988.9013@paul.rutgers.edu> halldors@paul.rutgers.edu (Magnus M Halldorsson) writes: >In article <3006@mulga.oz> ttey@mulga.oz (YEO Tee Thiam Eric) writes: > >> It is so complex that it has been said that to parse C++ correctly, >> a recursive decent parser with an infinite look ahead ... > >The syntax of C++ is not *complicated*. It isn't really any more >difficult to understand than plain C, however, it is somewhat harder >to parse. The complexity is in the semantics:... Let's get a couple of facts straight. 1. C++ does not require recursive descent (or any other particular technique) for parsing. 2. Parsing does require an indefinite (not infinite) lookahead to resolve certain cases. In my opinion, the cases where confusion may arise are uncommon and do not appear to cause any great difficulty with the language. C++ is complex, but parsing difficulties do not seem to contribute much to that complexity. Mike Ball TauMetric Corporation 1094 Cudahy Place, Ste 302 San Diego, CA 92110 (619)275-6381
shap@polya.Stanford.EDU (Jonathan S. Shapiro) (10/24/88)
In article <1000004@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: >You don't necessarily need an infinite-lookahead lexical analyzer or >heuristics or anything, if you can do one thing in the lexer: recognize >typedef names IMMEDIATELY, and use a different token for typedef names. Unfortunately, there are places where you cannot correctly determine that a name should be introduced into the typedef table without infinite lookahead. Jon
bright@Data-IO.COM (Walter Bright) (10/25/88)
In article <1000004@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: < an LALR(1) grammar. As a resut, in order to correctly parse it, < one needs a look-ahead lexical analyzer (with infinite lookahead), < and a recursive descent parser, guided by some good heuristics. <You don't necessarily need an infinite-lookahead lexical analyzer or <heuristics or anything, if you can do one thing in the lexer: recognize <typedef names IMMEDIATELY, and use a different token for typedef names. Hmm, try this one: int abc() { return sizeof( int (********p)[5]); } Until the [ is discovered, there are two possible parse trees, one is an abstract type and the other is a cast to int.
andyk@infmx.UUCP (Andy Kashyap) (10/27/88)
In article <4634@polya.Stanford.EDU> shap@polya.Stanford.EDU (Jonathan S. Shapiro) writes: - In article <1000004@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: - >You don't necessarily need an infinite-lookahead lexical analyzer or - >heuristics or anything, if you can do one thing in the lexer: recognize - >typedef names IMMEDIATELY, and use a different token for typedef names. - - Unfortunately, there are places where you cannot correctly determine - that a name should be introduced into the typedef table without - infinite lookahead. - - Jon Furthurmore, if you try to immediately recognize a token in lexer, you also immediately lose the context ... unless you want to pass lex the context; but that's what the parser does. Hmmm, did I just paraphrase Shapiro?? - andy kashyap @ Informix (415) 322-4100 x685
robert@pvab.UUCP (Robert Claeson) (10/30/88)
In article <442@gonzo.UUCP>, daveb@gonzo.UUCP (Dave Brower) writes: > With the (possible) exception of Ada, the main thing that gets people to > move towards a new language is the availability of a cheap workable > implementation. C came with your Unix system, C++ has the cheap site > license and a free G++. > > Eiffel, which looks interesting, has one implementation, a real-priced > commericial product. Interactive charges a lot of money for the Eiffel compiler and tools. But there are people out there who are working on other implementations of Eiffel as well... At least one of them is said to be PD or at least freely available. -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden Tel: +46 758-202 50 Fax: +46 758-197 20 EUnet: rclaeson@erbe.se ARPAnet: rclaeson%erbe.se@uunet.uu.net
bertrand@hub.ucsb.edu (Bertrand Meyer) (10/31/88)
In article <335@pvab.UUCP>, robert@pvab.UUCP (Robert Claeson) writes: > > Interactive charges a lot of money for the Eiffel compiler and tools. > Just how much money constitutes ``a lot of money'' is a matter of opinion and you are free to have your own. Just two comments for the record: 1 - Eiffel is a commercial product; its developers have neither the resources of a giant corporation nor the government funds which would permit them to indulge in dumping. However we believe our prices are quite reasonable when compared to other CASE tools and to other commercial implementations of object-oriented languages. For academic users, cheap licenses are available. 2 - Whatever individual opinions may be, I would hate to let the idea that ``Eiffel is great but only rich people can afford it'' become part of accepted wisdom. The net is not the appropriate place to post a price list but I urge any interested party to get concrete pricing information from the appropriate source. -- Bertrand Meyer Interactive Software Engineering, 270 Storke Road Suite 7 Goleta CA 93117 - Phone 805-685-1006, Fax 805-685-6869 In Europe: Societe des Outils du Logiciel Centre d'Affaires 3MPP, 4 rue Rene Barthelemy 92120 Montrouge France Phone (33 - 1) 46 57 13 36 or 42 53 65 82 - Fax (33 - 1) 46 57 01 03 Note: Best E-mail addresses willl soon (Mid-November) be bertrand@eiffel.COM and eiffel!bertrand@uunet.UU.NET. Current one will still work.