www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D, high-level, low-level, parameters

reply nick <nick.atamas gmail.com> writes:
After reading the relevant discussion threads, I thought I would
summarize my observations and normative thoughts.

I. INTRO
--------
It seems to me that the discussions in the "unsafe" thread and the "In,
inout, out, and damn lies...." are really touching on a larger issue.

D aims to be a high-level language and a low-level systems language at
the same time(*see footnote).  This seems to cause problems because the
two approaches are inherently contradictory. Specifically, low-level
constructs aim to hide nothing while high-level constructs aim to hide
the bare metal.
The implications are most vivid in how parameters are handled. (Function
declarations are interfaces, so this is to be expected.)

With respect to parameter passing, I do not see any reason why a
language couldn't do the following:


II. HIGH-LEVEL
--------------
Everything is passed by reference.
All the information the compiler needs can be conveyed by in/out/inout
(we could also use read/write/readwrite).

note: I treat arrays as objects and pointers as primitives.

1) For objects:
	in - read only; applies to ref and data
	out - can write data/ref; can read reference
	inout - can read and write; applies to ref and data

note: One might replace 'can' with 'shall' but that's another discussion.

2) For primitive types
	in - read only (passed by value as an optimization)
	out - passed by invisible reference; can write data
	inout - passed by invisible reference; can read/write data


III. LOW-LEVEL
--------------
If someone is coding at the low-level, they presumably understand the
high-level constructs but are also free to use pointers as they please
to achieve any effect necessary.


IV. DISCUSSION
--------------
My question is: "Why not use the above semantics? Is there something
wrong with them?"




Footnote:
*I wager that many of C++'s problems arise from trying to reconcile the
high-level and low-level approach.
Feb 20 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 20 Feb 2006 13:37:32 -0800, nick <nick.atamas gmail.com> wrote:

 After reading the relevant discussion threads, I thought I would
 summarize my observations and normative thoughts.

 I. INTRO
 --------
 It seems to me that the discussions in the "unsafe" thread and the "In,
 inout, out, and damn lies...." are really touching on a larger issue.

 D aims to be a high-level language and a low-level systems language at
 the same time(*see footnote).  This seems to cause problems because the
 two approaches are inherently contradictory. Specifically, low-level
 constructs aim to hide nothing while high-level constructs aim to hide
 the bare metal.
 The implications are most vivid in how parameters are handled. (Function
 declarations are interfaces, so this is to be expected.)

 With respect to parameter passing, I do not see any reason why a
 language couldn't do the following:


 II. HIGH-LEVEL
 --------------
 Everything is passed by reference.
 All the information the compiler needs can be conveyed by in/out/inout
 (we could also use read/write/readwrite).

 note: I treat arrays as objects and pointers as primitives.

 1) For objects:
 	in - read only; applies to ref and data
 	out - can write data/ref; can read reference
 	inout - can read and write; applies to ref and data

 note: One might replace 'can' with 'shall' but that's another discussion.

 2) For primitive types
 	in - read only (passed by value as an optimization)
 	out - passed by invisible reference; can write data
 	inout - passed by invisible reference; can read/write data


 III. LOW-LEVEL
 --------------
 If someone is coding at the low-level, they presumably understand the
 high-level constructs but are also free to use pointers as they please
 to achieve any effect necessary.


 IV. DISCUSSION
 --------------
 My question is: "Why not use the above semantics? Is there something
 wrong with them?"


No. The problem doesn't lie in the semantics but rather in how to enforce  
"readonly". Walter has said that he does not like C++ const. I believe one  
of the reason is because it does not guarantee protection, that the  
protection can be circumvented via aliasing, making it a somewhat 'hollow'  
promise, one which you therefore cannot rely on to be true at any stage.

Regan

p.s. I suggested something very similar to what you have above some time  
ago. I'm sure someone else suggested it some longer time before me. The  
idea is great, the reality is the problem. :)
Feb 21 2006
parent reply Tom <Tom_member pathlink.com> writes:
In article <ops5bhwscg23k2f5 nrage.netwin.co.nz>, Regan Heath says...

On Mon, 20 Feb 2006 13:37:32 -0800, nick <nick.atamas gmail.com> wrote:

 After reading the relevant discussion threads, I thought I would
 summarize my observations and normative thoughts.

 I. INTRO
 --------
 It seems to me that the discussions in the "unsafe" thread and the "In,
 inout, out, and damn lies...." are really touching on a larger issue.

 D aims to be a high-level language and a low-level systems language at
 the same time(*see footnote).  This seems to cause problems because the
 two approaches are inherently contradictory. Specifically, low-level
 constructs aim to hide nothing while high-level constructs aim to hide
 the bare metal.
 The implications are most vivid in how parameters are handled. (Function
 declarations are interfaces, so this is to be expected.)

 With respect to parameter passing, I do not see any reason why a
 language couldn't do the following:


 II. HIGH-LEVEL
 --------------
 Everything is passed by reference.
 All the information the compiler needs can be conveyed by in/out/inout
 (we could also use read/write/readwrite).

 note: I treat arrays as objects and pointers as primitives.

 1) For objects:
 	in - read only; applies to ref and data
 	out - can write data/ref; can read reference
 	inout - can read and write; applies to ref and data

 note: One might replace 'can' with 'shall' but that's another discussion.

 2) For primitive types
 	in - read only (passed by value as an optimization)
 	out - passed by invisible reference; can write data
 	inout - passed by invisible reference; can read/write data


 III. LOW-LEVEL
 --------------
 If someone is coding at the low-level, they presumably understand the
 high-level constructs but are also free to use pointers as they please
 to achieve any effect necessary.


 IV. DISCUSSION
 --------------
 My question is: "Why not use the above semantics? Is there something
 wrong with them?"


