www.digitalmars.com         C & C++   DMDScript  

D - Resolving outstanding issues - how?

reply "kaffiene" <kaffiene xtra.co.nz> writes:
This newsgroup has been extremely interesting so far - there have been a lot
of very interesting discussions.  What I'm wondering now is how the open
issues will move towards resolution?  And, as a precursor to that
discussion, what is the list of actual open issues?  What is in for sure,
and what is on the maybe list?

Personally, I'm very interested in seeing the resolution to some of the
issues that have been raised.  To this end, I'd like to get Walter's
feedback on some of the big issues that have been well debated - where are
the issues going?  Are you considering adding some new elements that weren't
in the original spec?  Reconsidering old ones?

Here are some of the major issues I'd like Walter to comment on:

--- Generics ---
I take it from Walter's posts and from the general sentiment, that some form
of Generics is desirable - are there any candidates looking at all likely?

--- Operator Overloading ---
Well, we've had quite a bun fight over operator overloading. ;-)  Is it in,
out or under consideration?

--- Exception Specification ---
The exception specification thread seemed very strongly in favour of
including exception specification and that leaving it out was a bad idea.
Walter - are you convinced?

--- Multiple Return Values from Functions ---
psheer introduced the idea of multiple return types for functions.  We've
discussed possible syntax and a lot of positive comment has been made.  I've
suggested that it's a much better idea that in, out and inout variables.
Walter, what do you think?

Others?

Peter.
Aug 21 2001
next sibling parent "Bradeeoh" <bradeeoh crosswinds.net> writes:
"kaffiene" <kaffiene xtra.co.nz> wrote in message
news:9ltg04$2361$1 digitaldaemon.com...
 This newsgroup has been extremely interesting so far - there have been a

 of very interesting discussions.  What I'm wondering now is how the open
 issues will move towards resolution?  And, as a precursor to that
 discussion, what is the list of actual open issues?  What is in for sure,
 and what is on the maybe list?

 Personally, I'm very interested in seeing the resolution to some of the
 issues that have been raised.  To this end, I'd like to get Walter's
 feedback on some of the big issues that have been well debated - where are
 the issues going?  Are you considering adding some new elements that

 in the original spec?  Reconsidering old ones?

 Here are some of the major issues I'd like Walter to comment on:

 --- Generics ---
 I take it from Walter's posts and from the general sentiment, that some

 of Generics is desirable - are there any candidates looking at all likely?

 --- Operator Overloading ---
 Well, we've had quite a bun fight over operator overloading. ;-)  Is it

 out or under consideration?

 --- Exception Specification ---
 The exception specification thread seemed very strongly in favour of
 including exception specification and that leaving it out was a bad idea.
 Walter - are you convinced?

 --- Multiple Return Values from Functions ---
 psheer introduced the idea of multiple return types for functions.  We've
 discussed possible syntax and a lot of positive comment has been made.

 suggested that it's a much better idea that in, out and inout variables.
 Walter, what do you think?

 Others?

 Peter.

Peter - Great idea. Personally, I'm intrigued by this language and the discussions going on here that may influence its development. I'd love to hear Walters "State of the Language" address. :) Another discussion that's been pretty active is the import format - stick with the original spec, or go towards a more Java-like import system that solves alot of the problems people have pointed out? -Brady
Aug 21 2001
prev sibling next sibling parent reply "David Caldlwell" <bogus porkrind.org> writes:
kaffiene <kaffiene xtra.co.nz> wrote in message
news:9ltg04$2361$1 digitaldaemon.com...
 Others?

