• Mark Evans (4/4) Jul 19 2003 http://xana.sourceforge.net/
• Antti =?iso-8859-1?Q?Syk=E4ri?= (57/63) Aug 15 2003 Where did you hear about this language, by the way?
• Philippe Mori (76/138) Aug 16 2003 For information, what is an orthogonal type-system ?
• Peter Hercek (16/22) Aug 16 2003 No two different types do the same (eg int and long mean the same
• Sean L. Palmer (44/68) Aug 17 2003 news:bhm4h6$5vq$1@digitaldaemon.com...
• Peter Hercek (4/76) Aug 17 2003 Yes, this is portability contra efficiency, ... or let the programer to ...
• Achilleas Margaritis (12/36) Aug 18 2003 C++ is misunderstood. Int and long are two different data types. It is j...
• Antti =?iso-8859-1?Q?Syk=E4ri?= (12/22) Aug 18 2003 No. IIRC, at least on the 64-bit Alpha architecture, the sizes are as
• Fabian Giesen (15/24) Aug 18 2003 I used to think that too, however ISO C++ clearly specifies that
• Sean L. Palmer (25/34) Aug 19 2003 Well, you should know that long has to be at least as large as int. If
• Fabian Giesen (12/18) Aug 19 2003 Hm, IMHO there are little uses for 64bit-arithmetic, very little uses
• Sean L. Palmer (22/34) Aug 20 2003 I don't think they'll replace 32-bit values anytime soon, but yeah, they...
• Bill Cox (18/39) Aug 20 2003 I agree that there are not many uses for 64 bit values or pointers. All...
• Achilleas Margaritis (10/73) Aug 18 2003 It seems like a good language, but does the world really need yet anothe...
• Ilya Minkov (5/7) Aug 18 2003 It's not at all the same direction as D. It shall never become as

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."

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

"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

"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.

"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.

"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.

"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.

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

"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

"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.

"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

"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

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.

"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

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.