[clean-list] Clean CVS and Haskell Sharing

[Diederik van Arkel]

On Saturday, June 7, 2003, at 12:52 AM, bfulgham@debian.org wrote:

> I wrote:
>
>> It would be nice if we could use a consistent interface
>> across both libraries.  However, you have carefully
>> factored things into Gtk/Win32 and I'm not sure if the
>> Clean developers are interested in doing something
>> similar.
>>
>
> Ronny:
>> (Note: I haven't had time to look at the sources).
>>
>> I think it would be a good thing if the Clean and Haskell versions 
>> could
>> share as much as possible. Is it feasible to use the same low-level
>> interface (the OS-layer in ObjectIO)?
>
> Possibly.  If you were to look in the GHC CVS tree, you would see that
> they have a very similar structure (the basis for my effort) to the 
> original
> Clean source layout.  However, they changed the layout from:
>
> ../Object IO 1.2.1/OS Windows/Windows_C_121
> ../Object IO 1.2.2/OS Linux/Linux_C_121 (my little area)
>
> To:
>
> ../Object IO 1.2.1/cbits/Windows (like Windows_C_121)
> ../Object IO 1.2.1/cbits/Linux (like my Linux_C_121)
> ../Object IO 1.2.1/include
> ../Object IO 1.2.1/graphics  (like OS Windows)
>
> So, there would have to be a meeting of the minds on the proper layout.
> I don't know what Diederik's Cocoa stuff look like, but I found it
> easiest to just use the exact same interface as Windows (building
> whatever abstractions I needed via Gtk's facilities) rather than
> create an "OS Linux" directory with Gtk-specific stuff in it.
>
> I would propose doing something like:
>
> Object IO/				(the developer-level files)
> Object IO/OS Interface			(the interface files
> Object IO/OS Interface/Windows_C_121	(native)
> Object IO/OS Interface/Linux_C_121	(native)

This won't work for the Carbon bindings as the files in OS Interface are
actually different.

> The other problem is the way Clean passes the environment around
> from function-to-function.  The Haskell code strips this out 
> completely,
> so to be compatible we would either have to wrap each function in
> a Clean version (that took the environment in as arguments) which
> could internally call the Haskell versions.

You mean the OSToolbox parameter that gets passed to and from the
C functions? This is actually unnecessary and can easily be changed.

> It's even harder to be compatible with Krasimir's Sourceforge work
> because the code has been heavily refactored into discrete units
> that don't map well to the current Clean source code.  He can probably
> provide better discussion on that topic.

It's probably a good idea to get Peter Achten involved as well once you
have an initial version working as I know there are some changes he
would like to see implemented.
	One of the (internal) changes I would desperately like to see is to
move from a polling architecture to a callback architecture which 
(amongst
other advantages) would allow us to remove the ugly and complex
threading architecture from the C code.

Regards,

Diederik van Arkel
(looking forward to getting the ide up and running on Linux)