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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,ea30c4e9c3d00b X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,ea30c4e9c3d00b X-Google-Attributes: gid103376,public From: Charles Hixson Subject: Re: Ultimate Language feature list Date: 1998/05/13 Message-ID: <3559CB6B.954B4AA3@earthling.net> X-Deja-AN: 352932828 Content-Transfer-Encoding: 7bit References: <6jc18b$lug$1@news.eclipse.net> Mime-Version: 1.0 To: MSG Content-Type: text/plain; charset=us-ascii Organization: http://extra.newsguy.com Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1998-05-13T00:00:00+00:00 List-Id: Here's my features (at the end), plus some notes (interspersed): MSG wrote: > > I do all my development in C++. Not necessarily because I want to, but > because I keep looking (and looking) for alternate languages/environments > and they ALWAYS come up short. I've decided that the language/environment > for me hasn't been created, so I'm starting a list of features that I > like/require. It's drawn from good languages (I don't consider C++ a "good" > language", neither is Java). If anyone would care to contribute, please > feel free. Who knows, maybe with enough interest we can create a > language/environment we REALLY like and that works easily on any platform, > allowing you to use a sophisticated language and still access platform > specific features for truly fantastic and stable applications. > > I hope a posting like this doesn't cause a flame war. I'm just sharing my > feelings and hoping that some interest will spark -- to what end, I'm not > sure. > > Michael Scott Garnett > michael@pickles.org > > #1 Verbosity. C++ and Java's cryptic syntax is cute and fun, but not > useful. Our Language (OL -- come up with a good name) should be verbose > like Ada and Eiffel. Semicolons optional like Eiffel (except where > ambiguous). Verbosity has it's points, but so does compactness. Zipf's laws rules here. Frequently used features should be v. short, e.g. {} is better than Begin End > #2 Completely OO. No free floating subroutines. The only construct higher > than a CLASS is an Organizational Unit (like an Eiffel cluster). Object Orientation is the correct solution for certain classes of problems, so the lanugage should support a totally object oriented style. It shouldn't insist on it. Byte arrays use up enormous amounts of storage when each byte is an object. > #3 Object-Dot-Feature syntax. No Ada95esque subprograms which take class > arguments (like C++ friend functions). I am torn between Object-Dot-Feature > and Object SPACE feature syntax (like Smalltalk). What about context specifier? 3 + 5 vs. "3" + "5" vs. 3.0 + 5 These can all be understood by a person, a compiler might reason: given a number, the operation + probably means addition, so check for the next argument. If types are staticly determined, then this is either ambiguous or determined at compile time. The question is what to do if it is ambiguous at run time. Note that the semantics is the same as object-dot-feature. Ideally, syntax should be flexible, and I don't know what's practical. > #4 Reference Objects as a default with the ability to expand an object or > class to full form (like Eiffel EXPANDED types) This is good. > #5 Garbage Collection. This is v. important. > #6 Construction and Finalization This needs to be elaborated, Final means something different in Java than it does in Eiffel, e.g. > #7 Predictable Finalization for stack-based objects (either reference or > expanded). When the immediately enclosing scope terminates, the > finalization is called THEN. This is VERY important for reliable external > resource management (OK, C++ did this right). Predictable or controlable? > #8 Polymorphism as the rule. Let the compiler figure out which routines are > not overridden and use static calls where appropriate (a la Eiffel). Yes. > #9 Named arguments. Either like Ada or like Smalltalk (object moveTo: here > usingPath: aPath). Good, although I've rarely used that feature when it was available. Still, it facilitates indirect object style constructions. > #10 Array and record aggregates (like Ada). YES!!! Nobody else has (except, poss. PL/1) that I've encountered has done arrays as well. > #11 Multiple inheritance like Eiffel, NOT C++. Yes, especially the rename and redefine constructs. > #12 STRONG typing and constraint/program checking in the compile and runtime > like Ada. Options to remove such features in a "finalized" version is very > much necessary. Strong typing should be available, and when used should allow compiler optimizations. However, a more perfect language would also allow "on-the-fly" constructions and evaluations (ala Lisp, Snobol, etc.) > #13 Ada-style tasks. Using Object-as-task, like the proposed Eiffel > extension "separate". Ada's SELECT mechanism. Protected types (like > Ada95), Java almost got this right. I wish that I understood this better. It sounds good, but I don't know the details of what it means. > #14 EASY access to other languages/calling conventions. Any CLASS's > features my be effected by external other-language routines. The includes an > easy way to link to C++ libraries. Such special classes can specify that > for "THIS" an other-language-notion be used. Such classes would lack > "variables", being limited to routines only. Yes. > #15 Generics. Not templates. Yes. > #16 Intrinsic types (like Integer) as objects, but completely replaced in > generated code by native types (like Eiffel). As long as they DO get replaced, or at least can be. Possibly some constructions could require that object style information be carried after compilation, but certainly arrays of intrinsic type shouldn't require that each of their members be a separate object. #16b: Homogenous arrays: In a homogenous array, all members of the array are of EXACTLY the same type (whether or not it is intrinsic), so indirect references, etc. are not needed, and storage (etc.) can be optimized. > #17 Ada's float types (delta, digits). Yes. > #18 Range specifications (like Ada). Checked at compile time and run time. Yes. > #19 Discriminated record/class types (like Ada). Checked at compile time > and run time. (maybe not necessary with inheritance) I'm unsure of this one. Inheritance seems to me to be a better choice. > #20 An easy with to extend and re-expose/hide features of parents. Like > Eiffel. No (and yes). One needs the private type as well as the protected type. Possibly there could be a Discrete type that was by default hidden, but which the descendants of could Peek at? > #21 Distributed computing. Yes, but what does this mean (beyond separable threads (or tasks)?) > #22 Pre- and post-conditions (from Eiffel). Including support for the "old" > keyword. The closest thing to Z (pronounced Zed - a formal method) that > I've seen. Yes. #23 Pattern Matching primitives and forms. A bit up in the air here, since I'm not sure the best way to blend it in. #24 Built in database (not an add-on). This could be a compiler option, but needs to be an integral feature of the language, not a JDBC style add-on. #25 Good random-access I/O capability. At least for homogenous files (see homogenous arrays, above) this should be easy. I would like something better, however. Something that doesn't assume that everything on the disk can fit into RAM, too. #26 Support for property lists. This could probably be done via a library, but it should be a part of the language definition, so that it is a transportable feature. -- Charles Hixson charleshixson@earthling.net (510) 464-7733 or chixso@mtc.dst.ca.us