Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!news.cis.ohio-state.edu!math.ohio-state.edu!howland.erols.net!newsfeed.internetmci.com!in3.uu.net!EU.net!Norway.EU.net!nntp.uio.no!nntp-oslo.UNINETT.no!nntp-trd.UNINETT.no!news-b.uni-c.dk!news.uni-c.dk!cph-1.news.DK.net!dkuug!dknet!funny.bahnhof.se!seunet!news2.swip.net!mn6.swip.net!seunet!mn4.swip.net!green!uucp
From: "Gabor Greif" <gabor@datawatch.osn.de>
Subject: Re: Metaclasses
Content-Type: multipart/alternative; boundary="Cyberdog-AltBoundary-000B3F4F"
To: unlisted-recipients:;@cambridge.apple.com (no To-header on input)
Message-ID: <AE59B666-B40DC@192.168.1.8>
>received: from mail-out2.apple.com by mail.swip.net (8.6.8/3.01)
	id MAA15357; Mon, 9 Sep 1996 12:09:46 +0200
Precedence: bulk
X-Newsgroups-To: nntp://news.osn.de/comp.lang.dylan
Sender: owner-info-dylan@cambridge.apple.com
Content-Transfer-Encoding: 7bit
Cc: info-dylan@cambridge.apple.com
Organization: Saab Dynamics AB, RLD-Gbg, Sweden
Mime-Version: 1.0
Date: Mon, 9 Sep 1996 09:56:15 GMT
Return-Path: <owner-info-dylan@cambridge.apple.com>
X-Mailer: Cyberdog/1.1b2
Content-Length: 14764
X-News-Servers: news.osn.de
Lines: 438


--Cyberdog-AltBoundary-000B3F4F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

	Hi,

can someone out there mail me some documentation on those ominous
"LapLex" macros? As far as I have figured out they serve as a high-
level assembly language (compiling to both 68k and PPC architectures)
accessible from prefix-dylan. It seems to me the architects of Dylan
TR use this (sub-)language for performance tweaking or accessing
functions and variables not available from infix-dylan (GC, hash-
functions etc.)

Since it is not easy for me to read it, I need some help.

Am I correct in assuming that with those macros I can reach otherwise
sealed entities in the Dylan library?

## response

In article <berdahl-0509961111080001@205.178.30.4>
Eric Berdahl (berdahl@intelligentparadigm.com) wrote:

>What's a metaclass (as opposed to an instance of <class>) and what do
you
>want your metaclass to do?

A class is an object that you can pass as the first argument to
make(). [Some
of you now think: But make() is defined on instantiable <types>! That
is not
the point here.] Then a metaclass is an object you can pass to a
cascaded make:
let instance =3D make(make(<<meta>>));
	or (nice syntax, but not appropriate because of init-args)
let instance =3D <<meta>>.make.make;
That is: make on a metaclass produces instances of the class <class>.
If one
could agree on the naming convention <<meta>> for metaclasses, <class>
had
to be called <<class>> :-)
Since <class> is the only metaclass defined in the DRM and it is
sealed, there is
no way to extend the metaclass hierarchy (whose root is <class>). Only
by
subclassing <class> one can define a new behaviour that is needed to
specialize
make.

Did I manage to convey the message? (For me it lasted several days
till I
grasped it.)

The purpose for introducing new metaclasses is my desire to model
categories
of entities in a hierarchical (heterarchical) fashion:

define category science (human-activity);
	define category math (science);
	define category biology (science);
	define category social-sci (science);
		define category population-research
		(biology, social-sci, math);

	(this is pseudo-dylan!)

It is clear that such disjoint classes as <group> and <theorem> can be
part of
the category math. (In spite of not being subclasses of one-another.)
When defining <field> as a subclass of <group> one would automatically
add it to the math category.

Imagine this:

define method same-category? (a, b) =3D> same :: <boolean>;
		a . object-class . object-class
	 =3D=3D	b . object-class . object-class;
end method;

One could test:

fermats-great-theorem =3D make(<theorem>, ...)
=3D> defined fermats-great-theorem

the-field-of-rationals =3D make(<field>, ...);
=3D> defined the-field-of-rationals

same-category? (fermats-great-theorem, the-field-of-rationals)
=3D> #t

My categories are much like this UseNet newsgroups, but they allow
mixing.
Like posting to math would mean the message is routed further to
social-sci.
Another analogy could be the module system of Dylan.

BTW has someone a good workaround for this?

> Which you cannot do because <class> is sealed. Check out the
protocol on
> <class> to see if it does what you want.

 Now you can see, subclasses of <class> won=B4t do it for me.

## response end


My aim is to create a small & naive MOP that allows me to create
metaclasses (i.e. subclasses from <class>). I would package it in a
module "Dylan-MOP" and communicate only behind the scenes with
Dylan-lib. Any hints? I suppose I could do some of my research in CLOS
(which has a MOP) but since eventually I would prefer to program in
Dylan I would like to try it this way. How difficult would that be?
In the first step I do not try to subclass <function> let alone weird
things like "define class <<weird>> (<class>, <function>) ..." which
could not work because of the disjoint structure of instances of those
classes.

