There are some problems in the core C types that need to be resolved before too much code would need to be changed.
First: the library defines ptr[T], cptr[T], vptr[T], cvptr[t] as abstract types for C pointers, pointers to const, pointers to volatile, and pointers to const volatile. We don't provide many operators for these. These types are *abstract*. In particular a Felix pointer &T is not the same type as ptr[T]. There is also a type "address" which is an abstract type for a void*. This stuff went into the library at a time when Felix and C pointers had different representations. This is no longer the case. However Felix doesn't support "const" concepts. We do provide some functors to enconst a non-const pointer though, and of course you can always use a C_hack::cast .. but this is all a pain. Without this typing, calling simple C functions is no problem, since a T* converts to T const *, T volatile *, and T const volatile *. However there are two problems. The first problem is with functions returning a T const*. For Felix to accept this pointer we have to cast away const. This can usually be done in the function call. The second problem is with callbacks, or higher order functions in C. Here, to pass a function, the types have to match, including the constness or otherwise of any pointer arguments or returns. Without ptr, cptr, etc, the proper types can't be constructed. I will note in passing this is a fundamental problem with the Felix callback feature. If you're not familiar with it: Felix can automatically generate C functions which are callbacks, and, server functions which accept such functions as arguments, where these functions are wrappers for Felix functions. Doing this by hand is almost impossible because the type names used in Felix are generated by the compiler and unknown to the person writing C bindings unless they can be explicitly extracted from a type argument. This is one reason, by the way, that Felix allows stuff like fun f[T,U, W where W = T * U] (..) = " (?3) .. the W is not just a convenience,it is required so the ?3 can get the C typename of the Felix tuple type T * U. It is a fact that correct wrapping of callbacks is impossible. The reason is that the C server functions we're passing the callbacks too ALWAYS use the wrong type. Felix has to choose between accommodating this incorrectness, or generating correctly typed callbacks and servers. The problem is that the void* representing user data can easily be cast to the right type in the callback, but such a cast cannot be done when registering the callback with the server because it is the function being passed which has the wrong type. To understand the problem try using the callback feature (it's way cool!) ... er ok, there's no doco yet .. :] The second problem is simple enough: for many data structures I'm using "any old type" that came to mind when I wrote it. For example arrays are indexed by an int. varray sizes are specified by a ulong. Felix has the abstract types "address", "size", "offset" which are abstractions for void*, size_t, and ptrdiff_t respectively. The question is: what to use where? If you require "size" then every size would need a cast: varray[int] (size(1)), malloc(size(x)) would be needed. Of course *each* of these functions could be configured to accept "any" kind of integer (using the constrained polymorphism feature). Here's an example in a C binding: lvalue fun subscript[t]: varray[t] * !ints -> lvalue[t] = "$1[$2]"; and in a Felix function: fun subscript[t,ii in ints] (a:darray[t], n:ii) => a.a.[n]; [for some reason you can't write the parameter n: !ints, probably because if you did there's no way to retrieve the type name, though in this case that isn't needed] Anyhow, it isn't clear what the *correct* protocol is here, but it is clear that an "ad hoc" solution isn't sustainable. BTW: it isn't clear arrays should use 0-origin addressing. This is wrong in principle. The correct way is, theoretically, to use 1-origin element numbering and 0-origin to locate points *between* elements. The first is an ordinal, the second is an offset. -- john skaller skal...@users.sourceforge.net ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
