|
Introduction
|
Tesla is an object-oriented native-compiling programming language that produces C++ code
and relies on GNU GCC. The compiler itself relies on the Expat XML parser v 1.95.7 or higher, and the standard
tools make and ar, Lex and Yacc or Flex and Bison and the GNU GCC c++ compiler. The executables produced by
Tesla use the Boehm-Demers-Weiser garbage collector.
Tesla supports object-oriented software development by packaging compiled code into library files that contain
information about the original source file and the public interface of the objects it contains. A Tesla source
file uses extension ".tesla" which compiles into a library with extension ".tlib". In that library is the native
compiled object file and a XML description of the public interface for that object file. Essentially a Tesla
source file is converted into a C++ source file which is then compiled by GCC. Thus Tesla is an extension of C++
with added language and syntax features and much better object-oriented language rules that facilitate software
development while avoiding and correcting many of C++'s faults.
The syntax will be familiar to anyone with experience in Java or C#, although there are a
few limitations since Tesla still relies on C++. Constructors cannot call others for instance
but super can be used to call superclass constructors. Objects are always allocated on the
heap and the delete keyword is available as well as automatic garbage collection. Inner classes
and anonymous classes are not allowed but data hiding is accomplished by declaring classes
as protected or private.
Currently Tesla works with POSIX-compatible systems (ie Un*x, Linux, Cygwin) and the Windows
version relies on MinGW since some code needs GCC-only features and MSYS for compiling from scratch. Both are
available from http://www.mingw.org
Tesla is distributed under the terms of the GNU General Public License, the terms of which are in the file
license.txt in the distribution tarball.
The compiler for Tesla uses the Expat XML parsing library that can be found at
http://expat.sourceforge.net/.
The executables generated by Tesla use the Boehm-Demers-Weiser conservative garbage collector which can be found at
http://www.hpl.hp.com/personal/Hans_Boehm/gc/.
The licensing conditions under which these are distributed can be found in the readme file of the distribution
tarball.
There's still a lot of work that needs to be done on Tesla. My objective is to produce a language that is source
portable over as many platforms as possible, and provide native language support for threads, networking, graphics
and multimedia, and shared libraries. I'd appreciate any help anyone can offer me, so if you know how to knock off one
of the items in the TODO file, or found a bug, or whatever other suggestions or input you have please email me about it.
|
Coding in Tesla
|
As I said above, Java and C# programmers will be in familiar territory. Here's hello world in Tesla:
include Tesla.IO;
public class hello
{
public static void main(String[] args)
{
Console.out.write("Hello, world!").endl();
}
}
Pretty simple, isn't it? Notice the string literal, it's type in Tesla is actually Tesla.Core.String and so can
be passed as Tesla.Core.Object in the method Tesla.IO.StreamWriter.write(Tesla.Core.Object).Thus a construct
like ("hello").length() is valid.
A lot more is explained in specification.txt which comes with the Tesla distribution available below for download.
The public interface information for all source files that comprise the Tesla Library is available here
for viewing or for download.
This is basic documentation for now until the library solidifies more and I can get more documentation written.
|
Example Tesla Code
|
Here's a few sample Tesla source files that demonstrate the basic concepts of the language.
|
Download Tesla
|
The current distribution of Tesla is version 0.12 and is for POSIX/Un*x/Linux, Cygwin, and Windows.
Installation instructions are in the readme file, but basically these commands will install the executable
to /bin and the configuration and library files to /usr/tesla when installing from the tarball:
tar xfz tesla.posix.tar.gz
cd tesla.posix
./install.sh /usr/tesla /bin
If you want to install to your home directory instead the command "./install.sh ~/tesla ~/bin" would work instead.
The auto-install packages (files named tesla.[cygwin|posix|windows].sh, which have the .sh extension but are much larger than regular shell scripts)
can be invoked directly from the command line, doing so without any arguments will show the help information needed to install from there but the
usual command is something like:
./tesla.posix.sh /usr/tesla /bin
This has the same effect as the above installation operation but is more convenient.
To install on Windows, open the Windows distribution zip file and copy the directory "tesla" to wherever is convenient. To compile a new
version MSYS is required which can be done in a similar was as explained above since the windows auto-installed is provided:
./tesla.windows.sh /c/tesla /c/msys/1.0 /c/mingw
Unfortunately I haven't access to many different architectures to test Tesla on, so if you have any problems installing
or using Tesla please email me at eric.kerfoot@comlab.ox.ac.uk. I'd be more than happy to try and
get Tesla to work for you as this would help me a great deal too. I wrote it actually using Cygwin in Win XP so I know it works
in that environment and would assume that any other POSIX environment that has the required tools would also work (of course this is overly optimistic).
|
Purpose
|
Tesla has evolved over time as my research progresses into a platform for formal methods research,
specifically into the formal design of a programming language so that it facilitates specification
and verification. To that end a specification language is in the works that will be closely tied to
Tesla, and with Tesla code that has close analogies in the specification mathematics, hopefully can
be used to provide some form of feasible program verification. My research is ongoing so I will
state what papers are written on the topic as they are written.
Originally my reasoning behind writing Tesla was to provide a new language for writing native libraries
and applications that fixes a lot of the problems with C/C++. Tesla uses an entirely object-
oriented design with more sensible, modern inheritance rules (though there's a few
limitations imposed by C++), a minimal set of language constructs, one superclass that all
others inherit from, garbage collection, and the ability to produce and link shared libraries
as a native language feature (not yet implemented though).
C++ I believe is overly-complex and is the source of many programming errors, bugs, vulnerabilities,
etc. There is simply too much language for most programmers to uderstand fully and be productive with.
Many of C++'s features are bandages to fix some deficiency in the core design of the language (templates
for example). My specifc points and how I believe Tesla addresses them:
- Being backwards compatible with C has produced a mixed language that has objects but still
uses non-OO functions and linking, this is confusing when trying to understand the syntax and
to know what is and is not valid; Tesla is backwards compatible with C but forces functions and
variables that it imports to be members of a library object and so they behave like static members
of that library.
- Since classes can have no superclass at all it's impossible to write generic containers or
algorithms. The solution to this problem, templates, are overly-complex, hard to understand,
produce a lot of duplicate code, and are still quite inflexible; all classes in Tesla implicitly
inherit from Tesla.Core.Object if not from any other class.
- Object-oriented design can be easily broken by casting class pointers to void* then to whatever
one wants so that private data doesn't stay private; the use of pointers in Tesla are for compatibility
with C libraries and there's no way of referencing object members thus ensuring that private members
cannot be accessed by other classes.
- Arrays are still just blocks of allocated memory pointed to by a normal pointer and so there's no
checking on index values when accessing array elements; Tesla arrays are actually objects that extend
from Tesla.Core.Object and throw exceptions if an invalid index is used to accessed an array member,
this eliminates a major source of crash bugs and security holes.
- Header files also expose all information about classes and if changed force a recompile of all
source files that include them; Tesla can't solve the later problem but the former is solved by
using headers internally and not exposing interface information to programmers.
- C++ is itself complex and is made more so by the preprocessor such that programmer tools and
code analysis software must do far too much work and might not even be able to produce correct
or useful results; Tesla doesn't use a preprocessor and has a purposely simple syntax that is
easy to parse, and the parts of the compiler (XMLInterface.h, TParse.h for instance) are modular and
available for people to use in software that needs to read Tesla sources or tlib files.
- Using a garbage collector in C++ can preclude the use of outside software libraries if they don't
use the same one or use another or none at all; since the garbage collector is integral to the language
the programmer can freely import any other Tesla libraries without these concerns.
- C++ supports multiple inheritance which greatly complicates the language and confuses programmers to no
ends, and causes inheritance problems such as the dreaded diamond which is fixed by hard-to-understand
virtual inheritance; Tesla only allows a class to inherit from one other but has interfaces as a separate
type of object which classes can implement as many as needed, thus there is no need for multiple
inheritance that doesn't outweigh the added complexity it would incur.
- C++ is a powerful language that can perform the low-level programming tasks that C does but still have
higher-level features neede for modern software design. This produces a complicated language since two
roles are being filled; I feel that low-level work should be left to C while higher-level programming is
best suited to a dedicated language like Tesla.
- C++ allows classes to be allocated on the stack as well as heap, this in itself is okay but it creates
issues with when overloaded operators are used of which operator ('.' or '->') or use which adds more
burden to the programmer; all Tesla objects are allocated on the heap and referred to by pointers and
so methods always pass objects by reference as well.
In short I feel that as C++ evolved from C each new feature added something to the language or fixed one
deficiency or another but added its own host of issues, such that it becomes simply too inefficient
for programmers to have to learn all of the language they need to know to accomplish their goals and
then actually write it in its tedious syntax.
I say that Tesla's syntax is purposely-simple but this doesn't translate into an incapable language. C++
is complex and powerful but I believe that much of the capability can be achieved with a simpler syntax
model. For example, Tesla uses the '.' separator for all qualified names (eg. Tesla.IO.Console.out.write)
while C++ uses '.', "::", and "->" depending on context (eg. Tesla::IO::Console::out->write). This is a
burden on the programmer which is aggrivated by useless error messages produced by easily-confused compilers.
Since Tesla produced C++ as its output it has to figure out which of these to use at any one time and so
proves that C++ place needless burden on the programmer. On the topic of useless error messages, since C++'s
syntax is so complex compilers often have real trouble figuring out what the problem is or what objects
are actually involved, especially in the case of mixing up '.' with '->' for a miriad of reasons including
the fact that '->' can be overridden. Add templates into the mix with multiple instances of the same
template class and very soon one character errors can produce many pages of error output.
And so Tesla is written without any exotic language features, a logical and object-oriented method of
C compatibility, and a compiler that takes annoying burdens off the programmer's shoulders. It performs
it's function by providing a logical and flexible environment that is no more complex than it need be.
|
About Me - Eric Kerfoot
|
I am currently a
D.Phil (PhD) student at the University of Oxford in Oxford, UK, under the supervision of Professor
Steve McKeever, doing research using Tesla into
formal methods of programming languages as applied to bioinformatics problems. I am also a teaching assistant for
the Software Engineering Programme at Oxford, my website for which can be found at
http://www.softeng.ox.ac.uk/Eric.Kerfoot/.
I completed my undergraduate degree at the University of Western Ontario in London, Ontario, Canada, with a Honours BSc
in Computer Science with Software Engineering Specialization. I have also worked as a research assistant at York
University in Toronto, Ontario, Canada, doing research into formal methods and program verification under
Professor Jonathan Ostroff.
My main interests in computer science have been formal methods, compiler theory and construction of programming languages, 3D graphics,
3D engine and game design. I have many years experience with Java, C/C++, Eiffel, DirectX/Direct3D, Z specification language, Haskell,
and many software and game development tools. The games side of this has always been a hobby, but an instructive and rewarding one that
would benefit any student of computer science.
I can be reached at eric.kerfoot@comlab.ox.ac.uk, I'd appreciate
any comments, suggestions, help with any aspect of Tesla, flames, insults, etc.
|
Nikola Tesla
|
I bet you can ask any number of people at random if they've heard of Nikola Tesla and almost all would say no. The modern
world would not be possible without his work in AC power, since the polyphase generator he pioneered produces almost all
of the electricity used by modern technology. You're reading this because of his work. He also can be attributed with the
invention of radio before Marconi, and otherwise advanced our understanding of electromagnetics more than any other person.
His 700+ patents attests to scientific genius with few equals in modern history, yet people in general know little if
anything about him. I've compiled a small list of links about the man, someone whom I feel people need to know more about.
|
|
|