My personal interests are: - enum.stringrep property (returns the name of an enum as a string). I can't tell you how often I have to have parallel arrays just for debugging stupid enums. As Walter pointed out in the D spec, parallel arrays are annoying (ie, forgetting to change one of them and then everything is mismatched). And the beauty of the module system is that the strings never need to be compiled into the resulting code unless they are used. Perfect for debugging. Most of the ideas in the "super enums" thread were very good. - Some kind of templatey/#define thing. Is that what you meant by "Generals"? - Some way to deal with hardware specific issues. little-endian and big-endian built in types could be very useful for reading rigid file formats using cross-platform code. Most non-x86 processors have instructions for reading opposite-endian integers, so it doesn't even have to be horribly inefficient. This could also be useful for talking to hardware. - Maybe a way to disable garbage collection for firmware code or some other cirmcumstance when it would be innapropriate to have large delays for GC or for code that needs really tight control of memory. I've never been so intrigued by a language spec before. Theres something in the called out features of D so far that strikes a chord in me. Its like someone grouped together all the things about C that annoy me and fixed them. :-) I definitely want this to see the light of day. -David david porkrind_org
Aug 22 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
David Caldlwell wrote in message <9lvdlb$603$1 digitaldaemon.com>...
I've never been so intrigued by a language spec before. Theres something in
the called out features of D so far that strikes a chord in me. Its like
someone grouped together all the things about C that annoy me and fixed
them. :-) I definitely want this to see the light of day.

What sold me was taking some old C code I had, and hand translating it into D. It just *looked* so much better. You can see some bits of my experiments in: www.digitalmars.com/d/ctod.html www.digitalmars.com/d/cpptod.html www.digitalmars.com/d/pretod.html Heck, D is the language I want to program in, so that's my incentive <g>.
Aug 23 2001
next sibling parent reply Russ Lewis <russ deming-os.org> writes:
I was reading the pages you put up.  Nice summary :)

However, there is a serious discrepancy between
http://www.digitalmars.com/d/lex.html and http://www.digitalmars.com/d/ctod.html
regarding escaped characters in strings.

lex.html says that strings in double-quotes include escape characters like C,
while strings in single-quotes are taken as-is:

"deltree c:\\windows\n"
    is the same as
'detree c:\windows' \n

ctod.html says that strings in double-quotes cannot have escape characters.
Aug 23 2001
parent "Walter" <walter digitalmars.com> writes:
Good catch! Thanks.

Russ Lewis wrote in message <3B8559AD.8EE411E1 deming-os.org>...
I was reading the pages you put up.  Nice summary :)

However, there is a serious discrepancy between
http://www.digitalmars.com/d/lex.html and

regarding escaped characters in strings.

lex.html says that strings in double-quotes include escape characters like

while strings in single-quotes are taken as-is:

"deltree c:\\windows\n"
    is the same as
'detree c:\windows' \n

ctod.html says that strings in double-quotes cannot have escape characters.

Aug 24 2001
prev sibling parent "Bradeeoh" <bradeeoh crosswinds.net> writes:
 What sold me was taking some old C code I had, and hand translating it

 D. It just *looked* so much better. You can see some bits of my

 in:

     www.digitalmars.com/d/ctod.html
     www.digitalmars.com/d/cpptod.html
     www.digitalmars.com/d/pretod.html

 Heck, D is the language I want to program in, so that's my incentive <g>.

Looking at those pages reaffirmed why I already wanted D to be a reality. :) -Brady
Aug 23 2001
prev sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
"David Caldlwell" <bogus porkrind.org> wrote in message
news:9lvdlb$603$1 digitaldaemon.com...
 My personal interests are:
  - enum.stringrep property (returns the name of an enum as a string). I
 can't tell you how often I have to have parallel arrays just for debugging
 stupid enums. As Walter pointed out in the D spec, parallel arrays are
 annoying (ie, forgetting to change one of them and then everything is
 mismatched). And the beauty of the module system is that the strings never
 need to be compiled into the resulting code unless they are used. Perfect
 for debugging. Most of the ideas in the "super enums" thread were very

Just have enums automatically have the ability to be converted to a string. Pascal did this from what I remember. Any enums that aren't actually ever converted to strings, would not require the runtime to contain those strings.
  - Some way to deal with hardware specific issues. little-endian and
 big-endian built in types could be very useful for reading rigid file
 formats using cross-platform code. Most non-x86 processors have

 for reading opposite-endian integers, so it doesn't even have to be

 inefficient. This could also be useful for talking to hardware.

