Slate and Agora; building the Slate VM

Shaping shaping1 at bellsouth.net
Wed Dec 29 02:36:01 PST 2004


> I don't think I've thought about Agora (see 
> http://prog.vub.ac.be/research/agora/ ) since then. We do have Self-style 
> delegation, although more and more we are abstracting over it, since Self's 
> style is pretty much unsound.

Unsound because there is no organizing browser?

 Our gradual goal is to
> shape it into a system of behavior composition (think of safe mixin 
> operators).

We may also need a way to view mixins taxonometrically, which brings us back to 
classes but not in the usual way.  I don't know the mixin perspective I'll need 
yet to make concrete suggestions.


 More importantly, Slate has object-based multiple dispatch,
> which changes the character of the language a bit, but makes it more powerful 
> in return.

I read about this in the tutorial, but I'm not satisfied yet by the role 
delegation strategy.  It seems to be in flux.


>
> Slate also has a lot of very powerful core libraries, more powerful than 
> Smalltalk's or Self's for collections and streams, for example. Much of the 
> reason of developing this new language was so that many more powerful 
> infrastructure libraries could be built, to allow a kind of continuous and 
> propagating elimination of design complexity. So far this has exceeded our 
> expectations, so much so that we won't go back to those old languages.

Interesting.  How do I look at the behavior of these core libraries?  Is the 
browser complete enough to do this?  Am I constrainted to investigate how things 
work by executing statements sequentially at the REPL?  How do I get an overview 
of system structure and behavior after I've developed a few variant prototypes, 
and can no longer accurately remember what I have in the image?


>> Having developed almost exclusively in Smalltalk (VW mostly) for the last 
>> decade, I lean toward Agora94.  I want something I can carry forward easily 
>> with browsing tools I know, but I'm willing to consider new directions. 
>> About when will there be a basic GUI framework for Slate?
>
> It already exists, but is not entirely complete. See src/ui/* in the Slate 
> distribution. It's a hybrid of the Morphic and CLIM frameworks - design 
> documents are at http://slate.tunes.org/doc/ui/ . There are backends 
> (abstractions over portable subsets of various bindings, could also include 
> PostScript and HTML) in progress for X11 and SDL, although they aren't 
> complete. There's also code for the console which is just now being developed 
> and may be a backend soon.

Does the browser work independently of the REPL?  I'm assuming a text editor 
where statements are typed and saved.  What happens to the statements after they 
are saved and compiled into the system?  How are they classified and viewed 
latter?  Am I just viewing .slate text files?


>
> Now, the question you /really/ want answered is when a browsing framework will 
> exist within this.

Right.

 I have already intended to port the
> OmniBrowser framework from Squeak, but right now my main concern is to make 
> Slate a safely-concurrent language, using the influence of E (see 
> http://erights.org/ ). Note: it's a limit right now that Slate is 
> single-threaded.

Do you mean a proper OS thread in an OS process, or do you mean a 
Smalltalk-like, lightweight process running in a block at a certain priority, 
such that each thread is really just a time-slice on a single OS thread in an OS 
process?

I don't know the OmniBrowser--but it sounds good!  I stopped using Squeak around 
2000.  I enjoyed the experience, but always I am pushed back to VW for it 
namespaces (so that I can experiment freely) and its computational speed, which 
is greater (in most cases) than that of the other Smalltalks I've tested (VW, 
VAST, Dolphin, MT, Squeak).

I have a recursive, /divisional/, not accretive approach to composing shapes in 
the client of a window (or Region).  The approach is not as practical (small), 
as it is elegant and easy to comprehend.  But that will change with proper 
factoring, which I /cannot/ admittedly do in Smalltalk, and I am usually the 
last to admit that Smalltalk has any problems--but it does.  I want to continue 
developing this graphic framework, to see where it goes.  I need to ascertain 
whether computer hardware must be more powerful for framework to be genrally 
useable in common production envionments.


>
> Right now the development focusses are to enhance the basic REPL and debugger 
> and in-image editing capabilities, which all the basic facilities exist for. 
> And our resident systems programmer is working on the direct-to-native dynamic 
> compiler framework (see src/mobius/optimizer/ although there is a super-simple 
> PIC-using compiler which might see the light of day much sooner).

Have any benchmarks been done on Slate?

>
> Slate is strictly more expressive than Agora, and the syntax is more flexible, 
> so I don't see the point of an Agora layer atop it if that is what you mean. 
> However, if it convinces you of this, or informs you on how to extend Slate 
> with whatever Agora features remain outstanding, then perhaps it is a 
> worthwhile exercise. ;)
>
I don't know all of the Slate syntax yet, but it appears to involve more than 
just a message send.  Agora's MOP is a just the message send.  In Slate you have 
to do assignements (a special case, not a message send, not as uniform as Agora, 
but perhaps no worse).  I like:

addSlot: #x valued: 1

But, because x is the slot and #x is its name, should we not use?:

addSlotNamed: #x valued: 1

In Agora, we have

x VARIABLE: 1

Strange is the "creatio ex nihio" (creation out of nothing) style, which treats 
the x as just a syntactic entity (it can't be anything else because it hasn't 
been defined before the sending of VARIABLE:).  I don't like the loud caps, and 
would change them to lowercase and use embolding or color, but over all the 
reifier is graceful.  The full-form post-modified grammar for this would be:

x variable valued: 1, in which only modifiers (not verbs) are used.  The first 
is an adjective proper (or a noun in apposition), and the second is a past 
participle functioning as an adjectival modifier.  Assigning values is so 
pervasive, we tend to use just the ':' when there is no other word 
involved--hence the contaction.

Agora is so simple that I was wondering why no one has used it to design, say, 
Slate.  Would that not work well?


> Alternatively, the OpenGL experience would be interesting for the guys working 
> on UI backends, since OpenGL (well, significantly, 3d shapes and embedding) is 
> a valid backend. Please look at the UI code if the interest tickles you, and 
> feel free to ask more questions.

It does interest me.  To start my porting and experimenting with OpenGL, I need 
to connect to opengl32.dll and glu.dll or statically link opengl32.lib and 
glu.lib.  Can we marshall data from Slate to a DLL and back.  What's possible 
now?


> Hopefully you've tried Self out, at least.

I have wanted to do so, but have not.  I talked with Jecel many times about 
Self, but was not able to find one that worked on Windows, by the time I had to 
move on to other things.  I also had a concern about Self's compiler complexity.

 It has a decidedly
> anti-browser focus, forcing everything into direct representation exploration,

Do you mean graphics/morphs for every little concept?


> Under src/mobius/vm/platforms/windows/ there is a .sln and .vcproj but no 
> .dsp. Please see if these work for you. If not, adjust them or do what you 
> need, and send us what does work and we will incorporate them.

There is no 'windows' directory under 'platforms'.  I download slate-0.3.tgz, 
not slate-current.tar.gz, which I have just disovered contains it.


> Isn't 6.0 a really old version?

Yes, a couple steps back, as Todd and David say.  I have VS .NET 2003 but not 
the MSDN Help for it; hence, I went back to 6.0.

> You should only need MinGW (see http://www.mingw.org/ ), which is a much 
> lighter setup, if you just need the GCC support.

I'll use this if I must.  I'm going to try the .sln file now.


Shaping 





More information about the Slate mailing list