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


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.


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


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


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


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


good.

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


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.


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


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.


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


and

 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


form

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.


I've

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


 form

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.


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




in,

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.


 I've

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


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


 form
 

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.
 


Well, I'll hope for version 2 then.  :-)

 

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


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

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.
 


...

 


Sorry.  I had misunderstood that the exception mechanism was being removed.
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.


Sorry.  I had misunderstood that the exception mechanism was being removed.



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.


 I've

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