I've read about 60 pages and a question came to my mind:
Authors talk about dynamic class creation, inspecting
classes at runtime, etc. How are these features compared
to "reflection" in Java, C#, etc? I don't know much
about that but as far as I know Java and C# programmers
can also introspect classes during runtime, create classes
on-the-fly, etc. which they call the "reflection" property
of their language, right?
Is MetaObject protocol for CLOS similar to "reflection"
in those languages? Is it something more, something less?
Has some advantages that reflection in Java and C# don't
have?
Maybe the masters well versed in both languages can enlighten
me.
Thanks in advance.
Happy hacking.
--
Emre Sevinc
eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr
there has been some addition in capabities with the recent annotations
mechanism added in java 5. annotations are essentially metadata which
can be (if specified) retained and obtained at runtime.
c++ doesnt have much support for reflection. dont know about c#.
Python does have a metaclass mechanism and also allows creation of
classes at runtime.
so its a partial answer to your question.
rahul
learning young lisper
Reflection originally means both introspection and intercession (these
are the technical terms). Introspection allows you to find out
information about elements of your program - classes, variables,
methods, functions, etc. What the Java folks called reflection in the
beginning is indeed just introspection.
Intercession is a way to modify the characteristics of the elements of
your program. So intercession allows you to change the properties of
classes, variables, methods, functions, etc.
Reflection was originally "invented" by Brian Smith in the form of
procedural reflection - i.e., you basically have a notion of interceding
procedure calls, inspecting the environment(s) that are active during
those calls, and possibly changing the way the program continues its
execution. If you allow programmers to intercede at each and every
single step of your program execution, though, your programs slow down
considerably, even if noone intercedes anything, because the runtime has
to continually check whether someone wants to do something additionally
or not.
For that reason, Brian Smith and Jim des Rivieres (if I understand
correctly, it was those two guys) implemented reflection by dividing the
program into levels, so that one could specify at which level you want
to intercede the program execution. The levels for which you don't
intercede can be executed "at full speed", while the other levels have
to run your additional code.
It was then discovered that this actually leads to an object-oriented
design of the reflection facilities, because the notion of dividing
programs into levels and specifying different behavior at different
levels is more or less exactly what you do in an object-oriented
hierarchy. So, for example, in a class hierarchy, the classes higher up
in the hierarchy define the "base" behavior while the classes that
inherit from those superclasses define the additional behavior. Next,
when you disallow programmers from changing the definitions of the base
classes, you can actually implement the runtime much more efficiently
because you can check whether a given object is an instance of a base
class or not, and if it's an instance of a base class you can run
optimized versions of the methods defined on those classes that don't
call the (non-existent) code of subclasses.
The CLOS Metaobject Protocol is essentially that idea carried through
the end.
Java reflection is not even close. Java has meta-level objects that
describe classes, methods, fields, etc., but there is no way to change
them. However, there are some little opportunities to get something
along the lines of a full-blown metaobject protocol:
- You can implement proxy classes - see
java.lang.reflect.InvocationHandler. This allows you to intercept method
calls to objects.
- There is a debugging API that allows you to change the definition of a
class (including its methods) at runtime, which in principle allows you
to add additional behavior to methods.
- Finally, you can intercept class loading and modify the bytecode for a
class before it enters the virtual machine. This is the most powerful
way to achieve similar effects as those of a MOP, but is not a proper
MOP in its own right. (You don't specify the new behavior as methods for
meta-level classes, but you rather just modify a byte stream.)
The latter has been used to define proper (load-time) metaobject
protocols, though, for example Javassist and Reflex.
These things are much more complicated to achieve in Java than in CLOS,
though, even with such frameworks. Furthermore, I am convinced that a
full runtime metaobject protocol is essential. (Load-time or
compile-time metaobject protocol can lead to more efficient code, that's
why they have been pursued in the past, but I think these efficiency
gains are too small to be important enough in the long run. The
flexibility of a runtime metaobject protocal is more important because
it gives you more expressivity IMHO.)
I think the situation for C# is similar to that for Java, although they
have added a few more practical stuff from the beginning. For example,
.NET comes with a library that gives you a (modifiable) representation
of their bytecode format, and I recall seeing a presentation about a
load-time bytecode modification approach for .NET that was a lot simpler
than what I have seen in the Java world. But that's all I can tell about C#.
Metaobject protocols exist for other languages (and also for other
domains than language implementations). A relatively old list of
metaobject protocols is given at
http://www2.parc.com/csl/groups/sda/projects/mops/existing-mops.html
Eric Tanter provides an excellent and recent overview of reflection,
metaobject protocols and aspect-oriented programming (which is another
form of reflection, in a sense) in his PhD thesis about Reflex - see
http://www.dcc.uchile.cl/~etanter/
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
> java reflection does not allow you to create classes at runtime.
It does, but not directly. You can, of course, create a class file (that
is, the corresponding bytecode stream) at runtime, and then cause the
class loader to load that class. If you implement your own class loader,
you could even do this without writing temporary files to a hard disk,
or some such.
Jerry
Do you happen to have a link to Oolong? I couldn't find anything
useful... I've used Jasmin in the past, but it isn't really
well-maintained either.
--
My mouth says the words, my brain is thinking monstertrucks.
Joey (Friends)
You can do that in C/C++/Objective-C and other languages too. That's
what Xcode on MacOSX does.
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
__Pascal Bourguignon__ http://www.informatimago.com/
> "Rahul" <cli...@gmail.com> writes:
>> Pascal Costanza wrote:
>>> > java reflection does not allow you to create classes at runtime.
>>>
>>> It does, but not directly. You can, of course, create a class file (that
>>> is, the corresponding bytecode stream) at runtime, and then cause the
>>> class loader to load that class. If you implement your own class loader,
>>> you could even do this without writing temporary files to a hard disk,
>>> or some such.
>>
>> Thank you for the information.. Never thought of that !!
>
> You can do that in C/C++/Objective-C and other languages too. That's
Create classes during runtime in C?
(ok, ok don't hit me, don't hit me... this MOP stuff is just
making my head dizzy, I'm trying to position it and compare it :)
> Pascal Bourguignon <sp...@mouse-potato.com> writes:
>
>> "Rahul" <cli...@gmail.com> writes:
>>> Pascal Costanza wrote:
>>>> > java reflection does not allow you to create classes at runtime.
>>>>
>>>> It does, but not directly. You can, of course, create a class file (that
>>>> is, the corresponding bytecode stream) at runtime, and then cause the
>>>> class loader to load that class. If you implement your own class loader,
>>>> you could even do this without writing temporary files to a hard disk,
>>>> or some such.
>>>
>>> Thank you for the information.. Never thought of that !!
>>
>> You can do that in C/C++/Objective-C and other languages too. That's
>
> Create classes during runtime in C?
Just have a look at how gcl does it. gcl does everything thru gcc!
> (ok, ok don't hit me, don't hit me... this MOP stuff is just
> making my head dizzy, I'm trying to position it and compare it :)
--
"Debugging? Klingons do not debug! Our software does not coddle the
weak."
> [...]
> up in the hierarchy define the "base" behavior while the classes that
> inherit from those superclasses define the additional behavior. Next,
> when you disallow programmers from changing the definitions of the
> base classes, you can actually implement the runtime much more
> efficiently because you can check whether a given object is an
> instance of a base class or not, and if it's an instance of a base
> class you can run optimized versions of the methods defined on those
> classes that don't call the (non-existent) code of subclasses.
>
> The CLOS Metaobject Protocol is essentially that idea carried through
> the end.
Hmm, reading your words ring a few bells, similar to what AMOP
authors tell about on-stage objects, backstage objects, etc. And
redefining being *backstage*, being able to modify objects
that I have created.
>
> Java reflection is not even close. Java has meta-level objects that
> describe classes, methods, fields, etc., but there is no way to change
> them. However, there are some little opportunities to get something
> along the lines of a full-blown metaobject protocol:
>
> - You can implement proxy classes - see
> java.lang.reflect.InvocationHandler. This allows you to intercept
> method calls to objects.
> - There is a debugging API that allows you to change the definition of
> a class (including its methods) at runtime, which in principle allows
> you to add additional behavior to methods.
> - Finally, you can intercept class loading and modify the bytecode for
> a class before it enters the virtual machine. This is the most
> powerful way to achieve similar effects as those of a MOP, but is not
> a proper MOP in its own right. (You don't specify the new behavior as
> methods for meta-level classes, but you rather just modify a byte
> stream.)
So, you say that in Java it is possible to change a class, add/remove
properties, add/remove methods (did I get it right?). I can
change the bytecode before it is loaded but this is low-level
stuff, not modifying a class using Java constructs themselves,
right? And once the class is loaded, I'm limited in some way.(?)
>
> The latter has been used to define proper (load-time) metaobject
> protocols, though, for example Javassist and Reflex.
Are they written in Java, can they be counted as simply "extending"
the language mechanism (I assume this can be said for MOP, using
simply the CLOS itself to extend itself, but of course I'm
nothing but a confused newbie, that's why I ask).
> These things are much more complicated to achieve in Java than in
> CLOS, though, even with such frameworks. Furthermore, I am convinced
> that a full runtime metaobject protocol is essential. (Load-time or
> compile-time metaobject protocol can lead to more efficient code,
> that's why they have been pursued in the past, but I think these
> efficiency gains are too small to be important enough in the long
> run. The flexibility of a runtime metaobject protocal is more
> important because it gives you more expressivity IMHO.)
Let me rephrase it again: You say that Java has load-time (just
before loading the classes into virtual machine) and/or
compile-time metaobject protocol and this contrasts with
Common Lisp MOP which lets you play with classes and methods
during runtime, right?
> I think the situation for C# is similar to that for Java, although
> they have added a few more practical stuff from the beginning. For
> example, .NET comes with a library that gives you a (modifiable)
> representation of their bytecode format, and I recall seeing a
> presentation about a load-time bytecode modification approach for .NET
> that was a lot simpler than what I have seen in the Java world. But
> that's all I can tell about C#.
The only detailed example of reflection in C# I know of is from
the book Programming C#, 2nd Edition by Jesse Liberty and there's
a full chapter at that URL:
http://www.oreilly.com/catalog/progcsharp2/chapter/ch18.html
Basically the author states that:
"Reflection is generally used for any of four tasks:
Viewing metadata:
This might be used by tools and utilities that wish to
display metadata.
Performing type discovery:
This allows you to examine the types in an assembly and
interact with or instantiate those types. This can be useful
in creating custom scripts. For example, you might want to
allow your users to interact with your program using a script
language, such as JavaScript, or a scripting language you
create yourself.
Late binding to methods and properties:
This allows the programmer to invoke properties and methods on
objects dynamically instantiated based on type discovery. This is
also known as dynamic invocation.
Creating types at runtime (Reflection Emit):
The ultimate use of reflection is to create new types at runtime
and then to use those types to perform tasks. You might do this
when a custom class, created at runtime, will run significantly
faster than more generic code created at compile time. An example
is offered later in this chapter."
In the "reflection emit" section, the author describes
a few methods and all of them except the last one includes
writing to a file the description of the class and
then compiling and loading and using it. And in the
last method, he "emits" MSIL opcodes directly (without
writing to a file) which leads to creation of a .NET
"assembly" whose methods can be invoked. However, I think
this is similar to what you said about Java, e.g., creating
some kind of bytecode that corresponds to a class and
then using it.
> Metaobject protocols exist for other languages (and also for other
> domains than language implementations). A relatively old list of
> metaobject protocols is given at
> http://www2.parc.com/csl/groups/sda/projects/mops/existing-mops.html
>
> Eric Tanter provides an excellent and recent overview of reflection,
> metaobject protocols and aspect-oriented programming (which is another
> form of reflection, in a sense) in his PhD thesis about Reflex - see
> http://www.dcc.uchile.cl/~etanter/
Thank you very much for the links, I'll check them out.
By the way, the AMOP is about 14 years old and does it still
reflect the MOP in Common Lisp or are there additions, modifications,
etc. to MOP?
Happy hacking,
> (ok, ok don't hit me, don't hit me... this MOP stuff is just
> making my head dizzy, I'm trying to position it and compare it :)
It was the same for me in the beginning. But it's actually (relatively)
straightforward. Have you understood the notion of a metacircular
interpreter? That's an interpreter that is written in its own language.
The CLOS MOP is "just" a metacircular implementation of CLOS, that is
CLOS implemented in itself. If you got that, it should become clear that
then you can also extend CLOS by providing your own subclasses for the
CLOS implementation.
There is one problem I can see with AMOP: It focuses too much on how a
MOP is implemented, and very little on how it can be used. It should
have provided more examples - and that's what I am trying to achieve
with the Closer project over time, to provide more examples of how to
use the CLOS MOP.
That's why I typically recommend Andreas Paepcke's "User-Level Language
Crafting" as an introduction to the CLOS MOP before reading AMOP itself.
Paepcke's paper manages to get a better feel on how the MOP can be used,
IMHO.
> Hmm, reading your words ring a few bells, similar to what AMOP
> authors tell about on-stage objects, backstage objects, etc. And
> redefining being *backstage*, being able to modify objects
> that I have created.
...modify _metaobjects_ that you have created. Of course, this
ultimately means modifying base-level objects, but when you write
meta-level extensions, you are focusing on the meta-level objects (i.e.,
objects that stand for classes, slots, generic functions, methods, etc.).
> So, you say that in Java it is possible to change a class, add/remove
> properties, add/remove methods (did I get it right?). I can
> change the bytecode before it is loaded but this is low-level
> stuff, not modifying a class using Java constructs themselves,
> right? And once the class is loaded, I'm limited in some way.(?)
In Java, once a class is loaded, you cannot change its structure
anymore. That is, you cannot change the number and types of fields, and
you cannot change the number and signatures of methods anymore. If you
want to do that, you have to do that at load-time (or compile time, of
course). What you can change at runtime is the definition of methods,
that's it.
(Sun has a working implementation of the JVM in their research labs in
which you can actually change the class structure in more depth, but
that's considered dangerous and therefore not released to the public.(!)
At least that was the state of affairs a few years ago. Maybe they have
added a few things, but I am not keeping track of the JVM anymore.)
>>The latter has been used to define proper (load-time) metaobject
>>protocols, though, for example Javassist and Reflex.
>
> Are they written in Java, can they be counted as simply "extending"
> the language mechanism (I assume this can be said for MOP, using
> simply the CLOS itself to extend itself, but of course I'm
> nothing but a confused newbie, that's why I ask).
Yes. I think this becomes more useful, btw, with the annotations they
have introduced in JDK 5.0 - then it also becomes more clear that it is
indeed a language extension mechanism. Annotations are kind of
user-defined modifiers, like public/protected/private, static, abstract,
transient, volatile, etc. The load-time class modification approaches
can take this annotations into account and change the bytecode
accordingly, which amounts to providing a language extension facility.
Kind of like macros through the backdoors.
> Let me rephrase it again: You say that Java has load-time (just
> before loading the classes into virtual machine) and/or
> compile-time metaobject protocol and this contrasts with
> Common Lisp MOP which lets you play with classes and methods
> during runtime, right?
Right.
> By the way, the AMOP is about 14 years old and does it still
> reflect the MOP in Common Lisp or are there additions, modifications,
> etc. to MOP?
Yes, it hasn't changed since then. Some suggestions have been made to
change parts of the specification. For example, google for "Kiczales" in
comp.lang.lisp and comp.lang.clos, and you will find a few discussions.
There is also a paper published in the book "Advances in Object-Oriented
Metalevel Architectures and Reflection", edited by Chris Zimmermann,
with some more detailed suggestions. But none of them have caught on.
This is mainly because the balance between giving the programmer of a
CLOS implementation more possibilities to optimize things and the user
of the MOP more flexilibity to change them is a delicate issue. For this
reason, in fact none of the CLOS implementations ever implemented the
full specification, as far as I can tell. All of them deviate in some
regard or the other. That's why you can find compatibility libraries in
several places that try to make up for some of the incompatibilities of
CLOS MOP implementations. My own Closer to MOP project is one of those,
and I hope to provide a somewhat more general approach than others that
typically focus on what is needed for some concrete project.
My overall impression is that the CLOS MOP specification works quite
well, and is indeed successfully used in practice. However, there are
some things that are underspecified, or not quite right. The AMOP
specification itself clearly states that it shouldn't be taken as the
final word on that matter. So there is definitely room for improvement.
> Emre Sevinc wrote:
>
>> (ok, ok don't hit me, don't hit me... this MOP stuff is just
>> making my head dizzy, I'm trying to position it and compare it :)
>
> It was the same for me in the beginning. But it's actually
> (relatively) straightforward. Have you understood the notion of a
> metacircular interpreter? That's an interpreter that is written in its
> own language.
Well, I heard about it a lot in context of Lisp, Scheme and PROLOG
however I don't have any hands-on experience implementing such
construct (maybe it is time to go back to Purple Book? Or
are there any other text that explains this subject matter (using
Common Lisp maybe)).
> The CLOS MOP is "just" a metacircular implementation of
> CLOS, that is CLOS implemented in itself. If you got that, it should
> become clear that then you can also extend CLOS by providing your own
> subclasses for the CLOS implementation.
Yes, even thought I don't have a very deep and complete
understanding of metacircular mechanism I can realize that
the authors are using the CLOS in order to create something
resembling CLOS, a subset of object oriented programming in Lisp.
(They say that, and also at some place they talk about "envrionment"
keyword in functions, tell that CL doesn't have such and such
environment support but they assume that and later they make
do without it, I'm confused at that point too but I've just
read about 50 pages so maybe it'll be clear later what they
exactly mean).
> There is one problem I can see with AMOP: It focuses too much on how a
> MOP is implemented, and very little on how it can be used. It should
> have provided more examples -
Something like a reference manual, that's what I felt too. A book
titled "Where and how to apply MOP - Real Life Examples" would
be fantastic I believe.
>and that's what I am trying to achieve
> with the Closer project over time, to provide more examples of how to
> use the CLOS MOP.
Is it some kind of collections of examples or kind of framework?
> That's why I typically recommend Andreas Paepcke's "User-Level
> Language Crafting" as an introduction to the CLOS MOP before reading
> AMOP itself. Paepcke's paper manages to get a better feel on how the
> MOP can be used, IMHO.
I've checked out my HDD and it is already there (for about 10
months!), Bülent M. had also advised me to read that paper
and I think the time has come to be brave and dive into it :)
--
"I'm a Lisp variable -- bind me!"
> Emre Sevinc wrote:
>
>> Hmm, reading your words ring a few bells, similar to what AMOP
>> authors tell about on-stage objects, backstage objects, etc. And
>> redefining being *backstage*, being able to modify objects
>> that I have created.
>
> ...modify _metaobjects_ that you have created. Of course, this
> ultimately means modifying base-level objects, but when you write
> meta-level extensions, you are focusing on the meta-level objects
> (i.e., objects that stand for classes, slots, generic functions,
> methods, etc.).
>
>> So, you say that in Java it is possible to change a class, add/remove
>> properties, add/remove methods (did I get it right?). I can
>> change the bytecode before it is loaded but this is low-level
>> stuff, not modifying a class using Java constructs themselves,
>> right? And once the class is loaded, I'm limited in some way.(?)
>
> In Java, once a class is loaded, you cannot change its structure
> anymore. That is, you cannot change the number and types of fields,
> and you cannot change the number and signatures of methods anymore. If
> you want to do that, you have to do that at load-time (or compile
> time, of course). What you can change at runtime is the definition of
> methods, that's it.
OK. Now I can contrast CLOS MOP with Java's reflection much
more clearly.
>
> (Sun has a working implementation of the JVM in their research labs in
> which you can actually change the class structure in more depth, but
> that's considered dangerous and therefore not released to the
> public.(!) At least that was the state of affairs a few years
> ago. Maybe they have added a few things, but I am not keeping track of
> the JVM anymore.)
>
>>>The latter has been used to define proper (load-time) metaobject
>>>protocols, though, for example Javassist and Reflex.
>> Are they written in Java, can they be counted as simply "extending"
>> the language mechanism (I assume this can be said for MOP, using
>> simply the CLOS itself to extend itself, but of course I'm
>> nothing but a confused newbie, that's why I ask).
>
> Yes. I think this becomes more useful, btw, with the annotations they
> have introduced in JDK 5.0 - then it also becomes more clear that it
> is indeed a language extension mechanism. Annotations are kind of
> user-defined modifiers, like public/protected/private, static,
> abstract, transient, volatile, etc. The load-time class modification
> approaches can take this annotations into account and change the
> bytecode accordingly, which amounts to providing a language extension
> facility. Kind of like macros through the backdoors.
"Kind of like macros through the backdoors." An instance of
Greenspun's Tenth Rule in action again?
>> Let me rephrase it again: You say that Java has load-time (just
>> before loading the classes into virtual machine) and/or
>> compile-time metaobject protocol and this contrasts with
>> Common Lisp MOP which lets you play with classes and methods
>> during runtime, right?
>
> Right.
Thanks a lot, having somebody well-versed in both
languages talk about the differences sharply helps
indeed.
>> By the way, the AMOP is about 14 years old and does it still
>> reflect the MOP in Common Lisp or are there additions, modifications,
>> etc. to MOP?
>
> Yes, it hasn't changed since then. Some suggestions have been made to
> change parts of the specification. For example, google for "Kiczales"
> in comp.lang.lisp and comp.lang.clos, and you will find a few
>
> [...]
>
> of the MOP more flexilibity to change them is a delicate issue. For
> this reason, in fact none of the CLOS implementations ever implemented
> the full specification, as far as I can tell. All of them deviate in
> some regard or the other. That's why you can find compatibility
> libraries in several places that try to make up for some of the
> incompatibilities of CLOS MOP implementations. My own Closer to MOP
> project is one of those, and I hope to provide a somewhat more general
> approach than others that typically focus on what is needed for some
> concrete project.
I hope you'll provide good documentation and a few detailed
real life examples, too ;-)
> My overall impression is that the CLOS MOP specification works quite
> well, and is indeed successfully used in practice. However, there are
> some things that are underspecified, or not quite right. The AMOP
> specification itself clearly states that it shouldn't be taken as the
> final word on that matter. So there is definitely room for improvement.
By the way, googleing for CLOS MOP has returned a recent
project which used CLOS MOP and I was happy to see that:
- SWCLOS: A Semantic Web Processor on Common Lisp Object System
http://iswc2004.semanticweb.org/demos/32/
And a not-so-recent one:
- Large-Scale Persistent Object Systems for Corpus
Linguistics and Information Retrieval
> Has [the CLOS MOP] some advantages that reflection in Java and C#
> don't have?
A couple of years back I was working on a project that made heavy use
of CLOS. At one point in the middle of hacking, I realized that the
class I was working on really ought to be two classes, one that
inherited from the other. I edited the file that defined the class,
reloaded and continued hacking.
About 3 minutes later it hit me. I didn't do something simple like
add or remove a slot or redefine a method, I just dynamically changed
the topology of the class hierarchy and didn't bother to recompile
everything. But it all still worked.
-----
In the CLOS MOP, you can change the heart of the object system. You
could make it all single-inheritance, single-dispatch, and interfaces
if you wanted. Try using the Java MOP to turn Java into a proper
generic-function based object system.
> Something like a reference manual, that's what I felt too. A book
> titled "Where and how to apply MOP - Real Life Examples" would
> be fantastic I believe.
This comes close, directly from the horse's mouth:
Open Implementations and Metaobject Protocols
Gregor Kiczales, Andreas Paepcke
http://www2.parc.com/csl/groups/sda/publications/papers/Kiczales-TUT95/for-web.pdf
See also this LtU item:
http://lambda-the-ultimate.org/classic/message5820.html
And this looks like the published version of the MOP notes:
http://www.amazon.com/exec/obidos/tg/detail/-/0262111926/002-3648868-3484007?v=glance
I don't know whether the book was actually published:
http://www.amazon.com/exec/obidos/tg/detail/-/0262611031/002-3648868-3484007?v=glance&vi=reviews
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- CFFI: Foreign Function Interface
> By the way, googleing for CLOS MOP has returned a recent
> project which used CLOS MOP and I was happy to see that:
>
>
> - SWCLOS: A Semantic Web Processor on Common Lisp Object System
> http://iswc2004.semanticweb.org/demos/32/
Thanks for the link.
Now, if anyone could actually explain to me what people are doing with
these semantic web approaches, I would be really thrilled. Currently, I
don't have a clue.
Anyone knows what that is about?
> And a not-so-recent one:
>
> - Large-Scale Persistent Object Systems for Corpus
> Linguistics and Information Retrieval
Thanks,
What's the "Purple Book"?
In the context of Lisp, I can strongly recommend to read the following
papers:
- Paul Graham, The Roots of Lisp, http://www.paulgraham.com/rootsoflisp.html
- Guy Steele, Gerald Sussman, The Art of the Interpreter,
http://library.readscheme.org/page1.html
...in that order. I think these are the papers that explain the concept
the best.
>>and that's what I am trying to achieve
>>with the Closer project over time, to provide more examples of how to
>>use the CLOS MOP.
>
> Is it some kind of collections of examples or kind of framework?
A collection of examples. But not toy examples. ContextL is one of them,
for example.
>>That's why I typically recommend Andreas Paepcke's "User-Level
>>Language Crafting" as an introduction to the CLOS MOP before reading
>>AMOP itself. Paepcke's paper manages to get a better feel on how the
>>MOP can be used, IMHO.
>
> I've checked out my HDD and it is already there (for about 10
> months!), Bülent M. had also advised me to read that paper
> and I think the time has come to be brave and dive into it :)
It's easier to read than AMOP, IMHO.
> Emre Sevinc <em...@bilgi.edu.tr> writes:
>
>>Something like a reference manual, that's what I felt too. A book
>>titled "Where and how to apply MOP - Real Life Examples" would
>>be fantastic I believe.
>
> This comes close, directly from the horse's mouth:
>
> Open Implementations and Metaobject Protocols
> Gregor Kiczales, Andreas Paepcke
> http://www2.parc.com/csl/groups/sda/publications/papers/Kiczales-TUT95/for-web.pdf
I think they rather focus on how to apply the principles of a metaobject
protocol to other domains than language implementations, not so much on
how to use the CLOS MOP.
> See also this LtU item:
>
> http://lambda-the-ultimate.org/classic/message5820.html
>
> And this looks like the published version of the MOP notes:
>
> http://www.amazon.com/exec/obidos/tg/detail/-/0262111926/002-3648868-3484007?v=glance
>
> I don't know whether the book was actually published:
>
> http://www.amazon.com/exec/obidos/tg/detail/-/0262611031/002-3648868-3484007?v=glance&vi=reviews
I am pretty sure it wasn't. Around that time (96/97) Gregor Kiczales
started to work on Aspect-oriented Programming, and I guess he just
dropped the idea of open implementations in favor of AOP.
>> Open Implementations and Metaobject Protocols
>> Gregor Kiczales, Andreas Paepcke
>> http://www2.parc.com/csl/groups/sda/publications/papers/Kiczales-TUT95/for-web.pdf
>
> I think they rather focus on how to apply the principles of a
> metaobject protocol to other domains than language implementations,
> not so much on how to use the CLOS MOP.
I read it a while back, but I seem to remember that the examples
discussed were interesting also from a user point of view. Anyway, I
mentioned this resource because it gave me an "aha!" moment on the
CLOS MOP.
> Emre Sevinc <em...@bilgi.edu.tr> writes:
>
>> Pascal Bourguignon <sp...@mouse-potato.com> writes:
>>
>>> "Rahul" <cli...@gmail.com> writes:
>>>> Pascal Costanza wrote:
>>>>> > java reflection does not allow you to create classes at runtime.
>>>>>
>>>>> It does, but not directly. You can, of course, create a class file (that
>>>>> is, the corresponding bytecode stream) at runtime, and then cause the
>>>>> class loader to load that class. If you implement your own class loader,
>>>>> you could even do this without writing temporary files to a hard disk,
>>>>> or some such.
>>>>
>>>> Thank you for the information.. Never thought of that !!
>>>
>>> You can do that in C/C++/Objective-C and other languages too. That's
>>
>> Create classes during runtime in C?
>
> Just have a look at how gcl does it. gcl does everything thru gcc!
As if my mind wasn't confused enough... :)
OK, I'll dare to look at it, too (preparing my phone to call
my psychiatrist any time, just in case I go through a mental
breakdown :)
>
>> (ok, ok don't hit me, don't hit me... this MOP stuff is just
>> making my head dizzy, I'm trying to position it and compare it :)
>
>
> --
> "Debugging? Klingons do not debug! Our software does not coddle the
> weak."
--
Thank you very much for this real-life experience.
This creates a clear and vivid picture for me that
I can use when I try to explain this subject to the others.
I also plan to write an article in Turkish about MOP
and your example is quite striking for many people I guess ;-)
> OK, I'll dare to look at it, too (preparing my phone to call
> my psychiatrist any time, just in case I go through a mental
> breakdown :)
Non need for a real shrink, just fire up your Emacs and evaluate `M-x
doctor'.
> Emre Sevinc <em...@bilgi.edu.tr> writes:
>
>> OK, I'll dare to look at it, too (preparing my phone to call
>> my psychiatrist any time, just in case I go through a mental
>> breakdown :)
>
> Non need for a real shrink, just fire up your Emacs and evaluate `M-x
> doctor'.
Hmm, I was just reading PAIP from Norvig and examining his
implementation of ELIZA in small and beautiful steps. ;-)
> Emre Sevinc wrote:
>> Pascal Costanza <p...@p-cos.net> writes:
>>
>>>Have you understood the notion of a
>>>metacircular interpreter? That's an interpreter that is written in its
>>>own language.
>> Well, I heard about it a lot in context of Lisp, Scheme and PROLOG
>> however I don't have any hands-on experience implementing such
>> construct (maybe it is time to go back to Purple Book? Or
>> are there any other text that explains this subject matter (using
>> Common Lisp maybe)).
>
> What's the "Purple Book"?
I meant SICP, Structure and Interpretations of Computer Programs
which uses Scheme and in later chapters of the book, authors implement
some meta-circuler interpreters.
> In the context of Lisp, I can strongly recommend to read the following
> papers:
>
> - Paul Graham, The Roots of Lisp, http://www.paulgraham.com/rootsoflisp.html
> - Guy Steele, Gerald Sussman, The Art of the Interpreter,
> http://library.readscheme.org/page1.html
OK, I've put them in my reading list.
> ...in that order. I think these are the papers that explain the
> concept the best.
>
>>>and that's what I am trying to achieve
>>>with the Closer project over time, to provide more examples of how to
>>>use the CLOS MOP.
>> Is it some kind of collections of examples or kind of framework?
>
> A collection of examples. But not toy examples. ContextL is one of
> them, for example.
I've downloaded your ContextL overview however still didn't read.
I don't know if that is also related to AspectL. Terms are not
very familiar to me as an Internet programmer (mostly) so I think
first I must understand those "cross cutting concerns", "aspects"
and maybe then I can understand context oriented programming and
what kind of advantages it brings to real life situations. And
maybe after that I can have a better grasp of MOP. Currently I
feel like I'm the guy in the Blub Paradox (described by Graham). :)
(after having spent 5.5 years classical MS ASP Internet programming
and just currently struggling with .NET and C#).
--
> Emre Sevinc wrote:
>
>> By the way, googleing for CLOS MOP has returned a recent
>> project which used CLOS MOP and I was happy to see that:
>> - SWCLOS: A Semantic Web Processor on Common Lisp Object System
>> http://iswc2004.semanticweb.org/demos/32/
>
> Thanks for the link.
>
> Now, if anyone could actually explain to me what people are doing with
> these semantic web approaches, I would be really thrilled. Currently,
> I don't have a clue.
>
> Anyone knows what that is about?
I'm not a Semantic Web/RDF/OWL expert, only that I took a
multiagent systems course (during my cognitive science program)
which also focused on these issues for some weeks.
After reading the famous Scientific American article that
introduced these terms to people and written by Tim Berners-Lee
and reading some journal articles related to the subject, here's
what I understood briefly:
- From a practical point of view people does not know
much about Semantic Web/RDF/OWL. All they know is RDF is the
R in RSS and it is some tuple-thing and it is XML stuff and
it works fine. :)
- Academic/standardization/W3C computer people love Semantic Web
stuff and they tell that one day we'll have smart & tiny
agents silently connecting to addresses, fetching lots of RDF
or OWL data and "reason" about that data, follow the links, connections
based on that reasoning, make logical conclusions. All about
being machine readable and logically processable.
- And it's all about building ontologies, and I feel like,
well there's no absolute meaning, it is just, err a kind of
web that defines the meaning, but that seems fair enough, so
that your tiny & smart agent is going to "know" that "an automobile"
is also "a car" (and maybe other synonyms, context dependent
reasoning, etc.), it will also know that "tires" are "parts of"
"automobiles" (the meaning of "part of" is not absolute I guess).
- So we'll be happier because all the framework will be laid
down, we'll have very very detailed and compatible ontologies,
cool and very fast programs that can grab those huge XML data
and do logical processing on them, etc.
The problem is that, unless you're actively working
on the subject as an academician it is not easy to feel
the thrill. I don't see lots of Semantic Web applications
in daily life, here's a funny search engine that may give
some look-and-feel of Semantic Web:
Of course RDF also has its uses in many fields which I
don't know very much except RSS and for programming
in Mozilla, etc.
I'm sure Semantic Web/RDF/OWL experts can provide a much
better picture of the state-of-the art and correct my
mistakes if any.
Those Japanese guys excited me because they mentioned
the use of s-exps instead of complicated XML (and
when you're talking about Semantic Web it's all
about XML this way or the other way).
> - Academic/standardization/W3C computer people love Semantic Web
> stuff and they tell that one day we'll have smart & tiny
> agents silently connecting to addresses, fetching lots of RDF
> or OWL data and "reason" about that data, follow the links, connections
> based on that reasoning, make logical conclusions. All about
> being machine readable and logically processable.
In short, they are greenspunning AI work already done in Lisp :)
> Pascal Costanza <p...@p-cos.net> writes:
>
>>What's the "Purple Book"?
>
> I meant SICP, Structure and Interpretations of Computer Programs
> which uses Scheme and in later chapters of the book, authors implement
> some meta-circuler interpreters.
Ah, is that a common abbrev.?
>>>>and that's what I am trying to achieve
>>>>with the Closer project over time, to provide more examples of how to
>>>>use the CLOS MOP.
>>>
>>>Is it some kind of collections of examples or kind of framework?
>>
>>A collection of examples. But not toy examples. ContextL is one of
>>them, for example.
>
> I've downloaded your ContextL overview however still didn't read.
> I don't know if that is also related to AspectL. Terms are not
> very familiar to me as an Internet programmer (mostly) so I think
> first I must understand those "cross cutting concerns", "aspects"
> and maybe then I can understand context oriented programming and
> what kind of advantages it brings to real life situations. And
> maybe after that I can have a better grasp of MOP. Currently I
> feel like I'm the guy in the Blub Paradox (described by Graham). :)
> (after having spent 5.5 years classical MS ASP Internet programming
> and just currently struggling with .NET and C#).
Hmm, ok, some clarifications are apparently necessary:
- You don't need to understand AspectL, aspect-oriented programming or
metaobject protocols in order to understand ContextL or context-oriented
programming. ContextL just happens to be implemented via the CLOS MOP.
Think: You also don't need to understand macros to understand a Lisp
library, even if that Lisp library happens to be implemented with macros.
- However, you can download the source code of ContextL and see how it
is implemented, which I hope gives people more insights on how to use
the CLOS MOP for one's own extensions. But this is really just about the
internals of ContextL then, not about how it presents itself to a "mere"
user of ContextL. From a user's perspective, it is irrelevant how
ContextL is implemented.
Again as an analogy: You can use CLOS without knowing how it is
implemented internally. The CLOS MOP specifies how certain aspects of
CLOS should be implemented internally, and that gives you new
opportunities as a programmer, but these are really two very different
perspectives.
ContextL could indeed be implemented from scratch without using the CLOS
MOP at all. (I have a very minimal implementation of the same idea in
Scheme that is indeed implemented from scratch. However, the full
feature set of ContextL would be a lot more work to implement without
something like the CLOS MOP.)
- Aspect-oriented programming and context-oriented programming are
different approaches, and so are AspectL and ContextL. You don't need to
understand the one to understand the other, and vice versa.
- There is an overlap of functionality provided by AspectL and ContextL,
and indeed ContextL evolved from AspectL. That's why some people think
that ContextL is indeed also an aspect-oriented approach. But it isn't.
I have specifically left out genuine AOP features in ContextL, because
by now I think they don't make a lot of sense in Common Lisp. (To be
even more specific, there is no notion of join points and pointcuts in
ContextL, so ContextL doesn't deal with crosscutting concerns in the AOP
sense!)
I am working on explaining the differences between AOP and COP in more
detail, but this will take some time. Please bear with me...
> Emre Sevinc <em...@bilgi.edu.tr> writes:
>
>> - Academic/standardization/W3C computer people love Semantic Web
>> stuff and they tell that one day we'll have smart & tiny
>> agents silently connecting to addresses, fetching lots of RDF
>> or OWL data and "reason" about that data, follow the links, connections
>> based on that reasoning, make logical conclusions. All about
>> being machine readable and logically processable.
>
> In short, they are greenspunning AI work already done in Lisp :)
>
>
> Paolo
Wouldn't it be just as fair to say they are enabling AI work pioneered
in LISP to be used on a wider scale.
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
> Wouldn't it be just as fair to say they are enabling AI work pioneered
> in LISP to be used on a wider scale.
A lot of AI was also done in Prolog and Modula as well.
> Emre Sevinc wrote:
>> Pascal Costanza <p...@p-cos.net> writes:
>>> What's the "Purple Book"?
>> I meant SICP, Structure and Interpretations of Computer Programs
>> which uses Scheme and in later chapters of the book, authors
>> implement some meta-circuler interpreters.
> Ah, is that a common abbrev.?
You mean "SICP" (spoken "Sick-Pee") or "Purple Book"? Both are common
although it's better known as the "Wizard Book" in reference to the
cover illustration.
Emre, I found very instructive to read Gregor Kiczales' TinyCLOS
Implementation for Scheme. You can download it from:
ftp://ftp.parc.xerox.com:/pub/mops/tiny/
The file of interest to you is `tiny-rpp.text'. It's only 523 lines
long including comments and yet implements a (tiny) CLOS with a MOP in
Scheme using basically only lexical closures. Fascinating!
Here's an excerpt from the top of the file:
; A very simple CLOS-like language, embedded in Scheme, with a simple
; MOP. The features of the default base language are:
;
; * Classes, with instance slots, but no slot options.
; * Multiple-inheritance.
; * Generic functions with multi-methods and class specializers only.
; * Primary methods and call-next-method; no other method combination.
; * Uses Scheme's lexical scoping facilities as the class and generic
; function naming mechanism. Another way of saying this is that
; class, generic function and methods are first-class (meta)objects.
;
; While the MOP is simple, it is essentially equal in power to both MOPs
; in AMOP. This implementation is not at all optimized, but the MOP is
; designed so that it can be optimized. In fact, this MOP allows better
; optimization of slot access extenstions than those in AMOP.
--
Emílio C. Lopes
Munich, Germany
> Emre, I found very instructive to read Gregor Kiczales' TinyCLOS
> Implementation for Scheme. You can download it from:
>
> ftp://ftp.parc.xerox.com:/pub/mops/tiny/
>
> The file of interest to you is `tiny-rpp.text'. It's only 523 lines
> long including comments and yet implements a (tiny) CLOS with a MOP in
> Scheme using basically only lexical closures. Fascinating!
>
> Here's an excerpt from the top of the file:
>
> ; A very simple CLOS-like language, embedded in Scheme, with a simple
> ; MOP. The features of the default base language are:
> ;
> ; * Classes, with instance slots, but no slot options.
> ; * Multiple-inheritance.
> ; * Generic functions with multi-methods and class specializers only.
> ; * Primary methods and call-next-method; no other method combination.
> ; * Uses Scheme's lexical scoping facilities as the class and generic
> ; function naming mechanism. Another way of saying this is that
> ; class, generic function and methods are first-class (meta)objects.
> ;
> ; While the MOP is simple, it is essentially equal in power to both MOPs
> ; in AMOP. This implementation is not at all optimized, but the MOP is
> ; designed so that it can be optimized. In fact, this MOP allows better
> ; optimization of slot access extenstions than those in AMOP.
I believe that the last paragraph is oversimplifying things. Tiny CLOS
doesn't have method combinations, user-defined method combinations or
eql specializers, and I believe that adding them without changing Tiny
CLOS internally is at least not trivial. (But I haven't tried this, so
take this with a grain of salt.)
I also don't believe that the new slot access protocol is necessary to
make slot accesses more efficient, and the slot access protocol in the
CLOS MOP is probably easier to understand. I don't think the different
slot access protocols have actually been benchmarked.
Further note that there is also a Common Lisp version of Tiny CLOS
available at
ftp://ftp.parc.xerox.com/pub/openimplementations/oopsla93-tutorial/
Finally, it's also worthwhile to add that Tiny CLOS was the basis for
the object system in Swindle, now part of PLT Scheme, for STk/STklos,
for Guile, and probably also for others.
> Emre Sevinc wrote:
>
> > By the way, googleing for CLOS MOP has returned a recent
> > project which used CLOS MOP and I was happy to see that:
> > - SWCLOS: A Semantic Web Processor on Common Lisp Object System
> > http://iswc2004.semanticweb.org/demos/32/
>
> Thanks for the link.
>
> Now, if anyone could actually explain to me what people are doing with
> these semantic web approaches, I would be really thrilled. Currently,
> I don't have a clue.
>
> Anyone knows what that is about?
Search.
The idea is to make the web machine readable. Then you can find
stuff.
For example, you can imagine creating a business, say a travel agency.
Say there are "semantic web services" out there, where the business
service is specified in a standard way. Then you could assemble a
travel agency by looking for the services on the web that make up the
travel agency, such as booking flights, booking hotels and so on. The
web service specification would include things like the business model
and how to securely exchange credit card information and so on.
If you look up OWL-S you will find out about the semantic web standard
for this kind of thing. We built an OWL-S editor here that allows
people to do this kind of thing.
There aren't many web services out there yet, though.
--
Fred Gilham gil...@csl.sri.com
Do remember you're there to fuddle him. From the way some of you
young fiends talk, anyone would suppose it was our job to teach!
-- The Screwtape Letters, C. S. Lewis
> Emre Sevinc <em...@bilgi.edu.tr> writes:
>
>> - Academic/standardization/W3C computer people love Semantic Web
>> stuff and they tell that one day we'll have smart & tiny
>> agents silently connecting to addresses, fetching lots of RDF
>> or OWL data and "reason" about that data, follow the links, connections
>> based on that reasoning, make logical conclusions. All about
>> being machine readable and logically processable.
>
> In short, they are greenspunning AI work already done in Lisp :)
>
Semantic web is a sort of sub-field of AI.
--
Surendra Singhi
http://www.public.asu.edu/~sksinghi/index.html
"All animals are equal, but some animals are more equal than others."
- Orwell, Animal Farm, 1945
> Finally, it's also worthwhile to add that Tiny CLOS was the basis for
> the object system in Swindle, now part of PLT Scheme, for STk/STklos,
> for Guile, and probably also for others.
I adapted Swindle for Common Larceny's object system.
Right - sorry for not mentioning it.
Thanks, I found a couple of .zip files.
Unfortunately it's not really a well-maintained or documented project.
Sure, there's Javadoc, but that's hardly very useful. I expected
language documentation, and a single class doc that I need to fumble
with, not just a bunch of random javadoced classes.
It seems like the venerable Jasmin finally got a Sourceforge page, though.
--
My mouth says the words, my brain is thinking monstertrucks.
Joey (Friends)
> Emre Sevinc <em...@bilgi.edu.tr> writes:
>
>> OK, I'll dare to look at it, too (preparing my phone to call
>> my psychiatrist any time, just in case I go through a mental
>> breakdown :)
>
> Non need for a real shrink, just fire up your Emacs and evaluate `M-x
> doctor'.
M-x all-hail-xemacs
Regards,
--
Julian Stecklina
When someone says "I want a programming language in which I
need only say what I wish done," give him a lollipop. - Alan Perlis