http://xana.sourceforge.net/

"Xana is a simple, modern, object-oriented, and type-safe programming language derived from C and C++. Like C and C++, Xana is strongly typed. Unlike C and C++, Xana's type-system is strongly orthogonal."

In article <bfdcqk$1gbf$1@digitaldaemon.com>, Mark Evans wrote:
> 
> http://xana.sourceforge.net/
> 
> "Xana is a simple, modern, object-oriented, and type-safe programming language derived from C and C++. Like C and C++, Xana is strongly typed. Unlike C and C++, Xana's type-system is strongly orthogonal."

Where did you hear about this language, by the way?

Quite interesting language, this Xana.  Seems very much like Java but lots more.  It also seems pretty rich in semantics and has plenty of ideas that I haven't seen yet anywhere else.  On the usual properties it seems surprisingly same as D.  But it has tons more.  For those language-enthusiasts that didn't have the time or strength to read the specification, here's a little summary of the most interesting features:

- In addition to C/C++, Xana has plenty of extra operators ("><" for
  swap, "in", "..", "^^", unary / (!), etc.).

- It supports for hashtables (under the name mapping). Other interesting
  types include safe union, fixed and regexp.

- It seems, however, not to have pointers.

- Automatic language support for stateful objects, an example from the
  specification:

class Framebuffer {
  state Active { void refresh () { ...  } }
  state Inactive { void refresh () = 0; }
};

states are changed with Object.enterState(state). This is claimed to be more efficient than writing the manual state pattern because of compiler support.

- Xana's explanation for the keyword "static" is to define it as a
  qualifier that extends its argument's scope to the next enclosing
  scope.  (Difficult to put into words; read the example at the
  specification, page 32)  This is either a really brilliant and elegant
  idea or just intellectual swish-swash, but I don't still know which.

- Converting between value-semantic structs and reference-semantic
  classes which is called "metacasting" - which looks like automatic
  boxing/unboxing but what do I know...

- Interesting properties, supporting the notion of query operator
  (operator ?()); example:

class Rational {
  ...
  int denumerator {
    int value;
    void operator = (int v) {
      value = v;
      if (!v) new ZeroDenumeratorException().throw();
    }
    int operator ? () {
      return value;
    }
  };
}

- A completely different approach to contracts (see 6.1.6)

- Treating of methods as objects (that can be instantiated with the lambda
expression)

- Some inline XML gook that I didn't quite understand :)

It seems that the designer has taken the true waterfall approach: to design first and implement afterwards. He has a long road to go, since the compiler currently consists of only the parser... good luck. The project seems not to be particularly popular; google for "xana language", and understand why. googlism.com, however, finds it: Xana is also a software design approach and a web browser, and in addition to that, a "fairly open person and will talk honestly about anything else."

-Antti

> >
> > http://xana.sourceforge.net/
> >
> > "Xana is a simple, modern, object-oriented, and type-safe programming
language
> > derived from C and C++. Like C and C++, Xana is strongly typed. Unlike C
and
> > C++, Xana's type-system is strongly orthogonal."

For information, what is an orthogonal type-system ?

>
> Where did you hear about this language, by the way?
>
> Quite interesting language, this Xana.  Seems very much like Java but lots more.  It also seems pretty rich in semantics and has plenty of ideas that I haven't seen yet anywhere else.  On the usual properties it seems surprisingly same as D.  But it has tons more.  For those language-enthusiasts that didn't have the time or strength to read the specification, here's a little summary of the most interesting features:
>
> - In addition to C/C++, Xana has plenty of extra operators ("><" for
>   swap, "in", "..", "^^", unary / (!), etc.).

Many of those extra operators are interesting and could probably added to D.

>
> - It supports for hashtables (under the name mapping). Other interesting
>   types include safe union, fixed and regexp.
>
> - It seems, however, not to have pointers.
>

IMO, pointer should not be required to program in a language by itself
but should provide for:
- low-level code
- interfacing with other languages (mostly C and C++)

