I'm making a new programming language based upon C++ and Java. A preliminary specification of some aspects of the language is available at http://xana.sourceforge.net/. Comments or suggestions are welcome, either here, or on the forum at sourceforge - http://sourceforge.net/forum/forum.php?forum_id=121437. All your bases belong to us Edited by - Mayrel on November 2, 2001 2:18:53 PM

quote:Original post by Big B
Interesting.

Correct me if I''m wrong but you seem to have Java with C++ style scoping.

Well, that''s all that''s in the spec right now, yes. I''ve got a pile of other stuff dotted around that I''m in the process of integrating into the spec (regexps, contracts, fields that know when you assign to them, inline XML fragments, events (like methods, except they''re multicasting), states (which is hard to explain in one sentence), and a few other trivial bits like default and reference parameters and parameter arrays).

quote:
The unnamed structs and classes remind me a bit of scheme or lisp''s lambda expressions.

There''s an actual lambda expression. The backquote operator is under review (I''m not sure if it''s intuitive enough).

quote:
The unions worried me at first, but if you can resolve everything at compile time, then that might actually make unions useful.

Well, using multiple inheritance, a union, U, of an int and and a string is equivalent to an interface, U, that subclasses an int and a string. Since MI is allowed, it seemed silly not to allow unions, as long as they were made safe.

quote:
The question I have to ask is: What purpose does your language fulfill? Typically when designing a language, it is because there is a need to be fulfilled. SQL was created to make database queries easier, Lisp for list processing and AI. I am curious as to what Xana is trying to make easier.

I have a need for a language with the portability and automatic memory management of Java, the flexibility of C++, and the ease of implementing event-based solutions of Visual Basic. Microsoft also had that need and made C#, which is nearly good enough: however, it is steeped in the Microsoft Way, and is proprietry (I can''t ever spell that word). My answer is Xana, which is intended to be neither.

Either Monday or later today, I''ll have an extended and formatted version of the spec ready. It actually has the meanings of the operators, although it doesn''t describe the statements or most of the declaration syntax.

All your bases belong to us

Tada. Updated spec and a couple of other bits uploaded. I've put everything at http://sourceforge.net/docman/index.php?group_id=39161, it's easier than wrestling with scp.

Hmm. I notice that Microsoft's XSLT processor has messed up my whitespace. How nice of them.

All your bases belong to us

Edited by - Mayrel on November 3, 2001 10:20:35 AM

quote:Original post by Dactylos
In section 2.2.1 (How Scope is Defined) you say:
"Implicit blocks exist around all declarations and all compound statements. "

I think you should rewrite that statement because it''s not really clear what you mean by saying that implicit blocks surround all declarations. To me it sounds like you can''t use declared names because they will go out of scope as soon as they are declared.

Erk! Yes, it does sound like that.

quote:
Also, please don''t include the "Perl-style ''weird'' statements" as you call them. They are very un-intuitive. Programmers tend to think that what appears first (left-most) on a line is the most important ''action'' on that line.

Hmm, I agree with you. Perl programmers don''t, however. But perhaps if any of them complain, I can tell them to use perl. Well then, ''weird'' statements are officially Under Question.

All your bases belong to us

Version 0.3 of the spec is available at the usual place. It''s available in Word or PostScript format, no HTML because Word blats the document if I do that, and I can''t be bothered to retype it by hand again.

I''ve also improved the site, in as much as it''s now a site rather than a couple of links. Comments?

As always, comments on the spec will also be welcome.

All your bases belong to us

quote:Original post by Big B
Seems good to me I started reading last night, and didn''t get to the in-out paramter passing, which is what I wondered about all day, but was pleasantly surprised to see it dealt with. Reminds me of the Pascal style of parameter passing.

Now, now. Don''t swear.

quote:
I would like a little more info about inline xml fragments. Can you build a W3C DOM or does it generate SAX events? Any consideration to SGML?

Version 0.1.0 of the spec is up and running. I''ve expanded upon the explanations of a lot of stuff, and made a few additions, including a section on inline XML (and a new versioning scheme).

Xana will use the DOM for accessing the inline XML. Since inline XML is parsed at compile-time, SAX support wouldn''t make sense; however, it''s likely that someone (not me, I don''t know SAX) can make a SAX module for it.

Inline SGML won''t be an option. As with SAX, there''s nothing to stop an SGML parser being made, it just won''t be inline.

quote:
Is there going to be a standard set of containers like Java or stl? What about a string class. Ever since I started using std::string, I have kinda frowned upon char*.

For most purposes, you''ll just use arrays or mappings. I don''t recall if mappings were in the last version I posted, so to summarise they''re arrays that are indexed by arbitrary types: int[string] x declares a map of ints indexed by strings.

There''s a standard string class, called, imaginatively, string .

quote:
Will Xana support operator overloading? Not having OO is one of my biggest gripes about Java.

Me to, and yes it will. It''ll simply be a copy of the C++ operator overloading system, which seems to work fine for me.

quote:
Out of curiosity, how many people are working on this and have you ever done something like this before? Sounds like you might be biting off more than you can chew. But if you can pull it off, I know you will have at least one user.

Right now, just me. If I can drum up some support, that''ll be great. But I don''t want to bring other people into the project until there''s enough for them to go on.

I''ve never done a real compiler before, although I''ve made more than my fair share of scanners and parsers. The hard bit will be compilation. Fortunately, I''ve got a few good books on the subject and compilers aren''t actually that tough to write: the tough bits are making a standard library, testing it to exaustion, and coping with oddities in the execution environment.

With a bytecode system, which is what I''ll be starting with, I can just have some jumps and instruction for each operator. With native code, I''ve actually got to know how to code in assembler, and although I learnt some assembler in my first year at college, it didn''t learn that much.

I also won''t be making the whole thing in one go. For example, I''ll probably start of with simple arrays, and add tables and mappings later. The same with properties and contracts. These are non-essential things that many programs might not use, so it''s okay if we don''t have them right away.

Having said that, I probably am biting off too much, but if you don''t aim high, you won''t even hit the middle.

All your bases belong to us