extprosys-devel Mailing List for XPS: eXtensible Programming System
Status: Alpha
Brought to you by:
raspencer
Menu
▾
▴
extprosys-devel — Developer's Mailing List For XPS Technical Discussions
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(3) |
Aug
(7) |
Sep
(9) |
Oct
|
Nov
(1) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
(1) |
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Reid S. <ras...@re...> - 2005-05-24 21:21:19
|
Hello, XPS 0.2.0 was released today. This is a pre-release version of the eXtensible Programming System. After two years of integration with LLVM and battling the XML validation challenge, we are finally making progress again. For full details, please review the release notes at http://x-p-s.net/releases/0.2/docs/ReleaseNotes.shtml. This version marks some significant milestones in XPS development: * The definition of XPL core has been finalized. XPL core is the lowest level language that XPS supports. It provides semantics very close to the semantics of the LLVM intermediate representation. * This release provides a version of xplc, the XPL compiler, that can validate XPL core programs and reproduce them in XPL as output. This is used to verify that the basic parsing, validation, compilation and generation infrastructure is in working order. * This release offers a test suite with 1000+ test cases derived from the LLVM 1.5 Feature and Regression tests. The test suite is used to ensure that all semantic constructs are recognized by the compiler and correctly interpreted and processed. * This release introduces the XPL Back End for LLVM which can generate valid XPL source code from any LLVM intermediate represenation. * XPS now uses Subversion for its source code repository. * XPS selected Relax NG for XML validation. * XPS incorporated the JING Relax NG validator. * XPS now uses the LLVM Makefile System for configuration and building. For further details on XPS, please visit http://x-p-s.org/ Best Regards, Reid Spencer |
|
From: Saem G. <sae...@sh...> - 2004-12-15 22:07:09
|
This is a summary of recent discussions between Reid and Saem. If any particular topic interests you or you have questions about them, start a new thread with that being the focus. First off, the project isn't dead. There is also an underlying tone of a little bit of urgency, lest we're left behind, jetbrains is already working on MPS (http://www.onboard.jetbrains.com/articles/04/10/lop/). The aim is the to make programming easier for non-programmers, such that they can not only be experts in their field but express that expertise to develop a computer program. There are issues on the tool side as well. Both Reid and Saem agree that the format of programs and source code, the way they're stored and the IDEs that edit them need work. Programs and libraries of reusable components should be stored in a database of some form. IDEs should be more powerful such that they can be more than a faster means to edit text, rather they should provide a lot of helpful suggestions based upon how and what you're doing. Reid agree, but feels the benefits of such aren't as dramatic as Saem. Instead, Reid feels that there will be greater benefit from an IDE working on a more macro scale and helping the user combine larger components. I think in this matter, there is room for both, creation versus derivation. It was agreed that programs are created best with an iterative or evolutionary process. However as the things went further down discussing software engineering it was decided that it was too tangential a discussion to persue. This would be revisited, however. The two issues slowing down XPS right now are LLVM going to 1.5 for portability features and linking syntax with semantics and generating efficient code. Both agreed that having languages work with each other is going to be key. The issue is how much cooperation is going to be allowed. Saem proposed a C interface which most language can work with. Reid, basically agreed and thought that there should be a few common things (strings and data structures) and the rest should be met with you can't do that in XPS from XYZ. Saem put forth the use templates and macros for translation of higher level source to core XPL. This allows one to fairly easily define syntax and semantics. Reid countered with having far too many layers for transformation and that code transformation isn't particularly good in terms of optimization unless the user does a lot of heavy lifting. Reid wanted a way to easily extend the compiler to understand new languages and language features natively by the compiler. Saem agreed and templates and macros fell from being the main thrust of extension. Namespaces and versioning came up. Fortunately, namespaces were already addressed even at the workspace level. This should hopefully avoid domain specific terminology collisions. Versioning is still unresolved. Reid and Saem agreed that versioning must be solved by the programming system; however, Reid wasn't sure he wanted he wanted it in the language or visible by the user, while Saem wanted it as a first class citizen in the form of changesets and incorporated into referencing components and code. Reid countered that there are companies which have versioned on per character and that mess should be avoided and a DSL might be up to solving the problem. Reid felt that it might be best if interfaces and implementation were versioned, that and they should play nicely from development, testing, integration, staging and production scenarios. Inheritance and it's pros and cons in terms of describing semantics was considered. Saem initially thought that this would be enough. Reid countered with an example, showing that fuzzy logic is more than a double and specialization/categorization wouldn't really cut it, in fact composition would be superior in most cases. Reid added that categorization would be completely ineffectual in terms of dealing with completely new types of semantics and that is likely the larger issue, creating semantics. |
|
From: Reid S. <dev...@re...> - 2003-09-21 19:39:19
|
Folks, I have recently received several administrative emails from SourceForge.net indicating that some of you have invalid email addresses to which your sourceforge email is forwarded. Accordingly, I'm taking a poll of which developers wish to remain active on the XPS project. If you do not reply to this email, I will assume your SourceForge account is inactive and remove your account from the list of active developers on the project. If you wish to remain associated, please respond. Thanks, Reid. -- Reid Spencer <dev...@re...> extprosys: eXtensible Programming System Team |
|
From: Reid S. <re...@x1...> - 2003-07-17 06:16:06
|
Dear XPS/XSI Mailing List Subscribers,
As you haven't heard much from me in the last few months, I thought I
should provide a little update about what's going on with the eXtensible
Programming System and eXtensible Systems, Inc.
Since incorporating XSI last February, much of my time and effort has
been devoted to working on the business side of the project rather than
the technical side. Now you know why there's been zero code commits in
the last few months! My theory was that working on the business side
could provide additional resources to help move the project along
faster. However, I've found that:
* Now is not a very good time to talk to people about parting with
their money (spending, donating or investing).
* Significant amounts of time and effort are needed to chase
money.
* Money will flow to the project with significantly less effort
once it has reached "critical mass".
* Critical mass won't happen until several technically qualified
colleagues completely "grok" what I'm doing, find that it makes
sense, and join the project to see it to completion.
* Those "technically qualified colleagues" won't be convinced
until I can provide a working prototype and sufficient technical
documentation.
* The project isn't ready to scale to multiple people yet because
many fundamental technical decisions need to be made before
anyone will be able to comprehend what it is that I'm trying to
accomplish.
So, as a result of the foregoing, I've decided to make a change in
strategy, for now. I'm going to focus purely on the technical side of
the project for the foreseeable future. I've recently taken an
interesting position with Mercury Interactive Corp. that will allow me
to continue to be exposed to all sorts of computing environments and
interesting software problems to solve. As with all my other experience,
this too will influence XPS directly. Unfortunately, it also means that
I will only be working on XPS in the background with available "spare"
time. In essence, I'm going back to the approach that has gotten the
project to where it is today!
Here is what you should expect from this change of strategy:
* The XPS project on SourceForge (
http://sourceforge.net/projects/extprosys ) will continue to be
the repository of code and documentation about the project. This
should be your primary source of information (i.e. join the
mailing lists there if you haven't already!)
* You should start to see much more technical activity on the XPS
project, especially on weekends.
* I expect to write and release an XPL primer concurrently with
the first functioning version of the compiler early next year.
* The XSI web site (www.x10sys.com) will be scaled down to just a
short "brochure" which points to the XPS project site. All
reference to business plans, investment, products, or services
will be removed.
* Little, if any, news from "XSI" will be forthcoming for at least
another year.
* If you were expecting to get a business plan in Q3 2003, I'm
sorry to say that you won't. Anything relating to the business
side of things will be postponed by at least one year.
* Funding efforts will resume when it comes time to market XSI's
first products (years from now).
Finally, here's some things you can do that would help us a lot:
* Make http://extprosys.sourceforge.net/news.php your home page!
This will allow you to keep track of the technical changes as
they happen and you'll also help us grow awareness of the
project because of additional hits on the web site.
* If you know anyone with deep technical skills in the areas of
operating systems, programming languages, virtual machines, or
scalable architectures, please send them to the project web
site. I need the feedback/input/critique from people that know
better than me. Yes, this could be you!
* Keep in touch, let me know what you think!
Thanks for all your support in the past..
Best Regards,
Reid
_______________________
Reid Spencer
President & CTO
eXtensible Systems, Inc.
re...@x1...
P.S. If you no longer want to be on one of the XPS or XSI email lists, I
completely understand. Just reply with an indication for removal and
I'll take you off the list promptly.
|
|
From: Reid S. <dev...@re...> - 2003-05-18 23:04:00
|
XPSers, I've just completed a set of modifications to the XPS home page that should make it a little easier to read/manage: 1. Changed the theme to use "black on white" instead of "blue on black" color theme (easier on the eyes). 2. Reduced the size of the main index page and put its content on the "overview" page of the project section. 3. Merged the Components and Architecture sections. The components are now listed on a single page under the architecture section. For those of you that have been waiting, I'll be working on documenting the architecture in a little more detail over the next couple of weeks. This should provide the high level overview that you're looking for. Best Regards, Reid Spencer XPS Project Lead. |
|
From: Reid S. <dev...@re...> - 2003-04-27 04:52:52
|
XPSers, Just a quick note to let you know that I've updated the XPS API documentation on Source Forge. There is now a complete introduction and brief documentation for every namespace, class and file. The detailed documentation for classes is still spotty but if you look at the various indices, you should get a good general understanding of the structure of the XPS code. From now on I will be publishing the documentation with each release and keeping it up to date and correct. To read the API documentation, please go here: http://extprosys.sourceforge.net/docs/apis/html/index.html -- Reid Spencer <dev...@re...> extprosys: eXtensible Programming System Team |
|
From: Reid S. <dev...@re...> - 2003-04-25 11:15:29
|
XPSers, I've just made the first cut of the XPS API documentation available for browsing at SourceForge. Here's the URL: http://extprosys.sourceforge.net/docs/apis/html/index.html When you go there, please be patient as the index pane on the left can take a few moments to download and for Java to start. I wouldn't recommend it over a slow link. Please note, XPS is at release 0.1.9 and the documentation reflects that. There are many errors, omissions and discrepancies. Since this was generated from the code, and the code is changing on the fly, by the time you read it, it will be out of date! However, it can still give you a general perspective on the code. The base, os, util, and mem modules (namespaces) are the most mature in terms of code but their documentation may not reflect that. The others might not even be worth looking at. The on-line documentation will be updated at least with each minor release (i.e. 0.2, 0.3 etc) from now on. I might do it more frequently. You can always generate it yourself after you download. Let me know if this is useful for you and I'll try to update more often. Happy Reading -- Reid Spencer <dev...@re...> extprosys: eXtensible Programming System Team |
|
From: Reid S. <dev...@re...> - 2003-04-22 09:00:39
|
Everyone,
I have just committed, tagged, and released version 0.1.9 of XPS.
Although I expected to be releasing the reflective compiler at this
point, I got sidetracked with various housekeeping issues. The
reflective compiler will be in the next release 0.2.0, hopefully within
the next month (depending on my work schedule). Release 0.1.9 fixes a
lot of housekeeping issues for XPS. Among them are:
* Removal Of Dependence On ACE. Although the venerable Adaptive
Communications Environment has served us well, I've removed it
from XPS because it was (a) too large, (b) too heavy (contained
way more features than XPS will every need), and (c) too hard to
configure and customize. While ACE isn't with us any more, we
thank Doug Schmidt, et.al. for their great inspiration. Many of
the patterns implemented in ACE will live on in XPS.
* Source now in "xps". There is a new top level source directory
named "xps" that replaces the now defunct "src". This directory
now contains all the software. This was necessary in order to
avoid complicated autoconf work to make links in the right
places. This assists use with getting the right path for
including header files.
* Removal of $ Log $ Lines. These lines were bloating the size of
the source files and mostly redundant. If you want to look at
the history, please use the "cvs log" command or browse it on
the site. Since all the files were changing to the "xps"
directory, I took the opportunity to clean these lines out since
all the files were getting fresh versions.
* New "os" module. This module provides an operating system
abstraction layer that provides simple abstractions implemented
by most operating systems without the need to #include ANY
system header files. This greatly speeds compilation and
provides a very concrete boundary between XPS and the operating
system. Support for files, memory mapping, asynchronous file
I/O, signal handling, dynamic libraries, threading, and
synchronization is currently implemented. Coming later will be
process management, asynchronous messaging, asynchronous socket
I/O, timers, and shared memory. Much of this will be used to
implement the XVM.
* New "base" module. If you ever looked at the old "util" module,
you'll probably find "base" familiar. Most of the classes have
migrated there. That's needed because of library ordering and
dependency. Think of "base" as operating system independent
stuff (dependent only on language features). Parts of the old
"util" module were dependent on the "os" module so we moved the
parts that weren't to "base" and left the rest in "util". This
is one of the consequences of removing ACE.
* Missing modules. The "adt", "meta", "task", "xvmapi", and
"xplec" modules have been temporarily removed. There is
significant work to do in these modules and rather than commit
them half-baked, I chose not to commit them at all for this
release. They'll reappear in 0.2.0. Its better that you don't
read broken code anyway.
As with the 0.1.8 release, you can build the XPL compiler (xplc) and use
it for checking your XPL program syntax. The XPS Daemon (xpsd), XPS
Shell (xpsh), and XPS Virtual Machine (xvm) all build correctly but
don't do anything other than print version information.
If you're going to build this, please read the file "INSTALL" before you
proceed. It will help you get the software you need in order
to successfully build XPS. As always, please let me know if you have
questions or problems.
Best Regards,
--
Reid Spencer <dev...@re...>
Open Source Developer
|
|
From: Reid S. <re...@re...> - 2003-02-10 21:51:25
|
XPS Folks,
Several things have happened over the last month of general interest
that I thought you'd like to know about.
* Web Site. The main web site at
http://extprosys.sourceforge.net/ (also available at
http://x10sible.org/) has been completely revised and
reorganized. It now uses a simple PHP theme and contains more
sections. Of particular note is a complete release plan for
XPS through version 1.0, access to project status and news,
and sections for descriptions of the architecture and
components of XPS.
* Formation of XSI. I have recently incorporated a company named
eXtensible Systems, Inc. to foster the development of XPS. The
company will seek investment capital to speed XPS development
and will offer commercial services and products based on XPS.
The XSI web site is not complete, but you can preview it at
http://www.x10sys.com/ ).
* SaveSomeGeeks.com. Inspired by the success of
www.savekaryn.com, I decided to see if XPS could benefit from
donations by Internet users. I don't know if this experiment
will go anywhere, but you can read my e-panhandling attempt at
http://savesomegeeks.com/. All net proceeds will go directly
to funding XPS development work. Help me promote this site
and it might just turn into some contract $ for XPS
developers.
* Architecture Changes. I've changed the architecture slightly
to include a general services daemon (XPSD) separate from the
XVM. The XPSD will provide software development services to
XPS developers. I have also renamed XVMSH as XPSH to more
accurately reflect its character as an interface into the
entire XPS system rather than just the XVM. I've also started
to document some of the extensions to XPS that we will tackle
early: User Interface, Virtual Reality Programming, Database
Interface, and Logic Programming.
* ADT Design. I have started an Abstract Data Types library to
provide the basic ADTs needed by XPS that are compatible with
its memory system. This includes things like lists, stacks,
queues, maps, hash tables, etc. I have a number of design
issues with this module and could really use some help
rationalizing it. Anyone interested in this area, please
contact me soon as this is what I'm working next. Its needed
to support the compiler's symbol table which is holding up
release 0.2.0.
That's it for now. I would appreciate your feedback on the websites and
other plans.
Best Regards,
Reid.
|
|
From: Reid S. <re...@re...> - 2002-12-31 11:08:17
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"CONTENT-TYPE" CONTENT=3D"text/html; charset=3Diso-8859= -1"> <TITLE></TITLE> <META NAME=3D"GENERATOR" CONTENT=3D"OpenOffice.org 1.0 (Linux)"> <META NAME=3D"CREATED" CONTENT=3D"20021230;22521600"> <META NAME=3D"CHANGED" CONTENT=3D"20021231;3503800"> <STYLE> <!-- H1 { color: #000080; text-align: left } H1.western { font-family: "Arial", sans-serif; font-size: 20pt } P.western { font-family: "Arial", sans-serif } H2 { color: #000080; text-align: left } H2.western { font-family: "Arial", sans-serif; font-size: 16pt } --> </STYLE> </HEAD> <BODY LANG=3D"en-US"> <P CLASS=3D"western" ALIGN=3DCENTER STYLE=3D"margin-top: 0.42cm; page-break= -after: avoid"> <FONT COLOR=3D"#000080"><FONT FACE=3D"Albany, sans-serif"><FONT SIZE=3D6><B= >XPS In A Nutshell</B></FONT></FONT></FONT></P> <P CLASS=3D"western" ALIGN=3DCENTER><I>Reid Spencer, January 1, 2003</I></P= > <P CLASS=3D"western">In reflecting on the past year's development of the eXtensible Programming System (XPS) , I decided that a shorter but comprehensive introduction to the system would be a good idea for those unfamiliar with XPS. This paper provides a quick overview of the system to help you get the “big” picture and the vision for the project. Much of the content is written in the present tense, as if XPS were a completed system. However, there is much to do! If you think the goals of the system are worthy, I hope you'll consider contributing your particular expertise to the development of XPS.</P> <H1 CLASS=3D"western">Background</H1> <P CLASS=3D"western">The original idea for XPS came about many years ago after watching the first few episodes of Star Trek: The Next Generation (circa 1987). Like most software engineers at the time, I was intrigued with the holodeck. But, my fascination with this programmable virtual world quickly turned into an earnest exploration of what it would take to build such a system. Instead of letting all the worrisome physics get in the way, I looked at the holodeck as a software system. What kind of software would be needed for such a system? Certainly, it would have to be object-oriented as it dealt mostly with the generation and manipulation of simulated real world objects (now <I>there's</I> an oxymoron). Programming the holodeck would have to be easy, since the Star Trek characters could create amazingly complex worlds rather quickly. It would have extensive command and control facilities as frequently exhibited on the show. It would have to be aware of both the human and generated participants in the scene, have some level of autonomy and provid appropriate spontaneous character interactions and scene changes. It would operate in at least four dimensions to maintain a continuous virtual reality for the participants. It would both understand and generate several natural language(s) fluently. It would incorporate much of artificial intelligence. It would be fast, efficient, fault tolerant, robust, dependable, secure, and safe. In essence, it would combine everything everyone knows about software and then some! (Sounds to me like a few large corporate IT projects I've worked on).</P> <P CLASS=3D"western">While being sane enough to know that building such a system in my lifetime would be a little out of reach (to put it mildly), I am just crazy enough to believe it would be a good idea to get started now! So, I've set out to build just the software portion of the holodeck. We'll leave all that nasty holographic particle physics stuff to some future genius. Assuming that characters and scenes could be rendered by hardware in some appropriate fashion, the rest is just some interesting software. If we start now, by the time the physics of the holodeck come to light (literally), we'll have most of the control software needed. Software will be ahead of hardware for once!</P> <P CLASS=3D"western">For several years I collected notes and research papers, learned the tenets of software development, devoted myself to providing the best solutions possible in my various jobs, and strived to gain my own understanding of as many software technologies as I could. Several things started to happen in software that were very encouraging. The Internet proved that internetworking could work on a global scale. SGML's child, HTML, spawned significant interest and development of one of my favourite technologies: XML. Previously proprietary advances in hardware, transaction processing, fault tolerance, clustering and other aspects of large scale systems became common place. The free software and open source movements became a commercial reality.</P> <P CLASS=3D"western">So, what does all this have to do with the eXtensible Programming System? Everything! There is now sufficient Open Source software to draw upon, the plan is succinct enough in my mind to execute, and I could use some interesting work to pass the idle days. Consequently, I've started putting the software for XPS together. Undoubtedly this will be a long process; but, I've always believed in setting my goals very high so that if I only achieve ½ of what I set out to achieve then I still have accomplished something worthwhile. Using the concept of the holodeck as a focal point for the project, has turned out to be quite useful. It is a constant reminder of the high ideals for the system and causes me to make design decisions that break through my own pre-conceived notions of what computing is or ought to be. At the core of the XPS is a striving to make a quantum leap forward in software technology using the same old techniques I've always used: incorporating the ideas of the giants that have gone before me and inventing the rest.</P> <P CLASS=3D"western">XPS is intended to take software to the next level by laying the foundation for an extensible machine that will support the rapid development of whole knowledge domains as yet undiscovered. It will raise the level of abstraction in programming and make scalable, network accessible programming available to large non-technical audiences. In its essence, it will provide the basic platform from which a system as complex as the holodeck could be built. It will incorporate every known tenet of computer science and software technology into a robust platform for the exploration and development of new ideas. Phew!</P> <P CLASS=3D"western">So how are we going to do this? I have my own ideas, but I was counting on you for the real answers!=20 </P> <H1 CLASS=3D"western">Overview</H1> <P CLASS=3D"western">The XPS is a large system and I make no apologies for it. One of its primary goals is to raise the level of abstraction for programming without sacrificing performance. In its essence, it provides a virtual machine with a very high level and extensible instruction set that abstracts away all the details of multi-processing, multi-threading, synchronization, internationalization, machine limitations, transaction processing, network communications, messaging, data storage and retrieval, mathematical functions, and etc. At its foundation, the system provides a comprehensive programming language (XPL), the compiler for that language (XPLC) and a capable virtual machine (XVM). In its initial incarnation, the system combines some of the best Open Source software (GNU/Linux, GCC, ACE, Xerces, ICU) to implement these components. Someday the virtual machine could be implemented in hardware.=20 </P> <P CLASS=3D"western">However, all of the above components, lofty as they may seem, are simply the foundation of XPS. They are the enablers of two badly needed things in software development: meta-programming and domain engineering. Meta-programming is the ability to program in higher level abstractions (preferably without loss of performance). Domain engineering provides the mechanisms for developing whole new computing vocabularies that support programming for specific knowledge domains without resorting to lower level languages. These two related concepts are at the core of extensibility and provide the reason for XPS' existence. Even though the base system (XPL + XPLC + XVM) is quite useful on its own, its intent is to only provide the common computing base that will enable extensible programming. To support extensibility, XPS provides an extension compiler (XPLEC) which processes extensions (written in XPL) to the system and allows the base system to operate with the compiled extension. The XPLEC is required to make extension development easier and to validate that the extension will not violate the integrity of the system as a whole. Extensions add fundamental and new operations to the virtual machine. Since XPL compiles to native machine code, it is used as the fundamental programming language for extension of the virtual machine. Through the magic of XML substitution groups, and XSLT, XPL itself can also be extended to include new information types and primitive operators (probably coinciding with a virtual machine extension). This combination of extension capabilities permits entirely new programming languages to be created using the facilities of XML and XPS.=20 </P> <P CLASS=3D"western">A few other things are needed to round out the picture. It isn't sufficient to simply provide the raw language and machine that support the system goals. We also need the tools that go along with programming.Today we use a variety of configuration management, software versioning, build and compilation tools to deal with our textual programs. All of these are valuable and the XPS encapsulates them and provides them as a network accessible service. Software can be written, developed and tested anywhere, any time and the XPS will handle all the underlying details of managing the code. Ultimately, the “integrated development environment” for XPS looks like the holodeck too: a virtual world of visual software components being constructed and assembled through direct interaction. No more typing!</P> <P CLASS=3D"western">The XPS provides a comprehensive platform that handles all the technical aspects of making a very high level language execute efficiently on an arbitrary machine. It does all this to support the extension of the virtual machine and the development of new executable XML based programming languages and knowledge domains.</P> <H1 CLASS=3D"western">The XPS Components</H1> <H2 CLASS=3D"western">XPL: eXtensible Programming Language</H2> <P CLASS=3D"western">The eXtensible Programming Language incorporates many of the key features from today's programming disciplines. The expression structure is reminiscient of Lisp. The object-oriented features are similar to Java. The algorithmic features are like “C&rd= quo;. The predicate calculus and fuzzy logic features are similar to Prolog. However, the syntax of XPL is simply XML and is defined with an XML Schema Definition. The XPL schema definition was designed from the ground up with extensibility in mind. It uses substitution groups heavily to permit incorporation of additions to the definitions of the basic language components and new primitive operations. While the language is comprehensive on its own, remember that its only goal is to provide the “computer science” parts so that additional languages can be developed with XPL as the base language.</P> <P CLASS=3D"western">Becase XPL is simply an XML document, it can be processed with the full power of XML technologies. Whole new XML based programming languages can be translated to XPL through the use of XSLT. XPL programs can be processed for purposes other than compilation: publishing, visual exploration, semantic analysis, database storage, etc. The choice to use XML as the syntax language for XPL makes the assumption that one day all information will be transmitted in XML or its successor. This isn't an unreasonable assumption given the prevalence of the world wide web.=20 </P> <H2 CLASS=3D"western">XPLC: XPL Compiler</H2> <P CLASS=3D"western">The XPL compiler handles the traditional task of converting XPL source programs into a format that can be directly executed by a native machine. However, in the case of the XPS, the “native machine” is actually the combination of a virtual machine (providing the high level instruction set) and native code. That is, the XPLC converts XPL into sequences of operations on the virtual machine. Instead of making a “portable back end” for the compiler, we've chosen to make a “portable instruction set” and ignored the myriad details of native machine code generation (fortunately, GCC does a wonderful job of that). The XPLC also handles all the details of semantic analysis of XPL programs. XPL groups software into packages that belong to some domain. The compiler produces and saves a symbol table for each package that successfully compiles. The symbol table can then be referenced directly by both executing programs and additional compilations. This makes the execution of the compiler faster (it doesn't have to recompile all the referent packages) and makes the entire symbol table available to executing programs.=20 </P> <H2 CLASS=3D"western">XPLI: XPL Interpreter</H2> <P CLASS=3D"western">As an intermediate step towards development of the compiler, an XPL Interpreter was developed. The interpreter parses and executes XPL code directly. That is, instead of producing a separately executable program (as the compiler does), the interpreter invokes operations on the XVM directly as it encounters them while parsing the XPL software. Interpreted XPL runs much slower than compiled XPL but it starts executing much sooner because the expensive compilation step is mostly avoided. In general, developers will use the interpreter for development, testing, and exploration. When an XPL package is ready for general consumption, it is then compiled and made available in its faster compiled form.</P> <H2 CLASS=3D"western">XVM: eXtensible Virtual Machine</H2> <P CLASS=3D"western">This is the heart of XPS. All the things that can be done in an XPL program are executed by the XVM. The XVM implements the XPS instruction set for a given computing platform. In this regard, it is much like the Java Virtual Machine but its instruction set is much larger and extensible. The core instruction set hides all the “nasty details” of the inherent functions of the XPS including memory management, threads, processes, tasks, synchronization, security, transactions, I/O, etc. All computing resources are managed by the XVM.</P> <P CLASS=3D"western">Each instruction in the core instruction set is 16 bits wide, providing for up to 65,536 instructions. To invoke an extension to the XVM, two core instructions are used to bracket sequences of extension instructions. There can be 2^32 (about 4 billion) extensions to the XVM, each with its own 16-bit instruction set. We think of the core instruction set as the “default extension” numbered 0.</P> <H2 CLASS=3D"western">XPLEC: XPL Extension Compiler</H2> <P CLASS=3D"western">The XPLEC does two things. First, it allows an XPL package that implements a specific, well-known interface to be used as an extension to the XVM. Second, it handles the translation of higher-level programming languages into XPL through XSLT templates and transformations. In both cases, the XPLEC simplifies the business of extending the XPS and verifies that each extension is legal and “does no harm”.=20 </P> <H2 CLASS=3D"western">XPSSH: eXtensible Programming System Shell</H2> <P CLASS=3D"western">This is the program that user's interact with. It is a shell program that responds to an XML based command language to get the XPS to do things (such as compile or run a program). Although it is possible for user's to directly interact with the XPSSH, it is generally assumed that some other (probably XPS based) program is handling the actual user interaction and passing on requests to the XPSSH. XPSSH provides a barrier between what is internal to the XPS and what is external. It handles all user authentication and authorization functions before passing requests on to the XPS Daemon (XPSD).=20 </P> <H2 CLASS=3D"western">XPSD: eXtensible Programming System Daemon</H2> <P CLASS=3D"western">This is a meta component of the system. It is a system services daemon that sits around waiting for an XPSSH instance to ask it to do something. Users send requests to the XPSD via the XPSSH which handles all the request validation functions. The XPSD assumes that when a request is made of it, all the necessary security precautions have been handled. Consequently, for security reasons, the XPSD is not a network daemon. It does not accept network connections. This makes it efficient for the various components of the system to make low-overhead requests of the daemon in order to get things done. The functions of the XPSD are broken down into four sub-services: Build, Develop, Deploy, Execute. The Build service handles software compilation and automatic dependency checking. The Develop service handles programmer editing requests, software versioning, check-in and check-out, configuration management, etc. The Deploy service handles the deployment of finished software into a public execution space. The Execute service handles requests to start, stop, pause, and manage XPL programs. All or none of the services can be enabled on a given XPS installation depending on the intended use of the machine.</P> <H1 CLASS=3D"western">Conclusion</H1> <P CLASS=3D"western">This paper has provided a cursory and somewhat tongue-in-cheek overview of the eXtensible Programming System. There is much more to discover. Use the following URLs to find additional information:</P> <UL> <LI><P CLASS=3D"western">Rather Verbose Home Page:=20 <A HREF=3D"www.x10sible.org/">http://www.10sible.org/</A> or <A HREF=3D"../../../../../../../">http://extprosys.sourceforge.net/</A> </P> <LI><P CLASS=3D"western">Source Forge Project Site: <A HREF=3D"http://sourceforge.net/projects/extprosys">http://sourceforge.n= et/projects/extprosys</A></P> <LI><P CLASS=3D"western">Software & Document Download: <A HREF=3D"http://sourceforge.net/project/showfiles.php?group_id=3D51164">= http://sourceforge.net/project/showfiles.php?group_id=3D51164</A> </P> <LI><P CLASS=3D"western">Subscribe To Our Email List: <A HREF=3D"http://sourceforge.net/mail/?group_id=3D51164">http://sourcefor= ge.net/mail/?group_id=3D51164</A> </P> </UL> <P CLASS=3D"western">You've have had your appetite whetted, now come and help us build software's future!</P> </BODY> </HTML> |
|
From: Reid S. <re...@re...> - 2002-12-30 05:05:34
|
Dear XPSers, Tonight I've released version 0.1.8 of XPS. This release includes tested and working versions of much of the infrastructure needed for the 0.2.0 release. Many improvements to the memory system have been made especially typesafe "pointers" in memory regions. The ADT module was overhauled and provides Array and HashTable templates now. The META module was revised to use the new HashTable and Array implementations as well as the new VectorPointer classes. It was also augmented to provide XPL output from a stored metaschema (partial implementation). This is the first release to pass the"make distcheck" target and should be simpler to build. This is a large step closer to getting to a reflective compiler. That is, one that can reproduce the original input from its symbol table. That is the goal for the 0.2.0 release. The next release, 0.1.9, will include a full meta schema for XPL which will be used as the compiler's symbol table. Once that is done, the metaschema will be attached to the xplc compiler so that the metaschema can be produced directly from XPL and hence we arrive at release 0.2.0. The compiler will then be able to correctly report on syntactic, grammatical, and semantic errors. This approach ensures that we've captured all the salient information about a program before moving forward with code generation which is the subject of the 0.3.0 release. Stay tuned, we'll have a compiler for XPL programs in a few months. Best Regards, Reid. |
|
From: Reid S. <ras...@re...> - 2002-12-16 15:15:15
|
XPSers,
I have released version 0.1.5 of the eXtensible Programming System.
This release contains the following:
1. Simplified XPL.xsd (XML schema for XPL) that eliminates all
the abstract elements, provides a consistent naming for the
operators, adds additional functionality not previously in
XPL. Review the annotations and comments in the XPL.xsd
schema file or browse with XML Spy.
2. A new sample program, HelloWorld.xpl has been added to the
src/schemas/tests directory. You can review this familiar
program as a way to get familiar with XPL. However, this
version of "Hello World" can print out the greeting in five
languages so its not quite as trivial as you might expect.
3. Full support for autoconf/automake. The bulk of the
configuration work is done. The remaining work in this area
will pertain to ensuring the correct set of capability tests
are provided. The current build system is capable of building
different configurations (one per build directory) right
through distribution. The XPS 0.1.5 release was made with
"make dist".
4. An improved memory allocation system. The Segment classes
have been revamped to be more efficient and to implement
missing functionality. The Region class has been totally
revised to minimized bookkeeping overhead and allow users to
roll their own region configuration. Two features remain:
making the system work with transient memory as well as
persistent memory and making it all thread safe (Segment
class is already thread safe).
5. New modules: adt (Abstract Data Types), obj (Object Schema),
meta (Object meta schema), space (workspaces, etc.). These
four modules are in a rudimentary form but all are part of
the XPL compiler, xplc. The space module manages a user's
workspace which is simply a directory with XPL programs,
compilation objects, & etc. The meta module provides the
type system for XPL and the compiler will use these classes
to capture the declarations of various types from user
programs. The adt module provides persistent-aware abstract
data types such as sets, vectors, arrays, maps, and hash
tables. These will be similar in nature to the STL but much
simpler and with the ability to handle persistent memory
allocation.
6. The "util" module now contains two new classes: "Config" and
"MsgLoader". The Config class provides for configuration of
the various XPS modules via XML-based configuration files.
The schema for the files is in the Configuration.xsd file in
the src/schemas directory. The configuration files are quite
simple. Properties are placed in groups which can contain
either groups or properties. The MsgLoader class provides
(via ICU) loading of natural language messages for XPS. The
messages are stored in the "*.msgs" files and these can be
internationalized as we go along. This means that all
user-bound messages generated by XPS can be reported in
multiple natural languages.
7. The "test" module has been merged into the "util" module to
eliminate cyclic build dependencies. Unfortunately, this
means that some of the separation of concerns has to be
handled in the makefiles in the util module. Hope you never
have to go there.
8. The XPL compiler will validate your XPL program, and report
errors. However, it currently doesn't compile to anything.
That is the next step (release 0.2.0).
9. The XVM is currently just a skeleton. This program will
eventually be the backbone of any running XPL program.
10. The XVMSH is currently just a skeleton. This program will
translate user level commands into something the XVM can act
upon.
If you would like to try this early release out, here's what you need to
do:
1. Get the distribution file from here:
http://sourceforge.net/project/showfiles.php?group_id=51164
2. Use winzip or "tar" to extract the files.
3. In the xps-0.1.5 directory you should find files named README
and INSTALL. Read them, it'll save you some time.
As always, if you have questions, please feel free to ask.
Best Regards,
Reid.
|
|
From: Reid S. <re...@re...> - 2002-12-06 00:15:32
|
Everyone, My recent set of changes have led to the first executable program for the XPS: an early version of the compiler, xplc. This current version uses Xerces to parse an XPL program and check it for syntax/grammar validity. I'm currently working on extending this to (a) capture the symbol table and (b) validate the compilation. Once all that is done, I'll turn my attention to the back end and start generating executable code from XPL source. If you want to try out the parser and try writing programs in XPL, here's what I suggest you do: 1. Get the latest tarball from SourceForge (http://sourceforge.net/projects/extprosys) 2. Get Xerces-C 2.2 (i.e. the "developer snapshot pre-release of 2.2", at http://xml.apache.org/xerces-c/) 3. Get ICU 2.2 from IBM (http://oss.software.ibm.com/icu/ 4. Configure & build both Xerces-C and ICU into a common install directory 5. Configure & build XPL (use the bootstraph.sh script at the top level directory) 6. Make sure you source the <xpl>/config/bashrc file in your bash shell (you might need to configure it first). The modules you need are: util, test, mem and xplc. Once xplc is finished build, it should produce a program named xplc which you can use to parse your XPL programs. Just provide it with a file name to parse. If you'd like to try the above, please let me know as I'm quite interested in having someone else verify the build and configuration of XPL. The above should work on RedHat 7.2 or later. It should also work on other recent GNU/Linux systems and possibly on cygwin under Windows 2K. If there are any questions, please ask. I'll help you. Other changes: 1. Schema updates (<xpl>/src/schemas/XPL.xsd). The language is MUCH simpler now. I got rid of the abstract schema components and reduced the operator complexity by 130 element types while adding more functionality 2. HelloWorld.xpl (<xpl>/src/schemas/tests/HelloWorld.xpl). This is an XPL program to print "Hello World." but it does it in 5 languages and uses method discriminants. Its a bit of an "overkill" for the traditional HelloWorld program but its instructional. 3. The memory system is up and running. I've tested it heavily and works well. 4. Lots of cleanup in makefiles and configuration stuff. Happy XPLing. Reid. P.S. If you write any XPL programs, please let me know. I'd like you to include them in the test suite for the compiler. |
|
From: Reid S. <ras...@re...> - 2002-11-27 09:29:01
|
*This message was transferred with a trial version of CommuniGate(tm) Pro*
Hi,
Sorry for the long delay in sending news about XPS. I figured I might as
well wait until I had something worthwhile to say. Much of my time was
taken up with settling in after the move to SF Bay area. That nasty need
for money has kept me away. Anyway, I'm back working on XPS as much as
I can.
Tonight I committed all my recent changes (all build on RedHat 7.3).
Here's a summary (in priority order):
1. src/schemas/XPL.xsd - this is a new schema without all the
abstract stuff. This is the way the schema will look from now
on. Its much simpler. Everything's in one file. All the
elements are concrete (with the exception of a few
substitution groups for the operators). I would encourage
everyone to review this (best with XML Spy) and let me know
what they think. Hopefully its an improvement. This schema
will form the foundation for the first version of the
compiler (which I'm starting on next). I hope to have an XPL
validator (can point out syntax/semantic errors) in the next
couple of months. That should prove to be the first useful
tool for everyone as it will "almost" compile XPL. Once that
is done, I'll plug in the GCC backend to produce code from
the semantic map. That will probably take a couple more
months.
2. src/mem - the first version of this persistent/transient
memory module has been completed. I've written an initial
test suite for it and the basics all seem to work. About the
only pressing thing remaining is testing it for thread
safety.
3. src/xvm - I've upgraded the XVM shell. It compiles to a
program that doesn't do a whole heck of a lot but at least it
is there.
4. src/util & src/test - these basic modules were upgraded and
tested
5. configuration - some minor improvements to configure.in, the
makefiles, bootstrap.sh, templates, etc.
To look at the schema, you can get it from the SourceForge CVS
repository here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/extprosys/src/schemas/XPL.xsd
To try building this (way early) version of XPS (or just looking at it),
you should get the gzipped tarball from:
http://cvs.sourceforge.net/cvstarballs/extprosys-cvsroot.tar.gz
and compile it on RedHat 7.3. Just run "bootstrap.sh" in the top
directory to run the compilation. You'll need ACE 5.2 at a minimum to
successfully compile.
If you're adventurous, try it compiling it on cygwin. It should (mostly)
work, but Its been a while since I tried it.
As always, if you have questions, feel free to ask.
Best Regards,
Reid.
|
|
From: Reid S. <re...@re...> - 2002-09-26 14:27:00
|
*This message was transferred with a trial version of CommuniGate(tm) Pro* All, My domains have been switched and I'm back online in Silicon Valley. I'll review the recent Logo submissions tonight and set forth some plans for the upcoming 0.2 release. If any email to me bounced, please resend now. Best Regards, Reid |
|
From: Reid S. <re...@re...> - 2002-09-20 04:57:00
|
*This message was transferred with a trial version of CommuniGate(tm) Pro* XPSers, My email server will be down for a few days as I travel to California. If you send me email and it bounces, you'll know why. Please resend after a couple of days. It should all be up and working by Monday (9/23) or Tuesday (9/24). Sorry I haven't had time to review logo submissions recently .. just gives you a little more time to perfect them. I'll take a look at them next week when the dust settles. Best Regards, Reid. |
|
From: Reid S. <re...@re...> - 2002-09-16 00:20:54
|
*This message was transferred with a trial version of CommuniGate(tm) Pro* Thanks, Vic. I didn't think you'd have any objections seeing as it was your comments that sparked the decision! :) Glad you'll be able to spend a little time on the project. I've just had the movers here today so I'm at at the end of a bit of a dry spell. This week I hope to get the Schema changes and start work on the compiler, probably starting with the XVM service. Want to help? Reid On Sun, 2002-09-15 at 16:06, Victor Kirk wrote: > *This message was transferred with a trial version of CommuniGate(tm) Pro* > At 01:31 12/09/2002 -0700, Reid Spencer wrote: > >So, I ask you to respond to the following questions: > > > > 1. Does anyone feel strongly about keeping the abstract schema? > > 2. Is anyone dead set against using English as the natural > > language for core XPL? > > 3. How much demand for programming in languages that use > > non-English keywords would you expect? > > 4. Do you see any fatal flaws in what I'm proposing above? > > I think that this a good idea. > > On another note, I hope to have a little spare time this week to > make a start on some things. > > Take care, > > Vic > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > eXtProSys-devel mailing list > eXt...@li... > https://lists.sourceforge.net/lists/listinfo/extprosys-devel |
|
From: Victor K. <vi...@mo...> - 2002-09-15 23:05:49
|
At 01:31 12/09/2002 -0700, Reid Spencer wrote: >So, I ask you to respond to the following questions: > > 1. Does anyone feel strongly about keeping the abstract schema? > 2. Is anyone dead set against using English as the natural > language for core XPL? > 3. How much demand for programming in languages that use > non-English keywords would you expect? > 4. Do you see any fatal flaws in what I'm proposing above? I think that this a good idea. On another note, I hope to have a little spare time this week to make a start on some things. Take care, Vic |
|
From: Reid S. <re...@re...> - 2002-09-14 02:23:10
|
Oops, I forgot to mention one other schema change that I am considering for the 2.0 release: Currently, the definitions of file, stream, region, and segment types all support full object orientation like interfaces and classes. However, in thinking about this, it makes them pretty heavy weight. It also gets confusing when multiple inheritance is involved. Suppose you derive a class that inherits from both file and stream? The interfaces of file and stream are almost identical so you'd have to rename one in favor of the other. That just smacks of bad design. So, I'm proposing that files, streams, regions, and segments be fundamental objects in XPL/XPS, each with their own set of operators. This makes their use much more concise, probably more efficient, and definitely more understandable. Furthermore, there is nothing that will stop us from creating wrapper classes around these objects so that, if needed, the full power of object-orientation can be accessed in conjunction with files, streams, regions, and segments. I think this will significantly streamline XPL and hope you agree. Please let me know if you disagree. Thanks, Reid |
|
From: Reid S. <re...@re...> - 2002-09-13 05:47:05
|
*This message was transferred with a trial version of CommuniGate(tm) Pro* Logo Designers, One of our more prodigious logo designers has spurred a creative spark in the form of a logo idea. To be fair to all of you, I thought I should share the idea clearly, as I see it in my mind's eye, so you're all on the same footing. What follows is a more detailed description of what the logo should look like. The logo should be 3 dimensional with appropriate texture and lighting effects (preferably with the light source coming over the viewer's left shoulder -- shadow extending to the right and away). At the base of the logo is a foundation that looks strong (granite or marble texture is what I think of, but use your imagination too). On top of the foundation are three letters: X P S. However, the texture of the letters conveys a certain elasticity, as if they were made from springs or rubber bands or some other material that looks malleable. However, the shape of the letters should look sturdy and solid, like the foundation. The face of the foundation should have the words "eXtensible Programming System" engraved on it. Three versions of the logo should be created according to the above theme: 1. A full color, high resolution work suitable for color glossy reproduction in marketing pieces (brochures, advertisements, etc.). This should be about 1" high by 2" wide when printed with at least 300dpi. 2. A web color, medium resolution work with animation (get the elasticity thing going somehow), suitable for web sites. This should be created in multiple sizes from small (32 pixels high) to large (256 pixels high) at a resolution of 72dpi 3. A 3 color piece suitable for printing on stationery (envelopes, letter head, business cards) using PANTONE colors at 300dpi. The color scheme for all three versions needs to be similar. That is, you're restricted by the 3-color piece for stationery. Someone viewing the stationery and then looking at a marketing piece should instantly recognize it as the same logo just with differing levels of detail (the marketing piece should be much more detailed with significant texture and lighting effects; the stationery piece should trade off some of the texture/lighting effects to keep printing costs lower by only using shades of three colors). In thinking about the foundation part of the logo, I have also just remembered a particular gemstone that I find very attractive and classy and would love to see it worked into the logo. The gemstone is Lapis Lazuli. It is a deep royal blue but has streaks or specks of gold color in it. You can get some information about this gemstone at Lapis Lazuli World: http://www.lapislazuliworld.com/lapislazulifacts.html Okay, I think the logo mission is a little more defined now .. hope this helps you create the winning design. Please submit all three versions of your design. When they are all in, I'll post them to the web site so you can see each other's work and I'll pick the winner. Then we can all work together to make the winning design a theme for the web site. THANK YOU for all the work you're putting in on this! I REALLY appreciate it! Reid |
|
From: Reid S. <re...@re...> - 2002-09-12 07:26:21
|
*This message was transferred with a trial version of CommuniGate(tm) Pro*
XPSers,
I've done a lot of thinking about the XPL Schema, as published in
release 0.1.1, and have made some decisions to reduce its complexity.
However, before just charging off and doing it, I thought I'd run my
thinking by you for your opinions. Please respond as quickly as possible
as I'm trying to get 0.2 out in a few weeks and this schema change needs
to be included.
After I published 0.1.1, Victor Kirk brought up a very good point: that
there is no need to support an abstract schema from which multiple
natural language schemas can be derived because (a) it thwarts software
reuse if everyone is developing code in different natural languages and
(b) multiple natural languages can still be supported via XSLT
transformations.
One of my goals for XPL has always been to make it easier to program for
non-English speaking people. However, Vic's two points keep ringing in
my ears. By making the core XPL language based on English only we can
reduce complexity (and thus speed up translation) of XPL significantly.
It will also make writing the XPL compiler easier. And, in doing this,
not much is lost if we can still create natural language variants of the
XPL core for those who wish to program using language keywords (element
names, really) that use terms in their native language.
So, the decision I've made is to modify the schema as follows:
1. Ensure there are no attributes in the language as it is more
difficult to create derivative alternate language schemas
since XML schema doesn't support extension of attributes
(this is a shortcoming of XML Schema that needs to be fixed!)
2. Eliminate all the abstract elements (everything ending in
.elem) and replace them with their English language
counterparts.
3. Keep all the complex/simple type definitions but define them
in terms of concrete English language elements instead of the
abstract names.
4. Combine XPL-Abstract.xsd and XPL-en.xsd into one file,
XPL.xsd.
I estimate that these changes will eliminate about 1/3 of the schema
definitions and make it much easier to grasp to the novice.
So, I ask you to respond to the following questions:
1. Does anyone feel strongly about keeping the abstract schema?
2. Is anyone dead set against using English as the natural
language for core XPL?
3. How much demand for programming in languages that use
non-English keywords would you expect?
4. Do you see any fatal flaws in what I'm proposing above?
Thanks in advance for your timely responses.
Best Regards,
Reid
|
|
From: Reid S. <ras...@re...> - 2002-09-07 23:53:01
|
*This message was transferred with a trial version of CommuniGate(tm) Pro* XPSers, I'm moving to Silicon Valley about the 20th of September. Consequently, I'll be without Internet service for a few days as I reconnect my systems in the new location. Please don't be surprised if my responses are slow between September 18th and September 25th. Thanks for your patience, Reid |
|
From: Reid S. <ras...@re...> - 2002-09-07 23:44:37
|
Logo Designers,
I'm sending this email to everyone that applied to help with the logo
design and other art work for the XPS project. To assist with
confidentiality, I've Bcc:'d you so the email addresses don't show up.
I thank you for the strong interest you have all shown in the XPS
project and for your submissions. My apologies in not getting you
feedback before now. I'm in the process of a move to Silicon Valley and
things are a bit hectic in my life right now. It will settle down toward
the end of September -- your patience greatly appreciated. I've also
been undecided as to how I should select among all your fine talents.
So, I thought I'd let you folks decide how you'd like to participate in
the project. This email will describe exactly what I'm looking for so
you can make a decision about how you'd like to participate. If you
wish to continue to volunteer on this project after reading this
message, you must email a response to this message. I will assume that
anyone who hasn't responded by 9/14 is not interested. For those who
do respond, I will add them to the SourceForge project immediately.
Volunteer Basis
The entire XPS project is being developed on a volunteer basis, my time
included. People who volunteer for the project do so because they are
excited about the idea of building a new application server platform
that is completely open source, state of the art, and involves
extensible programming with XML. Sometime later this year, I will be
forming a non-profit organization to give a formal organizational name
to the group of people that work on the project. It will also make it
easier to get funding for the project if/when that becomes a reality.
The project is aimed at commercial viability using a model similar to
Red Hat and JBoss. However, at this time there are no promises. There is
much work to be done and no money to pay for it. Those who join the
project at this early date will be the first to be compensated if/when
the project reaches commercial viability.
Competitive/Cooperative Design
Because six of you have shown interest in designing art work for this
project, I have decided to let you work competitively or cooperatively,
if you so choose. If that's doesn't work for you, I understand
completely and hope there's no hard feelings. If you wish to collaborate
rather than compete with the other artists, please contact me and I'll
email your request to the other respondents.
About XPS
The purpose of the XPS project is to bring highly effective, efficient
and powerful programming tools to the lay person (i.e. someone who is
not a computer programmer). The project consists of three basic
components:
* XVM: XPS Virtual Machine: a state-of-the-art application
server that takes care of the technical details such as
threading, synchronization, network interface, portability,
source repository, etc.
* XPLC: XPL Compiler: a compiler for the XML based programming
language XPL. This component turns human readable XML code
into instructions for the XVM.
* XPLEC. XPL Extension Compiler: a compiler for extending XPL to
do new things, particularly to support domain specific
languages. This allows XPS to be customized to particular
areas of expertise.
A good analogy for XPS is the way a PhotoShop plug-in works. PhotoShop
itself is like the XVM, providing the raw rendering and image
manipulation capabilities. The XVM provides the raw computing
capabilities. The plug-in interface is like XPL; it lets PhotoShop be
extended to do things that PhotoShop doesn't do inherently. XPL is the
interface to the XVM. The XPLEC is like the plug-in itself .. it
permits people to easily manipulate their images in wild and wonderful
ways. However, the difference between PhotoShop and XPS is quite
different. PhotoShop provides an extension capability in only one
knowledge domain (artistic rendering) while XPS will support this
extension capability in any domain. That is, chemists, economists,
musicians, and politicians will all be able to write XPS programs in a
language that is suitable to their domain. For example, a chemist would
write programs in terms of atoms, molecules, reactions and isotopes. He
doesn't have to worry about technical things like memory, transactions,
permanent storage, algorithms, etc. The entire point behind XPS is to
extend the reach of computer programming to every field that can benefit
from it without having to become an expert programmer.
Themes, Motif, Ideas, Concepts
The logo and subsequent art work that gets developed for XPS needs to
convey certain messages to the viewer. This is where the challenge is
because there are two conflicting themes that must be portrayed:
* a solid/strong/robust foundation (i.e. the XVM is a
solid/strong/robust base upon which to perform computing)
* a fluid/extensible/easy to use interface (i.e. the XPLC/XPLEC
allows rapid programming in a fluid, easy and extensible
manner)
The successful design will convey both of these themes in equal balance
so that the viewer is immediately assured of both the successful
execution of their programs and the ease with which the program can be
written. We want to project an image of quiet confidence and strength
but at the same time there needs to be a wistful playfulness to the
design. I child should be intrigued. A curmudgeon should be comforted.
Colors should be subdued but not dark. With the foregoing being said,
the art work needs to look "cool" as well. It should catch the viewer's
attention immediately and convey the two themes immediately.
Ultimately, the project needs more than just a simple logo or splash
page. The winning submission will be the one that competently presents a
whole theme for both the web site and printed materials. The logo is key
to developing the theme as it is the focal point, but the logo can't be
developed in isolation from the other works as they must blend together
well. Furthermore, the logo needs to work both statically (i.e. on
paper with no animation) as well as dynamically (i.e. on a web site with
animation).
The web site for the project will eventually be www.x10sible.org (domain
already acquired) so feel free to use "x10sible" in your design.
I've often thought of using a spring or elasticity effect to convey the
extensible part of the theme, however don't limit yourself to this idea
.. use your imagination to come up with new ideas to convey
extensibility.
Any use of a metallic, industrial or riveted effect to convey the
"solid/strong/robust foundation" will be frowned upon so save yourself
some effort and skip that idea .. its been done and looks tired these
days ( in my opinion).
In addition to the two main themes above, we also want the artwork to
convey the following attributes: fast, elegant, portable (i.e. works on
many computer platforms), well-designed, efficient, comprehensive (does
a lot for you), easy to work with, new (i.e. a new way of programming
computers), not for nerds and geeks only, stable, reliable, and secure.
I don't expect all those things to be covered in a single logo but
thought I'd mention them so you have some ideas about what I"m looking
for.
Form Of Submissions
The XPS project is inherently an open source and Internet based project.
Consequently, the types of artwork that will be accepted should use
common open source non-proprietary formats. For multimedia, please
ensure the piece is compatible with Plugger 4.0 (multi-format plug-in
for Netscape that handles a wide variety of multi-media formats; see
http://fredrik.hubbe.net/plugger.html for details). For bitmap based
works, please submit in GIF, JPEG, PNG or another format supported by
The GIMP (Gnu Image Manipulation Program, see http://www.gimp.org/ for
details). For vector graphics, I will accept only SVG format because of
its tie to XML. As an exception to these rules, I will accept
submissions in Shockwave-Flash format (SWF) since Macromedia is so good
about making their readers freely available on all platforms.
The design needs to work electronically as well as in print. This means
the motif should be limited to shades of at most 3 colors. Using
standard PANTONE colors would be preferable as it makes printing
easier. Select PANTONE colors that have good web equivalents.
Submissions should be accompanied by a written description of how the
work satisfies or uses the ideas in the Themes, Motifs, Ideas, Concepts
section above.
If your submission is large or contains multiple files, please compress
it to either a gzipped tar file (*.tar.gz) or a zip file (*.zip).
Questions
Please submit your questions about the project to the developer mailing
list at ext...@li.... I will do my best to
answer any question I receive in a timely fashion.
My Best Regards,
Reid Spencer
XPS Project Team Lead
ras...@re...
|
|
From: Reid S. <re...@re...> - 2002-08-22 03:12:24
|
*This message was transferred with a trial version of CommuniGate(tm) Pro*
Victor,
Thank you for your feedback. My further comments are inline as well ..
On Mon, 2002-08-19 at 15:52, Victor Kirk wrote:
> > I would like to solicit your feedback on a variety of topics about
> > the language definition so far. When you get to the point that you
> > grok what I've done, please see if you can provide your feedback on
> > the following topics.
>
> Sorry to take so long in replying to this, things are as hectic as
> ever :-(
Hey, it happens. I'm just glad to have any feedback at all :)
>
> > 1. Incorporating Memory Management (Regions and Segments) Into The
> > Language. I wanted to do this to be explicit in the language
> > about how memory is organized and allocated so that it isn't
> > shuffled off to some "library routine" that varies from machine
> > to machine and uses different strategies. By incorporating memory
> > management in the language, the programmer has greater control of
> > how the program utilizes memory.
>
> I'm afraid I haven't anything worthwhile to contribute to this,
> perhaps after some prototyping has been done I will be in a better
> position. However my first thoughts would be to try and make this as
> automatic as possible as one of the aims is to reduce the overhead and
> complexity in developing software (which unfortunately transfers the
> complexity to us).
I agree that one of the primary goals that we're after is to reduce the
complexity of programming. However, I'm also trying to strike a balance
between flexibility and performance. I have decided that there needs to
be a very rigorous interface between XPL and the XVM because they are
aimed at different purposes. XPL is the base language from which
flexibility is derived (by extending the schema, defining new languages
and translating to XPL, etc.). That is, we use XML/XSLT in the usual
ways to invent new programming languages/models/abstractions that
(eventually) translate down to the core XPL language. The XVM provides
a virtual machine for executing compilations of programs in that core
language. As long as the mappings between the higher level domain
specific languages and XPL are sane, we can program at higher levels of
abstraction without losing anything in terms of performance. What this
means for the XPS, however, is that it must be very focused on (a)
ensuring consistent execution semantics across multiple platforms, and
(b) performance. This leads to some interesting design issues with the
XVM ...
One of those issues is memory management. We have to deal with the
efficient allocation and deallocation of memory in the XVM. There are
several strategies that could be undertaken ranging from completely
automated memory management (i.e. XVM handles all issues including
garbage collection) to completely manual (i.e. programmer has to decide
how to lay out memory and when to allocate/deallocate it). Neither of
these extremes is appropriate. The former (fully automated) can't
perform (e.g. garbage collection for real time systems). The latter
(fully manual) is tedious and error prone. So, I've tried to come up
with a happy middle ground by including regions and segments in the XVM.
Briefly, a region is a 64 bit memory space that can grow as needed. It
contains segments and can be either persistent or transient. Segments
are fixed size, relocatable data regions. Objects and data are allocated
inside segments. The algorithm for segment allocation in a region is
fixed. However, allocation of objects in segments depends on the kind of
segment. There are various techniques that can be employed to manage
memory and the XVM will support whatever is needed. Everything from
"Blob" segments where the entire segment is allocated as one object to
B+ Trees could be implemented. The XVM will provide a number of useful,
standard memory allocation models and allow new models to be added,
depending on the needs of the program at hand (this is one of the ways
the XVM can be extended). This design permits a few interesting
features for the XVM:
1. Because segments are relocatable (i.e. contain no pointers), they
can be mapped in and out of memory as needed. This allows the XVM to use
very efficient I/O and sharing techniques based on the mmap calls.
2. Memory can be deallocated very efficiently. In general, programs will
want to allocate memory for a particular task. When that task is
complete and the results have been computed, it will want to deallocate
its memory. The program can simply allocate a segment, place all the
data it needs in that segment, and then deallocate the segment. This
kind of en masse deallocation means that the XVM doesn't have to keep
track of which objects are being referenced. The "garbage" is collected
simply be deallocating the segment. Unfortunately, for the programmer,
this means that the programmer needs to do a little work to compute how
much memory is needed since growing a segment is an expensive operation
in this design. This is one of the trade-offs between ease/flexibility
and performance that I'm willing to make.
3. Because regions can address a large memory area, most programs will
be able to work entirely within one region. However, there is
4. Because there is no difference between allocating transient or
persistent memory, the programming model is quite efficient.
5. Because persistent memory storage is supported, there is no need to
support things like serialization which is often a large performance
bottleneck. Cooperating tasks can simply build up a graph of objects in
a persistent (or even shared transient) memory segment and pass
information back and forth. A program can save its state and reload it
very quickly (a few mmap calls) with all the referential integrity still
in tact (i.e. without rebuilding it from some canonicalized disk storage
format). If you're familiar with Smalltalk, these ideas are borrowed
from Smalltalk's notion of an "image".
I think the model I've selected is reasonably flexible and will perform
quite well. It may not be as simple as a fully automated memory
management scheme, but I just can't see how to make one of those perform
well for all classes of programs. To some degree, the programmer needs
to make good choices for memory management. XPS will provide good
alternatives that can be selected without worrying about the
implementation details.
>
> > 2. Defining Files, Streams, Documents, Transforms, Segments, and
> > Regions as Object Classes. Regardless of whether you think it is
> > useful for these things to be in the language (as opposed to some
> > "standard library"), what do you think about including these
> > things in the class inheritance hierarchy. I think its a nifty
> > idea because it allows you to build a type hierarchy around
> > things that interact with "external entities" (i.e. files,
> > streams, documents, memory, etc. are all external to the XVM).
You didn't comment on this point, but I've made a little progress in my
thinking here. I've decided that regions, segments, files, and streams
are NOT objects. Objects in XPL will carry a certain performance
penalty with them. Files, streams, regions, and segments all need to
perform exceptionally well. The benefits of object orientation can
still be applied by wrapping a class around the language constructs that
support a file, stream, region, or segment. And, in fact, I plan to do
just that in the XPL standard library. By making this decision, nothing
in terms of flexibility is lost but a lot is gained in the area of
performance and simplicity. So, the XVM will support separate operators
for files, streams, regions and segments.
I have also come to the conclusion that XPL objects are XML documents
and vice versa (well, at some level of abstraction anyway). This means
that you could invoke parsing algorithm on an XPL object and what you'd
get is a traversal of its attributes. You could also define an XML
document type but also adorn it with attributes and methods. I think
this makes for some interesting design opportunities in XPL programs.
What do you think?
>
> > 3. Using Lisp Style Expressions. The operator expressions in XPL are
> > similar to LISP. That is, an expression is built from the inside
> > out. Instead of saying a+b, we say +(a,b). Instead of writing
> > (a*(b/c)) we write *(a,/(b,c)). This structure falls naturally in
> > line with XML content models and makes it very easy to correctly
> > parse the programming expressions with an XML parser. I believe
> > that it will also be very efficient way to program and generate
> > code. However, it is not necessarily intuitive for the
> > novice. The last example above in XPL look like:
>
> > <mult_ii>
> > <get_i>
> > <value_loc>a</value_loc>
> > </get_i>
> > <div_ii>
> > <get_i>
> > <value_loc>b</value_loc>
> > </get_i>
> > <get_i>
> > <value_loc>c</value_loc>
> > </get_i>
> > </div_ii>
> > </mult_ii>
>
> I certainly believe that this is the way to go. XML and lisp have a
> number of similar themes which should be exploited. I've never seen
> any discussion of the rationale behind DSSSL (on which xsl is of
> course based) but I'm sure this one of the major factors DSSSL was
> implemented on scheme.
Yes, agreed. Using a Lisp style operator semantic will make code
generation to C/C++ a little bit harder, but it in other areas
(execution by the XVM) things will be more streamlined.
>
> > Its rather verbose, but functionally elegant. I haven't worried
> > about how "pretty" XPL is because I don't think anyone is going to
> > program directly in the XML text.
>
> C or C++ don't look pretty without experience of the language. Even
> with experience, people still have issues with how `pretty' code
> should look. I can understand where these arguments come from when
> you work with a text editor, but when, as Reid mentioned, the code is
> automatically generated I think this is no longer an issue.
Thanks for validating that. I sometimes wonder if programmer's will
take a look at XPL in all its verbosity and dull syntax and just decide
its too "ugly" to bother with.
>
> The important aspect is how well the code can be transformed (of
> course I don't want to start imposing restrictions just to make
> processing easier).
Yes, like I mentioned earlier, much of the XPL/XVM design is going to be
focused on getting just the right balance of performance and
flexibility.
>
> > A visual editor (emacs mode?) that simplified editing XPL would be
> > an excellent tool to build for XPL. Any volunteers out there?
>
> While XPL is not intended to be programmed in directly I think this
> could still play a useful role. Developers of higher level
> languages (HLL) (and XPL it's self) are going to what to try out
> things directly in xpl and, while xml is human readable, it can be
> quite hard to edit the file directly as text when the document becomes
> complicated.
Agreed. Hopefully the support for multiple natural languages will
mitigate this concern a bit :)
One of the things I'd like to do eventually is to write a Java2XPL
translator as part of the compiler validation suite. If we can translate
large Java applications to XPL and have them work correctly, then I
think we'll have accomplished something significant. It will also prove
that XPL doesn't have to be the syntax of choice. Going forward from
there, I envision visual programming environments that are manipulated
in something like virtual reality where the programmer doesn't
manipulate text, but manipulates programming objects visually (e.g. drag
a "class object" from a palette into the program space and manipulate
its facts visually).
>
> Two emacs modes I really find useful are xslide and docbook, perhaps
> these could be plundered for a basis. I would volunteer my self but I
> just don't have the time. I would expect to be able to help extend
> and test as the project progresses though.
Yes, its definitely a "future" thing. I'm sure when XPL gets to a
certain level of maturity, some emacs hacker will take the plunge and
create an appropriate mode. However, there may be something useful out
there already. All we need is an emacs mode that can grok an XML Schema
Definition. Since XPl is defined as one, the mode should work for XPL or
any other XML schema. Furthermore, as extension languages are defined
(in XML), the mode would automatically work for them too. So, the task
isn't so much a need for an XPL specific mode as it is for a mode that
understands and implements XML Schema Definitions very well (XPL uses
LOTS of XML Schema features).
However, even if we had an XPL mode for emacs, we're still dealing with
text. I'd like to get away from that eventually and go much more visual
and/or verbal. Somewhere towards the end of my career (20 years out), I
envision being able to program my computer by talking to it and building
up a 3D visual representation of the program and then pushing a button
to translate to XPL and execute.
>
> > Does the inelegance of the syntax bother you?
>
> As I sort of mentioned above the `inelegance' does not bother me, in
> fact I'd bet that after some experience it would become elegant, eye
> of the beholder and all that.
>
Hmm .. I didn't expect THAT response! Having typed a bit of XPL myself
already, I find it tedious. We'll see if it grows on me (and others).
> > What if the entire structure of the program was represented in 3D
> > and manipulated in a VR kind of way? Would it bother you then?
> > Because its XML, we can do all kinds of transformations from other
> > languages, syntaxes and editing systems and still end up with XPL as
> > the basic language that gets compiled. It is this latter aspect of
> > the language that is important (rigid semantic specifications, fast
> > compilation, accurate results).
>
> The possibilities such as those you mentioned above are some of the
> main sources of my enthusiasm for this project. The fact that the
> actual source code is in a format that is easy to process opens up the
> potential for tools for visualization and understanding of the
> code.
Yup, me too! I'm so lazy that I'm willing to work hard to make
programming easier :)
>
> > 4. Everything In A Method/Function Is An Operator. I wanted to
> > provide a simplicity of design such that program could be
> > constructed by arbitrarily nesting various operators. The fact
> > that the control flow operators (if, repeat, for, foreach,
> > select, switch...) can return values means they can be used
> > directly in a computational expression. C++ provides a very
> > limited form of this with the ?: operator. I've generalized it so
> > that all control flow operators may be used in computation
> > expressions. For example, XPL permits the following C++
> > equivalent:
>
> > int array[maxlen];
> > /* ... */
> > int i = for (int j = 0; j < maxlen; j++) { if (array[j] == 15)
> > { result j; break; }
>
> > Note that I take the liberty that this C++ code can (a) assign the
> > result of a for loop to an integer variable and (b) has an operator
> > "results" which specifies the result for the enclosing block. I
> > won't write the equivalent XPL because there is an example similar
> > to this in the release. But, what I would like to know is what you
> > think of this ability? Power or confusion?
>
> The fact that everything is an operator appeals to me. While I don't
> think such a structure has a place in c++ (we have iterators an
> functors to so this), I think it makes sense in xpl.
>
> I also believe that this would ease the transformation into native
> code, which is good ;-)
Yeah, that was one of my original idea for this (simple machine code
translation). Making control structures into operators is just going
back to the Lisp idea.
>
> > 5. Method Discriminants. Unlike some other popular object-oriented
> > languages, I differentiate between the messages sent to an object
> > and the methods that implement those messages. To me, these are not
> > the same things. While the message send can be optimized to a simple
> > function call in many cases, XPL also directly supports active
> > objects (running in their own thread) in which case message sending
> > is an asynchronous operation. Furthermore, I allow a class to
> > implement a method multiple times. To disambiguate which methods get
> > run on which message sends, I have introduced the notion of a method
> > discriminant. Discriminants are simply boolean expressions that are
> > computed at runtime to determine which methods get run. While the
> > same ends can be achieved with if/unless/switch operators in the
> > body of a single method, the use of discriminants provides the
> > programmer with some syntactic sugar to help keep the program
> > organized. First, method names are not necessarily the same as the
> > message names. Since multiple methods can be defined for a single
> > message on a class, this must be true. Consequently, the method can
> > be named after what it does, not what the message means.
> > Extensibility is enhanced because adding a new behavior for a
> > message is as simple as adding a new method, leaving the existing
> > methods alone and simply defining a boolean expression that
> > determines the conditions under which the method executes. This
> > style of programming greatly aids state machine development since
> > the state of the machine can be used as the discriminant. Finally,
> > the XPL compiler can eliminate any apparent overheads by simply
> > recombining all the discriminant expressions into a single function
> > that implements all the methods. I'd like to hear your opinions
> > about this.
>
> I guess we are talking about the `double dispatch' problem here.
In the last week or so, I have refined this idea to minimize the "double
dispatch" problem. In my new plan, the discriminant is actually executed
when the object is created and used to select which method will be
chosen for the implementation of the corresponding message. This allows
objects to react to their environments at instantiation time by
selecting the set of method implementations they will use. We could even
provide an operator that re-evaluates the discriminants at any point in
the life cycle of the object to provide a form of object transformation.
For example, consider an object that had different behaviors depending
on whether some other component was "online" or "offline". Rather than
check that components status in every method, the object could use a
discriminant and set up its method dispatch pointers one way if the
component is online and another way if it is offline. This could
actually make the system performance improve for the same reason that
virtual method calls are faster than the equivalent if statements to
distinguish between types of objects.
>
> > 6. Overlays -- Anyone Need 'em? Overlays in XPL are like unions in
> > C/C++. They provide a way for using the same memory for multiple
> > fields. However, because XPL is a type safe language, Overlays
> > can't be used for type coercion or bit fiddling. Any attempt to
> > extract a field other than the last one set will yield an
> > error. So, what's the difference between that and just using
> > individual variables or a struct? Is memory consumption these
> > days really that big a concern?
>
> For client application I don't think memory consumption is an issue,
> however, for servers I think it is still an issue. I would be
> inclined to leave them in for the time being and see how. Having said
> that I'm sure they wouldn't be missed and consider adding them later
> as an enhancement.
Okay, they've worked their way into the XVMAPI so I'm going to support
them initially. The XVM is intended to work in both client and server
settings so we'll leave them in for those cases where memory overlay is
needed. They aren't particularly difficult to support and won't be hard
to drop if we decide they aren't useful.
> From your comments about type safety I assume you are think along the
> lines of a discrimated union, like that found in CORBA, for the actual
> implementation. If so I would agree with you.
Exactly.
>
> > 7. Documents & Transforms Needed? Since XPL is based on XML and the
> > XPS will use XSLT heavily, I thought that it would be useful to
> > incorporate the notion of an XML document and an XSLT
> > transformation directly into the language. However, I haven't
> > been able to think up many operators that could be invoked on
> > these kinds of objects. Perhaps I just haven't thought about
> > enough (a lot has gotten deferred), but it occurs to me that
> > perhaps these things are just not as fundamental to an XML
> > programming language as I had originally thought. The basic idea
> > is that you could invoke an XSLT transform on one document and
> > get a different document instance after transformation. Documents
> > could be parsed by sending messages to a parser class much the
> > same way as DOM/SAX do. In fact, it could just be the DOM or SAX
> > APIs. How important is it to put this in the core language as
> > opposed to supporting it in a standard library? Is it something
> > that every XPL program might need?
>
> I would be for putting it into a library. I don't think this is
> something that would be used by most programs. Having it as part of
> the language would add to the complexity.
I think I agree with you on transforms. However, I have some more
thinking to do on documents and objects. There's something compelling
about being able to easily wrap a class around an XML schema definition
but I haven't through it through enough. Its like giving dynamic
behavior to an XML document type. Microsoft would probably call it
"ActiveXML". The converse is also true, there's something utilitarian
about treating a graph of XPL objects as if they were an XML document.
Automatic serialization? (not that we need it).
>
> > 8. Multiple Natural Language Support. One of my original goals in
> > designing XPL was to allow the language to support multiple
> > natural languages. That is why the specification is broken into
> > two parts, XPL-Abstract.xsd and XPL-en.xsd. The abstract
> > definition defines all abstract elements using verbose and
> > precise names in English. The English language version (XPL-en)
> > defines concrete elements using shorter english names. The intent
> > is to also create XPL-fr.xsd (Francaise), XPL-de.xsd (Deutch),
> > XPL-sp (Espanol), and other natural language versions of the
> > abstract language definition. All these natural language versions
> > would be compilable as XPL because the compiler will only look at
> > the abstract substitution group names for the elements, not the
> > actual names of the elements for a given natural language. I
> > think this is very useful and would make XPL much more friendly
> > and amenable to programmers in other languages. Your opinions on
> > this?
>
> Being a native English speaker and not being able to speak any other
> language than English I don't think my opinions could carry, much
> weight. But that's never stopped me before :-)
>
> I've worked with quite a few non native English developers and they
> have always said that the fact that (programming) languages are in
> English has not interfered with their development. A few however have
> mentioned that some novices have used C macros to use equivalents for
> `while', `for' etc... However this tends to be dropped quite
> quickly.
>
> I guess that means it would be useful for when learning the language,
> but not essential for people being able to use it.
>
> It would also have the down side of making a lot of code unreadable to
> people who don't speak the language. At least when it is in English
> a Spanish speaker would only have to be familiar with English, and not
> French, German ...
>
> Of course we could have a natural language transform.
Interesting perspective. I'll have to give some more thought to this.
One of my original goals for XPL was to make it completely
internationalized. I imagine that your supposition holds for the
European based languages. But, I'd love to hear the perspective of some
Asians on this. English is sufficiently different from Kanjii or
Mandarin that I suspect being able to program in their native symbols
would be a big win for people using non-European languages. I think
this is one of those things that should go on the questionnaire so we
can collect some feedback on it.
>
> > I hope to hear back from you on these topics and any others you care
> > to bring up.
>
> I'll throw a few topics for consideration for the future (I'll
> continue Reids enumeration).
>
> Sorry Reid, these are more orientated to what we can do to get
> something practical rather than thoughts about the language.
>
>
> 9. One of the major issues in adopting something is how easily can it
> be incorporated into existing software. I have worked on projects
> where some of the legacy code was written before I was born,
> something years of effort and trust has been invested.
>
> To encourage adoption and maybe to reduce the effort it producing
> something to demonstrate it would be useful for a mechanism to
> interface with existing libraries, or creating libraries. Note when
> I say libraries I mean binaries, not xpl libraries.
I agree that this is a necessary step. I already have plans to be able
to make calls out to any C or C++ based library. We could probably quite
easily do the same for any other language supported by GCC (Java,
Objective-C, Fortran). One of the ideas I had for extensibility is to be
able to map the definitions in an XPL package onto some implementation
in another language. However, there's lots of "glue" issues that have to
be worked out there. I don't want to end up with something like JNI.
>
> 10. I would be useful if we could come up with a couple of trivial
> example HLLS and identify ones that are certainly going to be
> useful, e.g. MathML.
Absolutely. This is a much needed "to do".
>
>
> 11. Debugging. Has anyone any thoughts on debugging xpl programs.
> Someone who has written some code in a HLL is not going to want
> (or even can't) debug at a C++ level and map that up mentally
> through xpl to the language they wrote it in.
>
Yup, that's pretty much been thought through on this end. You won't get
stuck using GDB with C++ tokens. There's a trade off here. While much
of what we translate XPL into will be native code, that native code will
be manipulating a virtual machine. The machine will keep track of call
stacks, variables, etc. There will be a debugger interface that allows
you to interrupt the virtual machine, single step it, set break points,
examine the stack and variables on it, dump the contents of memory
segments, etc. The entire debugging interface will be (no suprises here)
XML based. That is, there will be an XML schema defined for interacting
with the debugger interface. You simply connect to the XVM, send some
commands, get some feedback. As with XPL, to be truly useful, it will
need some kind of an IDE on the other end that can deal with the XML
input/output but this is the most flexible way to approach it.
>
> I'll have to save the rest for another time.
>
Wow, there's more? I like this!
Thanks for your ideas!
> Vic
>
Reid.
|
|
From: Victor K. <vi...@mo...> - 2002-08-19 23:04:28
|
> I would like to solicit your feedback on a variety of topics about
> the language definition so far. When you get to the point that you
> grok what I've done, please see if you can provide your feedback on
> the following topics.
Sorry to take so long in replying to this, things are as hectic as
ever :-(
> 1. Incorporating Memory Management (Regions and Segments) Into The
> Language. I wanted to do this to be explicit in the language
> about how memory is organized and allocated so that it isn't
> shuffled off to some "library routine" that varies from machine
> to machine and uses different strategies. By incorporating memory
> management in the language, the programmer has greater control of
> how the program utilizes memory.
I'm afraid I haven't anything worthwile to contribibute to this,
perhaps after some prototyping has been done I will be in a better
position. However my first thoughts would be to try and make this as
automatic as possible as one of the aims is to reduce the overhead and
complexity in developing software (which unfortunately transfers the
complexity to us).
> 2. Defining Files, Streams, Documents, Transforms, Segments, and
> Regions as Object Classes. Regardless of whether you think it is
> useful for these things to be in the language (as opposed to some
> "standard library"), what do you think about including these
> things in the class inheritance hierarchy. I think its a nifty
> idea because it allows you to build a type hierarchy around
> things that interact with "external entities" (i.e. files,
> streams, documents, memory, etc. are all external to the XVM).
> 3. Using Lisp Style Expressions. The operator expressions in XPL are
> similar to LISP. That is, an expression is built from the inside
> out. Instead of saying a+b, we say +(a,b). Instead of writing
> (a*(b/c)) we write *(a,/(b,c)). This structure falls naturally in
> line with XML content models and makes it very easy to correctly
> parse the programming expressions with an XML parser. I believe
> that it will also be very efficient way to program and generate
> code. However, it is not necessarily intuitive for the
> novice. The last example above in XPL look like:
> <mult_ii>
> <get_i>
> <value_loc>a</value_loc>
> </get_i>
> <div_ii>
> <get_i>
> <value_loc>b</value_loc>
> </get_i>
> <get_i>
> <value_loc>c</value_loc>
> </get_i>
> </div_ii>
> </mult_ii>
I certainly believe that this is the way to go. XML and lisp have a
number of similar themes which should be exploited. I've never seen
any discussion of the rationale behind DSSSL (on which xsl is of
course based) but I'm sure this one of the major factors DSSSL was
implemented on scheme.
> Its rather verbose, but functionally elegant. I haven't worried
> about how "pretty" XPL is because I don't think anyone is going to
> program directly in the XML text.
C or C++ don't look pretty without experience of the language. Even
with experience, people still have issues with how `pretty' code
should look. I can understand where these arguments come from when
you work with a text editor, but when, as Reid mentioned, the code is
automatically generated I think this is no longer an issue.
The important aspect is how well the code can be transformed (of
course I don't want to start imposing restrictions just to make
processing easier).
> A visual editor (emacs mode?) that simplified editing XPL would be
> an excellent tool to build for XPL. Any volunteers out there?
While XPL is not intended to be programmed in directly I think this
could still play a useful role. Developers of higher level
languages (HLL) (and XPL it's self) are going to what to try out
things directly in xpl and, while xml is human readable, it can be
quite hard to edit the file directly as text when the document becomes
complicated.
Two emacs modes I really find useful are xslide and docbook, perhaps
these could be plundered for a basis. I would volunteer my self but I
just don't have the time. I would expect to be able to help extend
and test as the project progresses though.
> Does the inelegance of the syntax bother you?
As I sort of mentioned above the `inelegance' does not bother me, in
fact I'd bet that after some experience it would become elegant, eye
of the beholder and all that.
> What if the entire structure of the program was represented in 3D
> and manipulated in a VR kind of way? Would it bother you then?
> Because its XML, we can do all kinds of transformations from other
> languages, syntaxes and editing systems and still end up with XPL as
> the basic language that gets compiled. It is this latter aspect of
> the language that is important (rigid semantic specifications, fast
> compilation, accurate results).
The possibilities such as those you mentioned above are some of the
main sources of my enthusiasm for this project. The fact that the
actual source code is in a format that is easy to process opens up the
potential for tools for visualization and understanding of the
code.
> 4. Everything In A Method/Function Is An Operator. I wanted to
> provide a simplicity of design such that program could be
> constructed by arbitrarily nesting various operators. The fact
> that the control flow operators (if, repeat, for, foreach,
> select, switch...) can return values means they can be used
> directly in a computational expression. C++ provides a very
> limited form of this with the ?: operator. I've generalized it so
> that all control flow operators may be used in computation
> expressions. For example, XPL permits the following C++
> equivalent:
> int array[maxlen];
> /* ... */
> int i = for (int j = 0; j < maxlen; j++) { if (array[j] == 15)
> { result j; break; }
> Note that I take the liberty that this C++ code can (a) assign the
> result of a for loop to an integer variable and (b) has an operator
> "results" which specifies the result for the enclosing block. I
> won't write the equivalent XPL because there is an example similar
> to this in the release. But, what I would like to know is what you
> think of this ability? Power or confusion?
The fact that everything is an operator appeals to me. While I don't
think such a structure has a place in c++ (we have iterators an
functors to so this), I think it makes sense in xpl.
I also believe that this would ease the transformation into native
code, which is good ;-)
> 5. Method Discriminants. Unlike some other popular object-oriented
> languages, I differentiate between the messages sent to an object
> and the methods that implement those messages. To me, these are not
> the same things. While the message send can be optimized to a simple
> function call in many cases, XPL also directly supports active
> objects (running in their own thread) in which case message sending
> is an asynchronous operation. Furthermore, I allow a class to
> implement a method multiple times. To disambiguate which methods get
> run on which message sends, I have introduced the notion of a method
> discriminant. Discriminants are simply boolean expressions that are
> computed at runtime to determine which methods get run. While the
> same ends can be achieved with if/unless/switch operators in the
> body of a single method, the use of discriminants provides the
> programmer with some syntactic sugar to help keep the program
> organized. First, method names are not necessarily the same as the
> message names. Since multiple methods can be defined for a single
> message on a class, this must be true. Consequently, the method can
> be named after what it does, not what the message means.
> Extensibility is enhanced because adding a new behavior for a
> message is as simple as adding a new method, leaving the existing
> methods alone and simply defining a boolean expression that
> determines the conditions under which the method executes. This
> style of programming greatly aids state machine development since
> the state of the machine can be used as the discriminant. Finally,
> the XPL compiler can eliminate any apparent overheads by simply
> recombining all the discriminant expressions into a single function
> that implements all the methods. I'd like to hear your opinions
> about this.
I guess we are talking about the `double dispatch' problem here.
> 6. Overlays -- Anyone Need 'em? Overlays in XPL are like unions in
> C/C++. They provide a way for using the same memory for multiple
> fields. However, because XPL is a type safe language, Overlays
> can't be used for type coercion or bit fiddling. Any attempt to
> extract a field other than the last one set will yield an
> error. So, what's the difference between that and just using
> individual variables or a struct? Is memory consumption these
> days really that big a concern?
For client application I don't think memory consumption is an issue,
however, for servers I think it is still an issue. I would be
inclined to leave them in for the time being and see how. Having said
that I'm sure they wouldn't be missed and consider adding them later
as an enhancement.
From your comments about type safety I assume you are think along the
lines of a discrimated union, like that found in CORBA, for the actual
implementation. If so I would agree with you.
> 7. Documents & Transforms Needed? Since XPL is based on XML and the
> XPS will use XSLT heavily, I thought that it would be useful to
> incorporate the notion of an XML document and an XSLT
> transformation directly into the language. However, I haven't
> been able to think up many operators that could be invoked on
> these kinds of objects. Perhaps I just haven't thought about
> enough (a lot has gotten deferred), but it occurs to me that
> perhaps these things are just not as fundamental to an XML
> programming language as I had originally thought. The basic idea
> is that you could invoke an XSLT transform on one document and
> get a different document instance after transformation. Documents
> could be parsed by sending messages to a parser class much the
> same way as DOM/SAX do. In fact, it could just be the DOM or SAX
> APIs. How important is it to put this in the core language as
> opposed to supporting it in a standard library? Is it something
> that every XPL program might need?
I would be for putting it into a library. I don't think this is
something that would be used by most programs. Having it as part of
the language would add to the complexity.
> 8. Multiple Natural Language Support. One of my original goals in
> designing XPL was to allow the language to support multiple
> natural languages. That is why the specification is broken into
> two parts, XPL-Abstract.xsd and XPL-en.xsd. The abstract
> definition defines all abstract elements using verbose and
> precise names in English. The English language version (XPL-en)
> defines concrete elements using shorter english names. The intent
> is to also create XPL-fr.xsd (Francaise), XPL-de.xsd (Deutch),
> XPL-sp (Espanol), and other natural language versions of the
> abstract language definition. All these natural language versions
> would be compilable as XPL because the compiler will only look at
> the abstract substitution group names for the elements, not the
> actual names of the elements for a given natural language. I
> think this is very useful and would make XPL much more friendly
> and amenable to programmers in other languages. Your opinions on
> this?
Being a native English speaker and not being able to speak any other
language than English I don't think my opinions could carry, much
weight. But that's never stopped me before :-)
I've worked with quite a few non native English developers and they
have always said that the fact that (programming) languages are in
English has not interfered with their development. A few however have
mentioned that some novices have used C macros to use equivalents for
`while', `for' etc... However this tends to be dropped quite
quickly.
I guess that means it would be useful for when learning the language,
but not essential for people being able to use it.
It would also have the down side of making a lot of code unreadable to
people who don't speak the language. At least when it is in English
a Spanish speaker would only have to be familiar with English, and not
French, German ...
Of course we could have a natural language transform.
> I hope to hear back from you on these topics and any others you care
> to bring up.
I'll throw a few topics for consideration for the future (I'll
continue Reids enumeration).
Sorry Reid, these are more orientated to what we can do to get
something practical rather than thoughts about the language.
9. One of the major issues in adopting something is how easily can it
be incorporated into existing software. I have worked on projects
where some of the legacy code was written before I was born,
something years of effort and trust has been invested.
To encourage adoption and maybe to reduce the effort it producing
something to demonstrate it would be useful for a mechanism to
interface with existing libraries, or creating libraries. Note when
I say libraries I mean binaries, not xpl libraries.
10. I would be useful if we could come up with a couple of trivial
example HLLS and identify ones that are certainly going to be
useful, e.g. MathML.
11. Debugging. Has anyone any thoughts on debugging xpl programs.
Someone who has written some code in a HLL is not going to want
(or even can't) debug at a C++ level and map that up mentally
through xpl to the language they wrote it in.
I'll have to save the rest for another time.
Vic
|
2 messages has been excluded from this view by a project administrator.
