# GUI's in concatenative languages

## Chris Double — 2004-11-16 00:20:23

    Are there any graphical user interface libraries for any of the

    concatenative languages out there? What sort of programmatic API would a

    concatenative GUI have? I'm currently building a component/OO based API

    for a continuation based web server in Factor and am curious if perhaps

    there's an approach that's more in the concatenative spirit than the

    current approach I'm taking.

    Chris.

    --

      Chris Double

      chris.double@...

## Slava Pestov — 2004-11-16 01:19:03

    GUI's are the classical application of OOP, and OOP in a concatenative

    langauge is not that different from anything else. There are various

    Forth GUI toolkits, for example bigforth's minos toolkit, however it is

    quite low level. Perhaps you could post your code?

    Chris Double wrote:

     > Are there any graphical user interface libraries for any of the

    > concatenative languages out there? What sort of programmatic API would a

    > concatenative GUI have? I'm currently building a component/OO based API

    > for a continuation based web server in Factor and am curious if perhaps

    > there's an approach that's more in the concatenative spirit than the

    > current approach I'm taking.

    >

    > Chris.

## Chris Double — 2004-11-16 01:30:24

    On Mon, 15 Nov 2004 20:19:03 -0500, "Slava Pestov" <slava@...>

    said:

     >

    > GUI's are the classical application of OOP, and OOP in a concatenative

    > langauge is not that different from anything else.

     I agree but was curious to see if any work had been done on non-oop

    approaches in concatenative languages. I've used the oop approach for so

    long in GUI work it interests me to see other approaches.

     > There are various

    > Forth GUI toolkits, for example bigforth's minos toolkit, however it is

    > quite low level. Perhaps you could post your code?

     I will soon. As soon as I fix some bugs :-)

    I quite like the approach you took in factoroids. I'm more using the way

    that you did streams. Are you thinking of continuing the traits/generics

    approach further?

    Chris.

    --

      Chris Double

      chris.double@...

## Slava Pestov — 2004-11-16 01:45:08

    Chris Double wrote:

     > I quite like the approach you took in factoroids. I'm more using the way

    > that you did streams. Are you thinking of continuing the traits/generics

    > approach further?

     Yes, I intend to develop examples/oop.factor further, and indeed I plan

    to use it for streams. Feel free to make use of it -- I don't forsee

    huge changes to the syntax.

    The reason its not in the core is that it still needs one major piece of

    functionality. I plan on adding dispatch on arbitrary type predicates.

    Once this is done, it will go into the core, and will also be used for

    prettyprint, hashcode, and other such polymorphic words.

    Here is how it will look:

    GENERIC: foo

    M: cons foo "Called with a cons!" print ;M

    M: list foo "Called with a list!" print ;M

    M: vector foo "Called with a vector!" print ;M

    The predicates cons?, list? and vector? would be defined in a special

    way -- this syntax is not final, its just for illustrative purposes...

    First, predicates for built-in types would be defined with a type

    number, like so:

    BUILTIN: cons 2

    Predicates for composed types would first have the predicate word, as

    usual -- here is the list? from the library:

    : list? ( list -- boolean )

         dup [

             dup cons? [ cdr list? ] [ drop f ] ifte

         ] [

             drop

         ] ifte ;

    The definition would be followed though by something like this:

    EXTEND: cons CLASS: list

    The reason being to establish a subtype relationship. If generic

    dispatch has already tested that something is a cons and the test

    failed, calling list? is no use. This would be co-ordinated with word

    properties established by BUILTIN:, EXTEND: and CLASS:.

    In fact, the first level of dispatch would be a vector-nth on a vector

    of quotations, where each quotation dispatches on the built-in type with

    this number, so in the end it should be quite efficient.

    Slava

## Slava Pestov — 2004-11-16 01:52:38

    Just to clarify, TRAITS: is not going away, and will provide a way to

    dispatch on hashtables that have a method map. The CLASS: still is

    purely an extension.

    Slava Pestov wrote:

     > Chris Double wrote:

    >

    >>I quite like the approach you took in factoroids. I'm more using the way

    >>that you did streams. Are you thinking of continuing the traits/generics

    >>approach further?

    >

    >

    > Yes, I intend to develop examples/oop.factor further, and indeed I plan

    > to use it for streams. Feel free to make use of it -- I don't forsee

    > huge changes to the syntax.

    >

    > The reason its not in the core is that it still needs one major piece of

    > functionality. I plan on adding dispatch on arbitrary type predicates.

    > Once this is done, it will go into the core, and will also be used for

    > prettyprint, hashcode, and other such polymorphic words.

    >

    > Here is how it will look:

    >

    > GENERIC: foo

    > M: cons foo "Called with a cons!" print ;M

    > M: list foo "Called with a list!" print ;M

    > M: vector foo "Called with a vector!" print ;M

    >

    > The predicates cons?, list? and vector? would be defined in a special

    > way -- this syntax is not final, its just for illustrative purposes...

    >

    > First, predicates for built-in types would be defined with a type

    > number, like so:

    >

    > BUILTIN: cons 2

    >

    > Predicates for composed types would first have the predicate word, as

    > usual -- here is the list? from the library:

    >

    > : list? ( list -- boolean )

    >      dup [

    >          dup cons? [ cdr list? ] [ drop f ] ifte

    >      ] [

    >          drop

    >      ] ifte ;

    >

    > The definition would be followed though by something like this:

    >

    > EXTEND: cons CLASS: list

    >

    > The reason being to establish a subtype relationship. If generic

    > dispatch has already tested that something is a cons and the test

    > failed, calling list? is no use. This would be co-ordinated with word

    > properties established by BUILTIN:, EXTEND: and CLASS:.

    >

    > In fact, the first level of dispatch would be a vector-nth on a vector

    > of quotations, where each quotation dispatches on the built-in type with

    > this number, so in the end it should be quite efficient.

    >

    > Slava

    >

    >

    >

    >

    > Yahoo! Groups Links

    >

    >

    >

    >

    >

    >

    >

    >