Path: news.daimi.aau.dk!not-for-mail
From: Morten Grouleff <grouleff@daimi.aau.dk>
Newsgroups: comp.lang.beta
Subject: Re: Loki Paper 1: Overview
Date: Thu, 19 Mar 1998 17:24:43 +0100 (MET)
Organization: DAIMI, Computer Science Dept. at Aarhus University
Lines: 71
Approved: mailtonews@daimi.aau.dk
Distribution: world
Message-ID: <199803191624.RAA19911@noatun.mjolner.dk>
Reply-To: Morten Grouleff <grouleff@daimi.aau.dk>
NNTP-Posting-Host: daimi.daimi.aau.dk
Xref: news.daimi.aau.dk comp.lang.beta:11467

John Cowan <cowan@locke.ccil.org> writes:

> 			The Loki Papers
> 			Paper 1: Overview
> 			Version 0.1
> 			John Cowan <cowan@ccil.org>
> 
> The Loki Papers is a series of documents which I will be posting off and
> on to comp.lang.beta in the hope of stirring some interest.  The purpose
> of the Loki Project, which these papers document, is to provide a
> compiler and support classes for translating Beta into the Java
> language.  Although Beta and Java are very different languages in syntax
> as well as semantics, Java is flexible enough that compiling Beta into
> it does not seem an utterly impossible proposition.

True.

> In general, the Java object model is accepted, not flouted, but some
> Java infrastructure is created in each pattern by the compiler.  Beta
> patterns are implemented as Java classes, subpatterns are subclasses, and
> pattern attributes are inner classes.  Both static and dynamic object
> attributes are Java instance variables.  The do-part of each Beta pattern
> is implemented as a hidden Java method, and hidden methods are also
> created for implementing Beta's "inner" imperative and to optimize
> certain uses of inserted objects.

This is not very precise.  Lets try some examples. (see below)
 
> The Beta fragment architecture is mostly abstracted away by the
> compiler.  It is not yet clear to me whether it should attempt to do
> more than syntax and static semantics checking when compiling less
> than a complete program.  Generation of Java code may need to wait until
> all the Beta code is available.  The fragment visibility model, at any
> rate, is incompatible with Java's visibility model: all Beta classes
> and members would be declared "public" in the Java code.

I agree that it's okay to ignore the fragment system for a start.

How would you translate this into Java: 
=======================================
ORIGIN '~beta/basiclib/v1.6/betaenv';

-- program:descriptor --
(#
   P1: 
     (# 
        A:< (# do '1'->put; INNER #) 
     #);
   
   P2: P1
     (# 
        A::(# do '2'->put; INNER #);
        C: A(# do '3'->put; INNER #);
     #);
   
   P: @P2;
   
do P.C(# do '4'->putLine #) (* Should print '1234' *)
#)
=======================================
The above compiles with the Mjølner compiler and does indeed print '1234'

The catch it the final-binding of the vitual A which is then used as a
superpattern for C.

Lets get an inspiring exchange of ideas going here...
-- 
**  Morten Grouleff   <http://www.grouleff.dk/>          **
**  Earthworm Jim PC: <http://www.grouleff.dk/ewj.html>  **
**              Aggression comes back to you             **