I would welcome any pointers to (online) literature of MOPs (I already
have the Xerox PARC MOP spec for PCL, and some basic MCL 2.0 MOP
stuff)

Were there attempts to propose a such for Dylan, and how did those
look
like? A search in info-dylan and comp.lang.dylan archives did not
reveal
anything that could be a starting point.

Thanks, (for answers to my previous questions too)

	Gabor
	
PS. Is the MOP of SOM called Interface-Repository?


--Cyberdog-AltBoundary-000B3F4F
Content-Type: multipart/mixed; boundary="Cyberdog-MixedBoundary-000B3F4F"
Content-Transfer-Encoding: 7bit


--Cyberdog-MixedBoundary-000B3F4F
Content-Type: text/enriched; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM>	Hi,


can someone out there mail me some documentation on those ominous

"LapLex" macros? As far as I have figured out they serve as a high-

level assembly language (compiling to both 68k and PPC architectures)

accessible from prefix-dylan. It seems to me the architects of Dylan

TR use this (sub-)language for performance tweaking or accessing

functions and variables not available from infix-dylan (GC, hash-

functions etc.)


Since it is not easy for me to read it, I need some help.


Am I correct in assuming that with those macros I can reach otherwise

sealed entities in the Dylan library?


## response


In article <<berdahl-0509961111080001@205.178.30.4>

Eric Berdahl (berdahl@intelligentparadigm.com) wrote:


>What's a metaclass (as opposed to an instance of
</FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED><FONTFAMI=
LY><PARAM>Courier</PARAM><<class></FONTFAMILY></FIXED></X-FONTSIZE><X-F=
ONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM>) and what
do you

>want your metaclass to do?


A class is an object that you can pass as the first argument to
</FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED><FONTFAMI=
LY><PARAM>Courier</PARAM>make()</FONTFAMILY></FIXED></X-FONTSIZE><X-FON=
TSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM>. [Some

of you now think: But </FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</=
PARAM><FIXED><FONTFAMILY><PARAM>Courier</PARAM>make()</FONTFAMILY></FIX=
ED></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatin=
o</PARAM> is defined on instantiable </FONTFAMILY></X-FONTSIZE><X-FONTS=
IZE><PARAM>12</PARAM><FIXED><FONTFAMILY><PARAM>Courier</PARAM><<types><=
/FONTFAMILY></FIXED></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FONTFAMI=
LY><PARAM>Palatino</PARAM>! That is not

the point here.] Then a metaclass is an object you can pass to a
cascaded </FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED>=
<FONTFAMILY><PARAM>Courier</PARAM>make</FONTFAMILY></FIXED></X-FONTSIZE=
><X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM>:

</FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED><FONTFAMI=
LY><PARAM>Courier</PARAM>let instance =3D
make(make(<<<<meta>>));</FONTFAMILY></FIXED></X-FONTSIZE><X-FONTSIZE><P=
ARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM>

	or (nice syntax, but not appropriate because of init-args)

</FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED><FONTFAMI=
LY><PARAM>Courier</PARAM>let instance =3D
<<<<meta>>.make.make;</FONTFAMILY></FIXED></X-FONTSIZE><X-FONTSIZE><PAR=
AM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM>

That is: </FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED>=
<FONTFAMILY><PARAM>Courier</PARAM>make</FONTFAMILY></FIXED></X-FONTSIZE=
><X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM> on a
metaclass produces instances of the class
</FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED><FONTFAMI=
LY><PARAM>Courier</PARAM><<class></FONTFAMILY></FIXED></X-FONTSIZE><X-F=
ONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM>. If one

could agree on the naming convention </FONTFAMILY></X-FONTSIZE><X-FONTS=
IZE><PARAM>12</PARAM><FIXED><FONTFAMILY><PARAM>Courier</PARAM><<<<meta>=
></FONTFAMILY></FIXED></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FONTFA=
MILY><PARAM>Palatino</PARAM> for metaclasses,
</FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED><FONTFAMI=
LY><PARAM>Courier</PARAM><<class></FONTFAMILY></FIXED></X-FONTSIZE><X-F=
ONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM> had

to be called </FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FI=
XED><FONTFAMILY><PARAM>Courier</PARAM><<<<class>></FONTFAMILY></FIXED><=
/X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</P=
ARAM> :-)

Since </FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED><FO=
NTFAMILY><PARAM>Courier</PARAM><<class></FONTFAMILY></FIXED></X-FONTSIZ=
E><X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM> is
the only metaclass defined in the DRM and it is sealed, there is

no way to extend the metaclass hierarchy (whose root is
</FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED><FONTFAMI=
LY><PARAM>Courier</PARAM><<class></FONTFAMILY></FIXED></X-FONTSIZE><X-F=
ONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM>). Only by

subclassing </FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIX=
ED><FONTFAMILY><PARAM>Courier</PARAM><<class></FONTFAMILY></FIXED></X-F=
ONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM=
> one can define a new behaviour that is needed to specialize

</FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED><FONTFAMI=
LY><PARAM>Courier</PARAM>make</FONTFAMILY></FIXED></X-FONTSIZE><X-FONTS=
IZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM>.


Did I manage to convey the message? (For me it lasted several days
till I

grasped it.)


The purpose for introducing new metaclasses is my desire to model
categories

of entities in a hierarchical (heterarchical) fashion:


</FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED><FONTFAMI=
LY><PARAM>Courier</PARAM>define category science (human-activity);

	define category math (science);

	define category biology (science);

	define category social-sci (science);

		define category population-research

		(biology, social-sci, math);</FONTFAMILY></FIXED></X-FONTSIZE><X-FONT=
SIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM>


	(this is pseudo-dylan!)


It is clear that such disjoint classes as
</FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED><FONTFAMI=
LY><PARAM>Courier</PARAM><<group></FONTFAMILY></FIXED></X-FONTSIZE><X-F=
ONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM> and
</FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED><FONTFAMI=
LY><PARAM>Courier</PARAM><<theorem></FONTFAMILY></FIXED></X-FONTSIZE><X=
-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM> can be
part of

the category </FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FI=
XED><FONTFAMILY><PARAM>Courier</PARAM>math</FONTFAMILY></FIXED></X-FONT=
SIZE><X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM>.
(In spite of not being subclasses of one-another.)

When defining </FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><F=
IXED><FONTFAMILY><PARAM>Courier</PARAM><<field></FONTFAMILY></FIXED></X=
-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PAR=
AM> as a subclass of </FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</P=
ARAM><FIXED><FONTFAMILY><PARAM>Courier</PARAM><<group></FONTFAMILY></FI=
XED></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palati=
no</PARAM> one would automatically

add it to the </FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><F=
IXED><FONTFAMILY><PARAM>Courier</PARAM>math</FONTFAMILY></FIXED></X-FON=
TSIZE><X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM>
category.


Imagine this:


</FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED><FONTFAMI=
LY><PARAM>Courier</PARAM>define method same-category? (a, b) =3D> same
:: <<boolean>;

		a . object-class . object-class

	 =3D=3D	b . object-class . object-class;

end method;</FONTFAMILY></FIXED></X-FONTSIZE><X-FONTSIZE><PARAM>12</PAR=
AM><FONTFAMILY><PARAM>Palatino</PARAM>


One could test:

</FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED><FONTFAMI=
LY><PARAM>Courier</PARAM>

fermats-great-theorem =3D make(<<theorem>, ...)

=3D> defined fermats-great-theorem


the-field-of-rationals =3D make(<<field>, ...);

=3D> defined the-field-of-rationals


same-category? (fermats-great-theorem, the-field-of-rationals)

=3D> #t</FONTFAMILY></FIXED></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><=
FONTFAMILY><PARAM>Palatino</PARAM>


My categories are much like this UseNet newsgroups, but they allow
mixing.

Like posting to </FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM>=
<FIXED><FONTFAMILY><PARAM>Courier</PARAM>math</FONTFAMILY></FIXED></X-F=
ONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM=
> would mean the message is routed further to
</FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED><FONTFAMI=
LY><PARAM>Courier</PARAM>social-sci</FONTFAMILY></FIXED></X-FONTSIZE><X=
-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM>.

Another analogy could be the module system of Dylan.


BTW has someone a good workaround for this?


> Which you cannot do because <<class> is sealed. Check out the
protocol on

> <<class> to see if it does what you want.


 Now you can see, subclasses of <<class> won=B4t do it for me.


## response end



My aim is to create a small & naive MOP that allows me to create

metaclasses (i.e. subclasses from </FONTFAMILY></X-FONTSIZE><X-FONTSIZE=
><PARAM>12</PARAM><FIXED><FONTFAMILY><PARAM>Courier</PARAM><<class></FO=
NTFAMILY></FIXED></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY>=
<PARAM>Palatino</PARAM>). I would package it in a

module "Dylan-MOP" and communicate only behind the scenes with

Dylan-lib. Any hints? I suppose I could do some of my research in CLOS

(which has a MOP) but since eventually I would prefer to program in

Dylan I would like to try it this way. How difficult would that be?

In the first step I do not try to subclass <<function> let alone weird

things like "define class <<<<weird>> (<<class>, <<function>) ..."
which

could not work because of the disjoint structure of instances of those

classes.


I would welcome any pointers to (online) literature of MOPs (I already

have the Xerox PARC MOP spec for PCL, and some basic MCL 2.0 MOP
stuff)


Were there attempts to propose a such for Dylan, and how did those
look

like? A search in info-dylan and comp.lang.dylan archives did not
reveal

anything that could be a starting point.


Thanks, (for answers to my previous questions too)


	Gabor

	

PS. Is the MOP of SOM called Interface-Repository?</FONTFAMILY></X-FONT=
SIZE>
--Cyberdog-MixedBoundary-000B3F4F--

--Cyberdog-AltBoundary-000B3F4F--