And for interfacing with other languages and environment, I think that
being able to interface with COM and .NET easily in typical cases but
with enough power when desired (like .NET interaction with COM)
is something desirable.

> - Automatic language support for stateful objects, an example from the
>   specification:
>
> class Framebuffer {
>   state Active { void refresh () { ...  } }
>   state Inactive { void refresh () = 0; }
> };
>
> states are changed with Object.enterState(state). This is claimed to be more efficient than writing the manual state pattern because of compiler support.
>

This is also a welcome addition... It surely could help in many situations.
For
example a GUI toolkit would have at least one state when the real object
(window, control dialog) is created and functional and one state when only
the language (here D) object is created.

> - Xana's explanation for the keyword "static" is to define it as a
>   qualifier that extends its argument's scope to the next enclosing
>   scope.  (Difficult to put into words; read the example at the
>   specification, page 32)  This is either a really brilliant and elegant
>   idea or just intellectual swish-swash, but I don't still know which.
>

For this one, I think that by default, it would be advisable to have
the same scope as in C/C++ but we may support other scope if
it can be usefull (other than for intelectual demonstrrations).

Also what it mean for a member function? Does static have the same
effect as aan added member or as other static. For me, I think that
it would complex to implement for the benefit... but I think it could
be interesting as in some case, we have to pollute member a class
for a member that is used only for 1 member function. Also, this
is interesting for a function because sometimes we have to declare
a variable that will be used only in one scope (for example, a loop)
but need to keep it value between each iteration. For ex. to implement
a loop that will break after 5 matches, it would be possible to write
(syntax might note be valid in Xena

for (...)
{
    static int match = 0;
    if (++match == 5)
        break;
}

and match would apply only to the current function (thread)
and not be global.

In C++, in a case like this one, we have to move the declaration outside of the loop.

So I like the idea.... but we should maybe always label it and probably support "class", "function", "global", "thread", "fiber" .... as predefined scope...

> - Converting between value-semantic structs and reference-semantic
>   classes which is called "metacasting" - which looks like automatic
>   boxing/unboxing but what do I know...

IMO, Xana is too powerfull for the syntax because their should be
more keyword to ensure that the programmer really as coded what
it intent... In particular, I think that all cast should need a keyword to
specify the type of casting we want to do.

>
> - Interesting properties, supporting the notion of query operator
>   (operator ?()); example:
>
> class Rational {
>   ...
>   int denumerator {
>     int value;
>     void operator = (int v) {
>       value = v;
>       if (!v) new ZeroDenumeratorException().throw();
>     }
>     int operator ? () {
>       return value;
>     }
>   };
> }

This is nice... and the syntax is well though in my opinion at least for simple properties.

>
> - A completely different approach to contracts (see 6.1.6)
>

I haven't check them (either Xena or D) in detail... but I do think that contracts is a must and that the ability to do some check at compile time is also a must.

I have notice how class invariant are done but it should probably be a special "invariant" method.

> - Treating of methods as objects (that can be instantiated with the lambda
> expression)

This is also a good thing to be able to write functions directly where we
need
them...

>
> - Some inline XML gook that I didn't quite understand :)
>

I think that XML support is a must and hope that we will have editors
that would uses for documentation so that we won't generally need to
see XML code. Also, I think that embedded XML should be done
in a way that would allows a compiler to add information to a file
(bookmarks, breakpoints, profiler information, compiler settings,...)
and that some of them should be standardized among compiler (for ex.
to turn off a warning or changes an optimisation like inlining).

> It seems that the designer has taken the true waterfall approach: to
design
> first and implement afterwards. He has a long road to go, since the
compiler
> currently consists of only the parser... good luck. The project seems not
to be
> particularly popular; google for "xana language", and understand why. googlism.com, however, finds it: Xana is also a software design approach
and a
> web browser, and in addition to that, a "fairly open person and will talk honestly about anything else."
>

One big advantage that I see in Xena is that the language is defined so that
lex and yacc can parse it... So it should be easier to write good tool for
the
language (it would be harder in D and almost impossible in C++).

Design the language first should help to start with a consistent design. Also the fact that the language is parsable help ensure that there are not to much ambiguities...


> -Antti

"Philippe Mori" <philippe_mori@hotmail.com> wrote in message news:bhm4h6$5vq$1@digitaldaemon.com...

> For information, what is an orthogonal type-system ?

No two different types do the same (eg int and long mean the same
 in most C++ implementations; so it is not orthogonal). It looks to me
 like a stupid idea not to define exact ranges for types...
 Be exact I mean really exact, not only minimum, or something like
 this type must have the same or bigger range. From this point of
 view even Xana docs are ambiguous (eg on one place it is stated
 16 bit signed integer, on the other at least 32767, instead of exactly
 32767).

> > - A completely different approach to contracts (see 6.1.6)
> >
>
> I haven't check them (either Xena or D) in detail... but I do think that contracts is a must and that the ability to do some check at compile time is also a must.
>

Some AOP (aspect oriented programming, or adaptive programming,
 or hyperspaces or whatever they call their methods like :o) ) guys think,
 that special language constructs for contracts are redundant, because
 contract checking is only one of many possible aspects of your class...
