Re: [BLACKBOX] IN Parameters - Making the design more regular

From: [at]} <CFB>
Date: Tue, 29 Jan 2008 09:58:56 +1030

----boundary-LibPST-iamunique-744001529_-_-
Content-type: text/plain

>-----Original Message-----
>From: BlackBox [mailto:BLACKBOX{([at]})nowhere.xy
>Sent: Tuesday, 29 January 2008 9:07 AM
>To: BLACKBOX{([at]})nowhere.xy
>Subject: Re: [BLACKBOX] IN Parameters - Making the design more regular
>

>I think this is a rather brave suggestion!

I have a couple of others that I dare not mention. This one is relatively
uncontroversial in comparison.

>3 - I disagree that IN variables should (always) be passed by
>value.

I did not say that. Try forgetting what you know already and read it again.

> If you are passing a large RECORD or ARRAY it is much
>more efficient to simply pass 1 address.

Indeed.

> Your comments are
>inconsistent. How can both quotes below be true?
>
> - "Value and input (keyword IN) parameters are local
>variables to which the value of the corresponding actual
>parameter is assigned as an initial value"

>- "The compiler developer is still free to implement efficient
>handling of records and arrays when used as input parameters.
>As is the case currently, such parameters do not need to be
>copied to the stack when the procedure is invoked"
>

A local variable in a procedure is one that cannot be accessed from outside
that procedure. A local variable either has an undefined value at the start
of the procedure (OUT) or a defined value (default, IN and VAR). None of
this *dictates* exactly how this should happen inside the compiler.

>Anyway, I want to know that the compiler writer has
>implemented passing a large IN array efficiently, not just be
>assured that he/she is permitted to do so.
>

I would as well. I would also like to know that they have implemented a CASE
statement using jumps rather than a chain of if-then-elses, or that they
have used registers rather than the stack for passing parameters in leaf
procedures, or all of the many other ways that compiler writers can do their
job properly. Should all of these implementation details also be spelt out
in the language specification?

>
>5 - The biggest question of all is: If we start allowing some
>language changes where do we stop, and how do we control this?
>

I share your reservations concerning language changes. However, I see this
proposal more as a removal of an arbitrary implementation-driven restriction
rather than a language change.

Thanks for the feedback,

Regards,
Chris

Chris Burrows
CFB Software
http://www.cfbsoftware.com/cp

----
To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy----boundary-LibPST-iamunique-744001529_-_-
Content-type: application/rtf
Content-transfer-encoding: base64
Content-Disposition: attachment; filename="rtf-body.rtf"
e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZnJvbXRleHQgXGRlZmYwe1xmb250dGJsDQp7XGYwXGZz
d2lzcyBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmllciBOZXc7fQ0Ke1xmMlxmbmlsXGZjaGFy
c2V0MiBTeW1ib2w7fQ0Ke1xmM1xmbW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5ldzt9fQ0Ke1xj
b2xvcnRibFxyZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1NTt9DQpcdWMxXHBh
cmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLVxw
YXINCj5Gcm9tOiBCbGFja0JveCBbbWFpbHRvOkJMQUNLQk9YQExJU1RTLk9CRVJPTi5DSF0gT24g
QmVoYWxmIE9mIFJvYmVydFxwYXINCj5TZW50OiBUdWVzZGF5LCAyOSBKYW51YXJ5IDIwMDggOTow
NyBBTVxwYXINCj5UbzogQkxBQ0tCT1hATElTVFMuT0JFUk9OLkNIXHBhcg0KPlN1YmplY3Q6IFJl
OiBbQkxBQ0tCT1hdIElOIFBhcmFtZXRlcnMgLSBNYWtpbmcgdGhlIGRlc2lnbiBtb3JlIHJlZ3Vs
YXJccGFyDQo+XHBhcg0KXHBhcg0KPkkgdGhpbmsgdGhpcyBpcyBhIHJhdGhlciBicmF2ZSBzdWdn
ZXN0aW9uISBccGFyDQpccGFyDQpJIGhhdmUgYSBjb3VwbGUgb2Ygb3RoZXJzIHRoYXQgSSBkYXJl
IG5vdCBtZW50aW9uLiBUaGlzIG9uZSBpcyByZWxhdGl2ZWx5XHBhcg0KdW5jb250cm92ZXJzaWFs
IGluIGNvbXBhcmlzb24uXHBhcg0KXHBhcg0KPjMgLSBJIGRpc2FncmVlIHRoYXQgSU4gdmFyaWFi
bGVzIHNob3VsZCAoYWx3YXlzKSBiZSBwYXNzZWQgYnkgXHBhcg0KPnZhbHVlLiBccGFyDQpccGFy
DQpJIGRpZCBub3Qgc2F5IHRoYXQuIFRyeSBmb3JnZXR0aW5nIHdoYXQgeW91IGtub3cgYWxyZWFk
eSBhbmQgcmVhZCBpdCBhZ2Fpbi5ccGFyDQpccGFyDQo+IElmIHlvdSBhcmUgcGFzc2luZyBhIGxh
cmdlIFJFQ09SRCBvciBBUlJBWSBpdCBpcyBtdWNoIFxwYXINCj5tb3JlIGVmZmljaWVudCB0byBz
aW1wbHkgcGFzcyAxIGFkZHJlc3MuIFxwYXINClxwYXINCkluZGVlZC5ccGFyDQpccGFyDQo+IFlv
dXIgY29tbWVudHMgYXJlIFxwYXINCj5pbmNvbnNpc3RlbnQuIEhvdyBjYW4gYm90aCBxdW90ZXMg
YmVsb3cgYmUgdHJ1ZT9ccGFyDQo+XHBhcg0KPiAgLSAiVmFsdWUgYW5kIGlucHV0IChrZXl3b3Jk
IElOKSBwYXJhbWV0ZXJzIGFyZSBsb2NhbCBccGFyDQo+dmFyaWFibGVzIHRvIHdoaWNoIHRoZSB2
YWx1ZSBvZiB0aGUgY29ycmVzcG9uZGluZyBhY3R1YWwgXHBhcg0KPnBhcmFtZXRlciBpcyBhc3Np
Z25lZCBhcyBhbiBpbml0aWFsIHZhbHVlIlxwYXINClxwYXINCj4tICJUaGUgY29tcGlsZXIgZGV2
ZWxvcGVyIGlzIHN0aWxsIGZyZWUgdG8gaW1wbGVtZW50IGVmZmljaWVudCBccGFyDQo+aGFuZGxp
bmcgb2YgcmVjb3JkcyBhbmQgYXJyYXlzIHdoZW4gdXNlZCBhcyBpbnB1dCBwYXJhbWV0ZXJzLiBc
cGFyDQo+QXMgaXMgdGhlIGNhc2UgY3VycmVudGx5LCBzdWNoIHBhcmFtZXRlcnMgZG8gbm90IG5l
ZWQgdG8gYmUgXHBhcg0KPmNvcGllZCB0byB0aGUgc3RhY2sgd2hlbiB0aGUgcHJvY2VkdXJlIGlz
IGludm9rZWQiXHBhcg0KPlxwYXINClxwYXINCkEgbG9jYWwgdmFyaWFibGUgaW4gYSBwcm9jZWR1
cmUgaXMgb25lIHRoYXQgY2Fubm90IGJlIGFjY2Vzc2VkIGZyb20gb3V0c2lkZVxwYXINCnRoYXQg
cHJvY2VkdXJlLiBBIGxvY2FsIHZhcmlhYmxlIGVpdGhlciBoYXMgYW4gdW5kZWZpbmVkIHZhbHVl
IGF0IHRoZSBzdGFydFxwYXINCm9mIHRoZSBwcm9jZWR1cmUgKE9VVCkgb3IgYSBkZWZpbmVkIHZh
bHVlIChkZWZhdWx0LCBJTiBhbmQgVkFSKS4gTm9uZSBvZlxwYXINCnRoaXMgKmRpY3RhdGVzKiBl
eGFjdGx5IGhvdyB0aGlzIHNob3VsZCBoYXBwZW4gaW5zaWRlIHRoZSBjb21waWxlci4gXHBhcg0K
XHBhcg0KPkFueXdheSwgSSB3YW50IHRvIGtub3cgdGhhdCB0aGUgY29tcGlsZXIgd3JpdGVyIGhh
cyBccGFyDQo+aW1wbGVtZW50ZWQgcGFzc2luZyBhIGxhcmdlIElOIGFycmF5IGVmZmljaWVudGx5
LCBub3QganVzdCBiZSBccGFyDQo+YXNzdXJlZCB0aGF0IGhlL3NoZSBpcyBwZXJtaXR0ZWQgdG8g
ZG8gc28uXHBhcg0KPlxwYXINClxwYXINCkkgd291bGQgYXMgd2VsbC4gSSB3b3VsZCBhbHNvIGxp
a2UgdG8ga25vdyB0aGF0IHRoZXkgaGF2ZSBpbXBsZW1lbnRlZCBhIENBU0VccGFyDQpzdGF0ZW1l
bnQgdXNpbmcganVtcHMgcmF0aGVyIHRoYW4gYSBjaGFpbiBvZiBpZi10aGVuLWVsc2VzLCBvciB0
aGF0IHRoZXlccGFyDQpoYXZlIHVzZWQgcmVnaXN0ZXJzIHJhdGhlciB0aGFuIHRoZSBzdGFjayBm
b3IgcGFzc2luZyBwYXJhbWV0ZXJzIGluIGxlYWZccGFyDQpwcm9jZWR1cmVzLCBvciBhbGwgb2Yg
dGhlIG1hbnkgb3RoZXIgd2F5cyB0aGF0IGNvbXBpbGVyIHdyaXRlcnMgY2FuIGRvIHRoZWlyXHBh
cg0Kam9iIHByb3Blcmx5LiBTaG91bGQgYWxsIG9mIHRoZXNlIGltcGxlbWVudGF0aW9uIGRldGFp
bHMgYWxzbyBiZSBzcGVsdCBvdXRccGFyDQppbiB0aGUgbGFuZ3VhZ2Ugc3BlY2lmaWNhdGlvbj8g
XHBhcg0KXHBhcg0KPlxwYXINCj41IC0gVGhlIGJpZ2dlc3QgcXVlc3Rpb24gb2YgYWxsIGlzOiBJ
ZiB3ZSBzdGFydCBhbGxvd2luZyBzb21lIFxwYXINCj5sYW5ndWFnZSBjaGFuZ2VzIHdoZXJlIGRv
IHdlIHN0b3AsIGFuZCBob3cgZG8gd2UgY29udHJvbCB0aGlzP1xwYXINCj5ccGFyDQpccGFyDQpJ
IHNoYXJlIHlvdXIgcmVzZXJ2YXRpb25zIGNvbmNlcm5pbmcgbGFuZ3VhZ2UgY2hhbmdlcy4gSG93
ZXZlciwgSSBzZWUgdGhpc1xwYXINCnByb3Bvc2FsIG1vcmUgYXMgYSByZW1vdmFsIG9mIGFuIGFy
Yml0cmFyeSBpbXBsZW1lbnRhdGlvbi1kcml2ZW4gcmVzdHJpY3Rpb25ccGFyDQpyYXRoZXIgdGhh
biBhIGxhbmd1YWdlIGNoYW5nZS4gXHBhcg0KXHBhcg0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2ss
XHBhcg0KXHBhcg0KUmVnYXJkcyxccGFyDQpDaHJpc1xwYXINClxwYXINCkNocmlzIEJ1cnJvd3Nc
cGFyDQpDRkIgU29mdHdhcmVccGFyDQpodHRwOi8vd3d3LmNmYnNvZnR3YXJlLmNvbS9jcFxwYXIN
ClxwYXINClxwYXINCi0tLS1ccGFyDQpUbyB1bnN1YnNjcmliZSwgc2VuZCBhIG1lc3NhZ2Ugd2l0
aCBib2R5ICJTSUdOT0ZGIEJMQUNLQk9YIiB0byBMSVNUU0VSVkBMSVNUUy5PQkVST04uQ0hcfX0A
IGRl
----boundary-LibPST-iamunique-744001529_-_---

Received on Tue Jan 29 2008 - 00:28:56 UTC