Terminology (Re: [GUI] Re: Know you backends)

[Daan Leijen]

Hi Wolfgang,

> several GUI-related e-mails of the last days spoke about different library 
> "levels" (high, medium, low). I'm not sure, which the term "level" refers to. 
> Does it refer to
>     (a) different programming paradigms (high: functional; low: imperative)
>         or
>     (b) different views onto GUIs (high: application types (MDI, SDI etc.),
>         common dialogs etc.; low: just widgets or even drawing primitives
>         etc.)?

I can't speak for others but I interpreted the 'level' as the Haskell programmers
level. That is, 'high level' means something really declarative like franTk or
Fudgets. 'medium level' means that the library is imperative but offers
a lot of convenient functionality, like TkGofer. Low-level means that it is
imperative and offers no convenience, as Win32 or basic gtk2hs. 

> My opinion concerning (L) is the following: If (a) is meant, (L) should be 
> low-level and be implemented in C with a thin Haskell layer on top of it. 
> (The C interface would also be useable outside the Haskell context.) If (b) 
> is meant, (L) should be as high-level as it must be to provide native 
> look-and-feel.

In my opinion, (L) should be "low-level" from a Haskell programmer 
perspective. That is, there should be medium level library (A) built on top of
(L) that offers convenient functions to access (L). In this sense, we could
probably better talk about a core-functionality library for the medium level
library (A).  I think that it is really important to make this distinction, as we
can share the work on (A) and make it much easier to make a port of (L).

However, at the same time, (L) should be "high-level" from a  GUI perspective
to be as portable as possible  and to give a native look-and-feel. 
(i.e. your (b) option). As you say, it should talk in terms of application
types and common dialogs but not just in terms of drawing primitives.

Port tries to be these things, but we (me and Axel) are still discussing whether 
Port is actually "high level" enough from a GUI perspective or wheter we
need to look for another kind of interface.
 
> A related question: What do you mean with "abstraction"? Has it something to 
> do with "high-level" in the (b) meaning?

This depends entirely on the context :-)  I think I used "abstraction" in
connection with the (A) layer. In that sense, I meant that the (A) library
should offer convenient abstractions that the (L) layer doesn't offer.
For example, we can abstract over resource allocation by using
foreign pointers on Bitmap resources. Or use type classes to be
able to close any widget with "close" instead of "closeDialog" or "closeWindow".


All the best,    
    Daan.

for an example of how I see the distinction between (A) and (L), you
could browse the online docs of GIO (A) and Port (L) at:
http://htoolkit.sourceforge.net