It is interesting that Xana wants to check contracts in compile time when
 possible. Cool. May be with the state support it can do what Valut
 (http://research.microsoft.com/vault/) does with tracked keyword.

"Peter Hercek" <vvp@no.post.spam.sk> wrote in message news:bhn7e2$1nq5$1@digitaldaemon.com...
>
> "Philippe Mori" <philippe_mori@hotmail.com> wrote in message
news:bhm4h6$5vq$1@digitaldaemon.com...
>
> > For information, what is an orthogonal type-system ?
>
> No two different types do the same (eg int and long mean the same
>  in most C++ implementations; so it is not orthogonal). It looks to me
>  like a stupid idea not to define exact ranges for types...
>  Be exact I mean really exact, not only minimum, or something like
>  this type must have the same or bigger range. From this point of
>  view even Xana docs are ambiguous (eg on one place it is stated
>  16 bit signed integer, on the other at least 32767, instead of exactly
>  32767).

It seems to me that a given compiler/platform should provide exactly the
types available on the machine, i.e. s32 (signed 32-bit integer), u32
(unsigned), s16, u16, p4f32 (4 packed 32-bit floats), p8us8 (8 packed 8-bit
unsigned saturated bytes), whatever the machine has available.

Then another "portability" layer gives some "standard compatibility/performance" aliases.  int, float, double, ubyte, that sort of thing.  These would be different types on different platforms.  You can use them to achieve some measure of safe portability, but must not rely on exact sizes, though the language should give some hard minimums.

Then, the language should allow one to specify ranges;  custom types, which use the native register type which is closest to fitting them best.  So if you need a signed 6-bit integer, just declare one and use it;  the compiler finds a real register that is at least 6 bits and supports signed semantics, and deals with making it act like a 6-bit number.  (probably mask off/sign-extend the high bits after each operation?  Seems some of these could be optimized away.)

So if you want the ultimate performance, and want to be explicit about what type to use, go for s32.  If you want portability/compatibility, use int. If you want to be really picky about the range and yet remain portable, and speed is a secondary concern, use ranges.

Really I wouldn't mind if somewhere there were a "x86types.d" file containing this:

alias range(-2147483648..2147483647) s32;
alias range(-32768..32767) s16;
alias range(-128..127) s8;

alias range(0..4294967295) u32;
alias range(0..65535) u16;
alias range(0..255) u8;

alias s32 int;
alias u32 uint;
alias s16 short;
alias u16 ushort;
alias s8 byte;
alias u8 ubyte;

Not sure how you'd specify float types though.  It would also be nice to be able to specify the behavior when the value goes outside the range, such as modular or saturating, or "don't care".

One reason not to have ranges is that it would increase the complexity of the compiler implementations somewhat.  They'd have to be able to provide "emulation" code for types that aren't natively supported by the cpu.

Sean

> > > - A completely different approach to contracts (see 6.1.6)
> > >
> >
> > I haven't check them (either Xena or D) in detail... but I do think that contracts is a must and that the ability to do some check at compile time is also a must.
> >
>
> Some AOP (aspect oriented programming, or adaptive programming,
>  or hyperspaces or whatever they call their methods like :o) ) guys think,
>  that special language constructs for contracts are redundant, because
>  contract checking is only one of many possible aspects of your class...
> It is interesting that Xana wants to check contracts in compile time when
>  possible. Cool. May be with the state support it can do what Valut
>  (http://research.microsoft.com/vault/) does with tracked keyword.
>
>

Yes, this is portability contra efficiency, ... or let the programer to select
 whatever is better for his project.
For programs I typically write portability is more important.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bhnf58$234t$1@digitaldaemon.com...
> "Peter Hercek" <vvp@no.post.spam.sk> wrote in message news:bhn7e2$1nq5$1@digitaldaemon.com...
> >
> > "Philippe Mori" <philippe_mori@hotmail.com> wrote in message
> news:bhm4h6$5vq$1@digitaldaemon.com...
> >
> > > For information, what is an orthogonal type-system ?
> >
> > No two different types do the same (eg int and long mean the same
> >  in most C++ implementations; so it is not orthogonal). It looks to me
> >  like a stupid idea not to define exact ranges for types...
> >  Be exact I mean really exact, not only minimum, or something like
> >  this type must have the same or bigger range. From this point of
> >  view even Xana docs are ambiguous (eg on one place it is stated
> >  16 bit signed integer, on the other at least 32767, instead of exactly
> >  32767).
>
> It seems to me that a given compiler/platform should provide exactly the
> types available on the machine, i.e. s32 (signed 32-bit integer), u32
> (unsigned), s16, u16, p4f32 (4 packed 32-bit floats), p8us8 (8 packed 8-bit
> unsigned saturated bytes), whatever the machine has available.
>
> Then another "portability" layer gives some "standard compatibility/performance" aliases.  int, float, double, ubyte, that sort of thing.  These would be different types on different platforms.  You can use them to achieve some measure of safe portability, but must not rely on exact sizes, though the language should give some hard minimums.
>
> Then, the language should allow one to specify ranges;  custom types, which use the native register type which is closest to fitting them best.  So if you need a signed 6-bit integer, just declare one and use it;  the compiler finds a real register that is at least 6 bits and supports signed semantics, and deals with making it act like a 6-bit number.  (probably mask off/sign-extend the high bits after each operation?  Seems some of these could be optimized away.)
>
> So if you want the ultimate performance, and want to be explicit about what type to use, go for s32.  If you want portability/compatibility, use int. If you want to be really picky about the range and yet remain portable, and speed is a secondary concern, use ranges.
>
> Really I wouldn't mind if somewhere there were a "x86types.d" file containing this:
>
> alias range(-2147483648..2147483647) s32;
> alias range(-32768..32767) s16;
> alias range(-128..127) s8;
>
> alias range(0..4294967295) u32;
> alias range(0..65535) u16;
> alias range(0..255) u8;
>
> alias s32 int;
> alias u32 uint;
> alias s16 short;
> alias u16 ushort;
> alias s8 byte;
> alias u8 ubyte;
>
> Not sure how you'd specify float types though.  It would also be nice to be able to specify the behavior when the value goes outside the range, such as modular or saturating, or "don't care".
>
> One reason not to have ranges is that it would increase the complexity of the compiler implementations somewhat.  They'd have to be able to provide "emulation" code for types that aren't natively supported by the cpu.
>
> Sean
>
> > > > - A completely different approach to contracts (see 6.1.6)
> > > >
> > >
> > > I haven't check them (either Xena or D) in detail... but I do think that contracts is a must and that the ability to do some check at compile time is also a must.
> > >
> >
> > Some AOP (aspect oriented programming, or adaptive programming,
> >  or hyperspaces or whatever they call their methods like :o) ) guys think,
> >  that special language constructs for contracts are redundant, because
> >  contract checking is only one of many possible aspects of your class...
> > It is interesting that Xana wants to check contracts in compile time when
> >  possible. Cool. May be with the state support it can do what Valut
> >  (http://research.microsoft.com/vault/) does with tracked keyword.

C++ is misunderstood. Int and long are two different data types. It is just a coincidence that they have the same range on 32-bit machines. Int is a wildcard: it has the size of the native CPU's word. So it is 16 bits on 16-bit CPUs, 32-bits on 32 bit CPUs and 64 bits on 64-bit CPUs. On the other hand, 'long' is always 32 bits.

Since C/C++ is a language that can be used to write operating systems, there is a need to treat pointers as integers. That is the reason why 'int' exists; in other words, it is a native data type that pointer values can be stored into.

"Peter Hercek" <vvp@no.post.spam.sk> wrote in message news:bhn7e2$1nq5$1@digitaldaemon.com...
>
> "Philippe Mori" <philippe_mori@hotmail.com> wrote in message
news:bhm4h6$5vq$1@digitaldaemon.com...
>
> > For information, what is an orthogonal type-system ?
>
> No two different types do the same (eg int and long mean the same
>  in most C++ implementations; so it is not orthogonal). It looks to me
>  like a stupid idea not to define exact ranges for types...
>  Be exact I mean really exact, not only minimum, or something like
>  this type must have the same or bigger range. From this point of
>  view even Xana docs are ambiguous (eg on one place it is stated
>  16 bit signed integer, on the other at least 32767, instead of exactly
>  32767).
>
> > > - A completely different approach to contracts (see 6.1.6)
> > >
> >
> > I haven't check them (either Xena or D) in detail... but I do think that contracts is a must and that the ability to do some check at compile time is also a must.
> >
>
> Some AOP (aspect oriented programming, or adaptive programming,
>  or hyperspaces or whatever they call their methods like :o) ) guys think,
>  that special language constructs for contracts are redundant, because
>  contract checking is only one of many possible aspects of your class...
> It is interesting that Xana wants to check contracts in compile time when
>  possible. Cool. May be with the state support it can do what Valut
>  (http://research.microsoft.com/vault/) does with tracked keyword.
>
>

It seems like a good language, but does the world really need yet another C++ clone ? D is enough, I think.

"Antti Sykäri" <jsykari@gamma.hut.fi> wrote in message news:slrnbjqo85.mtu.jsykari@pulu.hut.fi...
> In article <bfdcqk$1gbf$1@digitaldaemon.com>, Mark Evans wrote:
> >
> > http://xana.sourceforge.net/
> >
> > "Xana is a simple, modern, object-oriented, and type-safe programming
language
> > derived from C and C++. Like C and C++, Xana is strongly typed. Unlike C
and
> > C++, Xana's type-system is strongly orthogonal."
>
> Where did you hear about this language, by the way?
>
> Quite interesting language, this Xana.  Seems very much like Java but lots more.  It also seems pretty rich in semantics and has plenty of ideas that I haven't seen yet anywhere else.  On the usual properties it seems surprisingly same as D.  But it has tons more.  For those language-enthusiasts that didn't have the time or strength to read the specification, here's a little summary of the most interesting features:
>
> - In addition to C/C++, Xana has plenty of extra operators ("><" for
>   swap, "in", "..", "^^", unary / (!), etc.).
>
> - It supports for hashtables (under the name mapping). Other interesting
>   types include safe union, fixed and regexp.
>
> - It seems, however, not to have pointers.
>
> - Automatic language support for stateful objects, an example from the
>   specification:
>
> class Framebuffer {
>   state Active { void refresh () { ...  } }
>   state Inactive { void refresh () = 0; }
> };
>
> states are changed with Object.enterState(state). This is claimed to be more efficient than writing the manual state pattern because of compiler support.
>
> - Xana's explanation for the keyword "static" is to define it as a
>   qualifier that extends its argument's scope to the next enclosing
>   scope.  (Difficult to put into words; read the example at the
>   specification, page 32)  This is either a really brilliant and elegant
>   idea or just intellectual swish-swash, but I don't still know which.
>
> - Converting between value-semantic structs and reference-semantic
>   classes which is called "metacasting" - which looks like automatic
>   boxing/unboxing but what do I know...
>
> - Interesting properties, supporting the notion of query operator
>   (operator ?()); example:
>
> class Rational {
>   ...
>   int denumerator {
>     int value;
>     void operator = (int v) {
>       value = v;
>       if (!v) new ZeroDenumeratorException().throw();
>     }
>     int operator ? () {
>       return value;
>     }
>   };
> }
>
> - A completely different approach to contracts (see 6.1.6)
>
> - Treating of methods as objects (that can be instantiated with the lambda
> expression)
>
> - Some inline XML gook that I didn't quite understand :)
>
> It seems that the designer has taken the true waterfall approach: to
design
> first and implement afterwards. He has a long road to go, since the
compiler
> currently consists of only the parser... good luck. The project seems not
to be
> particularly popular; google for "xana language", and understand why. googlism.com, however, finds it: Xana is also a software design approach
and a
> web browser, and in addition to that, a "fairly open person and will talk honestly about anything else."
>
> -Antti

In article <bhqbjl$6eu$1@digitaldaemon.com>, Achilleas Margaritis wrote:
> C++ is misunderstood. Int and long are two different data types. It is just a coincidence that they have the same range on 32-bit machines. Int is a wildcard: it has the size of the native CPU's word. So it is 16 bits on 16-bit CPUs, 32-bits on 32 bit CPUs and 64 bits on 64-bit CPUs. On the other hand, 'long' is always 32 bits.
> 
> Since C/C++ is a language that can be used to write operating systems, there is a need to treat pointers as integers. That is the reason why 'int' exists; in other words, it is a native data type that pointer values can be stored into.

No.  IIRC, at least on the 64-bit Alpha architecture, the sizes are as follows:

sizeof(int*) = 8
sizeof(long) = 8
sizeof(int) = 4
sizeof(short) = 2

I wouldn't wonder if this were the case on other 64-bit architectures as well.

It's a common obstacle to portability that programmers have assumed
sizeof(int) == sizeof(int*).

-Antti

> C++ is misunderstood. Int and long are two different data types. It is just a coincidence that they have the same range on 32-bit machines. Int is a wildcard: it has the size of the native CPU's word. So it is 16 bits on 16-bit CPUs, 32-bits on 32 bit CPUs and 64 bits on 64-bit CPUs. On the other hand, 'long' is always 32 bits.

I used to think that too, however ISO C++ clearly specifies that

'There are four signed integer types: "signed char", "short int", "int", and "long int." In this list, each type provides at least as much storage as those preceding it in the list.' (Section 3.9.1 Paragraph 2, with the same for unsigned types following in Paragraph 3).

In other words, sizeof(char)<=sizeof(short)<=sizeof(int)<=sizeof(long)
on any conforming C++ implementation.

> Since C/C++ is a language that can be used to write operating systems, there is a need to treat pointers as integers. That is the reason why 'int' exists; in other words, it is a native data type that pointer values can be stored into.

Nope, the C++ standard makes the storage and size of pointers an implementation detail. It does state that const/volatile pointers need to have the same value representation and alignemnt requirements, but that's it.

This is of course a rather pathological issue, because after all such handling happens in the system-dependent part of the OS anyway, so portability is a non-issue.

-fg