I'd also like to see this built into the language somehow, but if it was a modifier tacked onto a basic integer/float type, it would be a big drain on performance to manipulate variables declared that way. I'd only ever use endian specifications on structs representing disk data structures where I knew the file needed to be portable to multiple platforms. For games, the overhead of conversion is usually not acceptable, so we end up having to make file converters for each platform. The feature would help to write those kinds of tools, however. ;) Unfortunately I think endianness is such a platform specific thing that it's possible in the future someone will make a processor that uses some totally different scheme to arrange the layout of integers in memory. The language should probably be platform agnostic. Sean
Nov 03 2001
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9s2fbc$2264$1 digitaldaemon.com...
 Unfortunately I think endianness is such a platform specific thing that

 possible in the future someone will make a processor that uses some

 different scheme to arrange the layout of integers in memory.  The

 should probably be platform agnostic.

How I see resolving endian issues is via a class derived from OutBuffer and InBuffer, which respectively read and write to arrays of bytes. OutBufferLittleEndian, InBufferBigEndian, etc., translate to/from endians.
Jan 09 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a1j6gt$2b02$2 digitaldaemon.com...

 How I see resolving endian issues is via a class derived from OutBuffer

 InBuffer, which respectively read and write to arrays of bytes.

OutBuffer AND InBuffer? D supports multiple inheritance???
 OutBufferLittleEndian, InBufferBigEndian, etc., translate to/from endians.

Um... why not just overloaded btol() and ltob()?
Jan 10 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
kaffiene wrote in message <9ltg04$2361$1 digitaldaemon.com>...
--- Generics ---
I take it from Walter's posts and from the general sentiment, that some

of Generics is desirable - are there any candidates looking at all likely?

I've been looking at the Ada way of doing templates. It looks in the same direction as I've been thinking.
--- Operator Overloading ---
Well, we've had quite a bun fight over operator overloading. ;-)  Is it in,
out or under consideration?

Under consideration. I doubt it will make it into version 1.
--- Exception Specification ---
The exception specification thread seemed very strongly in favour of
including exception specification and that leaving it out was a bad idea.
Walter - are you convinced?

Not yet <g>.
--- Multiple Return Values from Functions ---
psheer introduced the idea of multiple return types for functions.  We've
discussed possible syntax and a lot of positive comment has been made.

suggested that it's a much better idea that in, out and inout variables.
Walter, what do you think?

A large reservation I have is that the syntax is too different from C. Tuple returns will take a lot of getting used to. BTW, some of my colleagues have been very adamant about the advantages of multiple return types <g>.
Aug 23 2001
next sibling parent "kaffiene" <kaffiene xtra.co.nz> writes:
"Walter" <walter digitalmars.com> wrote in message
news:9m2coh$1ve8$1 digitaldaemon.com...
 kaffiene wrote in message <9ltg04$2361$1 digitaldaemon.com>...
--- Generics ---
I take it from Walter's posts and from the general sentiment, that some

of Generics is desirable - are there any candidates looking at all


 I've been looking at the Ada way of doing templates. It looks in the same
 direction as I've been thinking.

Okay. I'm not very familiar with Ada. Could you (or anyone else) expand on how Ada templates work? I hate templates in C++, but I'm willing to be shown a better way ;-)
--- Operator Overloading ---
Well, we've had quite a bun fight over operator overloading. ;-)  Is it


out or under consideration?

Under consideration. I doubt it will make it into version 1.

OK. We'll just continue throwing buns at each other, I guess ;-)
--- Exception Specification ---
The exception specification thread seemed very strongly in favour of
including exception specification and that leaving it out was a bad idea.
Walter - are you convinced?

Not yet <g>.

OK. I'm concerned that this probably needs to be either included or rejected as early in the evolution of D as possible. As John Carney said in the Exception Specification thread: "Think of it this way: if it is decided five years down the track that rigid exception specification is, after all, a good thing, you're going to break an awful lot of code if you try to tack it onto the language. On the other hand, if we in the pro-specification camp turn out to be wrong, then relaxing the rules isn't going to render anybody's code base inoperable." (I'm biased - I think leaving this out would a huge loss)
--- Multiple Return Values from Functions ---
psheer introduced the idea of multiple return types for functions.  We've
discussed possible syntax and a lot of positive comment has been made.

suggested that it's a much better idea that in, out and inout variables.
Walter, what do you think?

A large reservation I have is that the syntax is too different from C.

 returns will take a lot of getting used to. BTW, some of my colleagues

 been very adamant about the advantages of multiple return types <g>.

