Slate and Agora; building the Slate VM

[Brian Rice]

On Dec 29, 2004, at 2:36 AM, Shaping wrote:

>> 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?

What? Browsers are tools, so are irrelevant to my point. I mean that 
the semantics of delegation are unsound - it does not distinguish 
between type-oriented inheritance and object-based delegation. So there 
are unavoidable bugs (more details are on the mailing list archives).

>> 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.

Look at the Smalltalk Traits research: 
http://www.iam.unibe.ch/~scg/Research/Traits/
It flattens everything into single-inheritance, but that specific 
aspect may be disregarded as such. The current mechanism described as a 
"traitsWindow" to you in another reply acheives much of the same effect 
for us right now, and there are sure to be more changes in the future.

Note: this is not documented in the manual yet, as the changes are 
relatively recent and I am still working on a general re-organization 
of the manual's explanations. The next release will have these updates.

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

You're confused. Roles have nothing to do with delegation. Hopefully 
Nicolas' clarification helped.

>> 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?

Right now: read the fine manual (http://slate.tunes.org/doc/progman/) 
and the sources. See src/lib/*.slate and src/mobius/vm/bootstrap.slate 
to see what files are loaded into the core image. There is no browser, 
currently, just a navigating inspector in the REPL. 
src/mobius/vm/interp/map.slate must be loaded to introspect into 
roles/maps easily. Remember that this is a 0.3.x series release for a 
programming language; what you don't bring to the table probably 
doesn't exist yet.

> 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?

Repeat after me: there is no browser yet, other than the REPL 
inspector. You are confusing my answer about a GUI framework with your 
apparent need for a mousable browser. Right now, /everything/ has to be 
done in text files and then loaded if you want organized persistence 
for your code. We are /currently/ working on an in-image editor which 
should be able to abstract over this, and then a proper image-linked 
source database so that we can drop the necessary limitations of files.

FYI, since Slate has been really poor so far for development, Vim and 
Emacs syntax modes have been provided - the Emacs mode in particular 
supports running a Slate instance and evaluating code using hot-keys. 
It has a workspace (scratch buffer), but no browser. Please read the 
README file which goes over this and the source structure and so forth.

>> 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 mean both, used interchangeably. E's notion of process has no shared 
state and is based on data-flow dependencies, so it is a lot safer than 
most concurrent systems.

> Have any benchmarks been done on Slate?

Yes, but only within a C profiler. Slate itself does not yet have a 
cross-platform userland timing mechanism for code (anyone is welcome to 
write one, though).

> 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.

We could support it with a macro (in Slate, this is a parse-time 
message-send), actually; "x variable `:= 1" could be transformed into a 
base level assignment. Modifiers per se without macros complicate the 
grammar unnecessarily.

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

That's not simple from the Slate perspective - Slate is simpler, as 
someone pointed out to you. Also, Agora has no decent implementations - 
Slate was initially implemented in Common Lisp as a dynamic 
semi-compiler and was very easy to experiment with in various ways. 
Anyway, it's a moot point now.

>> 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?

You should look into the "pidgin" sources we have, which are Slate 
files translated into C code. There is a bare sketch of Pidgin here:
http://slate.tunes.org/doc/mobius/#SECTION00060000000000000000

but it is easier to understand by reading existing code. The pidgin 
code for the VM is in:
src/mobius/vm/base/
src/mobius/vm/ext/ (for primitive methods exposed to the image)

 From there, there is src/mobius/vm/platform/ which is intended to store 
platform-specific VM functionality, but has wound up being a repository 
for our extensions, since we are still formulating a build structure 
for these things. In CVS (do NOT run with this currently; use a 
separate directory tree, please) you will find sdl.(c|h|slate) which 
will do things like provide platform-independent wrappers of API calls, 
a header for these wrappers for the VM to link with, and pidgin code to 
write Slate primitives. And, as I mentioned, under src/ui/ there will 
be sub-directories for the user-land integration of this functionality.

Marshalling is performed with SmallIntegers (31-bit capacity, signed), 
and then using ByteArrays for variable-size or larger data. Further 
details you will have to discover by asking specific questions, because 
this material is still not well-documented since it is not truly 
finalized.

>> [Self] has a decidedly anti-browser focus, forcing everything into 
>> direct representation exploration,
> Do you mean graphics/morphs for every little concept?

Yes, and particularly that new objects viewed result in new morphs 
opened nearby what you're working on, and also that the code panes 
expand in-place and resize what you are usually looking at, instead of 
having one view in which your navigation occurs.

>> 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.

Yes, stick with slate-current for now. Be sure to grab the alpha vm 
sources and images that go with it, by running "make get-alpha" or 
downloading the files in http://slate.tunes.org/downloads/alpha/.

--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/