|
|
|
| |
|
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.
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.
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
Copyright 2007 Christophe de Dinechin (Blog)
E-mail: XL Mailing List (polluted by spam, unfortunately)