Re: [XPS-devel] XPL 0.1.1 Released
Status: Alpha
Brought to you by:
raspencer
Menu
▾
▴
Re: [XPS-devel] XPL 0.1.1 Released
|
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
|
