- The 'usual' features: imperative style, objects, inheritance, runtime polymorphism, first-class functions, generics, namespaces, string interpolation, garbage collection and exceptions.
- Scheduling: any computation or operation can be deferred to a later time with a single keyword, with complete control over the canceling of a computation.
- References vs. values: unlike C++, a value-variable can only be changed by assigning to it (it is independent of its copies), a reference-variable can be changed by assigning to it or any of its copies.
- Copy-On-Write: all value objects support copy-on-write natively, including strings and arrays.
- Better null safety: null objects are handled through the type system, allowing elegant and simple code for non-null objects and requiring checks before using potentially null objects.
- Atomicity: a given block of code is always executed as a whole, without other bits of code being interlaces with it as in the case of threads. In fact, executions of different procedures are interlaced, but are guaranteed not to alter the semantics of the language.
- Eagerness: everything is evaluated as soon as possible. Function calls on constants can always be executed at compile-time without requiring heavy metaprogramming (as in C++). If X must occur at time T, but Y is required for X and does not have side-effects, then it might be executed before T if time allows. The main consequence of eagerness is that system load is spread over time (difficult computations are done over long durations instead of when they are finally required).
Xhed, the best language ever?
Now that my overly enthusiastic thread title has sucked you in, let us get to the meat of the issue: for the last few months, I have been working on the design of a programming language (recently named Xhed) for which I intend to build a compiler.
However, before moving on to the nitty-gritty details of proving that the type system is sound and that the various elements interact correctly, I would like people to look over my shoulder and point out any inconsistencies, bad ideas or potential pitfalls in the current design.
First, a link to a short introduction to Xhed and its main differences with C-family languages that most of you should be familiar with. If you don't feel like reading it yet, here is a short overview of the language's features:
this looks pretty interesting and possibly also useful in various settings and the syntax looks pretty intutive and readable to me-some of it seems to be inspired by Ada?
However, you said you would intend to write a "compiler", yet you a are posting in "Scripting Languages...", so do you really intend to write a full compiler or merely a VM engine for a SCRIPTING language?
If you do intend to write a full compiler, do you plan to implement it as a gcc frontend?
Also, you may find the following discussion interesting:
http://www.gamedev.net/community/forums/topic.asp?topic_id=383805 :-)
Apart from that, personally I would find it interesting to read some more about the goals/motives of Xhed, the reason why you conceived it, what it should be used for, how it is different from existing approaches etc.
Otherwise, it's hard to put things into perspective
However, you said you would intend to write a "compiler", yet you a are posting in "Scripting Languages...", so do you really intend to write a full compiler or merely a VM engine for a SCRIPTING language?
If you do intend to write a full compiler, do you plan to implement it as a gcc frontend?
Also, you may find the following discussion interesting:
http://www.gamedev.net/community/forums/topic.asp?topic_id=383805 :-)
Apart from that, personally I would find it interesting to read some more about the goals/motives of Xhed, the reason why you conceived it, what it should be used for, how it is different from existing approaches etc.
Otherwise, it's hard to put things into perspective
Quote:Original post by Anonymous Poster
this looks pretty interesting and possibly also useful in various settings and the syntax looks pretty intutive and readable to me-some of it seems to be inspired by Ada?
I've never used Ada, but maybe French minds think alike? The syntax and basic semantics for most of the system is ripped out of C++, with the exception of generics and type parameters, which are taken from ML, and procedures, which come from Pascal.
Quote:However, you said you would intend to write a "compiler", yet you a are posting in "Scripting Languages...", so do you really intend to write a full compiler or merely a VM engine for a SCRIPTING language?
Both. My objectives are, in the following order:
- To develop a program parser with semantics checking.
- To develop an Objective Caml virtual machine, which would be used to interpret the parsed code.
- To develop a C++ virtual machine, and create a C++ code generator that would make calls to that virtual machine.
Quote:If you do intend to write a full compiler, do you plan to implement it as a gcc frontend?
Maybe. Before I would write a fully functional compiler, I will probably have written a Xhed-to-C++ compiler which could be combined with any C++ compiler.
Quote:Also, you may find the following discussion interesting:
http://www.gamedev.net/community/forums/topic.asp?topic_id=383805 :-)
I've been following that discussion for a long time (although I never took the time of posting in it).
Quote:Apart from that, personally I would find it interesting to read some more about the goals/motives of Xhed, the reason why you conceived it, what it should be used for, how it is different from existing approaches etc.
Xhed is designed specifically for games and, to a lesser extent, other real-time interactive programs.
- The most important point in the design is that the usefulness of the language in general situations (such as computing 10000 digits of π) must be sacrificed to improve the performance and expressiveness of the language in the specific case of game development.
- The second most important point is that the language should map as cleanly as possible to the problem at hand — the change of behaviour of entities through decoration, the ability to delay or cancel an action or the presence of garbage collection are examples of attempts of catering to the game.
- A secondary point is that semantics must be simple to understand, but not necessarily equivalent to those of other languages. For instance, in all C-family languages, the question "who might modify this variable?" cannot receive answers, because anyone may use a reference to alter any variable. In Xhed, sharing of variables between users must be signalled explicitly through references. Another example is automatic copy-on-write, which is different from C's "a copy is always made" or C++'s "a reference to the original is passed". For the same reason, there are no class methods or access modifiers: access is handled through namespacing (yielding a simpler method of creating modules) while methods are replaced by freestanding functions mapping more clearly on the notion of object oriented message (while also allowing clearer expression of multiple dispatch polymorphism).
- The basic concepts of the language should be as simple as possible. The more complex elements should be easily expressed and incorporated as part of these concepts. This is why, unlike C++, compile-time value evaluation is done through functions and not through a second template-based language. This is also why type parametrization uses a "wildcard" approach instead of a "type variable" approach.
- The language should protect the programmer from himself without the programmer knowing. Did you know that the value/reference system has been constructed in such a way that it is impossible to create a cycle of values (or, worse, of extensions)? That the absence of NULL values (unless explicitly used) prevents NULL-errors while Shapir-Whorfing the programmer into forgetting about the concept of NULL? That the difference between functions and procedures gives the optimizing compiler a lot more information than what the programmer could have been able to communicate with the equivalent amount of work in another language?
I see things like "Console", "PrintedString" being highlighted suggesting they may be keywords or possibly stem from some sort of native in-built library or module, however there doesn't seem to be any sort of library/module-specifications statements (i.e. include, import, with, require, use etc).
So, do you have any concept of libraries or modules for Xhed?
Is everything that's required for a unit, included implicitly?
How exactly are programmers supposed to come up with their own modules and use them in other compilation units?
Thanks
So, do you have any concept of libraries or modules for Xhed?
Is everything that's required for a unit, included implicitly?
How exactly are programmers supposed to come up with their own modules and use them in other compilation units?
Thanks
Quote:Original post by Anonymous Poster
I see things like "Console", "PrintedString" being highlighted suggesting they may be keywords or possibly stem from some sort of native in-built library or module, however there doesn't seem to be any sort of library/module-specifications statements (i.e. include, import, with, require, use etc).
The words highlighted are the words that start with a capital letter. These are the namespace and class names. So, Console.print calls the "print" procedure in the Console namespace. If you will, a namespace equates a module.
Quote:So, do you have any concept of libraries or modules for Xhed?
Is everything that's required for a unit, included implicitly?
How exactly are programmers supposed to come up with their own modules and use them in other compilation units?
The initial parser outputs a machine-friendly bytecode file that corresponds to the source file, so there is one bytecode file per source file (as in Java). Each bytecode contains debugging and diagnostic information about the code it contains.
Bytecode files can then be combined together in two ways:
- Merging: create a larger bytecode file containing all the contents of the combined files and resolving any external references along the way. This is useful for creating libraries.
- Linking: this requires a main bytecode and several auxiliary bytecodes. It creates a new bytecode that incorporates the entire code of the main bytecode, plus any external reference identifiers from the auxiliary bytecodes that are necessary for the main bytecode to run.
So, it's possible to create a library by merging its component bytecode files together, and then to link a bytecode with a library to obtain an executable bytecode (with no undefined references).
The executable bytecode can then be executed as-is on a VM, or be compiled to C++ code.
The bytecode can be stripped of a lot of diagnostic information when redistributed (either as executable or library) as well, although a stripped executable is a lot lighter than a stripped library (because the library must keep information necessary for merging).
I just want to say that I absolutely love the scheduling you included in XHed. I think it is absolutely brilliant. I like how you really thought through the issues of reference versus copying in the scheduled blocks. I posted the link to your site on the private Hero of Allacrost forums showing them exactly what sort of functionality I want to implement using Lua. This sort of scheduling is long overdue in many languages, if you ask me.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement