davin.50webs.com New Zealanders making it harder to hate computers     Main Menu     Research Projects      Photo Album      Curriculum Vitae   Greatest Artists     Email Address   Computer Games       Web Design          Programming         Other Links      Debugging Macros String Class I Linked List System I Java for C Programmers Naming Convention String Class II How I use m4 Strings III Symmetrical I/O Linked List System II Run-Time Type Info Virtual Methods An Array System Science & Religion Submodes Nested Packages Memory Leaks Garbage Collection Internet & Poverty What is Knowledge? Limits of Evolution Emacs Additions Function Plotter Romantic Love The Next Big Thing Science Fiction Faster Compilation Theory of Morality Elisp Scoping Elisp Advice SOGM Pattern Safe Properties School Bullying Charisma Control Life and Death Splitting Java Multiple Ctors My Beliefs Conversation 1 Conversation 2 SJS Lisp++ Computer Tutorials

Abstract

1. Problems with C++ and Java

• The syntax of types in C++ is unnecessarily complex, especially when pointers, arrays and function pointers are employed.
• In C++ and Java the separation of expressions and statements is artificial. In Lisp, expressions and statements are the same thing, bracket enclosed lists.
• In C++ it is problematic how when the source code has more than one class, not all methods can be have their method bodies defined within the class that they belong to. Lisp++ emulates Java in this respect so that every method can be put directly inside a class. Here is an example of some code that won't compile under C++, but whose counterpart will compile under Java:

  class B;
  
  class A
  {
  public:
     int foo(B* b)
     {
        return b->x;
     }
  };
  
  class B
  {
  public:
     int x;
  };
    

  To get the above code to compile under C++, the definition of the method body of the foo method needs to be moved down to somewhere after the definition of the body of the B class like so:

  int A::foo(B* b)
  {
     return b->x;
  }
    

• The C++ preprocessor is poorly behaved in that it doesn't respect scoping rules and has other problems. Lisp++ provides a superior preprocessor.
• The Java language is problematic in how it lacks a preprocessor. Extensions to the Java language such as a "foreach" construct and assertions have to be made by editing and recompiling the Java compiler and cannot be achieved within the Java language itself. Note that it would be theoretically possible to add a preprocessor (such as m4) to the Java language but the preprocessor would have to be smart enough so that source level debugging functionality such as the presence of stack traces (specifically the call to the printStackTrace method of the Throwable class) still works.

2. How Lisp++ works

Lisp++ code resembles Lisp code. In Lisp++, the Emacs editor is used as a Lisp interpreter which compiles Lisp++ code into C++ code. Then the G++ compiler is used to compile C++ code into machine language code. If it is desired to have source level debugging then a Lisp++ interpreter could be written to achieve this feature. The basis of the Lisp interpreter is a new Lisp function which I will call compile that takes one argument, a Lisp-style progn. Here is an example of a call to this function:

(compile '(function f (void) (let ((int x = 0))
                               foo (123 * 456 , hello)
                               bar (123 , (456 + 789) , abc))))

void foo()
{
   int x = 0;
   foo(123 * 456,hello);
   bar(123,456 + 789, abc);
}

• The typeof function in case that temporary variables are needed to store the interim results of computations.
• Statements and declarations in expressions, so that for example, for loops can be placed inside expressions like they can in Lisp.