[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Agents as MCL building blocks?
- To: INFO-MCL@CAMBRIDGE.APPLE.COM, BUG-MCL@CAMBRIDGE.APPLE.COM
- Subject: Agents as MCL building blocks?
- From: JOOFUNG@AppleLink.Apple.COM (Sing - IS&T, Wong Joo Fung)
- Date: 03 Aug 92 00:17 GMT
- Cc: BILL@CAMBRIDGE.APPLE.COM
To: info-mcl@cambridge.apple.com
bug-mcl@cambridge.apple.com (re: MCL new feature wish list)
From: joofung@applelink.apple.com
Hi:
I am interested in using MCL to write agents that communicate via messages.
Each agent encapsulates some coherent body of knowledge and "knows", at
minimum, about the addresses and capabilities of other agents. Agents can
reside on various machines or nodes.
Messaging can be implemented using AppleEvents (AE) or PPC, and MCL has a good
interface to the former, so support for messaging is not an issue.
It appears to me that some desirable MCL features are (in order of priority):
1) small RAM footprints for each MCL application (maybe <500k)
2) multi-tasking threads in MCL
3) "lightweight" CLOS objects
Small RAM footprints for MCL applications will facilitate the creation of
agents of small to medium granularity. With this, instead of writing a single
monolith Macintosh application, one can conceivably craft agents (small,
specialised mini-applications). For example, a PageMaker-like application can
be crafted by:
a) first writing a "main" agent to handle the overall page layout
b) delegating text editing, drawing, movie-editing and other
operations to special agents (eg, StyledEdit Agent, PICT Agent,
MooV Agent, etc) via AE
(a wonderful, extendable and dynamic plug-and-play capability!)
Multi-tasking threads in MCL would enable the use of "parallel" processing
techniques on the Macintosh (with or without special nuBus or QuickRing
parallel processing cards).
"Lightweight" CLOS objects are a conjecture on my part. This struck me as an
implicit support requirement for small MCL applications (reason: for certain
small MCL applications, one may not need all the implicit garbage collection,
trace and other features in Common Lisp).
(Sorry, I haven't received the Dylan specs yet -- so maybe Dylan does implement
"lightweight" CLOS-like objects)
Please address replies directly to me and cc Info-MCL.
Thanks in advance,
JooFung Wong
P.S. Frameworks of objects are a nice way to do OOP, and mixins are a elegant
way to compose functionality.
Perhaps the advent of AE and the possibility of crafting small MCL applications
may facilitate experimentation with alternative system composition / reuse
techniques.
Yes, Frontier does support the creation of Applets (mini Macintosh
applications) that communicate via AE -- but it may be tough to design objects
that can gracefully handle plans, goals, world models, etc, in C or Pascal.