www.digitalmars.com         C & C++   DMDScript  

D - Xana Language

reply Mark Evans <Mark_member pathlink.com> writes:
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."
Jul 19 2003
parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
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
Aug 15 2003
next sibling parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 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
Aug 16 2003
parent reply "Peter Hercek" <vvp no.post.spam.sk> writes:
"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.
Aug 16 2003
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"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.
Aug 17 2003
parent "Peter Hercek" <vvp no.post.spam.sk> writes:
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.
Aug 17 2003
prev sibling parent reply "Achilleas Margaritis" <axilmar in.gr> writes:
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.
Aug 18 2003
next sibling parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
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
Aug 18 2003
prev sibling next sibling parent "Fabian Giesen" <rygNO SPAMgmx.net> writes:
 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
Aug 18 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Well, you should know that long has to be at least as large as int.  If
you're going to typecast a pointer to an integer, you should definitely use
long if you want to be portable.  There is no guarantee in C/C++ that any
given integer will fit a pointer (ok, long is all but guaranteed to fit a
pointer, but it may be wasteful).

Maybe D should have a type similar to C++'s pseudotype ptrdiff_t that is
always the integer representation of a pointer.  Same size as normal
pointers on the machine, and unsigned and signed versions should exist.

Not sure what you'd call them.

We really would need another type these days.. 128-bit cpu's are starting to
come out, and some of them let you do 128-bit arithmetic.  D has the cent
keyword for this, but what about the next one, 256?  Anyway today, we need
software emulation for cent type, just like 16-bit cpu's needed to software
emulate 32-bit math, and 8-bit cpu's had to emulate 16-bit math.  ;)

In C, those 4 types would just continue to slide over to cover the area
(breaking old code in the process, I might add).  In D at least the sizes
are fixed, even though this might potentially hurt D's portability (what if
a platform doesn't support a 32-bit integer register?)

Sean

"Achilleas Margaritis" <axilmar in.gr> wrote in message
news:bhqbjl$6eu$1 digitaldaemon.com...
 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.
Aug 19 2003
parent reply "Fabian Giesen" <rygNO SPAMgmx.net> writes:
 We really would need another type these days.. 128-bit cpu's are
 starting to come out, and some of them let you do 128-bit arithmetic.
 D has the cent keyword for this, but what about the next one, 256?
 Anyway today, we need software emulation for cent type, just like
 16-bit cpu's needed to software emulate 32-bit math, and 8-bit cpu's
 had to emulate 16-bit math.  ;)
Hm, IMHO there are little uses for 64bit-arithmetic, very little uses for 128bit-arithmetic, and I can't imagine why I would want 256bit arithmetic. In the time I've been coding, 32bit has always been a very sweet spot in terms of integer range - you very rarely need more in pratical applications. I remember lots of coding 32bit-with-16bit- arithmetic in my 16bit-times. The amount of occassions I've been doing 64bit-arithmetic is significantly lower, and the only reason for 128bit I can readily imagine is because the product of two 64bit-values fits in that range; I truly can't imagine one single reason for having individual 256bit values (4 64bit values packed in 256bits for SIMD, maybe; but one single 256bit chunk?) -fg
Aug 19 2003
next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
I don't think they'll replace 32-bit values anytime soon, but yeah, they're
for measuring really large quantities, such as nanoseconds since the
Egyptians built the pyramids, or millimeters to Alpha Centauri.  ;)  You
already find 64-bit values in CPU cycle timers, and if they get another
order of magnitude faster it'll be 128 before you know it.

You can think of an integer as the mantissa of a really high precision
fraction in the range 0 to 1, and then scale that conceptually to any range
you wish (you need double precision to hold temporary results of
multiplications!).  People are always wanting more precision.  If you gave a
film studio 3D hardware that had a 64-bit z-buffer they'd probably go insane
with glee.

Maybe it will stop at 128 bits.  I don't see register size growth slowing
completely to a halt, ever, not so long as the ram keeps getting larger,
we'll need integers big enough to address it.  Either that or use page
selectors (remember segment registers?)

Maybe the cpu vendors are using register size to sell increased ram capacity
and faster buses, since the bigger the registers, the more ram taken to hold
a value, which means you need more ram and a faster bus, which means you
need a new computer, which has bigger registers... hehehe.

Sean

"Fabian Giesen" <rygNO SPAMgmx.net> wrote in message
news:bhu9ph$30d9$1 digitaldaemon.com...
 Hm, IMHO there are little uses for 64bit-arithmetic, very little uses
 for 128bit-arithmetic, and I can't imagine why I would want 256bit
 arithmetic. In the time I've been coding, 32bit has always been a very
 sweet spot in terms of integer range - you very rarely need more in
 pratical applications. I remember lots of coding 32bit-with-16bit-
 arithmetic in my 16bit-times. The amount of occassions I've been doing
 64bit-arithmetic is significantly lower, and the only reason for 128bit
 I can readily imagine is because the product of two 64bit-values fits in
 that range; I truly can't imagine one single reason for having individual
 256bit values (4 64bit values packed in 256bits for SIMD, maybe; but one
 single 256bit chunk?)

 -fg
Aug 20 2003
prev sibling parent Bill Cox <bill viasic.com> writes:
Fabian Giesen wrote:
We really would need another type these days.. 128-bit cpu's are
starting to come out, and some of them let you do 128-bit arithmetic.
D has the cent keyword for this, but what about the next one, 256?
Anyway today, we need software emulation for cent type, just like
16-bit cpu's needed to software emulate 32-bit math, and 8-bit cpu's
had to emulate 16-bit math.  ;)
Hm, IMHO there are little uses for 64bit-arithmetic, very little uses for 128bit-arithmetic, and I can't imagine why I would want 256bit arithmetic. In the time I've been coding, 32bit has always been a very sweet spot in terms of integer range - you very rarely need more in pratical applications. I remember lots of coding 32bit-with-16bit- arithmetic in my 16bit-times. The amount of occassions I've been doing 64bit-arithmetic is significantly lower, and the only reason for 128bit I can readily imagine is because the product of two 64bit-values fits in that range; I truly can't imagine one single reason for having individual 256bit values (4 64bit values packed in 256bits for SIMD, maybe; but one single 256bit chunk?) -fg
I agree that there are not many uses for 64 bit values or pointers. All of our software is designed from the ground up in 64-bit land, but our needs in EDA are the exception. Personally, I don't like the 'cent' keyword. It reminds me of Verilog's 'time' keyword. Yuk. Here I am writing wide bus interfaces, and I keep using variables of type 'time'. It's only a matter of time before we start using 'cent' to represent all kinds of non-money related values. Why not allow types like int32 and uint32? That convention scales, and is easier to read than byte, short, int, long, and cent. All you have to do is parse keywords of the form "int[0-9]*", and assign a bit width to the token returned. The default width would be 32. You could still put aliases in Phobos to get the traditional keywords. If we can't get the more generic mechanism, then changing 'cent' to 'hyper' would be an improvement IMO. Bill P.S. Here's a somewhat contrived use for 256 bit values: computing standard deviations of 'cent' values.
Aug 20 2003
prev sibling parent reply "Achilleas Margaritis" <axilmar in.gr> writes:
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
Aug 18 2003
parent Ilya Minkov <midiclub 8ung.at> writes:
Achilleas Margaritis wrote:
 It seems like a good language, but does the world really need yet another
 C++ clone ? D is enough, I think.
It's not at all the same direction as D. It shall never become as popular as D may. It's quite interesting though. And it's approximately the same kind of C++ clone as you or myself are monkey clones. :) -i.
Aug 18 2003