[om-list] C++ extensions....

[Tom and other Packers]

Mark

    Can't you use the word "const" to indicate that a function has no side
effects (at least in member functions)?

    And, can't you put string literals on multiple lines, using the
backslash (escape sequence)?

tomp

----- Original Message -----
From: "Mark Butler" <butlerm at middle.net>
To: "Thomas Packer" <tomp at thoughtform.com>
Cc: "One Model List" <om-list at onemodel.org>
Sent: Wednesday, April 25, 2001 9:32 PM
Subject: [om-list] C++ extensions....


Thomas Packer wrote regarding planned changes to C++:
>
> [See] http://technetcast.ddj.com/tnc_play_stream.html?stream_id=560
>

  They are definitely moving in the right direction, although a bit
conservatively, in my opinion.  If I were in charge I would:

1. Create standard bit, int8, int16, int32, int16, and int128 types.

2. Create unsigned char8, char16, and char32 types.

3. Create standard float32, float64, float128 types.

4. Compile char, short, int, long, float, and double as user
   controllable typedefs for more concrete types.

5. Extend the standard C library using function overloading and templates
   so that function names are not type specific.

6. Standardize template instantiation so that standard template function
   and class implementations can be stored in library modules instead of
   having to be located in header files.

7. Standardize the application binary interface (ABI) for C++ libraries,
   including the name mangling scheme.

8. Standardize the implementation and binary interface of critical classes
   like string.  Consider making string a fundamental data type so compilers
   can compile it quickly and optimize it effectively.

9. Pass argument type information to to functions accepting a
   variable number of arguments, like printf().

10. Compile character literals in a context sensitive fashion,
    automatically adjusting width and format (C string vs. C++ string).
    Same for numeric literals.

11. Allow template argument inheritance, e.g. if A is B then
    T<A> should be compatible with T<B>.

12. Introduce the distinction between semantic inheritance and
    implementation inheritance.  Use to allow sub classes to implement
    the full semantics of parent classes using different (more efficient)
    binary formats.  Simple example:

    Every int8 is int16 is int32 is double is complex.

13. Allow classes to define declarative constraints that are not
    overridable in sub classes.  Have compilers optimize based
    on constraints.  Allow user to check non-compiler
    enforceable constraints at run-time as in Eiffel.

14. Allow user to specify explicit function specializations based
    on parameter value predicates.  Allow user to request compiler to
    create the same for certain predicates using optimizer. Compiler
    then chooses specialization based on knowledge of parameter values.

    This is very similar to global function optimization, except it allows
    the user to direct compiler and write own specializations.

    Trivial example: exp(0)=1, sin(0)=0, cos(0)=1, etc.

15. Allow user to define declarative constraints on functions and
    function call sequences.  Compiler then uses to do things like
    merge concatenated strings and sequential I/O operations at compile
    time.

    e.g. write("A"); write("B") ==> write("AB"); where x and y are strings.

17. Allow compilers to interpret/resolve C++ expressions at compile time
    using the same declarative constraints in a generalization of the way
    constant folding is done now.  Add a keyword to explicit indicate that
    a function is invariant (i.e. no side effects).

18. Deprecate the current macro syntax and replace with interpreted C++
    macro functions with an extended "emit" operator to allow arbitrary
    symbol generation.  Allow variable number of arguments.

19. Add a compile time typeof() operator.

20. Add set as a new fundamental type, with an "in" operator, as in Pascal.

21. Allow a function or module to declaratively expel and/or redefine any
    keyword with scope level effectivity.  Use for backward compatibility
    for code that uses new keywords.

23. Require the switch/case construct to operate on non-fundamental data
    types that have equality operators.

25. Allow users to define alphanumeric operators at one or more fixed
    levels of precedence.   e.g. "(a dot b)" or "(c cross d)"

26. Treat include modules like templates with a documented
    list of parameters to allow caching, precompiling, and re-ordering.
    Current system requires each unique sequence of included header files
    to be compiled independently due to unknown #define dependencies.

27. Create a standard meta information system that can be
    enabled to allow complete type and symbol information
    of a program to be accessed both internally and externally.

28. Create a standard runtime C++ interpreter facility, with optional
    JIT compilation.  Allow functions to be created and rewritten at
    runtime, as in LISP.

29. Allow string literals to span multiple lines, as in Perl.

30. Create a standard sub-language plug-in interface with facilities
    for transparently embedding languages like SQL.

31. Create a low-level platform independent code distribution format
    similar to those used by Java and C#. Translate to machine code
    at install time.

32. Add a standard garbage collection facility that uses calls to delete
    as GC optimization information.

33. New option: Use GC + variable / parameter meta information to
    guarantee that a pointer never points to an invalid location and
    that arrays / buffers are never over-run.  If necessary, change calling
    convention so that pointers are passed with bounding values where
    required.  Optimize out unnecessary bounds checks.

    (Note: Pointer based string processing is extremely efficient and
     much easier to write than the function based alternatives - this would
     allow it to be done in a safe manner).

34. Guarantee that all variables without constructors are initialized to
    zero. Optimize out redundant initializations.

35. As planned: Standard support for RPC, standard libraries for
    network I/O, asynchronous I/O, IPC, threads.

36. Standard cross platform GUI library - suggest adopting Qt.

37. Java style module declaration / implementation hybrid support.
    Sophisticated compile dependency analyzer with standard interface
    to replace checking header timestamp in tools like make.

38. Run-time function closure support, make pointers to member
    functions useable instead of something to be avoided.

39. Full nested function support.

40. Auto dynamic_cast pointers everywhere. Optimize out unnecessary
    cases.

41. Add support for including binary data files as static data.

42. Create standard date, time, and timestamp data types.

44. Add new keywords for +infinity, -infinity and support in numeric
    types.

44. Future: Adopt four valued logic: (true/definite/indefinite/false).

  For boolean expressions:

       true       (known true)
       definite   (known to be true or false)
       indefinite (not known to be true or false)
       false      (positively untrue - i.e. denial is true)

  For other variables:

       *value*    (has a normal value)
       definite   (referent known to exist, value unspecified)
       indefinite (referent not known to exist)
       nil        (referent non-existent)


45. Future: Use known, definite and indefinite as new type qualifiers.
    Initialize unitialized indefinite variables to "indefinite".

   e.g.
       indefinite integer x;   /* starts indefinite */
       definite integer y;     /* starts definite */
       known integer z;        /* always has value, i.e. "not null" */

43. Future: allow de-referencing any null pointer to return null instead
    of throwing an exception. Define null + constant == null.


- Mark

_______________________________________________
om-list mailing list
om-list at onemodel.org
http://www.pairlist.net/mailman/listinfo/om-list