From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,3d6ef988ec3a5ef7
X-Google-Attributes: gid103376,public
From: Chris Morgan <mihalis@ix.netcom.com>
Subject: Re: renaming Interfaces.Java.Ada_To_Java_String to the + operator
Date: 1998/01/11
Message-ID: <87u3bah4k1.fsf@ix.netcom.com>#1/1
X-Deja-AN: 315021702
Sender: cm@mihalis
References: <01bd1e34$1632c2c0$24326489@Westley-PC.calspan.com>
 <dewar.884489205@merv> <871zyej2sg.fsf@ix.netcom.com> <dewar.884531217@merv>
 <87vhvqhisy.fsf@ix.netcom.com> <dewar.884542283@merv>
Organization: Linux Hackers Unlimited
X-NETCOM-Date: Sun Jan 11  3:18:55 PM CST 1998
Newsgroups: comp.lang.ada
Date: 1998-01-11T15:18:55-06:00
List-Id: <comp.lang.ada>


dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> That's a very legitimate concern and indeed is one of the major arguments
> in favor of thin bindings. However, it is still reasonable to worry
> about execution time efficiency! (I don't understand your comment about
> compilation time here, I don't see that as an issue at all).

For some reason your mention of quadratic time made me think of
parsing the line of code I gave (no idea what order parsing actually
would be) but I did mention efficiency as well by which I meant the
run-time behaviour - I am aware for instance that 

text_io.put(a & b & c .... );

used to be very unpleasantly slow with at least one Ada83 compiler.

> 
> From my point of view
> 
>    (a,b,c,d,e,f,g)
> 
> is as reasonable translation of
> 
>    a,b,c,d,e,f,g
> 
> as
> 
>    a & b & c & d & e & f & g
> 
> actually, I think it is MORE reasonable. Now of course we can have & take
> care of the conversions if they are needed automatically, in which case
> the fair comparison is with
> 
>    (+a,+c,+c,+d,+e,+f,+g)
> 
> but still that's fairly reasonable, and I don't think any of these
> conventions will intefere with inter-lobel transfer of knowledge.


I think all those would be fine. I was just saying it was nice that
someone had offered something to allow an approximation of the varargs
C functions rather than the previous approach of saying "sorry, Ada
doesn't do varargs so you will have to use the non-varargs versions
instead" which wouldn't have fitted in with my accustomed style of
Motif programming.

Chris



-- 
Chris Morgan <mihalis at ix.netcom.com>
     "I'm considering throwing myself out of the window.  It
      wouldn't do me much damage because we're on the ground 
      floor, but it might make for a bit of variety."  - Lizzy Bryant