home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / compiler / 2037 < prev    next >
Encoding:
Text File  |  1992-12-15  |  13.6 KB  |  297 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!world!iecc!compilers-sender
  3. From: meldc@cs.columbia.edu
  4. Subject: MeldC 2.0, A Reflective Object-Oriented Coordination Language.
  5. Reply-To: meldc@cs.columbia.edu
  6. Organization: Compilers Central
  7. Date: Tue, 15 Dec 1992 18:18:57 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-12-069@comp.compilers>
  10. Keywords: C, OOP, available
  11. Sender: compilers-sender@iecc.cambridge.ma.us
  12. Lines: 283
  13.  
  14.             MeldC 2.0: A Reflective
  15.    Object-Oriented Coordination Programming Language
  16.  
  17. We are pleased to inform you that MeldC 2.0 is available to interested
  18. universities and our industrial sponsors.  Enclosed is an information
  19. sheet that details the current status of the MeldC Project here at
  20. Columbia University, and a selected list of related publications.
  21.  
  22. The release includes source and binary code for Sun4s running SunOS
  23. version 4.1 and DecStations running Ultrix 4.2.  It also includes a user's
  24. manual, implementor's manuals for the MeldC compiler and the MeldC runtime
  25. system, and numerous MeldC examples.
  26.  
  27. The release is available free of charge via FTP.  Please arrange for an
  28. authorized official to sign and submit to us two (2) copies of the
  29. attached license agreement.  Once we have received the signed license, we
  30. will provide you with the necessary password to obtain the MeldC release.
  31. This will be expedited if you include an email address with your license.
  32.  
  33. If you would prefer a Sun or DEC cartridge tape and hardcopy manuals
  34. rather than FTP, you must include a check for $995.00 (US dollars) to
  35. cover media, photocopying several hundred pages of manuals, shipping and
  36. handling.  Checks should be made payable to Columbia University, and must
  37. be drawn on a US bank.  Sorry, we cannot accept purchase orders or checks
  38. drawn on a non-US bank.
  39.  
  40. Please use the address: ATTN: Prof. Gail E. Kaiser, Columbia University,
  41. Department of Computer Science, 500 West 120th Street, New York, NY 10027,
  42. United States.  Any other name or address will substantially delay receipt
  43. and processing.
  44.  
  45. We look forward to hearing from you.
  46.  
  47.  
  48. Programming System Laboratory
  49. Department of Computer Science
  50. Columbia University 
  51. Email : MeldC@cs.columbia.edu
  52.  
  53.  
  54.  
  55.  
  56. Gail E. Kaiser
  57. Associate Professor
  58.  
  59.  
  60. /******************************************************************************/
  61.  
  62.  
  63.           MeldC 2.0
  64. A Reflective Object-Oriented Coordination Language
  65.  
  66. The MELD project has been one of the major foci of the Programming Systems
  67. Laboratory at Columbia University since 1987.  Our goal is to develop a
  68. parallel and distributed object-oriented programming language for
  69. large-scale applications.  Starting in 1990, the MELD language was
  70. completely redesigned and reimplemented from scratch to produce MELDC,
  71. which is closer to C, has fewer but more sophisticated ``features'', and a
  72. cleaner architecture with many of the facilities implemented in the MELDC
  73. language itself.
  74.  
  75. 1. Concepts
  76. The concept of ``coordination language'' was introduced by Carriero and
  77. Gelernter (CACM, Apr89) to designate a class of programming languages
  78. suitable for describing the behavior of open systems.  Ciancarini (ICCL,
  79. Mar90) suggests the following definition for open systems:
  80.  
  81.     An open system is a dynamic set of agents both cooperating and
  82.     conflicting for the use of a dynamic set of services and resources.
  83.     The agents, the services and the resources are heterogeneous; they
  84.     operate both in parallel and in concurrency; they communicate; they
  85.     have some goals (what they would like to do), some duties (what they
  86.     should do), some rights (what they may do), and some constraints (what
  87.     they must not do).
  88.  
  89. The development of open systems in distributed computing is a result of
  90. using computer and network technologies in real-world human society.  The
  91. complexity of open systems mirrors the complexity of human society.
  92. Coordination languages usually extend the declarations and statements of
  93. some base computation language, such as C and Pascal, with additional
  94. facilities to support distributed and/or parallel computation.  Many
  95. coordination languages and models have been proposed for open systems
  96. programming.  Among these approaches, the most popular one seems to be the
  97. concurrent object-oriented language approach, since it provides a natural
  98. environment for expressing concurrency and encapsulating distribution in
  99. objects and messages. Objects are naturally suited to represent real-world
  100. entities with private memory and predictable behavior, and messages are
  101. communication media among objects.  Most object-oriented coordination
  102. languages focus on providing immediate language features for building open
  103. systems and hard-code these features into the language internals.  One
  104. example would be supporting atomic actions that guarantee serializability;
  105. however, it would then be difficult to build applications with correctness
  106. criteria other than serializability.  Other object-oriented languages
  107. support persistency, remoteness, monitoring, authorization,
  108. authentication, etc. as immediate language features.
  109.  
  110. Like other languages, the ultimate goal of the MELDC language is to
  111. support a wide range of high-level features for programmers to cope with
  112. problems in designing open systems.  Unlike other language research, our
  113. focus is not to study what specific language features should be designed
  114. for solving certain open system problems, but to investigate the language
  115. architecture with which programmers are able to construct --- without
  116. modifying the language internals --- new features in a high-level and
  117. efficient way.
  118.  
  119. MELDC is a C-based, concurrent, object-oriented language built on a
  120. reflective architecture.  The core of the architecture is a micro-kernel
  121. (the MELDC kernel), which encapsulates a minimum set of entities that
  122. cannot be modeled as objects.  All components outside of the kernel are
  123. implemented as objects in MELDC itself and are modularized in the MELDC
  124. libraries.
  125.  
  126. MELDC is reflective in three dimensions: structural, computational and
  127. architectural.  The structural reflection indicates that classes and
  128. meta-classes are objects, which are written in MELDC.  The computational
  129. reflection means that object behaviors can be computed and extended at
  130. runtime.  The architectural reflection indicates that new
  131. features/properties (e.g., persistency and remoteness) can be constructed
  132. in MELDC.  These properties can be attached to and removed from objects at
  133. runtime.  The reflective architecture provides high flexibility to
  134. customize or extend object behaviors in an elegant way.  For example, a
  135. programmer builds a simple type of persistent objects that do not survive
  136. catestrophic system failures and then builds a comprehensive version of
  137. persistent objects that survive system failures by applying redundancy to
  138. the simple ones.  In MELDC, persistency is not a language primitive, but
  139. just another property that can be constructed for objects.  The semantics
  140. of persistency or policies to implement it are defined in MELDC.
  141.  
  142. Since micro-kernel facilities cannot be replaced or modified by the MELDC
  143. programmer, several common choices are supported by the kernel and can be
  144. designated by the programmer using compiler switches.  For example, MELDC
  145. intends to support a variety of parallel and distributed applications that
  146. have different concurrency characteristics.  Some applications require a
  147. small number of long-lived threads while others need a large number of
  148. short-lived threads that are created and destroyed dynamically.  Thus
  149. MELDC provides three different thread packages (interleaving stack,
  150. one-stack-per-thread and heap-based), which can be chosen with a compiler
  151. switch.  Other compiler options enable the programmer to choose
  152. pre-emptive versus non-pre-emptive schedulers and either merging or
  153. overriding behavior for multiple inheritance.
  154.  
  155. 2. Status
  156. The MELDC 2.0 implementation consists of about 15,000 lines of C, lex and
  157. yacc for the compiler, 4,300 lines of C and 500 lines of assembly code for
  158. the kernel, plus 10,000 lines MeldC runtime written in MELDC itself.  It
  159. runs on Sun4s with SunOS 4.1 and DecStations with Ultrix 4.2, although
  160. there are several limitations on the DEC version.  This is the first
  161. external release of MELDC, but version 1.0 has been used internally as an
  162. educational language for undergraduate courses.  The release includes a
  163. user manual, compiler and runtime implementation guides, a MeldC variant
  164. of the gdb debugger, and a sample program for network monitoring.
  165.  
  166. References
  167.  
  168. [1]   Gail E. Kaiser and Wenwey Hseush and Steven S. Popovich and
  169.       Shyhtsun F. Wu.
  170.       "Multiple Concurrency Control Policies in an Object-Oriented
  171.       Programming System".
  172.       In 2nd IEEE Symposium on Parallel and Distributed Processing,
  173.       pages 623-626.  Dallas TX, December, 1990.
  174.  
  175. [2]   Steven S. Popovich and Shyhtsun F. Wu and Gail E. Kaiser.
  176.       "An Object-Based  Approach  to  Implementing  Distributed 
  177.       Concurrency Control".
  178.       In 11th International Conference on Distributed Computing
  179.       Systems, pages 65-72.  Arlington TX, May, 1991.
  180.  
  181. [3]   Wenwey Hseush and James C. Lee and Gail E. Kaiser.
  182.       "MeldC Threads: Supporting Large-Scale Dynamic Parallelism". 
  183.       Technical Report CUCS-010-92, Columbia University, March, 1992.
  184.  
  185. [4]   James Lee and Wenwey Hseush and Erik Hilsdale and Gail E. Kaiser.
  186.       Dynamic Orthogonal Composition in MeldC. 
  187.       In 2nd Workshop on Objects in Large Distributed Applications.
  188.       Vancouver BC, Canada, October, 1992.
  189.  
  190. [5]   Steven S. Popovich and Gail E. Kaiser.
  191.       "An Architectural Survey of Object Management Systems".
  192.       International Journal of Intelligent & Cooperative Information
  193.       Systems , 1993.  In press.
  194.  
  195. /******************************************************************************/
  196.  
  197.  
  198.                    MELDC 2.0 SOFTWARE LICENSE
  199.                                FOR
  200.                   EDUCATIONAL AND RESEARCH USES
  201.  
  202.  
  203.  
  204.  
  205. License agreement between
  206.  
  207. Institution:
  208.  
  209. Address:
  210.  
  211.  
  212.  
  213. herein referred to as "You", and Columbia University in the City of New
  214. York, herein referred to as "Us", or "We", regarding the MeldC 2.0
  215. software and any future versions of MeldC designated 2.x (2.1, etc.).
  216. This includes all programs, code and associated documentation you receive
  217. from us and all modified versions or extensions that you may produce.
  218. Herein, this is all referred to as "the software and its derivatives":
  219.  
  220. 1.  You agree that you will not sell or otherwise distribute the software
  221. and its derivatives;
  222.  
  223. 2.  You acknowledge the confidential and valuable nature of the software
  224. and its derivatives.  You will not divulge or distribute the software and
  225. its derivatives to third parties, nor allow any part of the software and
  226. its derivatives to be so divulged or distributed, unless express written
  227. permission is given by us.  You will instruct your employees, students or
  228. other persons authorized to have access to the software and its
  229. derivatives not to divulge or distribute it to third parties, unless
  230. express written permission is given by us;
  231.  
  232. 3.  The software and its derivatives will be used only on computers you
  233. control;
  234.  
  235. 4.  You agree that you will use the software and its derivatives solely
  236. for internal, non-commercial research or academic purposes.  Nothing in
  237. this agreement gives you the right to sell, lease, distribute, transfer,
  238. sublicense, or otherwise dispose of the software and its derivatives, in
  239. whole or in part, or to make any commercial use of it whatsoever;
  240.  
  241. 5.  Title and copyright of the software and its derivatives will remain
  242. with us and shall at no point transfer to you.  You may make copies only
  243. for backup purposes, and they shall contain the original copyright notices
  244. we inserted;
  245.  
  246. 6.  Official publications such as manuals, technical reports and articles
  247. in journals or conference proceedings that are based on the ideas of the
  248. MeldC Project, its software or its derivatives will give proper
  249. recognition to the MeldC Project in the Programming Systems Laboratory of
  250. the Department of Computer Science at Columbia University and the people
  251. who worked on it;
  252.  
  253. 7.  You acknowledge that the software and its derivatives are being
  254. supplied "as-is" without any support services or future updates or
  255. releases.  We may or may not make future updates and releases designated
  256. MeldC 2.x available to you under this same licensing agreement, but we are
  257. in no way obligated to do so.  If you discover any error in the software
  258. or its derivatives, we encourage you to inform us.  We will not
  259. necessarily acknowledge or repair any such errors thus reported;
  260.  
  261. 8.  We make no warranties or representations of any kind, either express
  262. or implied, as to any matter whatsoever, including merchantability or
  263. fitness for any particular purpose.  You agree that we shall not be held
  264. to any liability with respect to any claim by you or a third party arising
  265. from or on account of the use of the software and its derivatives,
  266. regardless of the form of action; whether in contract or tort, including
  267. negligence.  In no event will we be liable for consequential or incidental
  268. damages of any nature whatsoever;
  269.  
  270. 9.  The user of the software and its derivatives will make sure that all
  271. potential users in his/her environment are aware of this agreement and of
  272. the terms for using the provided software and producing derived software.
  273.  
  274.  
  275.  
  276. Institution:                     Columbia University
  277.  
  278. Address:                         Department of Computer Science
  279.  
  280.                                  500 West 120th Street
  281.  
  282.                                  New York, NY 10027
  283.  
  284. Email:                           Email:
  285.  
  286. Date:                            Date:
  287.  
  288. Name:                            Name:
  289.  
  290. Title:                           Title:
  291.  
  292. Signature:                       Signature:
  293.  
  294. -- 
  295. Send compilers articles to compilers@iecc.cambridge.ma.us or
  296. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  297.