Slate and Agora; building the Slate VM

Shaping shaping1 at bellsouth.net
Wed Dec 29 11:36:47 PST 2004


 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 considered the environment, not just the language, because I was not sure of 
your focus.

 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.

I have ready only introductory explanations of roles.  I'm approaching that 
section of the Language Manual soon.  At this stage, however, I see complexity 
where none need exist.

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

Yes, you're right.  I took liberties with my imagination.  Four days of 
controlled systemic dehydration can make one a little dull/dopey (the semiannual 
deep tissue cleanse).  It should be over by Sunday, and then the synapses will 
be firing properly.  Bear with me.

How mousable then are the widgets (if any) in the framework?  Do they need to be 
finished, or can they be used now to assemble a browser?  I might go in this 
direction, if the widgets mostly work.  Otherwise, I would likely try to port my 
own graphics, but there is the external library issue.

 Right now, /everything/ has to be
> done in text files and then loaded if you want organized persistence for your 
> code.

Is "loading" compiling?  I'm assuming that code that has been compiled is 
sitting safely in the image and can be saved with it.  Is that correct?

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

You're not seeing the bigger grammatical picture, from the human's perspective, 
mostly because I'm not explaining it to you completely, but also because you're 
working too hard on your brain child, and perhaps suffering from a little mental 
myopia--happens to the best of us.  You are burdened by implementation details.

I will post a more thorough explanation of a pure, post-fixed-modifier 
anglogrammar for the control of a machines.  It should superpose very nicely on 
any highly plastic computer language like Slate, even Smalltalk, but not quite. 
But first I need to absorb a more of Slate's syntax and philosophy.

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

I don't see how Slate is simpler.  The roles and delegation appear to make it 
more complicated at its core.  These are inherent features, aren't they?  They 
are not constructed from the most basic items, which I now see as slots, and 
sends.  I don't think these patterns exist in the basic Agora, just nested 
blocks, message sends, slots, and a few key reifier methods to get everything 
going.  I'm not yet as familiar with Agora as I want to be, but I've read, with 
good comprehension, through several programs (large nested blocks) and found the 
language to be remarkably terse and expressive, given what you start with--or 
more likely /because/ of what you start with.  I'm only in section 2 of the 
Slate Language Manual.  I've seen how the _ and @ characters are used, but this 
seems to be a parsing strategy, not conformance to the (almost) uniform 
application of message passing.

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

I have some reading to do.

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

I think I see the problem--excess visual dynamic and congestion preclude 
coherency and perspective--and why you refer to Self as a sort of demo of 
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.
>
> 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/.

For me: little.image, vm.c, and vm.h.

I've had to do some unexpected maintenance on the PC today, including installing 
a new version of Visual Studio .NET 2003.  Version 7.0 or 7.1 will not accept 
the .vcproj or .sln files because they have been created with a newer version of 
VS.

Shaping 




More information about the Slate mailing list