So here's array optimised is2path function:
fun ix2path (t:typecode) (ix:int) : path =
{
fun aux (t:typecode) (var ix:int) (p:path) : path =
{
match t,ix with
| Primitive _, 0 => return rev p;
| Array (?n,?t0),_ =>
var sz = pcount t0;
var choice = ix / sz;
assert
No, I have no plan to replace Ocaml yet :)
Felix currently compiles using flx. In turn, flx invokes flxg (Ocaml)
and flx_pkgconfig .. which is written in Felix. This creates a circularity.
This circularity is resolved as follow currently:
flx_pkgconfig is built first, using hand crafted Python
s
In the long term, checking the generated C++ code into the repository in a
"bootstrap" or "cache" folder of some sort and switch alll the tools to be
written in Felix (especially flxg) is the way to go.
On Thu, Jan 17, 2013 at 2:07 AM, john skaller wrote:
> No, I have no plan to replace Oc
Now for the hard bit: variants. A variant node is just like
a tuple node, however the address of each branch is the same,
and the size of the node is the maximum of the branch sizes.
However: a variant node contains its own selector.
We don't know what that is, however a path going through
a varia
Now for the hard bit: variants. A variant node is just like
a tuple node, however the address of each branch is the same,
and the size of the node is the maximum of the branch sizes.
However: a variant node contains its own selector.
We don't know what that is, however a path going through
a varia
On 18/01/2013, at 9:16 AM, Michael Maul wrote:
[And Dobes also]
> Course I expect it is not quite as simple as just capturing the gen'd C
> code...
The task then is to make it that simple.
There are two distinct issues here.
The easy one is the impact on the repository.
The build can be
