|
|
|
| |
|
Quick Links
Understanding XL
In depth
Other projects
|
XLR: Extensible Language and Runtime
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
XL, an extensible programming language, implements the ideas of Concept Programming.
If you want to know more, you should start here.
Added support for function pointers in Revision 370. The real problem was support for overloading, as illustrated in this test, reproduced below:
In that example, the problem is with Invoke Foo, which needs to be able to decide which Foo is to be selected (the first one in that case).
Based on feedback from many people (most notably Daveed Vandevoorde and Lionel Schaffhauser), I posted a new presentation about Concept Programming. This should make the ideas much easier to grasp. During the discussion, Daveed Vandevoorde pointed me to a very interesting paper about memory transactional models, which he used as an argument in favor of functional programming. Recommended reading, even if I don't think that this is a point for functional programming at all myself. Lionel Schaffhauser pointed out a number of presentation-related issues, which prompted me to change the order of the slides and add a whole section about the "Maximum" example. As a reminder, there is also an older presentation about XL itself. Blog post about this presentation.
I finally posted a slideset about concept programming that had been rotting on my hard disk for way too long... This gave me an opportunity to re-read older articles on these topics, one I had written for Dr Dobb's Journal, and another one written by Martin Heller (Mr. Computer Language Person) in Byte.
With Revision 338, XL now has basic support for enumerations. Not a big deal as far as features are concerned, but it allowed me to figure out a long-standing bug in the treatment of named types that had prevented alternate X.Y translations from working right.
While writing code for pointer modules, and specifically XL.POINTER.MACHINE_ADDRESS, it occured to me that I had a problem with the following code:
function Pointer(addr : integer) return pointer is XL.BYTECODE.int_to_ptr The problem is that the intended usage, as illustrated in this example, would be something like:
Machine_Register : pointer to unsigned := Pointer(16#FF_FC0A) The problem with this is that none of the arguments to Pointer helps figuring out what particular generic parameters for the the return type are (i.e. in this case, pointer to integer, or pointer to real, or something else). I tried to wiggle out of this, because I know that C++ (the only mainstream language that massively implements automatic deduction in templates, since Ada for example requires explicit instantiation) does not implement return type deductions. There are good reasons for that: defining precisely how it works is hard. Ada does have return-type overloading, which is a somewhat similar problem, and it is known to be expensive. But ultimately, I had to concede, on concept programming grounds that there was simply no good alternative. So I ended up hacking together what seems to be the simplest, least expensive semantics allowing these particular examples to work. By "simplest and least expensive", I mean in particular that it works only at one level, and only if other parameters of the written form or function call entirely define the generic type being returned. But apparently, it now works to some extent.
The support for generics is now sufficiently robust to allow me to write modules defining pointer types. See native/TESTS/08.Aggregates/address-of-operator.xl for an example of the use of the functionality defined in native/library/xl.pointer.xs and native/library/xl.pointer.address.xs. I am still thinking about the various pointer models I'm going to provide.
Starting with Revision 316, the XL compiler supports multiple runtimes. What I call a "runtime" in that context is an execution environment. As of today, "multiple" means 2. One has to start somewhere. What this means is that you can now compile the same program two different ways. If you use nxl julia.xl, you compile it with the runtime called default, which is currently using C. If you use nxl -r Java julia.xl, you use a runtime called Java, which uses the Java programming language. There were minor changes to the language for that purpose. In particular, the declaration of C functions does not work for the Java runtime, obviously. So on a C runtime, you can declare:
function sin(X : real) return real is C.sin In Java, you would declare the same function as:
function sin(X : real) return real is Java."Math.sin" Notice the change in syntax to accomodate extended names. The textual form is to remind you that the "." in "Math.sin" is not the XL ".". In C++, if I ever implement it, you would write:
function sin(X : real) return real is CXX."std::sin" As a consequence of this change, I moved the most fundamental functions to the XL bytecode, so that the declaration remains the same in all cases, e.g. someting like:
function sin(X : real) return real is XL.BYTECODE.sin_real Using Java proved troublesome: Java is not a good low-level target language for a number of reasons, not the least being that there is no goto statement. Normally, a compiler transforms an if statement into a conditional goto. I hacked my way around, but I'll see if I can find a way that is more "structured" than the present approach. Another issue was finding ways to make sure that all variables were declared and initializd, knowing that Java uses two different syntaxen for objects and basic types (ugh). In short, within the first day of implementing this Java runtime, I had hit two of the reasons I don't like Java: its dogmatic nature (goto is bad, no goto), its dogmatic nature (basic single-inheritance objects are the one true way, so that's all there is for you). It is not clear that the Java runtime will ever allow more than basic "Hello world" style programs in XL. At some point, I will have to implement a non-imperative runtime. I will probably use XL to generate LaTeX or HTML or something like that, but I still need to find some really useful context to do so.
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Copyright 2008 Christophe de Dinechin (Blog)
E-mail: XL Mailing List (polluted by spam, unfortunately)