No. The problem doesn't lie in the semantics but rather in how to enforce  
"readonly". Walter has said that he does not like C++ const. I believe one  
of the reason is because it does not guarantee protection, that the  
protection can be circumvented via aliasing, making it a somewhat 'hollow'  
promise, one which you therefore cannot rely on to be true at any stage.


Can you throw an example of this stuff? Why is const bad? So by saying it can be
circumvented is enough to not implement something similar? With inline asm any
high level construct can be circumvented (i guess). That doesn't stop us to use
them.

I really believe it's a good feature (as it'd be 'in' if it were so strong as
const). As a programmer many times I've seen "bad-coded" C++ functions (that
missed up to make const some of the input parameters) and made me and others to
waste LOT of time finding a bug.

Tom;
Feb 21 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 21 Feb 2006 13:37:00 +0000 (UTC), Tom <Tom_member pathlink.com>  
wrote:

 In article <ops5bhwscg23k2f5 nrage.netwin.co.nz>, Regan Heath says...

 On Mon, 20 Feb 2006 13:37:32 -0800, nick <nick.atamas gmail.com> wrote:

 After reading the relevant discussion threads, I thought I would
 summarize my observations and normative thoughts.

 I. INTRO
 --------
 It seems to me that the discussions in the "unsafe" thread and the "In,
 inout, out, and damn lies...." are really touching on a larger issue.

 D aims to be a high-level language and a low-level systems language at
 the same time(*see footnote).  This seems to cause problems because the
 two approaches are inherently contradictory. Specifically, low-level
 constructs aim to hide nothing while high-level constructs aim to hide
 the bare metal.
 The implications are most vivid in how parameters are handled.  
 (Function
 declarations are interfaces, so this is to be expected.)

 With respect to parameter passing, I do not see any reason why a
 language couldn't do the following:


 II. HIGH-LEVEL
 --------------
 Everything is passed by reference.
 All the information the compiler needs can be conveyed by in/out/inout
 (we could also use read/write/readwrite).

 note: I treat arrays as objects and pointers as primitives.

 1) For objects:
 	in - read only; applies to ref and data
 	out - can write data/ref; can read reference
 	inout - can read and write; applies to ref and data

 note: One might replace 'can' with 'shall' but that's another  
 discussion.

 2) For primitive types
 	in - read only (passed by value as an optimization)
 	out - passed by invisible reference; can write data
 	inout - passed by invisible reference; can read/write data


 III. LOW-LEVEL
 --------------
 If someone is coding at the low-level, they presumably understand the
 high-level constructs but are also free to use pointers as they please
 to achieve any effect necessary.


 IV. DISCUSSION
 --------------
 My question is: "Why not use the above semantics? Is there something
 wrong with them?"


 No. The problem doesn't lie in the semantics but rather in how to  
 enforce
 "readonly". Walter has said that he does not like C++ const. I believe  
 one
 of the reason is because it does not guarantee protection, that the
 protection can be circumvented via aliasing, making it a somewhat  
 'hollow'
 promise, one which you therefore cannot rely on to be true at any stage.


 Can you throw an example of this stuff? Why is const bad? So by saying  
 it can be
 circumvented is enough to not implement something similar? With inline  
 asm any
 high level construct can be circumvented (i guess). That doesn't stop us  
 to use
 them.

 I really believe it's a good feature (as it'd be 'in' if it were so  
 strong as
 const). As a programmer many times I've seen "bad-coded" C++ functions  
 (that
 missed up to make const some of the input parameters) and made me and  
 others to
 waste LOT of time finding a bug.


There has been a *whole lot* of discussion in the past, let me point you  
to some threads on the subject:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/15924
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/18932
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/24340
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/24798
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/25659
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/25992
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26126
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26216
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26247
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26364
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26690
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26742

Some are directly on topic talking about const or readonly specifically,  
others are primarily about something else but at the root are a discussion  
on preventing write access to read only data.

Regan
Feb 21 2006
parent Tom <Tom_member pathlink.com> writes:
 [...]
Some are directly on topic talking about const or readonly specifically,  
others are primarily about something else but at the root are a discussion  
on preventing write access to read only data.


Yap, interesting. But not yet getting to understand why not make 'in' like C++
const. I missed Walter's opinion on that. I mean, it surely adds complexity to
the compiler but it's a VERY USEFUL feature.

Tom;
Feb 21 2006