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@...
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.
On Mon, 15 Nov 2004 20:19:03 -0500, "Slava Pestov" <slava@...>
said:
>I agree but was curious to see if any work had been done on non-oop
> GUI's are the classical application of OOP, and OOP in a concatenative
> langauge is not that different from anything else.
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 variousI will soon. As soon as I fix some bugs :-)
> Forth GUI toolkits, for example bigforth's minos toolkit, however it is
> quite low level. Perhaps you could post your code?
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@...
Chris Double wrote:
> I quite like the approach you took in factoroids. I'm more using the wayYes, I intend to develop examples/oop.factor further, and indeed I plan
> that you did streams. Are you thinking of continuing the traits/generics
> approach further?
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
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
>
>
>
>
>
>
>
>