World: r3wp

About Blogger: this platform is a real PIA in many ways. When I will 
have some time, I will look at how to move out, probably going to 
WordPress, or setting up my own blog using the script from Cheyenne's 
web site (I would need to integrate an anti-spam service like Akismet 
in such case).

I am proud to present my first Red/System dialect, for GTK. Here's 
an example of a window with a title, an icon, a label, an input field 
and a button with an associated action function:

http://red.esperconsultancy.nl/screenshots/Red-System-GTK.png

I demonstrated it yesterday at SylCon

Hello World would be:

gtk-begin
gtk-view window [label "Hello, Red world!"]

Wow! :-)

I see now what you meant by making dialects in Red/System!

I am surprised myself at how far you can get. I'm pretty certain 
this is now the most concise and efficient GTK binding in existence

That's really a smart use of 'typed function attribute.

Thanks :-)

Is 'fixed a function call in the dialect?

Yes

So it's a sort of static dialect. Red dialects will be much more 
dynamic

That's very nice work Kaj!

What was the audience reaction about that?

Thanks. I've been talking about such techniques for many years in 
Syllable and in general, and nobody will ever believe me. I'm very 
happy to now have a tool to show them

The audience... sigh. They were friends, but there was only one programmer, 
formerly C++ and now Python. I asked him beforehand how long he thought 
his equivalent Python program would be. He didn't seem to be much 
into GUI programming, but he maintained it would be only ten lines...

How big is the GTK dialect implemenation?

If that is so, it is in some mystery Python binding that is hidden 
very well. In the known PyGTK binding, it would be 2.5 to 3 times 
as long, with a lot of boilerplate code inbetween

The binding is currently 900 lines. The dialect implementation is 
300 of that, but almost half of it is not used in this example

It will become much bigger when you support significant parts of 
GTK

Do you think that adding a symbol! type would be a big help for building 
such dialects at this point?

Yes, but it occurred to me a day or two ago that it can be done simpler, 
if you support first class constants, which I would like anyway

The gtk-position-center is the only #define in the example, the other 
words are function calls

So it's an integer, while there are already two integers for the 
size. Because they can be required to be adjacent, you can detect 
one more integer if it's at the proper distance of the pair, but 
that's the limit

You also have to use a complicated word, because defines of simple 
words could mess up the program elsewhere

To use center instead of gtk-position-center, you'd have to do:

center: 1

for example and then check for that code. But you'd get a manual 
sort of symbol table that would take space

If you could do

center: constant 1

and have constants be real types that you can check for, you'd be 
able to stretch simple dialects a lot further

Supporting first class constants would require to duplicate all existing 
types... I was thinking recently about adding a PROTECT keyword that 
would allow to mark any variable as immutable, so they would act 
as constants. But I guess that such option wouldn't help much for 
dialects, unless I would also add a PROTECTED? keyword to detect 
them.

Also, some kind of namespace support should also help implement more 
cleanly Red/System-level dialects. I might need that too for Red's 
runtime as it will grow much bigger than initially planned, due to 
Red compiling to Red/System.

Very nice Kaj!

cool, Kaj

Thanks

Doc, for dialects I only need constant integers. The immutability 
doesn't matter much, so it's more like the symbol! you suggested, 
but with control over the internal value

Namespaces would be good, too

Enumerations would also help; they're sort of a namespace type for 
constants

Note that to make the dialects more powerful, I'm making use of GTK's 
object system, that allows you to check types. So I can distinguish 
between different Red structs

If you would want to support that in Red/System itself, you'd need 
some sort of user defined type

I think that extending the RTTI system to distinguish different type 
of structs (or at least aliased structs) should be doable without 
that. Aliases are already a form of user-defined type.

Very nice Kaj, congrats!

Looks like we'll all have to install Syllable!

How's the Red timetable going?

Tick-tock.

Yes, very nice Kaj.

Nenad keeps the status updated on the RoadMap http://www.red-lang.org/p/roadmap.html


Since taking the decision for Red to compile to Red/System code, 
Nenad has been spending additional time extending  Red/System to 
be able to do so. It will probably result in less work being needed 
on the first Red static compiler.