Re: [Felix-impl] help with fixing the sdl bindings?

[Erick T. <ida...@us...>]

On Tue, Oct 6, 2009 at 1:10 AM, john skaller
<sk...@us...> wrote:
>
>> If we disallowed
>> this, then it becomes pretty simple to bind the symbols. We can always
>> keep the macro #include if we ever actually need textual substitution.
>
> Too late, # pre-processor is completely gone :)


Well there's always calling out to cpp :)


> In practice this particular implementation would utterly destroy
> performance,
> and also require major rewriting because the concept of "id" is not
> abstract.


Boy do I know. I tried making it abstract a couple months ago. After
modifying nearly every file, I eventually gave up :)


> However this is NOT enough: when binding D which depends on B
> we still have to lookup in B! At present, there is NO lookup into already
> bound
> symbol tables.
>
> this has to be fixed FIRST. It will also speed up lookup, and remove
> the need for a cache (which would be hard to save and restore
> on a module basis).


What would we need to do for this? I'm not familiar enough with
binding yet to know where to look for what you're talking about :)


> We need to GET RID of the stupid include directive entirely,
> just like #include.
>
> I prefer:
>
>        requires package "faoi";
>
> which should load
>
>        faio.syn -- at parse time
>        faio.flx  -- at compile time
>
> This makes for a single unified package concept, where a requirement
> causes ALL the resources to be accessed, no matter what phase.
>
> Note that faio.hpp is *already* handled by *.fpc file, as well as
> the *.dll file at run time.
>
> However this means the *compiler* has to read *.fpc directories,
> either in Ocaml or by executing flx_pkgconfig -- which makes for
> a small bootstrapping problem .. perhaps we solve that by
> a Python version .. should be easy enough, yes?


This sounds reasonable, though I'd prefer to not try to do this at the
same time as
prebinding. It wouldn't be hard to write an ocaml parser, so I'd just
go that way, then we wouldn't have any boot strapping issues.

In the long run, it seems like the .fpc files act a little like a
library file. Similarly, the .par file and I guess the new .bind file
act a little like object files. Since I've been meaning to writing
some .flxo container file for the object-ish files, it might make
sense to through the .fpc files into a .flxo too.


>> We want to make sure that each file is sharing the same symbols for
>> "int" and "add". One way to do that is to use a two level symbol
>> namespace, where our symbol index becomes an string*int.
>
>
> Hehe .. as mentioned this is right in theory but would kill performance.
>
> Another way is to HASH the string and combine it with the integer,
> the result is hopefully a unique integer.


So how would it kill performance? Overhead from dealing the tuple? I'd
imagine there wouldn't be that many places that would require
destructuring the tuple. The main one would be if we find reference to
some external symbol, but that would load all those symbols into scope
and then any other referenced symbol from there would automatically be
found. Or we could go with my int*int optimization. That one requires
relocation, but that wouldn't be so bad.


> That is easy: init procedures will be BANNED (except for the mainline).
>
> Already init does not work AT ALL with polyjmorphic modules (the
> inits are just never done :)


I don't think we have to go that far. That'd mean global variables
were banned everywhere except the main file, right? As a stopgap,
that'd be okay, but I'd prefer to just initialization. I doubt it's
really that hard ;)


>> I'm not sure if we could really optimize the symbols at this point
>> though.
>
> Sure we can: just make all the "public" symbols roots (like "export"
> keyword).


Great, that doesn't sound bad at all.