So it's open for debate? ;-) Point taken about the syntax, but I don't think it's *too* major. You don't necessarily need tuples (as a language feature), just bind return values to descrete variables. Some of my colleagues were saying that having multiple return values from a function would be a good enough reason to use the language (this is coming from C++ zealots) Cheers, Peter.
Aug 23 2001
prev sibling next sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Walter wrote:
 kaffiene wrote in message <9ltg04$2361$1 digitaldaemon.com>...
 
--- Generics ---
I take it from Walter's posts and from the general sentiment, that some

of Generics is desirable - are there any candidates looking at all likely?

I've been looking at the Ada way of doing templates. It looks in the same direction as I've been thinking.
--- Operator Overloading ---
Well, we've had quite a bun fight over operator overloading. ;-)  Is it in,
out or under consideration?

Under consideration. I doubt it will make it into version 1.

 
--- Exception Specification ---
The exception specification thread seemed very strongly in favour of
including exception specification and that leaving it out was a bad idea.
Walter - are you convinced?

Not yet <g>.

The possibilities that occur to me are program termination (Ouch!) and exceptions (or Eiffel's Resume blocks). Do you intend to include Resume blocks that can catch them? I haven't been too pleased with how they work in Eiffel. But, I suppose, that with in-out parameters one could frequently pass back an error code. The problem is that in a stream of function operations the error code wouldn't get processed until after the rest of the processing of the stream with invalid information had occured, so you better be able to figure out a harmless return value. And I haven't always been able to. Perhaps program termination is the soft option?
 

Aug 23 2001
parent reply "Walter" <walter digitalmars.com> writes:
"Charles Hixson" <charleshixsn earthlink.net> wrote in message
 How do you see run-time contract violations as being handled?
 The possibilities that occur to me are program termination (Ouch!) and
 exceptions (or Eiffel's Resume blocks).

As throwing an exception.
 Do you intend to include Resume blocks that can catch them?   I haven't
 been too pleased with how they work in Eiffel.  But, I suppose, that
 with in-out parameters one could frequently pass back an error code.
 The problem is that in a stream of function operations the error code
 wouldn't get processed until after the rest of the processing of the
 stream with invalid information had occured, so you better be able to
 figure out a harmless return value.  And I haven't always been able to.

Exceptions would be caught by the usual catch() mechanism. If you don't catch them, they bubble up and terminate the program with an appropriate program.
Aug 23 2001
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Walter wrote:
 "Charles Hixson" <charleshixsn earthlink.net> wrote in message
 
How do you see run-time contract violations as being handled?
The possibilities that occur to me are program termination (Ouch!) and
exceptions (or Eiffel's Resume blocks).

As throwing an exception.

 

Aug 24 2001
parent "Walter" <walter digitalmars.com> writes:
Charles Hixson wrote in message <3B86743A.8010903 earthlink.net>...
Walter wrote:
 "Charles Hixson" <charleshixsn earthlink.net> wrote in message

How do you see run-time contract violations as being handled?
The possibilities that occur to me are program termination (Ouch!) and
exceptions (or Eiffel's Resume blocks).

As throwing an exception.


No prob. From the feedback in this group, I've been able to improve the spec a lot. There are a lot of errors and vaguenesses in it.
Aug 24 2001
prev sibling parent Dan Hursh <hursh infonet.isl.net> writes:
Walter wrote:
 
 kaffiene wrote in message <9ltg04$2361$1 digitaldaemon.com>...
--- Multiple Return Values from Functions ---
psheer introduced the idea of multiple return types for functions.  We've
discussed possible syntax and a lot of positive comment has been made.

suggested that it's a much better idea that in, out and inout variables.
Walter, what do you think?

A large reservation I have is that the syntax is too different from C. Tuple returns will take a lot of getting used to. BTW, some of my colleagues have been very adamant about the advantages of multiple return types <g>.

For what it's worth, it might help in making parts of the library less dependent on each other. You wouldn't have to deal with a web of feature specific objects that must be supported through out the library. Given the 'safety first' nature of D in most cases, I doubt that a library that made great use of multiple return values would be accepted. Also if you don't allow a function returning multiple value to be used in the place of multiple arguments in another function, then the gain wouldn't be much. It's still a cool feature. :-) Dan
Aug 25 2001