From colket@smtp-gw.spawar.navy.mil Thu Jul 24 01:14:55 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id BAA10608; Thu, 24 Jul 1997 01:14:54 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA17740; Thu, 24 Jul 97 01:13:01 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id BAA3481778; Thu, 24 Jul 1997 01:11:29 -0400 Received: from opal.spawar.navy.mil by sw-eng.falls-church.va.us (8.7.1/) id FAA21671; Thu, 24 Jul 1997 05:08:37 GMT Received: from smtp-gw.spawar.navy.mil by opal.spawar.navy.mil (5.x/SMI-SVR4) id AA10676; Thu, 24 Jul 1997 01:01:30 -0400 Received: from ccMail by smtp-gw.spawar.navy.mil (IMA Internet Exchange 1.04b) id 3d6de840; Thu, 24 Jul 97 00:48:04 -0400 Mime-Version: 1.0 Date: Wed, 23 Jul 1997 18:24:01 -0400 Message-Id: <3d6de840@smtp-gw.spawar.navy.mil> From: colket@smtp-gw.spawar.navy.mil (Currie Colket) Subject: Re[3]: Restart of String/Wide_String Discussion [for 2.0.N] To: asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su, colket@smtp-gw.spawar.navy.mil (Currie Colket) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Length: 2396 Status: OR Dear asis-technical, About a month ago, I sent out an email asking is anyone had an ASIS application where there would be a projected *serious* performance penalty should Wide_Strings be used exclusively? I have not received any replies. This implies that the ASIS specification can be simplified by eliminating the duplicated String / Wide_String interfaces by using Wide_String exclusively. Robert Dewar said it nicely => > Actually I must say that ASIS is rather a nice application of > wide character, and makes me pleased that we insisted that this > go in the core. The reason for this insistence was primarily the > very reasonable demand from the Japanese delegation that wide > character be a first class citizen in all respects, but here with > the ASIS interface, we see the advantage of having made this support > universal. Thus, the proposal is to change the disposition of Issue I#064 to reflect that ASIS will exclusively use Wide_String throughout the ASIS interface. If there are objections, please send email to asis-technical by 6 August. Thank you all for a very interesting discussion. v/r Currie ______________________________ Reply Separator _________________________________ Subject: Re[2]: Restart of String/Wide_String Discussion [for 2.0.N] Author: colket@smtp-gw.spawar.navy.mil (Currie Colket) at SMTP-GW Date: 6/25/97 5:48 PM Dear asis-technical, Vasiliy has raised an interesting point: > Am I right in assuming that no ASIS application will > use massive operations with ASIS queries that use strings > (of any sort)? It seems that most of the work goes on the > Element level, and we only need Element images when the > job is actually done and we are generating some output. > If so (and it seems like that), the problem of perfomance > is of less importance than compatibility. This is my understanding as well. If this is the case, then any performance impact could easily be counterbalanced by the extra processing to ascertain whether Wide_String or regular String processing should take place. This begs the question => Is there anyone who has an ASIS application where there would be a projected *serious* performance penalty should Wide_Strings be used exclusively? If so, then the performance issue could be important; otherwise it is simply academic. Discussion?? v/r Currie From dewar@gnat.com Thu Jul 24 09:12:36 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id JAA11047; Thu, 24 Jul 1997 09:12:36 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA21547; Thu, 24 Jul 97 09:12:49 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id JAA1370114; Thu, 24 Jul 1997 09:11:18 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id NAA00633; Thu, 24 Jul 1997 13:09:20 GMT Received: by nile.gnat.com (5.0/1.20) id AA25916; Thu, 24 Jul 97 09:11:17 EDT Date: Thu, 24 Jul 97 09:11:17 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9707241311.AA25916@nile.gnat.com> To: asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, fofanov@such.srcc.msu.su Subject: Re: Re[3]: Restart of String/Wide_String Discussion [for 2.0.N] Content-Length: 439 Status: OR for documentation purposes in the ASIS interface, where Wide_Character and Wide_String are used to represent elements in the souce program, it would probably help the reader to introduce: subtype Source_Text_Character is Wide_Character; subtype Source_Text_String is Wide_String; and use these synonyms where appropriate. i would not make them derived types, because then you can't use the standard string packages, and that is a pain. From rybin@possum.srcc.msu.su Thu Jul 24 13:24:25 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id NAA11792; Thu, 24 Jul 1997 13:24:25 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA27838; Thu, 24 Jul 97 13:24:34 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id NAA3011572; Thu, 24 Jul 1997 13:21:54 -0400 Received: from crocus.gamma.ru by sw-eng.falls-church.va.us (8.7.1/) id RAA06966; Thu, 24 Jul 1997 17:19:37 GMT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id VAA18376; Thu, 24 Jul 1997 21:22:39 +0400 (MSD) Received: by gamma.srcc.msu.su; Thu, 24 Jul 1997 21:21:15 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Thu, 24 Jul 1997 21:19:05 +0400 To: asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, fofanov@such.srcc.msu.su References: <9707241311.AA25916@nile.gnat.com> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Thu, 24 Jul 97 21:19:05 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: Re[3]: Restart of String/Wide_String Discussion [for 2.0.N] Lines: 26 Content-Length: 927 Status: OR I completely agree with both Robert's points: > for documentation purposes in the ASIS interface, where Wide_Character > and Wide_String are used to represent elements in the souce program, it > would probably help the reader to introduce: > > subtype Source_Text_Character is Wide_Character; > subtype Source_Text_String is Wide_String; > > and use these synonyms where appropriate. > > i would not make them derived types, because then you can't use the standard > string packages, and that is a pain. It would be very useful indeed to be able to use in the ASIS applications standard string handling packages, in particular, it would easily allow to adjust old String-based applications to Wide_String-only ASIS by applying standard String <-> Wide_String conversions. That's why deriving from Wide_String or making it a private type would only add problems with no real benefit from it. Sergey Rybin From sblake@sd.aonix.com Thu Jul 24 14:12:43 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id OAA11895; Thu, 24 Jul 1997 14:12:42 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA28935; Thu, 24 Jul 97 14:12:58 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id OAA3486898; Thu, 24 Jul 1997 14:11:03 -0400 Received: from gw.alsys.com by sw-eng.falls-church.va.us (8.7.1/) id SAA07952; Thu, 24 Jul 1997 18:09:14 GMT Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.alsys.com (4.1/SMI-4.1.1) id AA27860; Thu, 24 Jul 97 11:10:31 PDT Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA22375; Thu, 24 Jul 97 11:10:54 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id LAA03537; Thu, 24 Jul 1997 11:10:53 -0700 Date: Thu, 24 Jul 1997 11:10:53 -0700 From: sblake@sd.aonix.com (Steve Blake @pulsar) Message-Id: <199707241810.LAA03537@puumba.telesoft> To: asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, fofanov@such.srcc.msu.su, rybin@possum.srcc.msu.su Subject: Re: Re[3]: Restart of String/Wide_String Discussion [for 2.0.N] Content-Length: 787 Status: OR I agree this is a good idea. I wonder if it would be enough to just call them: subtype Text_Character is Wide_Character; subtype Text_String is Wide_String; simply to avoid the non-ARM term "source" and avoid possible confusion with the notion of source-based vs library-based implementations. Steve > for documentation purposes in the ASIS interface, where Wide_Character > and Wide_String are used to represent elements in the souce program, it > would probably help the reader to introduce: > > subtype Source_Text_Character is Wide_Character; > subtype Source_Text_String is Wide_String; > > and use these synonyms where appropriate. > > i would not make them derived types, because then you can't use the standard > string packages, and that is a pain. From dewar@gnat.com Thu Jul 24 15:29:53 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA12131; Thu, 24 Jul 1997 15:29:52 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA00644; Thu, 24 Jul 97 15:29:49 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id PAA3284180; Thu, 24 Jul 1997 15:28:08 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id TAA09693; Thu, 24 Jul 1997 19:25:49 GMT Received: by nile.gnat.com (5.0/1.20) id AA17437; Thu, 24 Jul 97 15:27:41 EDT Date: Thu, 24 Jul 97 15:27:41 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9707241927.AA17437@nile.gnat.com> To: asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, fofanov@such.srcc.msu.su, rybin@possum.srcc.msu.su, sblake@sd.aonix.com Subject: Re: Re[3]: Restart of String/Wide_String Discussion [for 2.0.N] Content-Length: 513 Status: OR << subtype Text_Character is Wide_Character; subtype Text_String is Wide_String; simply to avoid the non-ARM term "source" and avoid possible confusion with the notion of source-based vs library-based implementations. >> Good point (confusion on source) but on the other hand, Text seems to general, so let's be very RM and say subtype Program_Text_Character is Wide_Character; subtype Program_Text_String is Wide_String; if people find these names too long, I would omit Text before I omitted Program. From sblake@sd.aonix.com Thu Jul 24 16:45:24 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id QAA12426; Thu, 24 Jul 1997 16:45:24 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA02867; Thu, 24 Jul 97 16:45:43 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id QAA2645806; Thu, 24 Jul 1997 16:44:04 -0400 Received: from gw.alsys.com by sw-eng.falls-church.va.us (8.7.1/) id UAA11308; Thu, 24 Jul 1997 20:42:08 GMT Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.alsys.com (4.1/SMI-4.1.1) id AA04017; Thu, 24 Jul 97 13:43:26 PDT Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA26654; Thu, 24 Jul 97 13:43:49 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id NAA12737; Thu, 24 Jul 1997 13:43:47 -0700 Date: Thu, 24 Jul 1997 13:43:47 -0700 From: sblake@sd.aonix.com (Steve Blake @pulsar) Message-Id: <199707242043.NAA12737@puumba.telesoft> To: asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, fofanov@such.srcc.msu.su, rybin@possum.srcc.msu.su, sblake@sd.aonix.com Subject: Re: Re[3]: Restart of String/Wide_String Discussion [for 2.0.N] Content-Length: 171 Status: OR I like it. The names are perfectly clear and the length is fine. >subtype Program_Text_Character is Wide_Character; >subtype Program_Text_String is Wide_String; Steve From colket@smtp-gw.spawar.navy.mil Thu Jul 24 17:36:13 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA12513; Thu, 24 Jul 1997 17:36:13 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA03974; Thu, 24 Jul 97 17:36:33 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id RAA3486358; Thu, 24 Jul 1997 17:34:59 -0400 Received: from opal.spawar.navy.mil by sw-eng.falls-church.va.us (8.7.1/) id VAA12347; Thu, 24 Jul 1997 21:33:04 GMT Received: from smtp-gw.spawar.navy.mil by opal.spawar.navy.mil (5.x/SMI-SVR4) id AA06376; Thu, 24 Jul 1997 17:26:00 -0400 Received: from ccMail by smtp-gw.spawar.navy.mil (IMA Internet Exchange 1.04b) id 3d7c5e40; Thu, 24 Jul 97 17:15:16 -0400 Mime-Version: 1.0 Date: Thu, 24 Jul 1997 17:32:22 -0400 Message-Id: <3d7c5e40@smtp-gw.spawar.navy.mil> From: colket@smtp-gw.spawar.navy.mil (Currie Colket) Subject: Re[5]: Restart of String/Wide_String Discussion [for 2.0 To: asis-technical@sw-eng.falls-church.va.us, dewar@gnat.com, fofanov@such.srcc.msu.su, rybin@possum.srcc.msu.su, sblake@sd.aonix.com, sblake@sd.aonix.com (Steve Blake @pulsar) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Length: 418 Status: OR Robert and Steve are suggesting: >subtype Program_Text_Character is Wide_Character; >subtype Program_Text_String is Wide_String; Character is not an issue as we currently have no calls having character parameters. Consequently we do not need to differentiate between Character and String. How about: subtype Program_Text is Wide_String; or even subtype Source_Code is Wide_String; v/r Currie From dewar@gnat.com Thu Jul 24 17:37:32 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA12518; Thu, 24 Jul 1997 17:37:31 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA03992; Thu, 24 Jul 97 17:37:52 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id RAA3461184; Thu, 24 Jul 1997 17:36:14 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id VAA12376; Thu, 24 Jul 1997 21:34:26 GMT Received: by nile.gnat.com (5.0/1.20) id AA06661; Thu, 24 Jul 97 17:36:24 EDT Date: Thu, 24 Jul 97 17:36:24 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9707242136.AA06661@nile.gnat.com> To: asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, fofanov@such.srcc.msu.su, rybin@possum.srcc.msu.su, sblake@sd.aonix.com Subject: Re: Re[5]: Restart of String/Wide_String Discussion [for 2.0 Content-Length: 309 Status: OR <> I prefer Program Text to Source Code. The former is an RM term, the latter is not, and someone already pointed out the potential confusion with "source" as in "source based compilation" ... From roby Fri Sep 19 11:06:34 1997 Return-Path: Received: by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id LAA03137; Fri, 19 Sep 1997 11:06:33 -0400 From: roby (Clyde Roby) Message-Id: <199709191506.LAA03137@cronus.csed.ida.org> Subject: Wide_String and Program_Text resolution To: ASIS-Technical@SW-Eng.Falls-Church.Va.US (ASIS-Technical) Date: Fri, 19 Sep 1997 11:06:33 -0400 (EDT) Cc: roby (me) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3259 Status: OR All, As Currie said in his announcement concerning the CD status of ASIS 2.0.P., the resolution of Issue #064 for Ada Wide_Character and Wide_String was: > 3. Resolution for Issue #064 for Ada Wide_Character and > Wide_String. Based on the email traffic on the discussion > of this issue, the following was done: > > Commentary in Section 3 was changed to read: > > "The ASIS interface uses string parameters for many > procedure and function calls. Wide_String is used to > convey ASIS environment information. Program_Text, a > subtype of Wide_String is used to convey program text. > The type String is not used in the ASIS interface. > Neither the Ada types Character nor Wide_Character are > used in the ASIS interface." > > A new subtype was added: > > subtype Program_Text is Wide_String; > > Program_Text was defined in Section 3.14 so as not to cause > a renumbering of sections. This is also a good logical place > for Program_Text as the subtype is closely associated with > Package Asis.Text, numbered as Clause 20 towards the end. > > All the overloading between the previous String and > Wide_String subprograms has been eliminated. Clyde will > provide a list of specific procedures and functions > using Wide_String and Program_Text in the > resolution of Issue #064 when it gets updated. The following functions and parameters now use Wide_String as types of their parameters or return values: 6.1 function ASIS_Version 6.2 function ASIS_Implementor 6.3 function ASIS_Implementor_Version 6.4 function ASIS_Implementor_Information 6.6 procedure Initialize 6.8 procedure Finalize 6.10 function Diagnosis 6.11 procedure Set_Status 8.1 function Default_Name 8.2 function Default_Parameters 8.3 procedure Associate 8.12 function Name 8.13 function Parameters 8.14 function Debug_Image 9.10 function Name 10.6 function Library_Unit_Declaration 10.7 function Compilation_Unit_Body 10.19 function Unit_Full_Name 10.20 function Unique_Name 10.24 function Text_Name 10.25 function Text_Form 10.26 function Object_Name 10.27 function Object_Form 10.28 function Compilation_Command_Line_Options 10.29 function Has_Attribute 10.30 function Attribute_Value_Delimiter 10.31 function Attribute_Values 10.34 function Debug_Image 11.4 function Attribute_Time 13.41 function Debug_Image 15.4 function Representation_Value_Image 17.2 function Value_Image 20.22 function Delimiter_Image 20.28 function Debug_Image 21.9 function Debug_Image The following functions and parameters now use Program_Text as types of their parameters or return values: 13.39 function Pragma_Name_Image 15.2 function Defining_Name_Image 15.2 function Position_Number_Image 17.3 function Name_Image 20.23 function Element_Image 20.24 function Line_Image 20.25 function Non_Comment_Image 20.26 function Comment_Image > The Editorial and Technical Comment lists do not currently > reflect these changes, but will soon after Clyde has time > to catch up on all the other work he has put aside to produce > ASIS Version 20p. ... I will do my best to get these updated soon (but probably not before the end of September), including updating Issue #064 with information contained in this message. Clyde From rybin@possum.srcc.msu.su Mon May 26 15:10:32 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA08661; Mon, 26 May 1997 15:10:32 -0400 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA17693; Mon, 26 May 97 15:11:12 EDT Received: from crocus.gamma.ru by sw-eng.falls-church.va.us (8.7.1/) id TAA27506; Mon, 26 May 1997 19:04:19 GMT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id XAA13388 for asis-officers@sw-eng.falls-church.va.us; Mon, 26 May 1997 23:07:00 +0400 (MSD) Received: by gamma.srcc.msu.su; Mon, 26 May 1997 23:06:28 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Mon, 26 May 1997 23:05:28 +0400 To: asis-officers@sw-eng.falls-church.va.us Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Mon, 26 May 97 23:05:28 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: String/Wide_String problem (?) Lines: 32 Content-Length: 1261 Status: OR May be, it is not too late... Having finishing migrating to ASIS 2.0.M for GNAT, I've started to recompile my test applications. And I've realised the terrible consequence of having String/Wide_String pairs for *each* query having a string parameter - all the calls to Initialize, Associate and Finalize become ambiguous!!! So, now there is no way to write in an application code something like Initialize ("Debug_Mode"); Associate (My_Context, "./test_dir"); etc, and no full naming can help - we have overloaded queries with string parameters, and any call with any *string constant* will be ambiguous. I'm afraid, this price to pay for the "systematic" approach to String/Wide_String problem is too high. How do you like this: Initialize (String'("Debug_Mode")); Associate (My_Context, String'("./test_dir")); Of course, may be I'm suffering from the "first impact emotions". Of course, explicitly declared String (or Wide_String, if needed) constants for initializing an ASIS implementation and associating a Context give a solution (and, even more, may be, they also enforse better style), and constructions like String'("some initialization/association information") is not really terrible, but what do you think about this problem? Sergey From rybin@possum.srcc.msu.su Mon May 26 15:25:13 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA08675; Mon, 26 May 1997 15:25:13 -0400 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA17795; Mon, 26 May 97 15:25:53 EDT Received: from crocus.gamma.ru by sw-eng.falls-church.va.us (8.7.1/) id TAA27705; Mon, 26 May 1997 19:15:45 GMT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id XAA13497 for asis-officers@sw-eng.falls-church.va.us; Mon, 26 May 1997 23:18:43 +0400 (MSD) Received: by gamma.srcc.msu.su; Mon, 26 May 1997 23:18:09 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Mon, 26 May 1997 23:16:40 +0400 To: asis-officers@sw-eng.falls-church.va.us References: Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Mon, 26 May 97 23:16:40 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: P.S: String/Wide_String problem (?) Lines: 35 Content-Length: 1235 Status: OR P.S. to my previous message: > Initialize ("Debug_Mode"); > Associate (My_Context, "./test_dir"); > > etc, and no full naming can help - we have overloaded queries with string > parameters, and any call with any *string constant* will be > ambiguous. I'm afraid, this price to pay for the "systematic" approach > to String/Wide_String problem is too high. How do you like this: > > Initialize (String'("Debug_Mode")); > Associate (My_Context, String'("./test_dir")); > > Of course, may be I'm suffering from the "first impact emotions". Of course, > explicitly declared String (or Wide_String, if needed) constants for > initializing an ASIS implementation and associating a Context give a solution > (and, even more, may be, they also enforse better style), and constructions > like > > String'("some initialization/association information") > > is not really terrible, but what do you think about this problem? But now it is also impossible to use Initialize and Finalize *without* an explicit actual parameter, that is simply as Initialize; ..... Finalize; And this really looks strange - why do these queries have default parameters, if it is impossible to use them? Sergey From rybin@possum.srcc.msu.su Mon May 26 16:10:43 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id QAA08694; Mon, 26 May 1997 16:10:43 -0400 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA18011; Mon, 26 May 97 16:11:22 EDT Received: from crocus.gamma.ru by sw-eng.falls-church.va.us (8.7.1/) id TAA28238; Mon, 26 May 1997 19:44:10 GMT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id XAA13987 for asis-officers@sw-eng.falls-church.va.us; Mon, 26 May 1997 23:47:01 +0400 (MSD) Received: by gamma.srcc.msu.su; Mon, 26 May 1997 23:46:44 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Mon, 26 May 1997 23:30:33 +0400 To: asis-officers@sw-eng.falls-church.va.us Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Mon, 26 May 97 23:30:33 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: String/Wide_String problem - a suggestion Lines: 37 Content-Length: 1319 Status: OR The more I'm recompiling my applications for 2.0.M, the more I hate these pairs of String/Wide_String queries. And now I definitely have a suggestion to use *DIFFERENT* names for these queries instead of having pairs of *OVERLOADED* queries (just one more example: in 2.0.M it's impossible to write: if Defining_Name_Image (Some_Element) = "Hello_World" then but you have to write if Defining_Name_Image (Some_Element) = String'("Hello_World") then I am really afraid, that these pairs will make a lot of confusions and a lot of pain for application developers). The first thing I would definitely suggest is to use Xxx_Image as the names of queries returning *String* images of something, and Xxx_Wide_Image as the names of queries returning *Wide_String* images. (And it will be completely in Ada style, will not it?). Just the same for Diagnosis (Wide_Diagnosis) Initialize and Finalize makes a problem - now I do not have any good idea for a pair of names for Initialize (Wide_Initialize looks a bit crazy). But now I think we need a general solution: - does it really make a problem for applications - should we replace the pairs of *OVERLOADED* queries with String/Wide_String in parameter-result profiles with pairs of queries with *DISTINCT* names. I think, both answers are *YES* Sergey From dewar@gnat.com Mon May 26 17:38:35 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA08723; Mon, 26 May 1997 17:38:34 -0400 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA18440; Mon, 26 May 97 17:39:13 EDT Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id VAA00089; Mon, 26 May 1997 21:29:08 GMT Received: by nile.gnat.com (5.0/1.20) id AA08253; Mon, 26 May 97 17:30:11 EDT Date: Mon, 26 May 97 17:30:11 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705262130.AA08253@nile.gnat.com> To: asis-officers@sw-eng.falls-church.va.us, rybin@possum.srcc.msu.su Subject: Re: String/Wide_String problem (?) Content-Length: 259 Status: OR what a mistake (this overloading), it will be a huge pain in the neck. You can make it a little easier by defining function "+"(S : String) return String is begin return S; end; so that you can write Initialize(+"Debug_Mode"); but this is still a pain. From dewar@gnat.com Mon May 26 18:10:30 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id SAA08750; Mon, 26 May 1997 18:10:30 -0400 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA18634; Mon, 26 May 97 18:11:10 EDT Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id VAA00284; Mon, 26 May 1997 21:36:19 GMT Received: by nile.gnat.com (5.0/1.20) id AA08444; Mon, 26 May 97 17:37:22 EDT Date: Mon, 26 May 97 17:37:22 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705262137.AA08444@nile.gnat.com> To: asis-officers@sw-eng.falls-church.va.us, rybin@possum.srcc.msu.su Subject: Re: String/Wide_String problem - a suggestion Content-Length: 139 Status: OR note that the RM carefully avoided this mistake, I am surprised no one noticed it, but it is certainly something that should be corrected. From colket@smtp-gw.spawar.navy.mil Tue May 27 11:27:02 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id LAA09430; Tue, 27 May 1997 11:27:02 -0400 Received: from opal.spawar.navy.mil by ida.org (4.1/SMI-4.1) id AA28023; Tue, 27 May 97 11:27:38 EDT Received: from smtp-gw.spawar.navy.mil by opal.spawar.navy.mil (5.x/SMI-SVR4) id AA18360; Tue, 27 May 1997 11:17:33 -0400 Received: from ccMail by smtp-gw.spawar.navy.mil (IMA Internet Exchange 1.04b) id 38afce80; Tue, 27 May 97 11:25:28 -0400 Mime-Version: 1.0 Date: Tue, 27 May 1997 11:24:17 -0400 Message-Id: <38afce80@smtp-gw.spawar.navy.mil> From: colket@smtp-gw.spawar.navy.mil (Currie Colket) Subject: Re: String/Wide_String problem : NEED INPUT ASAP To: "Sergey I. Rybin" , "ASIS Technical" , "Clyde Roby" , colket@smtp-gw.spawar.navy.mil (Currie Colket) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Length: 5633 Status: OR Dear asis-technical, Sergey wrote => > The more I'm recompiling my applications for 2.0.M, the more > I hate these pairs of String/Wide_String queries. > And now I definitely have a suggestion to use *DIFFERENT* names > for these queries instead of having pairs of *OVERLOADED* queries > (just one more example: in 2.0.M it's impossible to write: > > if Defining_Name_Image (Some_Element) = "Hello_World" ... > > but you have to write > > if Defining_Name_Image (Some_Element) = String'("Hello_World") ... > > I am really afraid, that these pairs will make a lot of confusions > and a lot of pain for application developers). > > The first thing I would definitely suggest is to use > Xxx_Image as the names of queries returning *String* images > of something, and Xxx_Wide_Image as the names of queries returning > *Wide_String* images. (And it will be completely in Ada style, will > not it?). Just the same for Diagnosis (Wide_Diagnosis) > Initialize and Finalize makes a problem - now I do not have any > good idea for a pair of names for Initialize (Wide_Initialize looks > a bit crazy). > But now I think we need a general solution: > - does it really make a problem for applications > - should we replace the pairs of *OVERLOADED* queries with > String/Wide_String in parameter-result profiles with pairs > of queries with *DISTINCT* names. > I think, both answers are *YES* We need to agree on an approach for addressing the Wide_String issue soon. Clyde and I are planning to finalize ASIS 2.0.N tomorrow (Wednesday, 28 May). Our options for resolution are many. The major options are as follows: 1. Status quo => Use the overloaded procedure and function calls as currently in ASIS Version 2.0.m. and live with the problem. Every call having a String parameter, an overloaded call having a Wide_String parameter was provided. FYI, The following note was placed in Clause 3, (2.0.m) (with reformatting for email): -- The ASIS interface uses both Ada strings and wide strings -- as parameters to many function and procedure calls. -- Overloaded function and procedure calls are provided -- for each situation. The context of a function call will -- differentiate returned values of String or Wide_String. -- However, where procedure or function calls pass String or -- Wide_String as an argument, an object of that type should -- be created, such as: -- -- My_String : String; -- My_Wide_String : Wide_String; -- -- My_String := "My String"; -- My_Wide_String := "My Wide String"; -- -- Alternatively, the call can qualify a literal argument -- using the: -- -- String'("My String") or Wide_String'("My Wide String") -- -- Otherwise, the application does not compile as the -- overloaded calls are ambiguous. 2. Status quo with elimination of Wide_String defaults - The elimination of Wide_String defaults for procedures such as Initialize would eliminate the ambiguity problem for null parameters. 3. Provide separate procedures/functions for Wide_String - Instead of having overloaded procedures, rename each from XXX to XXX_Wide. This would eliminate the problem stated by Sergey, but might not be viewed as elegant as the status quo with other options. [Note: Sergey suggested we use XXX and Wide_XXX. It might be better to use XXX and XXX_Wide for indexing purposes.] 4. Provide "+"/"-" String/Wide/String functions - As Robert Dewar suggested, the problem can be mitigated by defining: function "+"(S : String) return String is begin return S; end; and function "-"(W : Wide_String) return Wide_String is begin return W; end; this would allow one to write: Initialize(+"Debug_Mode"); or Initialize(-"Debug_Mode"); As noted by Robert Dewar, "this is still a pain." Also it does not eliminate the default parameter problem where one might simply want to say: Initialize; This option could easily be implemented by the user. Hence should it be provided in ASIS, it would simply facilitate the use of String/Wide_String. 5. Provide mirror ASIS packages for String and Wide_String - Provide for an implementor to provide an Asis package and an Asis_Wide package. The Asis package would have no Wide_String parameters; the Asis_Wide package would have no String parameters. This approach is also not very elegant and limits tools using both String and Wide_String. 6. Combination of 1,3, and 4 above - Maintain overloading for most of ASIS, providing XXX_Wide names for procedures/functions where: a. default String/Wide_String parameters are possible; b. functions are likely to be used in a print statement, for example: XXX_Image and XXX_Image_Wide; c. procedures/functions are commonly used; This could eliminate the most common ambiguity problems using String and Wide_String. Although appealing, this option might be confusing as an ASIS user is presented with alternative options. 7. Combination of 2 and 4 above - Eliminate ambiguous Wide_String defaults and provide "+"/"-" functions for String/Wide_String disambiguation. Responses by Wednesday morning (28 May) are needed. Should you have a preference on any of the options above, please provide ASAP. Other combinations are possible, and will be considered. Please send responses to asis-officers@sw-eng.falls-church.va.us Thank you!!! v/r Currie Colket Chair ASISWG/Chair ASISRG +1 (703) 602-1483 From rybin@possum.srcc.msu.su Tue May 27 17:09:31 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA10882; Tue, 27 May 1997 17:09:30 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA05244; Tue, 27 May 97 17:10:10 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id RAA2085122 for ; Tue, 27 May 1997 17:07:46 -0400 Received: from crocus.gamma.ru by sw-eng.falls-church.va.us (8.7.1/) id VAA27559; Tue, 27 May 1997 21:06:27 GMT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id BAA00695; Wed, 28 May 1997 01:09:04 +0400 (MSD) Received: by gamma.srcc.msu.su; Wed, 28 May 1997 01:08:00 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Wed, 28 May 1997 00:49:28 +0400 To: asis-officers@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil Cc: Alain.LeGuennec@enst-bretagne.fr References: <38afce80@smtp-gw.spawar.navy.mil> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Wed, 28 May 97 00:49:28 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: String/Wide_String problem : NEED INPUT ASAP Lines: 155 Content-Length: 6384 Status: OR > We need to agree on an approach for addressing the Wide_String issue > soon. Clyde and I are planning to finalize ASIS 2.0.N tomorrow > (Wednesday, 28 May). > > Our options for resolution are many. The major options are as follows: > > 1. Status quo => Use the overloaded procedure and function calls > as currently in ASIS Version 2.0.m. and live with the problem. Every > call having a String parameter, an overloaded call having a > Wide_String parameter was provided. I do understand the main advantege of #1 - avoiding last minute changes, but I am really afraid to face some comments like mine coming from "outside" on the latest step of reviewing of ASIS drafts. And I am almost sure, that application programmers will not like this problem at all. > FYI, The following note was placed in Clause 3, (2.0.m) (with > reformatting for email): > > -- The ASIS interface uses both Ada strings and wide strings > -- as parameters to many function and procedure calls. > -- Overloaded function and procedure calls are provided > -- for each situation. The context of a function call will > -- differentiate returned values of String or Wide_String. > -- However, where procedure or function calls pass String or > -- Wide_String as an argument, an object of that type should > -- be created, such as: > -- > -- My_String : String; > -- My_Wide_String : Wide_String; > -- > -- My_String := "My String"; > -- My_Wide_String := "My Wide String"; > -- > -- Alternatively, the call can qualify a literal argument > -- using the: > -- > -- String'("My String") or Wide_String'("My Wide String") > -- > -- Otherwise, the application does not compile as the > -- overloaded calls are ambiguous. This is formally correct, but does it help for *practical* programming? > > 2. Status quo with elimination of Wide_String defaults - The > elimination of Wide_String defaults for procedures such as Initialize > would eliminate the ambiguity problem for null parameters. Only a small "cosmetic repair" (does this term really exist in technical English? :), comparing with #1 > 3. Provide separate procedures/functions for Wide_String - Instead of > having overloaded procedures, rename each from XXX to XXX_Wide. This > would eliminate the problem stated by Sergey, but might not be viewed > as elegant as the status quo with other options. > > [Note: Sergey suggested we use XXX and Wide_XXX. It might be better to > use XXX and XXX_Wide for indexing purposes.] First, I agree, that XXX_Wide is better, then Wide_XXX. Second, it completely eliminate the problem, and it is the best approach from the KISS (keep it simple, stupid) principle - no new package, no mirrors. Everything is almost the same, only a dozen (or a couple of dozens :) of new queries with specific names for specific purposes. I still think, that Wide_String for Initialize is somewhat specific, and for all the queries returning images the query name as "Element_Image_Wide" is quite natural, and it perfectly reflects the very nature of the query. Third, it looks like the best (that is, the simplest, the easiest to do and the most reliable) solution for the last minute change, if we agree to make the change. > 4. Provide "+"/"-" String/Wide/String functions - As Robert Dewar > suggested, the problem can be mitigated by defining: > > function "+"(S : String) return String is > begin > return S; > end; > > and > function "-"(W : Wide_String) return Wide_String is > begin > return W; > end; > > this would allow one to write: > > Initialize(+"Debug_Mode"); > or Initialize(-"Debug_Mode"); > > As noted by Robert Dewar, "this is still a pain." Also it does not > eliminate the default parameter problem where one might simply want to > say: > Initialize; > > This option could easily be implemented by the user. Hence should it > be provided in ASIS, it would simply facilitate the use of > String/Wide_String. I would say, that this is the way to migrate from ASIS to C++ ;-) This solves the problem, but what a nice source code will we get in every ASIS application! > 5. Provide mirror ASIS packages for String and Wide_String - Provide > for an implementor to provide an Asis package and an Asis_Wide > package. The Asis package would have no Wide_String parameters; the > Asis_Wide package would have no String parameters. This approach is > also not very elegant and limits tools using both String and > Wide_String. Too complicated, too many changes, too heavy. > 6. Combination of 1,3, and 4 above - Maintain overloading for most of > ASIS, providing XXX_Wide names for procedures/functions where: > > a. default String/Wide_String parameters are possible; > b. functions are likely to be used in a print statement, > for example: XXX_Image and XXX_Image_Wide; > c. procedures/functions are commonly used; > > This could eliminate the most common ambiguity problems using String > and Wide_String. Although appealing, this option might be confusing as > an ASIS user is presented with alternative options. Does not correspond to the KISS principle, and I cannot see, why it may be better, then #3 without any combinations. > 7. Combination of 2 and 4 above - Eliminate ambiguous Wide_String > defaults and provide "+"/"-" functions for String/Wide_String > disambiguation. > > Responses by Wednesday morning (28 May) are needed. Should you have a > preference on any of the options above, please provide ASAP. Other > combinations are possible, and will be considered. "Improved" C++ approach. So, I vote for #3. Sergey. P.S. Sorry for this delay - I planed to migrate to 2.0.M more then a month ago. If I would have done this, I would face this problem much eatlier and we would have enough time to discuss the issue. But, you know, Merphy laws work well in every area :((( P.P.S I'm sending this message as "Cc:" also to Alain - now he is in a very good shape as an ASIS application developer, and I would like to know his opinion From roby Tue May 27 17:18:24 1997 Return-Path: Received: by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA10899; Tue, 27 May 1997 17:18:22 -0400 From: roby (Clyde Roby) Message-Id: <199705272118.RAA10899@cronus.csed.ida.org> Subject: Re: String/Wide_String problem : NEED INPUT ASAP To: ASIS-Officers@SW-Eng.Falls-Church.Va.US (asis-officers) Date: Tue, 27 May 1997 17:18:21 -0400 (EDT) Cc: roby (me), Colket@SMTP-GW.SPAWAR.Navy.Mil (Currie Colket), rybin@alex.srcc.msu.su (Rybin), ASIS-Technical@SW-Eng.Falls-Church.Va.US (asis-technical) In-Reply-To: <38afce80@smtp-gw.spawar.navy.mil> from "Currie Colket" at May 27, 97 11:24:17 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5663 Status: OR Currie replied to Sergey: > We need to agree on an approach for addressing the Wide_String issue > soon. Clyde and I are planning to finalize ASIS 2.0.N tomorrow > (Wednesday, 28 May). > > Our options for resolution are many. The major options are as follows: My FIRST choice is #7 (which includes both #2 and #4). My SECOND choice is #1. In my opinion, NONE of #3, #5, or #6 should be done! > 1. Status quo => Use the overloaded procedure and function calls > as currently in ASIS Version 2.0.m. and live with the problem. Every > call having a String parameter, an overloaded call having a > Wide_String parameter was provided. > > FYI, The following note was placed in Clause 3, (2.0.m) (with > reformatting for email): > > -- The ASIS interface uses both Ada strings and wide strings > -- as parameters to many function and procedure calls. > -- Overloaded function and procedure calls are provided > -- for each situation. The context of a function call will > -- differentiate returned values of String or Wide_String. > -- However, where procedure or function calls pass String or > -- Wide_String as an argument, an object of that type should > -- be created, such as: > -- > -- My_String : String; > -- My_Wide_String : Wide_String; > -- > -- My_String := "My String"; > -- My_Wide_String := "My Wide String"; Actually, what would be better in the case of a constant is: My_String : constant STRING := "My String"; My_Wide_String : constant Wide_String := "My Wide String"; However, his is my SECOND choice as a solution (see below for my FIRST choices). > -- Alternatively, the call can qualify a literal argument > -- using the: > -- > -- String'("My String") or Wide_String'("My Wide String") > -- > -- Otherwise, the application does not compile as the > -- overloaded calls are ambiguous. > > 2. Status quo with elimination of Wide_String defaults - The > elimination of Wide_String defaults for procedures such as Initialize > would eliminate the ambiguity problem for null parameters. This is one of my FIRST choices and should be done anyway. Subprograms such as Initialize (and Finalize) should be: procedure Initialize (Parameters : in String := ""); procedure Initialize (Parameters : in Wide_String); Thus, code such as: Initialize; would not be ambiguous since it would be the first one above. > 3. Provide separate procedures/functions for Wide_String - Instead of > having overloaded procedures, rename each from XXX to XXX_Wide. This > would eliminate the problem stated by Sergey, but might not be viewed > as elegant as the status quo with other options. > > [Note: Sergey suggested we use XXX and Wide_XXX. It might be better to > use XXX and XXX_Wide for indexing purposes.] In my opinion, this should NOT be done, under any circumstances! > 4. Provide "+"/"-" String/Wide/String functions - As Robert Dewar > suggested, the problem can be mitigated by defining: > > function "+"(S : String) return String is > begin > return S; > end; > > and > function "-"(W : Wide_String) return Wide_String is > begin > return W; > end; Actually, the "-" function should be: function "-"(S : String) return Wide_String is begin return Wide_String(S); end; > this would allow one to write: > > Initialize(+"Debug_Mode"); > or Initialize(-"Debug_Mode"); > > As noted by Robert Dewar, "this is still a pain." Also it does not > eliminate the default parameter problem where one might simply want to > say: > Initialize; > > This option could easily be implemented by the user. Hence should it > be provided in ASIS, it would simply facilitate the use of > String/Wide_String. This is another of my FIRST choices and should be done in any case. (Although if tool writers were using both String and Wide_String stuff in their tools, they would probably also have something similar, if not exactly like, the above two functions in one of their tool packages.) > 5. Provide mirror ASIS packages for String and Wide_String - Provide > for an implementor to provide an Asis package and an Asis_Wide > package. The Asis package would have no Wide_String parameters; the > Asis_Wide package would have no String parameters. This approach is > also not very elegant and limits tools using both String and > Wide_String. This should NOT be done, in any circumstances! Absolutely NOT! > 6. Combination of 1,3, and 4 above - Maintain overloading for most of > ASIS, providing XXX_Wide names for procedures/functions where: > > a. default String/Wide_String parameters are possible; > b. functions are likely to be used in a print statement, > for example: XXX_Image and XXX_Image_Wide; > c. procedures/functions are commonly used; > > This could eliminate the most common ambiguity problems using String > and Wide_String. Although appealing, this option might be confusing as > an ASIS user is presented with alternative options. This, too, should NOT be done! > 7. Combination of 2 and 4 above - Eliminate ambiguous Wide_String > defaults and provide "+"/"-" functions for String/Wide_String > disambiguation. As indicated in my previous remarks, both 2 and 4 should be done. This is my FIRST choice. To summarize, my FIRST choice is #7 (which includes both #2 and #4). My SECOND choice is #1. And in my opinion, NONE of #3, #5, or #6 should be done! Clyde Roby From sblake@sd.aonix.com Tue May 27 18:44:53 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id SAA11057; Tue, 27 May 1997 18:44:53 -0400 Received: from gw.alsys.com by ida.org (4.1/SMI-4.1) id AA06523; Tue, 27 May 97 18:45:24 EDT Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.alsys.com (4.1/SMI-4.1.1) id AA05182; Tue, 27 May 97 15:45:42 PDT Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA20953; Tue, 27 May 97 15:44:02 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id PAA11602; Tue, 27 May 1997 15:44:01 -0700 Date: Tue, 27 May 1997 15:44:01 -0700 From: sblake@sd.aonix.com (Steve Blake @pulsar) Message-Id: <199705272244.PAA11602@puumba.telesoft> To: asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, roby@ida.org, rybin@possum.srcc.msu.su Subject: Re: String/Wide_String problem : NEED INPUT ASAP Content-Length: 1273 Status: OR >1. Status quo => Use the overloaded procedure and function calls We need to change something. >2. Status quo with elimination of Wide_String defaults - The >elimination of Wide_String defaults for procedures such as Initialize >would eliminate the ambiguity problem for null parameters. We could also add a parameterles procedure to provide default init/finalize which is probably what 99% of all ASIS programs will want to use. procedure Initialize; procedure Finalize; Another way to disambiguize; remove defaults and make the formal names different. procedure Initialize (String_Parameters : in String); procedure Initialize (Wide_String_Parameters : in Wide_String); Users would be able to use any of these: Initialize(String_Parameters => "abc"); Initialize(String'("abc")); Initialize(Wide_String_Parameters => "abc"); >3. Provide separate procedures/functions for Wide_String - Instead of I would Vote no. 4. Provide "+"/"-" String/Wide/String functions - As Robert Dewar suggested, the problem can be mitigated by defining: I agree this is still a pain, but always available for the user to implement. Not very elegant. >5. Provide mirror ASIS packages for String and Wide_String - Provide Please don't. Steve From eachus@spectre.mitre.org Tue May 27 20:28:44 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id UAA11125; Tue, 27 May 1997 20:28:44 -0400 Received: from mbunix.mitre.org by ida.org (4.1/SMI-4.1) id AA07897; Tue, 27 May 97 20:29:18 EDT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id UAA12417; Tue, 27 May 1997 20:29:16 -0400 (EDT) Received: (from eachus@localhost) by spectre.mitre.org (8.8.5/8.8.5) id UAA17328; Tue, 27 May 1997 20:29:16 -0400 (EDT) Date: Tue, 27 May 1997 20:29:16 -0400 (EDT) From: "Robert I. Eachus" Message-Id: <199705280029.UAA17328@spectre.mitre.org> To: ASIS-Officers@sw-eng.falls-church.va.us, roby@ida.org, Colket@SMTP-GW.SPAWAR.Navy.Mil, rybin@alex.srcc.msu.su, ASIS-Technical@sw-eng.falls-church.va.us In-Reply-To: <199705272118.RAA10899@cronus.csed.ida.org> (roby@ida.org) Subject: Re: String/Wide_String problem : NEED INPUT ASAP Content-Length: 1255 Status: OR I think I agree with Clyde. First, there should never be two overloaded suprograms which are identical except for parameters with defaults. That just looks sloppy, and is a pain for users. (Option 2) On option 4, the idea is right, but I'm not sure that all operators is the right way to go. (Yes, I know the use type issues, but we don't have those types declared locally.) If people are writing Initialize, and don't want to write: Initialize(String'("Debug_Mode")); Then Initialize(+"Debug_Mode"); is okay, but Initialize(-"Debug_Mode"); is stretching it--a lot. While: Initialize(Wide("Debug_Mode")); and Initialize(Latin("Debug_Mode")); are much easier to understand as conversions between Wide to Latin1. I am not as opposed to the XX_Wide solution as Clyde is, but I think that to do it right will require reviewing all operations with Wide_String parameters to decide whether overloading or the XXX_Wide form is better. There just isn't enough time to do that with sufficient review at this point in time. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From rybin@possum.srcc.msu.su Wed May 28 01:27:43 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id BAA11392; Wed, 28 May 1997 01:27:42 -0400 Received: from crocus.gamma.ru by ida.org (4.1/SMI-4.1) id AA10397; Wed, 28 May 97 01:28:14 EDT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id JAA04333; Wed, 28 May 1997 09:26:29 +0400 (MSD) Received: by gamma.srcc.msu.su; Wed, 28 May 1997 09:25:46 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Wed, 28 May 1997 09:24:55 +0400 To: ASIS-Officers@sw-eng.falls-church.va.us, ASIS-Technical@sw-eng.falls-church.va.us, Colket@SMTP-GW.SPAWAR.Navy.Mil, eachus@spectre.mitre.org, roby@ida.org References: <199705280029.UAA17328@spectre.mitre.org> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Wed, 28 May 97 09:24:54 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: String/Wide_String problem : NEED INPUT ASAP Lines: 15 Content-Length: 731 Status: OR > I am not as opposed to the XX_Wide solution as Clyde is, but I > think that to do it right will require reviewing all operations with > Wide_String parameters to decide whether overloading or the XXX_Wide > form is better. There just isn't enough time to do that with > sufficient review at this point in time. The simplest way is to use XXX_Wide for *ALL* queries having Wide_String as a parameter or a result type. XXX is for standard mode, XXX_Wide is for Wide_String/Wide_Charecter literals and for Ada sources written in non-standard mode to support local conventions. Bor both cases _Wide as a part of query names looks natural. And what real advantage can we get from overloading of ASIS queries? Sergey From rybin@possum.srcc.msu.su Wed May 28 01:49:14 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id BAA11415; Wed, 28 May 1997 01:49:14 -0400 Received: from crocus.gamma.ru by ida.org (4.1/SMI-4.1) id AA10731; Wed, 28 May 97 01:49:46 EDT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id JAA04692 for roby@ida.org; Wed, 28 May 1997 09:49:41 +0400 (MSD) Received: by gamma.srcc.msu.su; Wed, 28 May 1997 09:49:34 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Wed, 28 May 1997 09:47:59 +0400 To: ASIS-Officers@sw-eng.falls-church.va.us, roby@ida.org Cc: ASIS-Technical@sw-eng.falls-church.va.us, Colket@SMTP-GW.SPAWAR.Navy.Mil, rybin@alex.srcc.msu.su References: <199705272118.RAA10899@cronus.csed.ida.org> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Wed, 28 May 97 09:47:59 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: String/Wide_String problem : NEED INPUT ASAP Lines: 130 Content-Length: 5173 Status: OR > > 2. Status quo with elimination of Wide_String defaults - The > > elimination of Wide_String defaults for procedures such as Initialize > > would eliminate the ambiguity problem for null parameters. > > This is one of my FIRST choices and should be done anyway. > Subprograms such as Initialize (and Finalize) should be: > > procedure Initialize (Parameters : in String := ""); > procedure Initialize (Parameters : in Wide_String); > > Thus, code such as: > > Initialize; > > would not be ambiguous since it would be the first one above. I agree, that if we keep the overloaded names, this should be done. > > 3. Provide separate procedures/functions for Wide_String - Instead of > > having overloaded procedures, rename each from XXX to XXX_Wide. This > > would eliminate the problem stated by Sergey, but might not be viewed > > as elegant as the status quo with other options. > > > > [Note: Sergey suggested we use XXX and Wide_XXX. It might be better to > > use XXX and XXX_Wide for indexing purposes.] > > In my opinion, this should NOT be done, under any circumstances! I realise, that finally you and Currie will make changes and will take the "official" responcibility for them, so the final choice will be yours, but I'm really interesting, why you are so strongly agains this solution? Did I missed something important? > > 4. Provide "+"/"-" String/Wide/String functions - As Robert Dewar > > suggested, the problem can be mitigated by defining: > > > > function "+"(S : String) return String is > > begin > > return S; > > end; > > > > and > > function "-"(W : Wide_String) return Wide_String is > > begin > > return W; > > end; > > Actually, the "-" function should be: > > function "-"(S : String) return Wide_String is > begin > return Wide_String(S); > end; > > > this would allow one to write: > > > > Initialize(+"Debug_Mode"); > > or Initialize(-"Debug_Mode"); > > > > As noted by Robert Dewar, "this is still a pain." Also it does not > > eliminate the default parameter problem where one might simply want to > > say: > > Initialize; > > > > This option could easily be implemented by the user. Hence should it > > be provided in ASIS, it would simply facilitate the use of > > String/Wide_String. > > This is another of my FIRST choices and should be done in any case. > > (Although if tool writers were using both String and Wide_String stuff > in their tools, they would probably also have something similar, if > not exactly like, the above two functions in one of their tool > packages.) But do *we* really need to provide this five-lines function *in ASIS*??? We may show this code in comments as a possible solution, and then it will be up to an application how to resolve the possible ambiguity. It will not have any impact on the portability of an application, because the functions like these will have to be included in the application code, and they are portable ;) I'm afraid, if we really include these "+" and "-" function *in the ASIS compilable code*, this will make a bad impression for some of the possible "external" reviewers, because for some people it may look like an indication, that ASIS is very far from being mature enough for standardization. > > 5. Provide mirror ASIS packages for String and Wide_String - Provide > > for an implementor to provide an Asis package and an Asis_Wide > > package. The Asis package would have no Wide_String parameters; the > > Asis_Wide package would have no String parameters. This approach is > > also not very elegant and limits tools using both String and > > Wide_String. > > This should NOT be done, in any circumstances! Absolutely NOT! Nice to see at least one point all of us agree upon! :-) > > > 6. Combination of 1,3, and 4 above - Maintain overloading for most of > > ASIS, providing XXX_Wide names for procedures/functions where: > > > > a. default String/Wide_String parameters are possible; > > b. functions are likely to be used in a print statement, > > for example: XXX_Image and XXX_Image_Wide; > > c. procedures/functions are commonly used; > > > > This could eliminate the most common ambiguity problems using String > > and Wide_String. Although appealing, this option might be confusing as > > an ASIS user is presented with alternative options. > > This, too, should NOT be done! This is definitely worse, then #3. I think, the only approach to #3 should be "all or nothing". > > 7. Combination of 2 and 4 above - Eliminate ambiguous Wide_String > > defaults and provide "+"/"-" functions for String/Wide_String > > disambiguation. > > As indicated in my previous remarks, both 2 and 4 should be done. > This is my FIRST choice. > > To summarize, my FIRST choice is #7 (which includes both #2 and #4). > My SECOND choice is #1. And in my opinion, NONE of #3, #5, or #6 > should be done! > > Clyde Roby Sergey From alfred.strohmeier@di.epfl.ch Wed May 28 03:22:37 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id DAA11473; Wed, 28 May 1997 03:22:36 -0400 Received: from dimail.epfl.ch by ida.org (4.1/SMI-4.1) id AA11229; Wed, 28 May 97 03:23:03 EDT Received: from lglsun11.epfl.ch by dimail.epfl.ch (SMI-8.6/EPFL-DI-5.2-S-MX) id JAA14143; Wed, 28 May 1997 09:20:48 +0200 Received: from lglsun12 by lglsun11.epfl.ch (SMI-8.6/EPFL-DI-5.2-MX) id JAA19914; Wed, 28 May 1997 09:22:35 +0200 Sender: astroh@di.epfl.ch Message-Id: <338BDD28.2F17@di.epfl.ch> Date: Wed, 28 May 1997 09:22:16 +0200 From: Alfred Strohmeier Organization: EPFL-DI-LGL X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) Mime-Version: 1.0 To: Currie Colket Cc: "Sergey I. Rybin" , ASIS Technical , Clyde Roby Subject: Re: String/Wide_String problem : NEED INPUT ASAP References: <38afce80@smtp-gw.spawar.navy.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1336 Status: OR Dear all, To sum up, my preferences are: - the best: option 5. It is like the approach taken by the RM for string handling, see A.4.7. The language designers, and I agree with them, made the hypothesis that mixing strings and wide-strings in a same piece of code is rare. I also think that the solution is quite elegant. It's not even necessary to provide the full text of the wide-string variant, see again A.4.7. Yes, I know you are back to ambiguities when you "use" both packages, but resolution by the full name is straight. - acceptable: option 1 with or without option 2. - don't like: option 3: it's lengthy and cumbersome; moreover, if you want to port a string-based application to a wide-string-based application, the port is cumbersome. - don't like: option 4 in a standard. An individual programmer may use it, but myself I don't like it, and I think it's bad practice (isn't it in the C style: make it short, but the "name" don't say you anything on what is going on :-) - reject: option 6: it's confusing, and will become a maintenance nightmare. - reject: option 7. Hope this helps, -- Alfred -- Prof. Alfred Strohmeier, Swiss Fed Inst of Technology in Lausanne EPFL-DI-LGL, CH-1015 Lausanne, Switzerland Tel +41 21 693 4231, Fax +41 21 693 5079 mailto:alfred.strohmeier@di.epfl.ch or http://lglwww.epfl.ch/ From jj@ddci.dk Wed May 28 04:01:09 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id EAA11503; Wed, 28 May 1997 04:01:08 -0400 Received: from uucp.DK.net by ida.org (4.1/SMI-4.1) id AA11375; Wed, 28 May 97 04:01:44 EDT Received: from ddci (uucp@localhost) by uucp.DK.net (8.6.12/8.6.12) with UUCP id KAA29362; Wed, 28 May 1997 10:01:26 +0200 Received: from sparc7.ddci.dk by ddci.dk (4.1/j1.1.2) id AA19953; Wed, 28 May 97 09:10:44 +0200 Date: Wed, 28 May 97 09:10:44 +0200 Message-Id: <9705280710.AA19953@ddci.dk> Received: by sparc7.ddci.dk (4.1/SMI-4.1) id AA21559; Wed, 28 May 97 09:09:06 +0200 From: Jesper Joergensen To: colket@smtp-gw.spawar.navy.mil Cc: rybin@possum.srcc.msu.su, asis-technical@sw-eng.falls-church.va.us, roby@ida.org, colket@smtp-gw.spawar.navy.mil, jj@ddci.dk In-Reply-To: <38afce80@smtp-gw.spawar.navy.mil> (colket@smtp-gw.spawar.navy.mil) Subject: Re: String/Wide_String problem : NEED INPUT ASAP Content-Length: 3443 Status: OR > > We need to agree on an approach for addressing the Wide_String issue > soon. Clyde and I are planning to finalize ASIS 2.0.N tomorrow > (Wednesday, 28 May). > > Our options for resolution are many. The major options are as follows: I prefer #3. I dislike #4 which I think should be avoided altogether. > 1. Status quo => Use the overloaded procedure and function calls > as currently in ASIS Version 2.0.m. and live with the problem. Every > call having a String parameter, an overloaded call having a > Wide_String parameter was provided. I don't like this. > 2. Status quo with elimination of Wide_String defaults - The > elimination of Wide_String defaults for procedures such as Initialize > would eliminate the ambiguity problem for null parameters. This only solves one of the problems. > 3. Provide separate procedures/functions for Wide_String - Instead of > having overloaded procedures, rename each from XXX to XXX_Wide. This > would eliminate the problem stated by Sergey, but might not be viewed > as elegant as the status quo with other options. Yes, this is also the solution of the language reference manual itself, e.g. having both of the attributes Image/Wide_Image, Value, Wide_Value and both of the packages Text_IO/Wide_Text_IO. > [Note: Sergey suggested we use XXX and Wide_XXX. It might be better to > use XXX and XXX_Wide for indexing purposes.] I have no preferences for either way. > 4. Provide "+"/"-" String/Wide/String functions - As Robert Dewar > suggested, the problem can be mitigated by defining: > > function "+"(S : String) return String is > begin > return S; > end; > > and > function "-"(W : Wide_String) return Wide_String is > begin > return W; > end; > > this would allow one to write: > > Initialize(+"Debug_Mode"); > or Initialize(-"Debug_Mode"); > > As noted by Robert Dewar, "this is still a pain." Also it does not > eliminate the default parameter problem where one might simply want to > say: > Initialize; > > This option could easily be implemented by the user. Hence should it > be provided in ASIS, it would simply facilitate the use of > String/Wide_String. This is an ugly, C like hack. I hate it. ;-) > 5. Provide mirror ASIS packages for String and Wide_String - Provide > for an implementor to provide an Asis package and an Asis_Wide > package. The Asis package would have no Wide_String parameters; the > Asis_Wide package would have no String parameters. This approach is > also not very elegant and limits tools using both String and > Wide_String. No. > 6. Combination of 1,3, and 4 above - Maintain overloading for most of > ASIS, providing XXX_Wide names for procedures/functions where: > > a. default String/Wide_String parameters are possible; > b. functions are likely to be used in a print statement, > for example: XXX_Image and XXX_Image_Wide; > c. procedures/functions are commonly used; Avoid 4! > This could eliminate the most common ambiguity problems using String > and Wide_String. Although appealing, this option might be confusing as > an ASIS user is presented with alternative options. > > 7. Combination of 2 and 4 above - Eliminate ambiguous Wide_String > defaults and provide "+"/"-" functions for String/Wide_String > disambiguation. No. /Jesper From Alain.LeGuennec@enst-bretagne.fr Wed May 28 04:40:36 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id EAA11521; Wed, 28 May 1997 04:40:35 -0400 Received: from audrey.enst-bretagne.fr by ida.org (4.1/SMI-4.1) id AA11520; Wed, 28 May 97 04:40:58 EDT Received: from huygens.enst-bretagne.fr (huygens.enst-bretagne.fr [192.44.75.121]) by audrey.enst-bretagne.fr (8.8.5/8.8.5) with SMTP id KAA19852; Wed, 28 May 1997 10:37:28 +0200 Received: by huygens.enst-bretagne.fr (SMI-8.6/SMI-SVR4) id KAA12846; Wed, 28 May 1997 10:37:27 +0200 To: roby@ida.org (Clyde Roby) Cc: colket@SMTP-GW.SPAWAR.Navy.Mil (Currie Colket), rybin@alex.srcc.msu.su (Rybin), ASIS-Technical@SW-Eng.Falls-Church.Va.US (asis-technical) Subject: Re: String/Wide_String problem : NEED INPUT ASAP (fwd) References: <199705272121.RAA10926@cronus.csed.ida.org> From: Alain Le Guennec In-Reply-To: roby@ida.org's message of Tue, 27 May 1997 17:21:58 -0400 (EDT) Date: 28 May 1997 10:37:24 +0200 Message-Id: Lines: 45 X-Mailer: Gnus v5.4.55/Emacs 19.34 Content-Length: 1763 Status: OR For the moment, my prefered solutions are #1 or #2. Now I have a question whose answer I couldn't find so far: How does an application developper know which of a normal (String) query or its Wide_String counter part should be used, and what happens if a query with a String result is used when its Wide_String version should have been used because the corresponding program text contains non-latin1 characters ? Is the result somehow 'encoded' to fit in a String ? Is an exception raised and if so, which one ? Don't we need something like function Image_Is_Wide (E : Asis.Element) return Boolean; to choose which of the 2 queries is to be called ? > FYI, The following note was placed in Clause 3, (2.0.m) (with > reformatting for email): > > -- The ASIS interface uses both Ada strings and wide strings > -- as parameters to many function and procedure calls. > -- Overloaded function and procedure calls are provided > -- for each situation. The context of a function call will > -- differentiate returned values of String or Wide_String. > -- However, where procedure or function calls pass String or > -- Wide_String as an argument, an object of that type should > -- be created, such as: > -- > -- My_String : String; > -- My_Wide_String : Wide_String; > -- > -- My_String := "My String"; > -- My_Wide_String := "My Wide String"; > -- > -- Alternatively, the call can qualify a literal argument > -- using the: > -- > -- String'("My String") or Wide_String'("My Wide String") > -- > -- Otherwise, the application does not compile as the > -- overloaded calls are ambiguous. -- Alain Le Guennec ENST de Bretagne. From fofanov@such.srcc.msu.su Wed May 28 05:07:59 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id FAA11548; Wed, 28 May 1997 05:07:59 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA11674; Wed, 28 May 97 05:08:07 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id FAA05406; Wed, 28 May 1997 05:04:25 -0400 Received: from such.srcc.msu.su by sw-eng.falls-church.va.us (8.7.1/) id JAA10463; Wed, 28 May 1997 09:03:36 GMT Received: from uumars.UUCP (uucp@localhost) by such.srcc.msu.su (8.8.5/8.8.3) with UUCP id NAA01227 for asis-technical@sw-eng.falls-church.va.us; Wed, 28 May 1997 13:06:31 +0400 (MSD) Received: by mars.srcc.msu.su (UUPC/@ v6.14g, 04Jan96) id AA28378; Wed, 28 May 1997 13:04:39 +0400 (MSD) To: asis-technical@sw-eng.falls-church.va.us References: <199705272244.PAA11602@puumba.telesoft> Message-Id: Date: Wed, 28 May 97 13:04:39 +0400 X-Mailer: BML [MS/DOS Beauty Mail v1.36h] Organization: Science Research Computer Center, Moscow State University From: fofanov@such.srcc.msu.su (Vasiliy A. Fofanov) Subject: Re: String/Wide_String problem : NEED INPUT ASAP Lines: 27 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 802 Status: OR Dear ASIS WG, I would like to take part in this very hot discussion over the issue of String/Wide_String usage. My vote is #3 (XXX_Wide) As an implementor of an interactive ASIS queries interpreter, I am strongly against any solution that requires massive overloading. Please also note that the current solution renders most existing ASIS-apps uncompilable. For me, it would be best to use the solution XXX_Wide. Franlky speaking, I don't see _any_ problems with this approach. Would anyone who is _strongly against_ it explain his position? Sincerely Yours, Vasiliy Fofanov. --- ------------------------------------------------------------------- Vasiliy A. Fofanov Email: fofanov@such.srcc.msu.su Ada Programmer WWW: http://such.srcc.msu.su/fofanov/ From dewar@gnat.com Wed May 28 06:07:14 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id GAA11579; Wed, 28 May 1997 06:07:14 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA12000; Wed, 28 May 97 06:07:53 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id GAA1769680 for ; Wed, 28 May 1997 06:05:32 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id KAA11488; Wed, 28 May 1997 10:04:19 GMT Received: by nile.gnat.com (5.0/1.20) id AA02645; Wed, 28 May 97 06:05:12 EDT Date: Wed, 28 May 97 06:05:12 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705281005.AA02645@nile.gnat.com> To: asis-officers@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, rybin@possum.srcc.msu.su Subject: Re: String/Wide_String problem : NEED INPUT ASAP Cc: Alain.LeGuennec@enst-bretagne.fr Content-Length: 554 Status: OR <<> 1. Status quo => Use the overloaded procedure and function calls > as currently in ASIS Version 2.0.m. and live with the problem. Every > call having a String parameter, an overloaded call having a > Wide_String parameter was provided.>> This is not acceptable. We have a clear technical mistake here, given the presence of completely useless default parameters, which makes it clear that this was indeed an unintended technical oversight. I would recommend against final approval of the standard if errors such as this are not corrected. From dewar@gnat.com Wed May 28 06:10:15 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id GAA11584; Wed, 28 May 1997 06:10:14 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA12003; Wed, 28 May 97 06:10:54 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id GAA1768818 for ; Wed, 28 May 1997 06:08:33 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id KAA11620; Wed, 28 May 1997 10:07:37 GMT Received: by nile.gnat.com (5.0/1.20) id AA03703; Wed, 28 May 97 06:08:34 EDT Date: Wed, 28 May 97 06:08:34 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705281008.AA03703@nile.gnat.com> To: asis-officers@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, rybin@possum.srcc.msu.su Subject: Re: String/Wide_String problem : NEED INPUT ASAP Cc: Alain.LeGuennec@enst-bretagne.fr Content-Length: 766 Status: OR <> I strongly disagree, the RM clearly indicates a preference for Wide_XXX (e.g. Wide_Text_IO), and it is inappropriate for ASIS to choose a different style of definition. I would strongly oppose the introduction of "+" into the standard. This is a kludge that I suggested as a user level reaction to the situation, it is not suitable for standardization. You will find that many people are strongly opposed to this use of + (which is why the proposal to set aside a specal unary operator for this purpose failed). I really think the only viable solution is to introduce a separate set of routines with names Wide_xxx. Anything else will introduce controversial elements that could impede standardization. From dewar@gnat.com Wed May 28 06:12:07 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id GAA11593; Wed, 28 May 1997 06:12:07 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA12008; Wed, 28 May 97 06:12:47 EDT Received: by nile.gnat.com (5.0/1.20) id AA04462; Wed, 28 May 97 06:10:33 EDT Date: Wed, 28 May 97 06:10:33 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705281010.AA04462@nile.gnat.com> To: ASIS-Officers@sw-eng.falls-church.va.us, roby@ida.org Subject: Re: String/Wide_String problem : NEED INPUT ASAP Cc: ASIS-Technical@sw-eng.falls-church.va.us, Colket@smtp-gw.spawar.navy.mil, rybin@alex.srcc.msu.su Content-Length: 631 Status: OR <> The reason that such a proposal is entirely unacceptable from a standardization point of view is that it favors Character over Wide_Character. The entire standard has been carefully designed to ensure that no such favoring occurs. Again you will lose standardization votes by such a choice. From dewar@gnat.com Wed May 28 06:26:40 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id GAA11612; Wed, 28 May 1997 06:26:40 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA12091; Wed, 28 May 97 06:27:18 EDT Received: by nile.gnat.com (5.0/1.20) id AA08834; Wed, 28 May 97 06:21:23 EDT Date: Wed, 28 May 97 06:21:23 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705281021.AA08834@nile.gnat.com> To: ASIS-Officers@sw-eng.falls-church.va.us, ASIS-Technical@sw-eng.falls-church.va.us, Colket@smtp-gw.spawar.navy.mil, eachus@spectre.mitre.org, roby@ida.org, rybin@alex.srcc.msu.su Subject: Re: String/Wide_String problem : NEED INPUT ASAP Content-Length: 484 Status: OR << I am not as opposed to the XX_Wide solution as Clyde is, but I think that to do it right will require reviewing all operations with Wide_String parameters to decide whether overloading or the XXX_Wide form is better. There just isn't enough time to do that with sufficient review at this point in time.>> There is *always* sufficient time to fix errors, because the alternative is to try to standardize with clear errors, something that you will find is very hard to achieve. From dewar@gnat.com Wed May 28 06:28:08 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id GAA11616; Wed, 28 May 1997 06:28:08 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA12107; Wed, 28 May 97 06:28:47 EDT Received: by nile.gnat.com (5.0/1.20) id AA09209; Wed, 28 May 97 06:23:01 EDT Date: Wed, 28 May 97 06:23:01 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705281023.AA09209@nile.gnat.com> To: ASIS-Officers@sw-eng.falls-church.va.us, ASIS-Technical@sw-eng.falls-church.va.us, Colket@smtp-gw.spawar.navy.mil, eachus@spectre.mitre.org, roby@ida.org, rybin@alex.srcc.msu.su Subject: Re: String/Wide_String problem : NEED INPUT ASAP Content-Length: 752 Status: OR << I am not as opposed to the XX_Wide solution as Clyde is, but I think that to do it right will require reviewing all operations with Wide_String parameters to decide whether overloading or the XXX_Wide form is better. There just isn't enough time to do that with sufficient review at this point in time.>> One point to consider here is that there is considerable uneasiness about the speed with which ASIS is being pushed through. This worries people because they are afraid that in the haste to get a standard, shortcuts will be taken. The view that there is not enough time to fix a clear error is exactly what people are concerned about, and if you present them with a very clear example, it is likely that it will derail the final approval. From dewar@gnat.com Wed May 28 06:46:09 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id GAA11629; Wed, 28 May 1997 06:46:09 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA12209; Wed, 28 May 97 06:46:49 EDT Received: by nile.gnat.com (5.0/1.20) id AA16697; Wed, 28 May 97 06:44:09 EDT Date: Wed, 28 May 97 06:44:09 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705281044.AA16697@nile.gnat.com> To: alfred.strohmeier@di.epfl.ch, colket@smtp-gw.spawar.navy.mil Subject: Re: String/Wide_String problem : NEED INPUT ASAP Cc: asis-technical@sw-eng.falls-church.va.us, roby@ida.org, rybin@possum.srcc.msu.su Content-Length: 578 Status: OR Alfred said <> I strongly support this point of view. From dewar@gnat.com Wed May 28 06:50:40 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id GAA11638; Wed, 28 May 1997 06:50:40 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA12235; Wed, 28 May 97 06:50:49 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id GAA07464; Wed, 28 May 1997 06:48:26 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id KAA12433; Wed, 28 May 1997 10:47:38 GMT Received: by nile.gnat.com (5.0/1.20) id AA18040; Wed, 28 May 97 06:48:40 EDT Date: Wed, 28 May 97 06:48:40 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705281048.AA18040@nile.gnat.com> To: asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su Subject: Re: String/Wide_String problem : NEED INPUT ASAP Content-Length: 503 Status: OR <> Providing we use the RM style names of Wide_XXX, this is acceptable as a solution to me, but I still agree with Alfred that it is better to have separate packages, since this is more consistent with the RM. XXX_Wide in *that form* is definitely not acceptable. From Alain.LeGuennec@enst-bretagne.fr Wed May 28 07:22:22 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id HAA11655; Wed, 28 May 1997 07:22:21 -0400 Received: from audrey.enst-bretagne.fr by ida.org (4.1/SMI-4.1) id AA12409; Wed, 28 May 97 07:22:47 EDT Received: from huygens.enst-bretagne.fr (huygens.enst-bretagne.fr [192.44.75.121]) by audrey.enst-bretagne.fr (8.8.5/8.8.5) with SMTP id NAA33628; Wed, 28 May 1997 13:21:09 +0200 Received: by huygens.enst-bretagne.fr (SMI-8.6/SMI-SVR4) id NAA15521; Wed, 28 May 1997 13:21:08 +0200 To: roby@ida.org (Clyde Roby) Cc: Colket@SMTP-GW.SPAWAR.Navy.Mil (Currie Colket), rybin@alex.srcc.msu.su (Rybin), ASIS-Technical@SW-Eng.Falls-Church.Va.US (asis-technical) Subject: Re: String/Wide_String problem : NEED INPUT ASAP (fwd) References: <199705272123.RAA10932@cronus.csed.ida.org> From: Alain Le Guennec In-Reply-To: roby@ida.org's message of Tue, 27 May 1997 17:23:29 -0400 (EDT) Date: 28 May 1997 13:21:07 +0200 Message-Id: Lines: 24 X-Mailer: Gnus v5.4.55/Emacs 19.34 Content-Length: 992 Status: OR Here is another idea, which may or may not be acceptable, I don't know: There used to be types (or was it subtypes ?) called ASIS_String and ASIS_Character which were later removed because useless. Why not restore them as private or implementation dependend types ? Theses types would keep the implementation depend way of storing strings, (maybe a normal string with a special encoding for non-latin1 characters.) There would be functions to convert to/from ASIS_String/String/Wide_String and ASIS_Character/Character/Wide_Character. We would also need 2 boolean functions called Is_Wide_Character (C : ASIS_Character) and Is_Wide_String (S : ASIS_String). With this approach, there is no need to duplicate all queries, and no problem to choose which form is appropriate between Wide or non-Wide. That looks cleaner to me, since processing is usually independant of "width" issues. Any comment ? (Sorry if this is not realistic, this is an idea that just came to my mind.) /Alain. From rybin@possum.srcc.msu.su Wed May 28 08:14:43 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA11712; Wed, 28 May 1997 08:14:43 -0400 Received: from crocus.gamma.ru by ida.org (4.1/SMI-4.1) id AA12908; Wed, 28 May 97 08:15:16 EDT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id QAA10188; Wed, 28 May 1997 16:15:04 +0400 (MSD) Received: by gamma.srcc.msu.su; Wed, 28 May 1997 16:14:30 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Wed, 28 May 1997 16:12:45 +0400 To: alfred.strohmeier@di.epfl.ch, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com Cc: asis-technical@sw-eng.falls-church.va.us, roby@ida.org References: <9705281044.AA16697@nile.gnat.com> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Wed, 28 May 97 16:12:44 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: String/Wide_String problem : NEED INPUT ASAP Lines: 58 Content-Length: 2314 Status: OR > Alfred said > > < > - the best: option 5. It is like the approach taken by the RM for string > handling, see A.4.7. The language designers, and I agree with them, made > the hypothesis that mixing strings and wide-strings in a same piece of > code is rare. I also think that the solution is quite elegant. It's not > even necessary to provide the full text of the wide-string variant, see > again A.4.7. Yes, I know you are back to ambiguities when you "use" both > packages, but resolution by the full name is straight.>> > > I strongly support this point of view. May be, this is really better and more consistent with RM, then option 3 I've preferred myself. The only question - would you like to duplicate *all* the ASIS functionalities (that is, queries having nothing to do with Strings) in both Asis amd Wide_Asis hierarchies? Oops!... Have I got Alferd right?!?! Is the idea really to have *TWO* hierarchies? That is, two top packages (Asis and Wide_Asis) defining two *different* types named Element (Compilation_Unit, etc.)? If so, I do not think this will work (or, more precisely, it will, but as two *different* ASIS definitions). What do you think about the following "compromise": to separate all the queries having String/Wide_String as a parameter/result type in (gnand)child packages (one step down the *single* hierarchy), and to have *two* versions of these grandchilds - one for String, another for Wide_String for a *single* Element type: Asis ___________________ |_________________ | | .... Declarations | ___________|___________________ | | Images Wide_Images | | Defining_Name_Image Defining_Name_Image (E : Asis.Element) (E : Asis.Element) return String return Wide_String That is, we will have Asis.Declarations.Images.Defining_Name_Image returning String and we will have Asis.Declarations.Wide_Images.Defining_Name_Image returning Wide_String. Alfred, is this what you've suggested. If it is, I am strongly support this approach, if not - I'm suggesting it and vote for it, and only after it - for option 3. Sergey From alfred.strohmeier@di.epfl.ch Wed May 28 09:06:26 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id JAA11739; Wed, 28 May 1997 09:06:25 -0400 Received: from dimail.epfl.ch by ida.org (4.1/SMI-4.1) id AA13813; Wed, 28 May 97 09:07:04 EDT Received: from lglsun11.epfl.ch by dimail.epfl.ch (SMI-8.6/EPFL-DI-5.2-S-MX) id PAA25824; Wed, 28 May 1997 15:05:12 +0200 Received: from lglsun12 by lglsun11.epfl.ch (SMI-8.6/EPFL-DI-5.2-MX) id PAA29146; Wed, 28 May 1997 15:07:03 +0200 Sender: astroh@di.epfl.ch Message-Id: <338C2DE3.6D5C@di.epfl.ch> Date: Wed, 28 May 1997 15:06:43 +0200 From: Alfred Strohmeier Organization: EPFL-DI-LGL X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) Mime-Version: 1.0 To: "Sergey I. Rybin" Cc: colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, asis-technical@sw-eng.falls-church.va.us, roby@ida.org Subject: Re: String/Wide_String problem : NEED INPUT ASAP References: <9705281044.AA16697@nile.gnat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3209 Status: OR Sergey I. Rybin wrote: > > > Alfred said > > > > < > > > - the best: option 5. It is like the approach taken by the RM for string > > handling, see A.4.7. The language designers, and I agree with them, made > > the hypothesis that mixing strings and wide-strings in a same piece of > > code is rare. I also think that the solution is quite elegant. It's not > > even necessary to provide the full text of the wide-string variant, see > > again A.4.7. Yes, I know you are back to ambiguities when you "use" both > > packages, but resolution by the full name is straight.>> > > > > I strongly support this point of view. > > May be, this is really better and more consistent with RM, then option 3 > I've preferred myself. > > The only question - would you like to duplicate *all* the ASIS > functionalities (that is, queries having nothing to do with Strings) in > both Asis amd Wide_Asis hierarchies? No, no, no. > > Oops!... Have I got Alferd right?!?! Is the idea really to have *TWO* > hierarchies? That is, two top packages (Asis and Wide_Asis) defining two > *different* types named Element (Compilation_Unit, etc.)? No, no, no. There is only one Element type, etc. > > If so, I do not think this will work (or, more precisely, it will, but as > two *different* ASIS definitions). > > What do you think about the following "compromise": For me, it's not a compromise. It's THE solution I thought would be nice. > to separate all the > queries having String/Wide_String as a parameter/result type in (gnand)child > packages (one step down the *single* hierarchy), and to have *two* versions > of these grandchilds - one for String, another for Wide_String for a *single* > Element type: Yes, let's group all the string stuff (one or several child units, I don't mind, and I don't have the time to elaborate the exact solution), and then mirror these groupings, one for String, and one for Wide_String. > > Asis > ___________________ |_________________ > | | > .... Declarations > | > ___________|___________________ > | | > Images Wide_Images > | | > Defining_Name_Image Defining_Name_Image > (E : Asis.Element) (E : Asis.Element) > return String return Wide_String > > That is, we will have Asis.Declarations.Images.Defining_Name_Image > returning String and we will have > Asis.Declarations.Wide_Images.Defining_Name_Image returning Wide_String. Looks excellent, but I have to say that I did not examine what would be moved down exactly. > > Alfred, is this what you've suggested. If it is, I am strongly support > this approach, if not - I'm suggesting it and vote for it, and only > after it - for option 3. > > Sergey Thanks a lot for taking up my proposal even though you were first against it. Alfred -- Prof. Alfred Strohmeier, Swiss Fed Inst of Technology in Lausanne EPFL-DI-LGL, CH-1015 Lausanne, Switzerland Tel +41 21 693 4231, Fax +41 21 693 5079 mailto:alfred.strohmeier@di.epfl.ch or http://lglwww.epfl.ch/ From eachus@spectre.mitre.org Wed May 28 09:41:58 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id JAA11893; Wed, 28 May 1997 09:41:57 -0400 Received: from mbunix.mitre.org by ida.org (4.1/SMI-4.1) id AA14786; Wed, 28 May 97 09:42:01 EDT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id JAA19245; Wed, 28 May 1997 09:41:49 -0400 (EDT) Received: (from eachus@localhost) by spectre.mitre.org (8.8.5/8.8.5) id JAA19281; Wed, 28 May 1997 09:41:48 -0400 (EDT) Date: Wed, 28 May 1997 09:41:48 -0400 (EDT) From: "Robert I. Eachus" Message-Id: <199705281341.JAA19281@spectre.mitre.org> To: rybin@possum.srcc.msu.su Cc: ASIS-Officers@sw-eng.falls-church.va.us, ASIS-Technical@sw-eng.falls-church.va.us, Colket@SMTP-GW.SPAWAR.Navy.Mil, roby@ida.org In-Reply-To: (rybin@possum.srcc.msu.su) Subject: Re: String/Wide_String problem : NEED INPUT ASAP Content-Length: 1026 Status: OR Sergey I. Rybin (rybin@possum.srcc.msu.su) asked: > And what real advantage can we get from overloading of ASIS queries? There will be some benefit in reuse of code if all that has to be changed is the name of the string type, not all the calls. But I don't know if that justifies overloading in the cases where it creates ambiguity. What I was saying was that at this point in the process, we don't have time to find out which ones benefit and which don't. Given that changing all or none are the only two choices worth considering, I think we are better off sticking with the status quo, with the obvious bug fix. (Well, not so obvious. I think I am now convinced that the better option where strings (or wide_strings) are optional is to declare three subprograms, one with a wide parameter, one with a string parameter and one with no parameter at all.) Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From eachus@spectre.mitre.org Wed May 28 10:14:40 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id KAA12108; Wed, 28 May 1997 10:14:40 -0400 Received: from mbunix.mitre.org by ida.org (4.1/SMI-4.1) id AA15604; Wed, 28 May 97 10:15:12 EDT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id KAA24445; Wed, 28 May 1997 10:15:09 -0400 (EDT) Received: (from eachus@localhost) by spectre.mitre.org (8.8.5/8.8.5) id KAA19369; Wed, 28 May 1997 10:15:09 -0400 (EDT) Date: Wed, 28 May 1997 10:15:09 -0400 (EDT) From: "Robert I. Eachus" Message-Id: <199705281415.KAA19369@spectre.mitre.org> To: dewar@gnat.com Cc: ASIS-Officers@sw-eng.falls-church.va.us, roby@ida.org, ASIS-Technical@sw-eng.falls-church.va.us, Colket@smtp-gw.spawar.navy.mil, rybin@alex.srcc.msu.su In-Reply-To: <9705281010.AA04462@nile.gnat.com> (dewar@gnat.com) Subject: Re: String/Wide_String problem : NEED INPUT ASAP Content-Length: 894 Status: OR Robert Dewar said: > The reason that such a proposal is entirely unacceptable from a > standardization point of view is that it favors Character over > Wide_Character. The entire standard has been carefully designed > to ensure that no such favoring occurs. Again you will lose > standardization votes by such a choice. Which is why: procedure Initialize; procedure Initialize (Parameters : in String); procedure Initialize (Parameters : in Wide_String); is so Solomonic. Neither type of string is favored, but you still have an unambiguous call with no parameters. Of course, to maintain the equality the documentation should state that the first version is equivalent to calling either of the others with a null string. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From eachus@spectre.mitre.org Wed May 28 10:20:27 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id KAA12129; Wed, 28 May 1997 10:20:27 -0400 Received: from mbunix.mitre.org by ida.org (4.1/SMI-4.1) id AA15691; Wed, 28 May 97 10:20:49 EDT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id KAA25150; Wed, 28 May 1997 10:20:40 -0400 (EDT) Received: (from eachus@localhost) by spectre.mitre.org (8.8.5/8.8.5) id KAA19394; Wed, 28 May 1997 10:20:35 -0400 (EDT) Date: Wed, 28 May 1997 10:20:35 -0400 (EDT) From: "Robert I. Eachus" Message-Id: <199705281420.KAA19394@spectre.mitre.org> To: dewar@gnat.com Cc: ASIS-Officers@sw-eng.falls-church.va.us, ASIS-Technical@sw-eng.falls-church.va.us, Colket@smtp-gw.spawar.navy.mil, roby@ida.org, rybin@alex.srcc.msu.su In-Reply-To: <9705281021.AA08834@nile.gnat.com> (dewar@gnat.com) Subject: Re: String/Wide_String problem : NEED INPUT ASAP Content-Length: 955 Status: OR I said: > I am not as opposed to the XX_Wide solution as Clyde is, but I > think that to do it right will require reviewing all operations > with Wide_String parameters to decide whether overloading or the > XXX_Wide form is better. There just isn't enough time to do that > with sufficient review at this point in time. Robert Dewar said: > There is *always* sufficient time to fix errors, because the > alternative is to try to standardize with clear errors, something > that you will find is very hard to achieve. No disagreement. There is a problem here which needs to be fixed, and must be fixed. I was just saying that my concern with the XXX_Wide solution is that it will require more review than the alternatives, and in reality more review than time available. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From Ron_Price/CACI_at_STDXchgPO@turing-smtp1.std.caci.com Wed May 28 10:32:41 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id KAA12215; Wed, 28 May 1997 10:32:40 -0400 From: Ron_Price/CACI_at_STDXchgPO@turing-smtp1.std.caci.com Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA15900; Wed, 28 May 97 10:32:49 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id KAA20270; Wed, 28 May 1997 10:30:12 -0400 Received: from sun3.std.caci.com by sw-eng.falls-church.va.us (8.7.1/) id OAA17183; Wed, 28 May 1997 14:29:17 GMT Received: from turing-smtp1.std.caci.com by sun3.std.caci.com (4.1/1.34) id AA28104; Wed, 28 May 97 09:58:29 EDT Received: from ccMail by turing-smtp1.std.caci.com (SMTPLINK V2.11) id AA864841806; Wed, 28 May 97 10:26:00 EST Date: Wed, 28 May 97 10:26:00 EST Message-Id: <9704288648.AA864841806@turing-smtp1.std.caci.com> To: Subject: Re: String/Wide_String problem : NEED INPUT ASAP (fwd) Content-Length: 1065 Status: OR > Here is another idea, which may or may not be acceptable, I don't know: > There used to be types (or was it subtypes ?) called ASIS_String > and ASIS_Character which were later removed > because useless. > Why not restore them as private or implementation > dependend types ? > Theses types would keep the implementation depend > way of storing strings, > (maybe a normal string with a special encoding for non-latin1 characters.) > There would be functions to convert to/from > ASIS_String/String/Wide_String and > ASIS_Character/Character/Wide_Character.We would also need 2 boolean functions > called > Is_Wide_Character (C : ASIS_Character) and > Is_Wide_String (S : ASIS_String). > With this approach, there is no need to duplicate > all queries, and no problem > to choose which form > is appropriate between Wide or non-Wide. > That looks cleaner to me, since processing is > usually independant of "width" issues. I agree with this concept, but I would make ASIS_String and ASIS_Character a tagged type and allow dispatching to correct operation. From rybin@possum.srcc.msu.su Wed May 28 11:49:46 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id LAA12338; Wed, 28 May 1997 11:49:46 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA17503; Wed, 28 May 97 11:49:54 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id LAA1778898; Wed, 28 May 1997 11:46:55 -0400 Received: from crocus.gamma.ru by sw-eng.falls-church.va.us (8.7.1/) id PAA18822; Wed, 28 May 1997 15:45:31 GMT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id TAA13034; Wed, 28 May 1997 19:48:28 +0400 (MSD) Received: by gamma.srcc.msu.su; Wed, 28 May 1997 19:47:39 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Wed, 28 May 1997 19:34:35 +0400 To: asis-technical@sw-eng.falls-church.va.us, Ron_Price/CACI_at_STDXchgPO@turing-smtp1.std.caci.com References: <9704288648.AA864841806@turing-smtp1.std.caci.com> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Wed, 28 May 97 19:34:35 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: String/Wide_String problem : NEED INPUT ASAP (fwd) Lines: 17 Content-Length: 774 Status: OR > I agree with this concept, but I would make ASIS_String and ASIS_Character > a tagged type and allow dispatching to correct operation. It looks like in two-three weeks we may come to some fully object-oriented version of the ASIS definition :-) I think, both these ideas give a good impact in designing and implementing some ASIS secondary layer stuff, but they are not acceptable for the "core" ASIS definition, because they (at least the second one) are too "heavy". In some sense ASIS is some kind of assembler for developing the secondary layers for developing real-life tools. But what you are suggested are of too high level for such an assembler, and it looks like too resource-consuming to be used in the basis of *all* the ASIS applications. Sergey Rybin From roby Wed May 28 11:53:52 1997 Return-Path: Received: by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id LAA12343; Wed, 28 May 1997 11:53:51 -0400 From: roby (Clyde Roby) Message-Id: <199705281553.LAA12343@cronus.csed.ida.org> Subject: String/Wide_String : proposed solutions To: ASIS-Technical@SW-Eng.Falls-Church.Va.US (asis-technical) Date: Wed, 28 May 1997 11:53:51 -0400 (EDT) Cc: ASIS-Officers@SW-Eng.Falls-Church.Va.US (asis-officers), roby (me) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1167 Status: OR Thanks to everyone who contributed to the discussion for this issue. We really appreciate it! We are currently looking at 2 possible solutions and we (Currie and Clyde) request your thoughts on them. 1. Provide Wide_XXX interfaces for those few situations where a problem exists. Currently, there are 42 interfaces which are overloaded. A problem exists only for 8 interfaces: 6.6 Initialize 6.8 Finalize 6.11 Set_Status 8.3 Associate 10.6 Library_Unit_Declaration 10.7 Compilation_Unit_Body 10.29 Has_Attribute 10.31 Attribute_Value 11.4 Attribute_Time For these 8 cases, it makes sense to have Wide_XXX interfaces. In all other cases, functions are returning String or Wide_String results which should be unambiguous. 2. Use Wide_String exclusively at the interface level, not using String at all. This appears to be the way the commercial world is going, as Microsoft's newer releases of their operating systems are using 16-bit characters rather than 8-bit characters. Solution 2 seems to be the most elegant and simplest solution. Any needed conversions to/from String can be performed using features in the Ada language. Clyde and Currie From bthomas@mitre.org Wed May 28 11:58:34 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id LAA12393; Wed, 28 May 1997 11:58:34 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA17674; Wed, 28 May 97 11:58:42 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id LAA24494; Wed, 28 May 1997 11:56:09 -0400 Received: from mwunix.mitre.org by sw-eng.falls-church.va.us (8.7.1/) id PAA19023; Wed, 28 May 1997 15:55:18 GMT Received: from milner.mitre.org (milner.mitre.org [128.29.13.14]) by mwunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id LAA05420; Wed, 28 May 1997 11:58:18 -0400 (EDT) Received: from [128.29.13.4] (m22345-mac.mitre.org [128.29.13.4]) by milner.mitre.org (8.6.9/8.6.9) with ESMTP id LAA29944; Wed, 28 May 1997 11:36:17 -0400 X-Sender: bthomas@milner.mitre.org Message-Id: In-Reply-To: <38afce80@smtp-gw.spawar.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 May 1997 11:57:57 -0400 To: colket@smtp-gw.spawar.navy.mil (Currie Colket), roby@ida.org From: Bill Thomas Subject: Re: String/Wide_String problem : NEED INPUT ASAP Cc: bthomas@milner.mitre.org, asis-technical@sw-eng.falls-church.va.us Content-Length: 904 Status: OR Currie, Clyde: I thought we had previously agreed to use option 3 to resolve the problem with the default parameters (e.g., Initialize & Initialize_Wide). However, I prefer Steve's suggestion to correct the problem with the default parameters, (remove the defaults, and add a parameterless version), and option 1 (status quo) for the other queries. In looked through my Asis applications, and found no cases where I was using a string literal in a way that would cause a problem here. Sergey's example might be useful in debugging, but in general such use of embedded literals is not considered good programmming style. We could consider removing some of the overloaded queries that are not really useful, (for example, the Library_Unit_Declaration query.) I think we can delete delete the Wide_String queries for the following: 10.6, 10.7, 10.19, 13.39, 15.2, 15.3, 15.4, 17.2, 17.3, 20.25. Bill From bthomas@mitre.org Wed May 28 11:57:51 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id LAA12380; Wed, 28 May 1997 11:57:51 -0400 Received: from mwunix.mitre.org by ida.org (4.1/SMI-4.1) id AA17663; Wed, 28 May 97 11:58:24 EDT Received: from milner.mitre.org (milner.mitre.org [128.29.13.14]) by mwunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id LAA05420; Wed, 28 May 1997 11:58:18 -0400 (EDT) Received: from [128.29.13.4] (m22345-mac.mitre.org [128.29.13.4]) by milner.mitre.org (8.6.9/8.6.9) with ESMTP id LAA29944; Wed, 28 May 1997 11:36:17 -0400 X-Sender: bthomas@milner.mitre.org Message-Id: In-Reply-To: <38afce80@smtp-gw.spawar.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 May 1997 11:57:57 -0400 To: colket@smtp-gw.spawar.navy.mil (Currie Colket), roby@ida.org From: Bill Thomas Subject: Re: String/Wide_String problem : NEED INPUT ASAP Cc: bthomas@milner.mitre.org, asis-technical@sw-eng.falls-church.va.us Content-Length: 904 Status: OR Currie, Clyde: I thought we had previously agreed to use option 3 to resolve the problem with the default parameters (e.g., Initialize & Initialize_Wide). However, I prefer Steve's suggestion to correct the problem with the default parameters, (remove the defaults, and add a parameterless version), and option 1 (status quo) for the other queries. In looked through my Asis applications, and found no cases where I was using a string literal in a way that would cause a problem here. Sergey's example might be useful in debugging, but in general such use of embedded literals is not considered good programmming style. We could consider removing some of the overloaded queries that are not really useful, (for example, the Library_Unit_Declaration query.) I think we can delete delete the Wide_String queries for the following: 10.6, 10.7, 10.19, 13.39, 15.2, 15.3, 15.4, 17.2, 17.3, 20.25. Bill From Alain.LeGuennec@enst-bretagne.fr Wed May 28 12:45:15 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id MAA12583; Wed, 28 May 1997 12:45:15 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA18497; Wed, 28 May 97 12:45:14 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id MAA1762938; Wed, 28 May 1997 12:42:45 -0400 Received: from audrey.enst-bretagne.fr by sw-eng.falls-church.va.us (8.7.1/) id QAA20089; Wed, 28 May 1997 16:41:56 GMT Received: from huygens.enst-bretagne.fr (huygens.enst-bretagne.fr [192.44.75.121]) by audrey.enst-bretagne.fr (8.8.5/8.8.5) with SMTP id SAA17906 for ; Wed, 28 May 1997 18:44:30 +0200 Received: by huygens.enst-bretagne.fr (SMI-8.6/SMI-SVR4) id SAA21450; Wed, 28 May 1997 18:44:28 +0200 To: asis-technical@sw-eng.falls-church.va.us Subject: Re: String/Wide_String problem : NEED INPUT ASAP (fwd) References: <9704288648.AA864841806@turing-smtp1.std.caci.com> From: Alain Le Guennec In-Reply-To: "Sergey I. Rybin"'s message of Wed, 28 May 97 19:34:35 +0400 Date: 28 May 1997 18:44:23 +0200 Message-Id: Lines: 110 X-Mailer: Gnus v5.4.55/Emacs 19.34 Content-Length: 3243 Status: OR "Sergey I. Rybin" wrote: > I think, both these ideas give a good impact in designing and implementing > some ASIS secondary layer stuff, but they are not acceptable for > the "core" ASIS definition, because they (at least the second one) are too "heavy". What I was thinking of was NOT that heavy (no tagged type or any other very heavy stuff such as discriminated records). Here is a very quick draft of a possible partial implementation: package ASIS is .... type ASIS_String is private; Nil_ASIS_String : constant ASIS_String; function Is_Nil (S : ASIS_String) return Boolean; function Is_String (S : ASIS_String) return Boolean; function Is_Wide_String (S : ASIS_String) return Boolean; function To_String (S : ASIS_String) return String; function To_Wide_String (S : ASIS_String) return Wide_String; function To_ASIS_String (S : String) return ASIS_String; function To_ASIS_String (S : Wide_String) return ASIS_String; pragma Inline (....); .... private .... type ASIS_STRING is new String; Nil_ASIS_String : constant ASIS_String := ""; -- A wide_string is stored as 'W' & Encoded_Wide_String -- A "normal" string is stored as 'S' & The_String function Encode_Wide_String (S : Wide_String) return String is ... function Decode_Wide_String (S : String) return Wide_String is ... function Is_Nil (S : ASIS_String) return Boolean is begin return S'Length = 0; end Is_Nil; function Is_String (S : ASIS_String) return Boolean is begin return (S'Length = 0) or else (S (S'First) = 'S'); end Is_String; function Is_Wide_String (S : ASIS_String) return Boolean is begin return (S'Length = 0) or else (S (S'First) = 'W'); end Is_String; function To_String (S : ASIS_String) return String is begin if Is_String (S) then return String (S (S'First + 1 .. S'Last)); else -- error handling... end To_String; function To_Wide_String (S : ASIS_String) return Wide_String is begin if Is_Wide_String (S) then return Decode_Wide_String (S (S'First + 1 .. S'Last)); else -- error handling... end To_Wide_String; function To_ASIS_String (S : String) return ASIS_String is begin return 'S' & S; end To_ASIS_String; function To_ASIS_String (S : Wide_String) return ASIS_String is begin return 'W' & Encode_Wide_String (S); end To_ASIS_String; .... end ASIS; There may be some overhead due to string copies, admittedly. It may be possible to avoid some of them by using the first index as a distinction instead of the first character, eg. : -normal strings are ASIS_String starting with a 'First of 1 -wide_strings are ASIS_String (encoded) with a 'First of 2. Adapting current queries seems reasonably easy to do. Then we would have only one set of queries with ASIS_String as parameters. Of course, the pb disappears altogether if using Wide_String everywhere, but are Wide_Strings used that often in Ada program text to justify it ? Well, this is just an idea (I did not even try to compile the example above.) /Alain. From sblake@sd.aonix.com Wed May 28 14:04:16 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id OAA12667; Wed, 28 May 1997 14:04:15 -0400 Received: from gw.alsys.com by ida.org (4.1/SMI-4.1) id AA19957; Wed, 28 May 97 14:04:53 EDT Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.alsys.com (4.1/SMI-4.1.1) id AA21279; Wed, 28 May 97 11:05:10 PDT Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA16422; Wed, 28 May 97 11:03:29 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id LAA05834; Wed, 28 May 1997 11:03:28 -0700 Date: Wed, 28 May 1997 11:03:28 -0700 From: sblake@sd.aonix.com (Steve Blake @pulsar) Message-Id: <199705281803.LAA05834@puumba.telesoft> To: ASIS-Technical@sw-eng.falls-church.va.us, roby@ida.org Subject: Re: String/Wide_String : proposed solutions Cc: ASIS-Officers@sw-eng.falls-church.va.us Content-Length: 1724 Status: OR >From roby@ida.org Wed May 28 09:22:26 1997 > >Thanks to everyone who contributed to the discussion for this issue. >We really appreciate it! > >We are currently looking at 2 possible solutions and we (Currie and >Clyde) request your thoughts on them. > >1. Provide Wide_XXX interfaces for those few situations where a >problem exists. Currently, there are 42 interfaces which are >overloaded. A problem exists only for 8 interfaces: > > 6.6 Initialize > 6.8 Finalize > 6.11 Set_Status > 8.3 Associate > 10.6 Library_Unit_Declaration > 10.7 Compilation_Unit_Body > 10.29 Has_Attribute > 10.31 Attribute_Value > 11.4 Attribute_Time > >For these 8 cases, it makes sense to have Wide_XXX interfaces. In all >other cases, functions are returning String or Wide_String results >which should be unambiguous. > >2. Use Wide_String exclusively at the interface level, not using >String at all. This appears to be the way the commercial world is >going, as Microsoft's newer releases of their operating systems are >using 16-bit characters rather than 8-bit characters. I much prefer this approach. It is simple, elegant, and fair. Standardization should not look at this approach as favoring wide_string. All the interfaces that take a wide_string parameter will accept a converted string value. All the interfaces that return a wide_string value can be converted to string just as the overloadings would have to do if they were provided. Duplication of these interfaces can be done in a secondary layer if a tool so desires. Steve Blake > >Solution 2 seems to be the most elegant and simplest solution. Any >needed conversions to/from String can be performed using features in >the Ada language. > >Clyde and Currie From rybin@possum.srcc.msu.su Wed May 28 14:26:43 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id OAA12696; Wed, 28 May 1997 14:26:42 -0400 Received: from crocus.gamma.ru by ida.org (4.1/SMI-4.1) id AA20481; Wed, 28 May 97 14:27:19 EDT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id WAA14920; Wed, 28 May 1997 22:27:06 +0400 (MSD) Received: by gamma.srcc.msu.su; Wed, 28 May 1997 22:26:56 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Wed, 28 May 1997 22:23:29 +0400 To: ASIS-Technical@sw-eng.falls-church.va.us Cc: ASIS-Officers@sw-eng.falls-church.va.us, roby@ida.org References: <199705281553.LAA12343@cronus.csed.ida.org> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Wed, 28 May 97 22:23:29 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: String/Wide_String : proposed solutions Lines: 83 Content-Length: 3577 Status: OR > Thanks to everyone who contributed to the discussion for this issue. > We really appreciate it! > > We are currently looking at 2 possible solutions and we (Currie and > Clyde) request your thoughts on them. I'm sorry, but I do not like any of them :(( > 1. Provide Wide_XXX interfaces for those few situations where a > problem exists. Currently, there are 42 interfaces which are > overloaded. A problem exists only for 8 interfaces: > > 6.6 Initialize > 6.8 Finalize > 6.11 Set_Status > 8.3 Associate > 10.6 Library_Unit_Declaration > 10.7 Compilation_Unit_Body > 10.29 Has_Attribute > 10.31 Attribute_Value > 11.4 Attribute_Time > > For these 8 cases, it makes sense to have Wide_XXX interfaces. In all > other cases, functions are returning String or Wide_String results > which should be unambiguous. But why do not you like to follow the Ada style (Test_IO and Wide_Text_IO, 'Image and 'Wide_Image) completely? I cannot beleive, that it really might be useful to make some reusing of the existing code when migrating from String to Wide_String and keeping the names of overloaded queries and string constants... > 2. Use Wide_String exclusively at the interface level, not using > String at all. This appears to be the way the commercial world is > going, as Microsoft's newer releases of their operating systems are > using 16-bit characters rather than 8-bit characters. > > Solution 2 seems to be the most elegant and simplest solution. Any > needed conversions to/from String can be performed using features in > the Ada language. It seems to be *too* radical. I'm not sure, that this approach can be applied to the area ASIS is designed for. 16-bit characters are really important for local conventions, and for nice end-user interfaces, but in the Ada standard mode they can exist only in comments (RM 95, 2.1(1)). I think, String is really important for developing *tools* and making *tools* as small and as fast as possible. And the last, but not the least - what about upward compatibility of the existing ASIS 83 applications (if this problem still exists)? And now, if I have to vote, my preferences are: 1. The old option #1 - "status quo". Rationale: *WE ARE NOT READY _NOW_ TO MAKE A CHOICE*. If ASIS should be presented to some ISO formal structure tomorrow (sorry if in my hole I do not follow all the formal steps of the ISO procedure), it would be better not to make any change at all if we cannot agree upon it. (In the Russian aviation (and, probably, not only in Russian) there is a rule for a test-pilot: "If you do not know what to do, do not do anything". But this "status quo" solution cannot be kept - we do have a problem, and we will have to solve it. 2. Alfred's suggestion to move all the qieries having String/Wide_String in *separate* (one - for String, another - for Wide_String) gnandchild packages. For me now it looks like the ideal solution - it looks very easy and safe to do at the current stage of the ASIS process, it keeps the existing names, it allows to use expanded names to resolve any ambiguoty, and it allows an application to choose String, Wide_String or both itself. I would vote for this solution as for the first and the only one if we had enough time to examine it without hurry. 3. Wide_XXX for *ALL* overloaded queries. 4. If I have to choose *only* from two options above, I would choose the first one. Sergey Rybin From dewar@gnat.com Wed May 28 15:02:38 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA12834; Wed, 28 May 1997 15:02:38 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA21110; Wed, 28 May 97 15:02:19 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id OAA1786838; Wed, 28 May 1997 14:59:54 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id SAA22917; Wed, 28 May 1997 18:59:02 GMT Received: by nile.gnat.com (5.0/1.20) id AA00735; Wed, 28 May 97 14:59:56 EDT Date: Wed, 28 May 97 14:59:56 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705281859.AA00735@nile.gnat.com> To: Ron_Price/CACI_at_STDXchgPO@turing-smtp1.std.caci.com, asis-technical@sw-eng.falls-church.va.us Subject: Re: String/Wide_String problem : NEED INPUT ASAP (fwd) Content-Length: 237 Status: OR <> That is an extraordinarily heavy solution, that means that each character typically takes 8 bytes! From dewar@gnat.com Wed May 28 15:03:39 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA12839; Wed, 28 May 1997 15:03:39 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA21148; Wed, 28 May 97 15:04:18 EDT Received: by nile.gnat.com (5.0/1.20) id AA00631; Wed, 28 May 97 14:57:57 EDT Date: Wed, 28 May 97 14:57:57 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705281857.AA00631@nile.gnat.com> To: dewar@gnat.com, eachus@spectre.mitre.org Subject: Re: String/Wide_String problem : NEED INPUT ASAP Cc: ASIS-Officers@sw-eng.falls-church.va.us, ASIS-Technical@sw-eng.falls-church.va.us, Colket@smtp-gw.spawar.navy.mil, roby@ida.org, rybin@alex.srcc.msu.su Content-Length: 584 Status: OR << Which is why: procedure Initialize; procedure Initialize (Parameters : in String); procedure Initialize (Parameters : in Wide_String); is so Solomonic. Neither type of string is favored, but you still have an unambiguous call with no parameters. Of course, to maintain the equality the documentation should state that the first version is equivalent to calling either of the others with a null string.>> Right, but genrally we have tried to minimize the aggravation cuased by "abc" meaning two different things, by aviding this kind of overloading. From dewar@gnat.com Wed May 28 15:05:34 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA12843; Wed, 28 May 1997 15:05:34 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA21196; Wed, 28 May 97 15:06:13 EDT Received: by nile.gnat.com (5.0/1.20) id AA01311; Wed, 28 May 97 15:03:59 EDT Date: Wed, 28 May 97 15:03:59 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705281903.AA01311@nile.gnat.com> To: ASIS-Technical@sw-eng.falls-church.va.us, roby@ida.org Subject: Re: String/Wide_String : proposed solutions Cc: ASIS-Officers@sw-eng.falls-church.va.us Content-Length: 541 Status: OR <<2. Use Wide_String exclusively at the interface level, not using String at all. This appears to be the way the commercial world is going, as Microsoft's newer releases of their operating systems are using 16-bit characters rather than 8-bit characters. Solution 2 seems to be the most elegant and simplest solution. Any needed conversions to/from String can be performed using features in the Ada language.>> I dislike this idea, I think it will cause a lot of problems in practice, since it is so at odds with the existing RM design. From rybin@possum.srcc.msu.su Wed May 28 15:38:51 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA12941; Wed, 28 May 1997 15:38:51 -0400 Received: from crocus.gamma.ru by ida.org (4.1/SMI-4.1) id AA21905; Wed, 28 May 97 15:39:28 EDT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id XAA15617; Wed, 28 May 1997 23:39:19 +0400 (MSD) Received: by gamma.srcc.msu.su; Wed, 28 May 1997 23:38:48 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Wed, 28 May 1997 23:37:30 +0400 To: ASIS-Technical@sw-eng.falls-church.va.us, roby@ida.org, sblake@sd.aonix.com Cc: ASIS-Officers@sw-eng.falls-church.va.us References: <199705281803.LAA05834@puumba.telesoft> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Wed, 28 May 97 23:37:30 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: String/Wide_String : proposed solutions Lines: 41 Content-Length: 1955 Status: OR Afrer some more thoughts.... > >2. Use Wide_String exclusively at the interface level, not using > >String at all. This appears to be the way the commercial world is > >going, as Microsoft's newer releases of their operating systems are > >using 16-bit characters rather than 8-bit characters. > > I much prefer this approach. It is simple, elegant, and fair. > Standardization should not look at this approach as favoring wide_string. > All the interfaces that take a wide_string parameter will accept a converted > string value. All the interfaces that return a wide_string value can be > converted to string just as the overloadings would have to do if they were > provided. > > Duplication of these interfaces can be done in a secondary layer if a tool > so desires. In fact, the only reason for me to be strongly agains this solution is that Wide_String is *too* expensive, and that it would be too wasteful to use it for *tools* dealing with real-life Ada code. But I must confess, that being almost alone in my hole now, I cannot estimate, how importhat (and even how true) this reason is. If the Ada world is going now or just tomorrow to migrate from using String as the "base" string type to Wide_String, we should do the same. I do not think, that upward compatibility of ASIS-83 applications is really an issue (we already have enough changes in ASIS to be afraid of one more). So, if it is really acceptable to use in ASIS applications Wide_String instead of String, I would join Steve (and Clyde and Currie :). But I would definitely like to have more time to think about this! (There was the law in the old Prussian army - in case of a conflict a solger was not allowed to complain on his officer during the day when the conflict happened. Only the next day he could come to super-officer to ask for justice and defence. This was the good rule, and I would like to have this "next day" now :) Sergey Rybin From rybin@possum.srcc.msu.su Wed May 28 15:50:50 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA12964; Wed, 28 May 1997 15:50:49 -0400 Received: from crocus.gamma.ru by ida.org (4.1/SMI-4.1) id AA22149; Wed, 28 May 97 15:51:27 EDT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id XAA15727; Wed, 28 May 1997 23:51:11 +0400 (MSD) Received: by gamma.srcc.msu.su; Wed, 28 May 1997 23:50:39 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Wed, 28 May 1997 23:49:10 +0400 To: ASIS-Technical@sw-eng.falls-church.va.us, dewar@gnat.com, roby@ida.org Cc: ASIS-Officers@sw-eng.falls-church.va.us References: <9705281903.AA01311@nile.gnat.com> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Wed, 28 May 97 23:49:09 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: String/Wide_String : proposed solutions Lines: 23 Content-Length: 1109 Status: OR > <<2. Use Wide_String exclusively at the interface level, not using > String at all. This appears to be the way the commercial world is > going, as Microsoft's newer releases of their operating systems are > using 16-bit characters rather than 8-bit characters. > > Solution 2 seems to be the most elegant and simplest solution. Any > needed conversions to/from String can be performed using features in > the Ada language.>> > > I dislike this idea, I think it will cause a lot of problems in practice, > since it is so at odds with the existing RM design. But the existing RM design has already started to become obsolete! Of course, Ada 95 is still ahead a lot of other languages and technologies, but the question is - what could (and what should) we expect in Ada 200X? Do not you think, that Wide_String will take the current "position" of String, and String itself will join the obsolescent language features? If this is (will probably be) so, should we be afraid of migrating to Wide_String-only approach already now? (I myself do not know the answers, I'm just asking) Sergey From Alain.LeGuennec@enst-bretagne.fr Wed May 28 16:57:12 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id QAA13180; Wed, 28 May 1997 16:57:12 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA23454; Wed, 28 May 97 16:57:20 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id QAA1770740; Wed, 28 May 1997 16:54:38 -0400 Received: from audrey.enst-bretagne.fr by sw-eng.falls-church.va.us (8.7.1/) id UAA25686; Wed, 28 May 1997 20:53:41 GMT Received: from huygens.enst-bretagne.fr (huygens.enst-bretagne.fr [192.44.75.121]) by audrey.enst-bretagne.fr (8.8.5/8.8.5) with SMTP id WAA45769 for ; Wed, 28 May 1997 22:56:14 +0200 Received: by huygens.enst-bretagne.fr (SMI-8.6/SMI-SVR4) id WAA24552; Wed, 28 May 1997 22:56:12 +0200 To: ASIS-Technical@sw-eng.falls-church.va.us Subject: Re: String/Wide_String : proposed solutions References: <9705281903.AA01311@nile.gnat.com> From: Alain Le Guennec In-Reply-To: dewar@gnat.com's message of Wed, 28 May 97 15:03:59 EDT Date: 28 May 1997 22:56:09 +0200 Message-Id: Lines: 50 X-Mailer: Gnus v5.4.55/Emacs 19.34 Content-Length: 1930 Status: OR dewar@gnat.com (Robert Dewar) wrote: > <<2. Use Wide_String exclusively at the interface level, not using > String at all. This appears to be the way the commercial world is > going, as Microsoft's newer releases of their operating systems are > using 16-bit characters rather than 8-bit characters. > > Solution 2 seems to be the most elegant and simplest solution. Any > needed conversions to/from String can be performed using features in > the Ada language.>> > > I dislike this idea, I think it will cause a lot of problems in practice, > since it is so at odds with the existing RM design. I also dislike the idea. Although it is too late for ASIS-2.0.N, I have a better formulation of my previous proposition: I think we don't need Wide_String _at the query level_. Instead, we can simply use String everywhere, using a given encoding scheme for non-latin1 characters so that they can fit in a String. (No need of a private ASIS_String type as I previously suggested.) So the only needed changes would be: -a way to know that a String is actually an encoded Wide_String -a way to decode this string to get the Wide_String form if needed. -a Is_Equal (S1, S2) function that works correctly all the time (?) To distinguish a "normal" string of an "encoded" string, we could use the convention that a normal string has a 'First of 1 and an encoded string has a 'First of 2 (this is maybe not very clean..) and provide the following function to hide the trick: function Is_Encoded_Wide_String (S : String) return Boolean is begin return S'First > 1; end; To get the Wide_String from the encoded string, we need a second function that actually decodes the encoded string, if this form is really needed (for output purposes or whatever.) In short: -only 3 new functions -no duplication of queries -no change at all when processing normal strings (upward compatibility) Drawbacks ? (there must be some.) From eachus@spectre.mitre.org Wed May 28 17:20:57 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA13215; Wed, 28 May 1997 17:20:56 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA23820; Wed, 28 May 97 17:21:05 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id RAA1778788; Wed, 28 May 1997 17:18:32 -0400 Received: from mbunix.mitre.org by sw-eng.falls-church.va.us (8.7.1/) id VAA26202; Wed, 28 May 1997 21:17:40 GMT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id RAA01345; Wed, 28 May 1997 17:20:44 -0400 (EDT) Received: (from eachus@localhost) by spectre.mitre.org (8.8.5/8.8.5) id RAA20846; Wed, 28 May 1997 17:20:44 -0400 (EDT) Date: Wed, 28 May 1997 17:20:44 -0400 (EDT) From: "Robert I. Eachus" Message-Id: <199705282120.RAA20846@spectre.mitre.org> To: Alain.LeGuennec@enst-bretagne.fr Cc: ASIS-Technical@sw-eng.falls-church.va.us In-Reply-To: (message from Alain Le Guennec on 28 May 1997 22:56:09 +0200) Subject: Re: String/Wide_String : proposed solutions Content-Length: 1764 Status: OR Alain Le Guennec (Alain.LeGuennec@enst-bretagne.fr) asked: > I also dislike the idea. Although it is too late for ASIS-2.0.N, > I have a better formulation of my previous proposition: I think we > don't need Wide_String _at the query level_. > Instead, we can simply use String everywhere, using a given encoding > scheme for non-latin1 characters so that they can fit in a String. > (No need of a private ASIS_String type as I previously suggested.) No, use ASIS_String and define it to be UTF3? (is that the right one) from ISO 10646. For ASCII only results the conversion to Standard.String is trivial. (Actually even better would be a private type with functions To_String, To_Wide_String, Is_ASCII, and Is_Latin1. You would also require the reverse operations. Note that in Ada 95 we can base this on UTF3, Unbounded_String, and/or Unbounded_Wide_String, and not have to worry about sizes, constraints, or garbage collection. > So the only needed changes would be: > -a way to know that a String is actually an encoded Wide_String > -a way to decode this string to get the Wide_String form if needed. > -a Is_Equal (S1, S2) function that works correctly all the time (?) > To distinguish a "normal" string of an "encoded" string, we could > use the convention that a normal string has a 'First of 1 and an > encoded string has a 'First of 2 (this is maybe not very clean..) > and provide the following function to hide the trick: Ugh! and more Ugh! > Drawbacks ? (there must be some.) Not enough testing (of the proposal) will be done, that is about it. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From dewar@gnat.com Wed May 28 19:19:23 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id TAA13369; Wed, 28 May 1997 19:19:23 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA25237; Wed, 28 May 97 19:20:03 EDT Received: by nile.gnat.com (5.0/1.20) id AA00587; Wed, 28 May 97 19:17:55 EDT Date: Wed, 28 May 97 19:17:55 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705282317.AA00587@nile.gnat.com> To: ASIS-Technical@sw-eng.falls-church.va.us, roby@ida.org, rybin@possum.srcc.msu.su, sblake@sd.aonix.com Subject: Re: String/Wide_String : proposed solutions Cc: ASIS-Officers@sw-eng.falls-church.va.us Content-Length: 536 Status: OR <> There is no question of the Ada world in general migrating from String to Wide_String .. so I do not see this line of reasoning. Using Wide_String alone in ASIS would be a violation of the RM principle of trreating the two string types in an equivalent manner. From dewar@gnat.com Wed May 28 19:20:16 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id TAA13374; Wed, 28 May 1997 19:20:15 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA25245; Wed, 28 May 97 19:20:55 EDT Received: by nile.gnat.com (5.0/1.20) id AA00595; Wed, 28 May 97 19:18:49 EDT Date: Wed, 28 May 97 19:18:49 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705282318.AA00595@nile.gnat.com> To: ASIS-Technical@sw-eng.falls-church.va.us, dewar@gnat.com, roby@ida.org, rybin@possum.srcc.msu.su Subject: Re: String/Wide_String : proposed solutions Cc: ASIS-Officers@sw-eng.falls-church.va.us Content-Length: 611 Status: OR <> I do not see the basis of your evidence for the first sentence here. In fact Wide_String has extremely little usage at the current time. From dewar@gnat.com Wed May 28 19:26:12 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id TAA13386; Wed, 28 May 1997 19:26:12 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA25300; Wed, 28 May 97 19:26:17 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id TAA2123270; Wed, 28 May 1997 19:23:49 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id XAA28607; Wed, 28 May 1997 23:23:02 GMT Received: by nile.gnat.com (5.0/1.20) id AA00695; Wed, 28 May 97 19:24:02 EDT Date: Wed, 28 May 97 19:24:02 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705282324.AA00695@nile.gnat.com> To: ASIS-Technical@sw-eng.falls-church.va.us, Alain.LeGuennec@enst-bretagne.fr Subject: Re: String/Wide_String : proposed solutions Content-Length: 520 Status: OR <> This makes Wide_String a second class citizen, and I definitely dislike the encoding idea, as this will cause trouble on devices that can display wide_strings usefully. Such devices use either 16-bit characters, or they use a particular encoding, e.g. Shift-JIS that would not be suitable for standardization. From dewar@gnat.com Wed May 28 19:26:57 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id TAA13391; Wed, 28 May 1997 19:26:56 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA25316; Wed, 28 May 97 19:27:03 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id TAA1770554; Wed, 28 May 1997 19:24:38 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id XAA28616; Wed, 28 May 1997 23:23:51 GMT Received: by nile.gnat.com (5.0/1.20) id AA00705; Wed, 28 May 97 19:24:52 EDT Date: Wed, 28 May 97 19:24:52 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705282324.AA00705@nile.gnat.com> To: Alain.LeGuennec@enst-bretagne.fr, eachus@spectre.mitre.org Subject: Re: String/Wide_String : proposed solutions Cc: ASIS-Technical@sw-eng.falls-church.va.us Content-Length: 557 Status: OR << No, use ASIS_String and define it to be UTF3? (is that the right one) from ISO 10646. For ASCII only results the conversion to Standard.String is trivial. (Actually even better would be a private type with functions To_String, To_Wide_String, Is_ASCII, and Is_Latin1. You would also require the reverse operations. Note that in Ada 95 we can base this on UTF3, Unbounded_String, and/or Unbounded_Wide_String, and not have to worry about sizes, constraints, or garbage collection.>> This is getting too bizarely different from the RM for my taste. From alfred.strohmeier@di.epfl.ch Thu May 29 08:12:17 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA13803; Thu, 29 May 1997 08:12:17 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA00172; Thu, 29 May 97 08:12:13 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id IAA1759632; Thu, 29 May 1997 08:09:32 -0400 Received: from dimail.epfl.ch by sw-eng.falls-church.va.us (8.7.1/) id MAA12516; Thu, 29 May 1997 12:08:31 GMT Received: from lglsun11.epfl.ch by dimail.epfl.ch (SMI-8.6/EPFL-DI-5.2-S-MX) id OAA04296; Thu, 29 May 1997 14:09:15 +0200 Received: from lglsun12 by lglsun11.epfl.ch (SMI-8.6/EPFL-DI-5.2-MX) id OAA14729; Thu, 29 May 1997 14:11:20 +0200 Sender: astroh@di.epfl.ch Message-Id: <338D724C.12D9@di.epfl.ch> Date: Thu, 29 May 1997 14:10:52 +0200 From: Alfred Strohmeier Organization: EPFL-DI-LGL X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) Mime-Version: 1.0 To: Robert Dewar Cc: ASIS-Technical@sw-eng.falls-church.va.us, roby@ida.org, ASIS-Officers@sw-eng.falls-church.va.us Subject: Re: String/Wide_String : proposed solutions References: <9705281903.AA01311@nile.gnat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 705 Status: OR > > <<2. Use Wide_String exclusively at the interface level, not using > String at all. This appears to be the way the commercial world is > going, as Microsoft's newer releases of their operating systems are > using 16-bit characters rather than 8-bit characters. > > Solution 2 seems to be the most elegant and simplest solution. Any > needed conversions to/from String can be performed using features in > the Ada language.>> > I would strongly oppose this solution. -- Alfred -- Prof. Alfred Strohmeier, Swiss Fed Inst of Technology in Lausanne EPFL-DI-LGL, CH-1015 Lausanne, Switzerland Tel +41 21 693 4231, Fax +41 21 693 5079 mailto:alfred.strohmeier@di.epfl.ch or http://lglwww.epfl.ch/ From dewar@gnat.com Thu May 29 08:13:20 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA13812; Thu, 29 May 1997 08:13:19 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA00382; Thu, 29 May 97 08:13:56 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id GAA1789630; Thu, 29 May 1997 06:20:38 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id KAA10553; Thu, 29 May 1997 10:19:33 GMT Received: by nile.gnat.com (5.0/1.20) id AA01817; Thu, 29 May 97 06:20:33 EDT Date: Thu, 29 May 97 06:20:33 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705291020.AA01817@nile.gnat.com> To: asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su Subject: Re: RADICAL! Re: String/Wide_String problem Content-Length: 3540 Status: OR One fundamental problem here it seems to me is that ASIS is assuming that there is a connection between the characters in the source program, and the characters in String or Wide_String types. The RM of course makes no such connection. In other words, if there is an A in a program, it has nothing whatsoever to do with the A in Character or the A in Wide_Character. Using either of these types to represent source characters is therefore quite confusing. Really it would be best to have a separate type, perhaps called Source_Character, with a corresponding string type Source_String. Having separate queries for String and Wide_String for returning, e.g. a comment from the source program, really makes no conceptual sense. A single enquiry returning Source_String makes far more sense. I would guess that this is close to what ASIS_String was about, but I think it is important to understand that Source_String is specifically for representing characters that appear in the source program. One could approach the definition of Source_String two ways type Source_String is new Wide_String; This in practice is reasonable, since all the characters that can appear in the source program have corresponding representations in Wide_Character. Of course in practice some (possibly quite tricky) translation may be needed between the source code and this type, since of course there is no requirement at all that the source representation have anything to do with type Wide_Character, but that is a reaosnable requirement in an ASIS implementation. A variation of this would be subtype Source_String is Wide_String; where the name Source_String becomes just documentation to emphasize that this particular use of Source_String is for this purposes. The advantage of the subtype approach is that the wide string packages are immediately available for conveniently operating on this type without conversions. Alternatively, one can define a completely new type, but I think this is a mistake, since then the string packages are not available at all. It does not make any sense at all to use type Character in representing a source program, unless you specify a standard encoding, and the reason I think that such an encoding is undesirable is that there is no obvious standard encoding to be used. I suppose you could leave it implementation dependent, but this definitely seems undesirable. Why even consider using type Character/String to represent source characters. It's just plain inappropriate, since it does not covre all the possibilities. In other words here, I am agreeing that it makes sense to have only one set of queries where the string values involved are source related. This really is in agreement with the idea of having only the Wide_Character enquiries, but clarifies why that makes perfect sense in this case, and why it makes no sense to have String enquiries in this case. ASIS applications should work on Ada programs. Ada programs are allowed to have comments and strings that have non-Latin1 graphics. ASIS applications should therefore handle such graphics, and if you have only the Source_String version, these applications will naturally be encouraged to be wide string inclusive, rather than accidentally restricting themselves to subsets. Note that the approach of encoded strings using type String will NOT accomplish this. That's because, although the queries will return the appropriate encodings, the program has to be prepared to handle the queries, which it easily may not bother to do. From fofanov@such.srcc.msu.su Thu May 29 08:13:25 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA13816; Thu, 29 May 1997 08:13:24 -0400 Received: from by ida.org (4.1/SMI-4.1) id AB00382; Thu, 29 May 97 08:14:02 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id GAA24488; Thu, 29 May 1997 06:03:51 -0400 Received: from such.srcc.msu.su by sw-eng.falls-church.va.us (8.7.1/) id KAA10368; Thu, 29 May 1997 10:02:59 GMT Received: from uumars.UUCP (uucp@localhost) by such.srcc.msu.su (8.8.5/8.8.3) with UUCP id OAA03344 for asis-technical@sw-eng.falls-church.va.us; Thu, 29 May 1997 14:05:52 +0400 (MSD) Received: by mars.srcc.msu.su (UUPC/@ v6.14g, 04Jan96) id AA28250; Thu, 29 May 1997 14:03:25 +0400 (MSD) To: asis-technical@sw-eng.falls-church.va.us References: Message-Id: Date: Thu, 29 May 97 14:03:24 +0400 X-Mailer: BML [MS/DOS Beauty Mail v1.36h] Organization: Science Research Computer Center, Moscow State University From: fofanov@such.srcc.msu.su (Vasiliy A. Fofanov) Subject: RADICAL! Re: String/Wide_String problem Lines: 51 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2339 Status: OR Dear ASIS WG, It was already noted by Sergey Rybin and by Bill Thomas that the only two cases in which it is appropriate to speak about Wide_Strings are cases when ASIS queries either receive/return implementation specific information (Initialize, Asis_Version, Debug_Image etc.) or return source code fragments that contain comments (Comment_Image, etc.). All other queries (Library_Unit_Declaration, Value_Image etc.) CANNOT return Wide_Strings (LRM 2.1). Am I right? If that is true, than 1) Wide_String versions of 10.6, 10.7, 10.19, 13.39, 15.2, 15.3, 15.4, 17.2, 17.3, 20.25 should be removed as having no sense. 2) For case 1 (implementation specific information) a best solution seems to have only Wide_String versions of queries. Reason: it is not, as Robert Dewar puts it, favor of Wide_Strings against Strings, but just a simple stating of the fact that these queries are, essentially, an interface between ASIS and a human being, perhaps not english-speaking and perhaps unable to use plain String to represent his/ her language. Indeed, queries like Asis_Provider_Information are of no use to any ASIS application, only to humans that use it. Maybe, only control queries like Initialize require additional consideration. 3) For case 2 (Comments images), we, indeed, need two queries and the query to test which of the first two is applicable (see Allaine Le Guenec suggestion). PLEASE NOTE that for any given case of a comment image only one query is applicable - either String or Wide_String version. It is not a matter of free will! Either it is in English or it is in languages like Chinese, and you will never stuff Chinese into plain String. For this case it seems rational to use XXX and Wide_XXX versions, because overloading is not applicable. That seems to solve the problem. A bit of emotions, though. No matter what reactions will my suggestion cause, no matter even if it is true or not, it is really sorry for me to see such a hot discussion over such a serious issue in such a late stage of ASIS development. Is ASIS mature enough, I wonder again and again? Sincerely Yours, Vasiliy Fofanov. --- ------------------------------------------------------------------- Vasiliy A. Fofanov Email: fofanov@such.srcc.msu.su Ada Programmer WWW: http://such.srcc.msu.su/fofanov/ From dewar@gnat.com Thu May 29 08:13:35 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA13824; Thu, 29 May 1997 08:13:35 -0400 Received: from by ida.org (4.1/SMI-4.1) id AB00382; Thu, 29 May 97 08:14:13 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id FAA1769508; Thu, 29 May 1997 05:19:58 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id JAA09517; Thu, 29 May 1997 09:19:11 GMT Received: by nile.gnat.com (5.0/1.20) id AA22715; Thu, 29 May 97 05:20:10 EDT Date: Thu, 29 May 97 05:20:10 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705290920.AA22715@nile.gnat.com> To: Alain.LeGuennec@enst-bretagne.fr, dewar@gnat.com Subject: Re: String/Wide_String : proposed solutions Cc: ASIS-Technical@sw-eng.falls-church.va.us Content-Length: 790 Status: OR <> You miss the point. These strings will have to appear within a program, and you want to be able to edit them using your normal keyboard for editing wide string data, using whatever encoding is normal (and which of course your Ada 95 compiler accepts directly if it is properly adapted for the environment). Similarly, as you enter your program, you want these strings displayed properly. This kind of explicit encoding is a non-starter, it is a typical suggestion from someone not used to working, e.g. with the Japanese or Chinese versions of PC operating systems. From dewar@gnat.com Thu May 29 08:17:50 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA13883; Thu, 29 May 1997 08:17:50 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA00621; Thu, 29 May 97 08:18:30 EDT Received: by nile.gnat.com (5.0/1.20) id AA09511; Thu, 29 May 97 08:16:07 EDT Date: Thu, 29 May 97 08:16:07 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705291216.AA09511@nile.gnat.com> To: alfred.strohmeier@di.epfl.ch, dewar@gnat.com Subject: Re: String/Wide_String : proposed solutions Cc: ASIS-Officers@sw-eng.falls-church.va.us, ASIS-Technical@sw-eng.falls-church.va.us, roby@ida.org Content-Length: 250 Status: OR Alfred said <> I reacted that way at first but on more careful reflection, I realized that this situation is not at all parallel to the situation with, say, string packages in the RM> See my most recent note. From Alain.LeGuennec@enst-bretagne.fr Thu May 29 08:18:53 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA13891; Thu, 29 May 1997 08:18:52 -0400 Received: from by ida.org (4.1/SMI-4.1) id AB00382; Thu, 29 May 97 08:14:17 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id FAA1762792; Thu, 29 May 1997 05:06:24 -0400 Received: from audrey.enst-bretagne.fr by sw-eng.falls-church.va.us (8.7.1/) id JAA09350; Thu, 29 May 1997 09:05:26 GMT Received: from huygens.enst-bretagne.fr (huygens.enst-bretagne.fr [192.44.75.121]) by audrey.enst-bretagne.fr (8.8.5/8.8.5) with SMTP id LAA33719; Thu, 29 May 1997 11:07:50 +0200 Received: by huygens.enst-bretagne.fr (SMI-8.6/SMI-SVR4) id LAA28524; Thu, 29 May 1997 11:07:49 +0200 To: dewar@gnat.com (Robert Dewar) Cc: ASIS-Technical@sw-eng.falls-church.va.us Subject: Re: String/Wide_String : proposed solutions References: <9705282324.AA00695@nile.gnat.com> From: Alain Le Guennec In-Reply-To: dewar@gnat.com's message of Wed, 28 May 97 19:24:02 EDT Date: 29 May 1997 11:07:47 +0200 Message-Id: Lines: 36 X-Mailer: Gnus v5.4.55/Emacs 19.34 Content-Length: 1767 Status: OR dewar@gnat.com (Robert Dewar) writes: > This makes Wide_String a second class citizen, and I definitely dislike > the encoding idea, as this will cause trouble on devices that can display > wide_strings usefully. To output on such devices, just convert (decode) the encoded string to Wide_String before, and then use Wide_Text_IO (but the encoded form should be chosen so as not to cause trouble if output on a 8bits devices) My ONLY concern with a set of duplicate queries is how an ASIS application should use them. I can see 3 ways: (1)-always use String based queries (ignoring non-latin1 issues completely...) (2)-always use Wide_String based queries to handle all possible cases correctly (but this looks heavy if non-latin1 characters are actually rare) (3)-use String based queries most of the time, and use Wide_String queries in those cases we have non-latin1 characters. (1) doesn't seem right if we want a robust appli (what happens if there actually are some non-latin1 characters around ?) (2) makes String based queries somehow "obsolete"/"useless". (3) is what I prefer, but I don't know how to do it: Suppose I want to get and analyse a comment on a given line. Since I don't know _a priori_ whether this comment will contain non-latin1 characters or not, I have to use the Wide_String form to be safe, hence falling back to (2). With an "encoding" solution, I can test _a posteriori_ if I obtained a "normal" string, and if so process it "as is", or otherwise decode it and process it as a Wide_String. Looks reasonable to me. If this is not a real issue (I may be missing something, since nobody else mentionned it), then I'll be happy with any clean solution to the wide_string problem. /Alain. From fofanov@such.srcc.msu.su Thu May 29 08:37:50 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA14003; Thu, 29 May 1997 08:37:50 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA02628; Thu, 29 May 97 08:37:57 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id IAA1774504; Thu, 29 May 1997 08:35:30 -0400 Received: from such.srcc.msu.su by sw-eng.falls-church.va.us (8.7.1/) id MAA13114; Thu, 29 May 1997 12:34:43 GMT Received: from uumars.UUCP (uucp@localhost) by such.srcc.msu.su (8.8.5/8.8.3) with UUCP id QAA03713 for asis-technical@sw-eng.falls-church.va.us; Thu, 29 May 1997 16:37:39 +0400 (MSD) Received: by mars.srcc.msu.su (UUPC/@ v6.14g, 04Jan96) id AA31341; Thu, 29 May 1997 16:34:29 +0400 (MSD) To: asis-technical@sw-eng.falls-church.va.us References: <9705291020.AA01817@nile.gnat.com> Message-Id: Date: Thu, 29 May 97 16:34:28 +0400 X-Mailer: BML [MS/DOS Beauty Mail v1.36h] Organization: Science Research Computer Center, Moscow State University From: fofanov@such.srcc.msu.su (Vasiliy A. Fofanov) Subject: Re: RADICAL! Re: String/Wide_String problem Lines: 72 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3201 Status: OR Dear ASIS WG, Robert Dewar wrote: > One fundamental problem here it seems to me is that ASIS is assuming > that there is a connection between the characters in the source program, > and the characters in String or Wide_String types. The RM of course > makes no such connection. In other words, if there is an A in a program, > it has nothing whatsoever to do with the A in Character or the A in > Wide_Character. > > Using either of these types to represent source characters is therefore > quite confusing. It is an interesting point (whether or not an Ada-source can be analyzed by an Ada program (consists of entities known to Ada-program) - from philosophical point of view), however not entirely true. The RM, of course, DOES make a connection. LRM 2.1 and C.1 clearly link Ada source charset with types Character and Wide_Character. 2.1 says that an Ada program (minus comments) consists of characters of row 00 of ISO 10646 BMP. C.1 defines Wide_Character as ISO 10646, Character - as ASCII, or row 00. Therefore Character IS fit to represent Ada source (minus comments), Wide_Character may help (not necessarily, but probably) - to represent ANY Ada source. So, in most cases, for perfomance sake we should use Character, in other cases (comments) - Wide_Character. Note that in a VAST majority of cases Character is more than adequate. > Really it would be best to have a separate type, perhaps called > Source_Character, with a corresponding string type Source_String. > > Having separate queries for String and Wide_String for returning, e.g. > a comment from the source program, really makes no conceptual sense. > A single enquiry returning Source_String makes far more sense. Contradicts with LRM. Comments DIFFER from source, i.e. program (2.1), so it makes all the conceptual sense to keep them different in ASIS. The Source_Character idea is good, but it maps to Character, not to Wide_Character. > It does not make any sense at all to use type Character in representing > a source program, unless you specify a standard encoding, and the reason > I think that such an encoding is undesirable is that there is no obvious > standard encoding to be used. 2.1: ISO 8859-1 > Why even consider using type Character/String to represent source characters. > It's just plain inappropriate, since it does not covre all the > possibilities. What possibilities does it not cover? > Note that the approach of encoded strings using type String will NOT > accomplish this. That's because, although the queries will return the > appropriate encodings, the program has to be prepared to handle the > queries, which it easily may not bother to do. Perhaps so, but isn't the cost too high? In this unjust world there will always be users left out by _any_ solution, so it is important to stop before we overbalance. I feel that switching source representation to Wide_String is such overbalancing. Sincerely Yours, Vasiliy Fofanov. --- ------------------------------------------------------------------- Vasiliy A. Fofanov Email: fofanov@such.srcc.msu.su Ada Programmer WWW: http://such.srcc.msu.su/fofanov/ From jj@ddci.dk Thu May 29 09:00:11 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id JAA14035; Thu, 29 May 1997 09:00:10 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA03820; Thu, 29 May 97 09:00:12 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id IAA1759492; Thu, 29 May 1997 08:57:44 -0400 Received: from uucp.DK.net by sw-eng.falls-church.va.us (8.7.1/) id MAA13548; Thu, 29 May 1997 12:56:51 GMT Received: from ddci (uucp@localhost) by uucp.DK.net (8.6.12/8.6.12) with UUCP id OAA15949; Thu, 29 May 1997 14:59:26 +0200 Received: from sparc7.ddci.dk by ddci.dk (4.1/j1.1.2) id AA05307; Thu, 29 May 97 14:49:16 +0200 Date: Thu, 29 May 97 14:49:16 +0200 Message-Id: <9705291249.AA05307@ddci.dk> Received: by sparc7.ddci.dk (4.1/SMI-4.1) id AA27419; Thu, 29 May 97 14:47:37 +0200 From: Jesper Joergensen To: fofanov@such.srcc.msu.su Cc: asis-technical@sw-eng.falls-church.va.us In-Reply-To: (fofanov@such.srcc.msu.su) Subject: Re: RADICAL! Re: String/Wide_String problem Content-Length: 1815 Status: OR > > Dear ASIS WG, > > It was already noted by Sergey Rybin and by Bill Thomas that the only > two cases in which it is appropriate to speak about Wide_Strings are > cases when ASIS queries either receive/return implementation specific > information (Initialize, Asis_Version, Debug_Image etc.) or return > source code fragments that contain comments (Comment_Image, etc.). All > other queries (Library_Unit_Declaration, Value_Image etc.) CANNOT > return Wide_Strings (LRM 2.1). Am I right? > No, what [2.1(1)] says is that graphic_characters and format_effectors are allowed outside comments. [2.1(3)] says that graphic_character can be a special_character and [2.1(12)] in turn says that special_character can be taken from the complete ISO 10646 BMP, not only from Row 00 (which corresponds to the 8-bit characters). See also [2.1(17)]. All in all this means that 16-bit characters can appear in comments, character literals and string literals. /Jesper -- +---------------------------------------------------------------------+ | | | \_\_\_\_ \_\_\_\_ \_\_\_\_ \_ | | \_ \_ \_ \_ \_ \_ | | \_ \_ \_ \_ \_ \_\_\_ \_ | | \_ \_ \_ \_ \_ \_ | | \_\_\_\_ \_\_\_\_ \_\_\_\_ \_ | | | | Jesper Jørgensen | | DDC-I A/S Phone: +45 45 87 11 44 | | Gl. Lundtoftevej 1 B Fax: +45 45 87 22 17 | | DK-2800 Lyngby, Denmark Email: jj@ddci.dk | +---------------------------------------------------------------------+ From dewar@gnat.com Thu May 29 09:06:12 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id JAA14039; Thu, 29 May 1997 09:06:11 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA04212; Thu, 29 May 97 09:06:13 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id JAA1781060; Thu, 29 May 1997 09:03:46 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id NAA13628; Thu, 29 May 1997 13:03:00 GMT Received: by nile.gnat.com (5.0/1.20) id AA25196; Thu, 29 May 97 09:03:59 EDT Date: Thu, 29 May 97 09:03:59 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705291303.AA25196@nile.gnat.com> To: asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su Subject: Re: RADICAL! Re: String/Wide_String problem Content-Length: 5817 Status: OR Vasiliu says <> No, this is quite incorrect. First it misses my point. The types Character and Wide_Character are *encodings* of the relevant sets. The statement in the RM, let's look at the relevant one: 4 The character repertoire for the text of an Ada program consists of the collection of characters called the Basic Multilingual Plane (BMP) of the ISO 10646 Universal Multiple-Octet Coded Character Set, plus a set of format_ effectors and, in comments only, a set of other_control_functions; the coded representation for these characters is implementation defined (it need not be a representation defined within ISO-10646-1). This is talking about the character repertoire. Not about the encoding. Note that despite the confusing note at the end of this paragraph (the issues of source representation always cause confusion), there is aboslutely NO requirement that any part of the program be encoded in any way whatsoever. For example, it is fine to represent the characters in EBCDIC. Please accept this as correct, or first go and read the report of the CRG. I do not feel like revisiting this whole complex issue again! Some things to notice about the above paragraph (I think perhaps Vasiliu accidentally read para 5 which is irrelevant of course to this discussion): 1. Of course the repertoire is not restricted to row 00 2. THere is no differentiation here between comments and text, the para applies to both. There are certain characters allowed only in comments, namely additional control functions Vasiliu says <> That's wrong. The source program contains characters from the complete set in character and string constants, and these of course do not map into Character. It is quite impossible to map Ada programs into type Character. It is possible to map them into String using explicit implementation dependent encodings (e.g. EUC, Shift-JIS etc), but it would be inappropriate to enshrine any such encoding in the ASIS standard, and inappropriate. My view is that an ASIS implementation should provide a way of encoding program source as type WIDE_CHARACTER (or a type derived from WC). Moreover, for non-comment text, the encoding should be the natural one. For comments, the encoding should be the natural one apart from any additional control functions, and here the ASIS implementation shyould provide an impl defined encoding. Consider an ASIS application which wants to find all occurrences of identifier names in comments, and hook them up to their visible entities (a useful tool). This should work fine with a compiler option to allow wide characters in identifier names, without having to do anything special. Similarly, suppose that you want to identify all lexical elements appearing in comments. It shouldbe possible to handle character and string literals with no special treatment, even if they contain wide characters. By the way, the RM introduces the term character to refer to characters in the source program (and this is not related, except indirectly, to the type Character), but it does not introduce a term wide character to refer to characters that are not in the ISO Latin-1 set. I find that the use of the term wide character (in lower case, not to be confused with the Ada type WIDE_CHARACTER) to be a useful convention. For example, I want to say: If a string contains at least one wide character then .... which has nothing to do with the type of the string, which may have nothing to do with the predefined type WIDE_CHARACTER. ----------------------------- Just to add one thought here, which perhaps may save some people from reading througfh the whole CRG stuff. The RM uses the ISO graphics of row 0 for descrbing programs, but there is no requirement that these graphics be used in phyiscal equipment for processing Ada programs. For example, the character '#' may print on your printer or display as a pound stirling sign, and that does not somehow mean that your Ada compiler is invalid. So in terms of actual Ada programs used with an Ada compiler, the RM prescribes neither the appearence of the characters, nor their encoding. Of course a given implementation must clearly say how programs are encoded, and one assumes that implementors will choose to represent A as A and B as B, rather than the other way around, but there is nothing incorrect about a compiler that represents the RM character A as something that looks like a B, and vice versa (it may be unusable, but it is not somehow non-conformant). This is a vital point, often missed by people who do not clearly distinguish between a source program and its representation (the RM has a lot to say about source programs, nothing at all about their representations). From dewar@gnat.com Thu May 29 09:10:37 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id JAA14044; Thu, 29 May 1997 09:10:36 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA04367; Thu, 29 May 97 09:10:44 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id JAA1768260; Thu, 29 May 1997 09:08:17 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id NAA13764; Thu, 29 May 1997 13:07:31 GMT Received: by nile.gnat.com (5.0/1.20) id AA26347; Thu, 29 May 97 09:08:30 EDT Date: Thu, 29 May 97 09:08:30 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705291308.AA26347@nile.gnat.com> To: fofanov@such.srcc.msu.su, jj@ddci.dk Subject: Re: RADICAL! Re: String/Wide_String problem Cc: asis-technical@sw-eng.falls-church.va.us Content-Length: 1170 Status: OR Jesper says <> Exactly correct. Furthermore, in any Ada implementation which is usable in a 16-bit environment, there is almost certainly an option to allow wide characters in identifiers (in GNAT it is the -gnatiw switch). The ASIS interface should be able to handle this extension naturally, and furthermore, typical ASIS programs should by default handle this extension. By using Wide_Character everywhere, we will encourage ASIS programs to avoid accidental dependence on wester alphabets. The RM avoids this dependence, by saying quite generally that Ada programs are represented using the full BMP set, there is no reason for ASIS to encourage more resrtictive interpretations in application programs. From fofanov@such.srcc.msu.su Thu May 29 09:24:18 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id JAA14058; Thu, 29 May 1997 09:24:17 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA04742; Thu, 29 May 97 09:24:23 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id JAA1856760; Thu, 29 May 1997 09:21:55 -0400 Received: from such.srcc.msu.su by sw-eng.falls-church.va.us (8.7.1/) id NAA14023; Thu, 29 May 1997 13:21:01 GMT Received: from uumars.UUCP (uucp@localhost) by such.srcc.msu.su (8.8.5/8.8.3) with UUCP id RAA06486 for asis-technical@sw-eng.falls-church.va.us; Thu, 29 May 1997 17:24:01 +0400 (MSD) Received: by mars.srcc.msu.su (UUPC/@ v6.14g, 04Jan96) id AA31085; Thu, 29 May 1997 17:21:57 +0400 (MSD) To: asis-technical@sw-eng.falls-church.va.us References: <9705291249.AA05307@ddci.dk> Message-Id: Date: Thu, 29 May 97 17:21:56 +0400 X-Mailer: BML [MS/DOS Beauty Mail v1.36h] Organization: Science Research Computer Center, Moscow State University From: fofanov@such.srcc.msu.su (Vasiliy A. Fofanov) Subject: Re: RADICAL! Re: String/Wide_String problem Lines: 45 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1766 Status: OR Dear ASIS WG, Jesper Joergensen wrote: > > It was already noted by Sergey Rybin and by Bill Thomas that the only > > two cases in which it is appropriate to speak about Wide_Strings are > > cases when ASIS queries either receive/return implementation specific > > information (Initialize, Asis_Version, Debug_Image etc.) or return > > source code fragments that contain comments (Comment_Image, etc.). All > > other queries (Library_Unit_Declaration, Value_Image etc.) CANNOT > > return Wide_Strings (LRM 2.1). Am I right? > > > > No, what [2.1(1)] says is that graphic_characters and format_effectors are > allowed outside comments. > > [2.1(3)] says that graphic_character can be a special_character and [2.1(12)] > in turn says that special_character can be taken from the complete ISO 10646 > BMP, not only from Row 00 (which corresponds to the 8-bit characters). See also > [2.1(17)]. > > All in all this means that 16-bit characters can appear in comments, character > literals and string literals. Oops. Thank you, Jesper. Indeed, LRM states exactly that. I apologize for not reading it attentively enough. Strangely, it doesn't change my point significantly. Every time we _can_ use Character instead of anything more cumbersome, we _should_ do it. Let's read my original letter this way: ... or return source code fragments that may contain Wide_Characters (in comments and character/string literals). All other queries (Library_Unit_Declaration, etc.) CANNOT return Wide_Strings. Sincerely, Vasiliy Fofanov. --- ------------------------------------------------------------------- Vasiliy A. Fofanov Email: fofanov@such.srcc.msu.su Ada Programmer WWW: http://such.srcc.msu.su/fofanov/ From fofanov@such.srcc.msu.su Thu May 29 09:47:19 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id JAA14114; Thu, 29 May 1997 09:47:19 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA05254; Thu, 29 May 97 09:47:27 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id JAA1762716; Thu, 29 May 1997 09:44:59 -0400 Received: from such.srcc.msu.su by sw-eng.falls-church.va.us (8.7.1/) id NAA14489; Thu, 29 May 1997 13:44:08 GMT Received: from uumars.UUCP (uucp@localhost) by such.srcc.msu.su (8.8.5/8.8.3) with UUCP id RAA06534 for asis-technical@sw-eng.falls-church.va.us; Thu, 29 May 1997 17:47:10 +0400 (MSD) Received: by mars.srcc.msu.su (UUPC/@ v6.14g, 04Jan96) id AA31149; Thu, 29 May 1997 17:45:05 +0400 (MSD) To: asis-technical@sw-eng.falls-church.va.us References: <9705291308.AA26347@nile.gnat.com> Message-Id: Date: Thu, 29 May 97 17:45:04 +0400 X-Mailer: BML [MS/DOS Beauty Mail v1.36h] Organization: Science Research Computer Center, Moscow State University From: fofanov@such.srcc.msu.su (Vasiliy A. Fofanov) Subject: Re: RADICAL! Re: String/Wide_String problem Lines: 27 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1042 Status: OR Dear Robert, I now understand the issue more clearly thanks to your and Jesper's comments, and now see my error. It came to my attention, however, that Ada standard is essentially different from ASIS standard in that the later is more, how to put it, practice oriented, in the sense that Ada LRM refers to a more universal entity than ASIS spec. That makes our references to RM with connection to ASIS a bit out of scope. I think, we _can_ and _should_ add arbitrary restrictions to ASIS queries rules provided this improves the practical qualities and applications of the Specification. For instance, we may enforce usage of Latin_1 as Character set even if it will require translation here in Russia. This is the idea I wanted to express, although, it seems, was using an erroneous way to prove it. Sincerely, Vasiliy Fofanov. --- ------------------------------------------------------------------- Vasiliy A. Fofanov Email: fofanov@such.srcc.msu.su Ada Programmer WWW: http://such.srcc.msu.su/fofanov/ From dewar@gnat.com Thu May 29 11:30:54 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id LAA14409; Thu, 29 May 1997 11:30:54 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA07660; Thu, 29 May 97 11:31:01 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id LAA1768778; Thu, 29 May 1997 11:28:13 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id PAA16813; Thu, 29 May 1997 15:26:55 GMT Received: by nile.gnat.com (5.0/1.20) id AA02817; Thu, 29 May 97 11:27:54 EDT Date: Thu, 29 May 97 11:27:54 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705291527.AA02817@nile.gnat.com> To: asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su Subject: Re: RADICAL! Re: String/Wide_String problem Content-Length: 881 Status: OR Vasiliy says <> This is a bad idea, as I hope is clear from my previous notes. In practice it will be common for Ada compilers to have an option allowing wide characters in identifiers, and indeed such an option is definitely encouraged (see the CRG report). There is absolutely no reason to arrange the ASIS interface to be hostile to such an option. From dewar@gnat.com Thu May 29 11:34:56 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id LAA14418; Thu, 29 May 1997 11:34:55 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA07738; Thu, 29 May 97 11:35:00 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id LAA24536; Thu, 29 May 1997 11:32:27 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id PAA16908; Thu, 29 May 1997 15:31:41 GMT Received: by nile.gnat.com (5.0/1.20) id AA04006; Thu, 29 May 97 11:32:38 EDT Date: Thu, 29 May 97 11:32:38 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705291532.AA04006@nile.gnat.com> To: asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su Subject: Re: RADICAL! Re: String/Wide_String problem Content-Length: 1209 Status: OR <> On the other hand, GNAT certainly has an option to handle Russian properly (I forget which it is, GNAT supports Latin-1 through Latin-4 for identifiers). I see no reason why ASIS should be hostile to such options. Vasiliy, you seem to be working hard to retain Character/String instead of agreeing to what seems the obviously simpler notion that Wide_String is always more appropriate for source text, given the RM statement that says the source is made up of BMP characters. Can you explain *why* you so much want to retain CHaracter and String when they are clearly unsuitable (at least it is clear to me :-) From colket@smtp-gw.spawar.navy.mil Thu May 29 12:27:42 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id MAA14471; Thu, 29 May 1997 12:27:42 -0400 Received: from opal.spawar.navy.mil by ida.org (4.1/SMI-4.1) id AA08769; Thu, 29 May 97 12:28:07 EDT Received: from smtp-gw.spawar.navy.mil by opal.spawar.navy.mil (5.x/SMI-SVR4) id AA10524; Thu, 29 May 1997 12:18:30 -0400 Received: from ccMail by smtp-gw.spawar.navy.mil (IMA Internet Exchange 1.04b) id 38daa300; Thu, 29 May 97 12:09:20 -0400 Mime-Version: 1.0 Date: Thu, 29 May 1997 12:21:39 -0400 Message-Id: <38daa300@smtp-gw.spawar.navy.mil> From: colket@smtp-gw.spawar.navy.mil (Currie Colket) Subject: String/Wide_String - The Approach for ASIS 2.0.N To: "ASISWG/ASISRG" , colket@smtp-gw.spawar.navy.mil (Currie Colket), "Clyde Roby" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Length: 7208 Status: OR [Normally technical issues are kept from the ASIS mailing list. The String/Wide_String issue has resulted in significant discussion on the asis-technical maillist (over 40 messages, not counting duplicates), of which many of those on ASIS might be interested. The attached is a summary and the approach selected for ASIS 2.0.N] Dear ASIS, Issue #64, resulting from the WG9 Ballot, requested ASIS support both String and Wide_String. The String/Wide_String issue apparently is a very interesting one. ASIS has 42 procedure/function calls in 9 different Asis child packages having String parameters. At the last ASISWG/ASISRG meeting in March 1997, we approved issue I#0064 to support both Strings and Wide_Strings. The agreed approach was to overload each call having String parameters with a call having Wide_Sting parameters. After the meeting, it was recognized that there were 4 procedure calls and 5 function calls which would require disambiguation each time used. These 9 problematic calls were viewed as unacceptable, despite an identified process to disambiguate, since several of the procedure calls are frequently used and now messy. Initially, seven options were presented to ASIS Technical as possible unified solutions. Of the 7 options, there was no clear consensus, in fact, twice as many new options were presented. Every presented option had its spokesman as being the favorite (except option 6). Approximately half of those responding wanted the status quo (overloaded String/Wide_String interfaces - the initial resolution to Issue #064), with ambiguities resolved; almost half wanted all Wide_String interfaces to be explicit. There were suggestions to bring back ASIS_Character and ASIS_String; there were suggestions to use new string representations for source code; there were suggestions to used Tagged types with String/Wide_String resolution provided by the dispatching operations; there were suggestions to only address the Wide_String issue for interfaces having text/literal return; there was a suggestion to provide additional queries to ascertain the original form of the program; there was the suggestion to make all calls Wide_String; and there was an emerging group that wanted child packages for String versus Wide_String support. Although appealing, the child package option was rejected for ASIS 2.0.N because: - this could result in 18 new child packages - it would significantly add to the complexity and understandability of ASIS - users queried did not like the approach and felt it was too heavy handed for a solution - the quoted parallel to the situation justifying Text_Io and Wide_Text_Io is not the same. Additional queries to ascertain the original form of the program were viewed as not needed to support this issue. The question was, how should a user know which interface to use? Actually it makes little difference to the ASIS interface. The user can request the form desired and the ASIS interface would provide it. Regardless of the form in the original code, the ASIS implementation can make the conversion from String to Wide_String to support the ASIS interface or Wide_String to String [This should be OK for Wide_Strings containing Latin-1 characters, the typical situation today - However, Ada allows conversion to be implementation defined - R.M. 3.5(37)]. From a practical perspective, most ASIS users will either be exclusively String or exclusively Wide_String, with some trying to cope with both String and Wide_String (possibly as they migrate to Wide_String). It was pointed out, that several of the calls having Wide_String as a parameter do not make sense for Ada will never have a natural use of Wide_String in these situations. Hence we could eliminate the Wide_String overloading/interfaces to these functions. A possible value to having these interfaces is to support an ASIS tool developer who can develop applications totally in Wide_String with no String issues. This can be very important as the world is migrating to a 16-bit character representation. Also, it may be common practice for Ada compilers to have an option allowing wide characters in identifiers; such an option is definitely encouraged for the Ada community. My favorite solution was to simply make all interfaces use Wide_String. This appears to be the direction of industry. Microsoft is driving this with their new environments. In 10 years, the use of String could likely be found only in legacy solutions. This could also be a very simple and pragmatic solution for us. ISO 8652 could not adopt this solution as 8-bit character representation was the norm when Ada was standardized; As this is no longer the case, there is no compelling reason why ASIS could not use Wide_String exclusively, should we choose to do so. It is easy to implement on the ASIS provider side, and even easier to implement on the ASIS tool side. ASIS tools wanting to use String could easily convert from the Wide_String to String using facilities already available in Ada. For most users, the exclusive use of Wide_String would insulate them from details which are abstracted out and it would reduce the complexity of their programs. However, to use the Wide_String for all interfaces solution in ASIS 2.0.N would violate your trust, so I can only hope support for this idea grows and might be suggested as a National non-binding comment during future balloting. +-------------------------------------------------------------------+ ASIS 2.0.N has a compromise solution which should be appealing to most camps. The solution in 2.0.N is as follows => For the 33 function calls returning String, an overloaded function call returning Wide_String is provided. The context of these functions in an ASIS Application would be unambiguous. Hence ASIS users desiring String or Wide_String interfaces should have no problem with these functions. For the nine interfaces where overloading would be ambiguous, an analogous interface is provided in the form of Wide_XXX, in particular, the following have been added: 6.6 Wide_Initialize 6.8 Wide_Finalize 6.10 Wide_Set_Status 8.3 Wide_Associate 10.6 Wide_Library_Unit_Declaration 10.7 Wide_Compilation_Unit_Body 10.29 Wide_Has_Attribute 10.31 Wide_Attribute_Value 11.4 Wide_Attribute_Time Again, this is a compromise as no overarching solution was acceptable. It does eliminate the ambiguity problem. There is no impact on ASIS tool builders for those using String only. For those using Wide_String only, the impact is minimal and very straight forward. I would like to thank Steve Blake, Robert Dewar, Robert Eachus, Vasiliy Fofanov, Alain le Guennec, Jesper Jorgensen, Ron Price, Clyde Roby, Sergey Rybin, Alfred Strohmeier, and Bill Thomas who provided very wise input for this difficult issue. I plan to discuss this issue with WG9 at their meeting on 2 June for their thoughts. v/r Currie Colket Chair ASISWG/Chair ASISRG From dewar@gnat.com Thu May 29 12:50:11 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id MAA14537; Thu, 29 May 1997 12:50:11 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA09146; Thu, 29 May 97 12:50:51 EDT Received: by nile.gnat.com (5.0/1.20) id AA19955; Thu, 29 May 97 12:47:19 EDT Date: Thu, 29 May 97 12:47:19 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705291647.AA19955@nile.gnat.com> To: asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, roby@ida.org Subject: Re: String/Wide_String - The Approach for ASIS 2.0.N Content-Length: 2169 Status: OR Currie says <> I think you are rushing things here, the discussion has not begun to resolve. The decision taken is in my opinion seriously incorrect, and please note that I say that having initiallly supported it, but on further discussion, I consider my earlier contributions simply to have been misinformed. You thank me for my wise input, but it looks like you have not read it carefully! I don't mind someone making clear technical arguments as to why my position is incorrect (as you see in this discussion, I easily change my mind as I understand more). I *do* mind if you rush to judgment because of some misguided view that it is more important to have a decision fast, even if it is wrong, than to wait till the problem is fully understood. For me, this episode is worrisome. As I said earlier, a lot of people worry that the ASIS standard is being pushed through with insufficient review. This sure seems like an example. If we do not have consensus on this issue yet, it means we do not fully understand it. Obviously it is not so critical that anyone would wwant to hold things up for a slightly better solution, but in my view the solution you dictate may be seriously wrong. I am happy to take this up at the WG9 meeting if necessary, but I think it would be better to let the discussion continue for a while longer. I think you may be surprised that it resolves. I definitely do not have the foggiest idea what you are talking about when you say that the idea of using Wide_String would "violate your trust" -- what's that about??? Now it may be that the idea of using Wide_String all the time (at least hopefully renamed using a subtype declaration, is somehow flawed, but if so I do not see the flaw. Vasiliy clearly does not like the idea, and I have asked him (as you have seen if you have read all the mail) to explain further what his objections are, so that we can all understand them better. Robert Dewar From rybin@possum.srcc.msu.su Thu May 29 12:53:03 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id MAA14546; Thu, 29 May 1997 12:53:02 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA09200; Thu, 29 May 97 12:53:10 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id MAA1779284; Thu, 29 May 1997 12:50:35 -0400 Received: from crocus.gamma.ru by sw-eng.falls-church.va.us (8.7.1/) id QAA18810; Thu, 29 May 1997 16:49:43 GMT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id UAA28412; Thu, 29 May 1997 20:52:27 +0400 (MSD) Received: by gamma.srcc.msu.su; Thu, 29 May 1997 20:51:58 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Thu, 29 May 1997 20:48:29 +0400 To: asis-technical@sw-eng.falls-church.va.us, dewar@gnat.com, fofanov@such.srcc.msu.su References: <9705291532.AA04006@nile.gnat.com> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Thu, 29 May 97 20:48:29 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: RADICAL! Re: String/Wide_String problem Lines: 11 Content-Length: 554 Status: OR > Vasiliy, you seem to be working hard to retain Character/String instead > of agreeing to what seems the obviously simpler notion that Wide_String > is always more appropriate for source text, given the RM statement that > says the source is made up of BMP characters. Robert, do your last messages mean, that in the current situation the best practical solution for the ASIS draft is to cut out all the queries with String (as a parameter or a result subtype) and as a result to have Wide_String as the only string type used in ASIS? Sergey. From dewar@gnat.com Thu May 29 12:58:52 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id MAA14557; Thu, 29 May 1997 12:58:51 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA09299; Thu, 29 May 97 12:58:57 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id MAA1774684; Thu, 29 May 1997 12:56:26 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id QAA18884; Thu, 29 May 1997 16:55:31 GMT Received: by nile.gnat.com (5.0/1.20) id AA21614; Thu, 29 May 97 12:56:32 EDT Date: Thu, 29 May 97 12:56:32 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705291656.AA21614@nile.gnat.com> To: asis-technical@sw-eng.falls-church.va.us, dewar@gnat.com, fofanov@such.srcc.msu.su, rybin@possum.srcc.msu.su Subject: Re: RADICAL! Re: String/Wide_String problem Content-Length: 761 Status: OR <> Well be careful, it means that this is my current thinking, it is not the case that Dewar's current thinking = "the best practical solution". That this is true is clearly demonstrated by the fact that I have changed my mind during this discussion. But yes, my thought is that for those queries where the string involved is source text, then the use of Wide_String, probably declared as subtype Source_String is Wide_String for documentation purposes, makes the best sense. From rybin@possum.srcc.msu.su Thu May 29 14:25:53 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id OAA14749; Thu, 29 May 1997 14:25:53 -0400 Received: from crocus.gamma.ru by ida.org (4.1/SMI-4.1) id AA11493; Thu, 29 May 97 14:23:21 EDT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id WAA29686; Thu, 29 May 1997 22:21:45 +0400 (MSD) Received: by gamma.srcc.msu.su; Thu, 29 May 1997 22:21:17 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Thu, 29 May 1997 22:20:24 +0400 To: asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, roby@ida.org References: <9705291647.AA19955@nile.gnat.com> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Thu, 29 May 97 22:20:24 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: String/Wide_String - The Approach for ASIS 2.0.N Lines: 56 Content-Length: 2424 Status: OR Currie, Robert, > Currie says > > < 2.0.N would violate your trust, so I can only hope support for this > idea grows and might be suggested as a National non-binding comment > during future balloting.>> > > I think you are rushing things here, the discussion has not begun to resolve. > The decision taken is in my opinion seriously incorrect, and please note > that I say that having initiallly supported it, but on further discussion, > I consider my earlier contributions simply to have been misinformed. > > You thank me for my wise input, but it looks like you have not read it > carefully! I still think, that we have made a good progress here! First, we have realised the problem. Then, we have discussed several ways to resolve it. Third, we (that is, Clyde and Currie) have made some changes, and these changes are not the last ones! I agree, that things are rushed now. I myself changed my mind at least twice (the first preference was Wide_XXX for everything, the next - Alfreds gnandchilds for String and Wide_String, the last - Wide_String, and only Wide_String for everything). But Clyde and Currie, are (the only two) persons who are *formally* responsible for the *official* ASIS documents, they are in quite different situation, then the rest of us. Now ASIS is in the formal ISO process. If all of us agree in two things: 1. The ASIS standard will be useful; 2. To be useful, the ASIS standard should not appear too late, then ASIS should be presented to WG 9 at its Ada-Europe meeting, and we cannot change this. I think, now it is not really important, what solution for the problem will be presented at Ada-Europe, but the fact, that we know about the problem, and that we will have a chance to find some better solution, is really important. I am also not saticfied by the Currie's solution, but I myself am not ready to present the better solution to WG 9 now. What I can do, and what I'm going to do is to prepare the national non-binding comment for this problem. The problem is far from being discussed enough. (By the way, half an hour ago I had a phone discussion with Vasily, and it looked like his mind was also being changed). So, let's separate rushing enforsed by the formal situation around ASIS and the technical discussion aimed at finding some better technical solution. Sergey Rybin From dewar@gnat.com Thu May 29 14:45:36 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id OAA14764; Thu, 29 May 1997 14:45:35 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA11948; Thu, 29 May 97 14:46:15 EDT Received: by nile.gnat.com (5.0/1.20) id AA23014; Thu, 29 May 97 14:43:53 EDT Date: Thu, 29 May 97 14:43:53 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705291843.AA23014@nile.gnat.com> To: asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, roby@ida.org, rybin@possum.srcc.msu.su Subject: Re: String/Wide_String - The Approach for ASIS 2.0.N Content-Length: 376 Status: OR <> There is no rushing enforced by the formal situatoin. On the contrary, any impression of rushing is likely to derail the formal process. In this particular case, I suspect we need just a day or two more to resolve this. From eachus@spectre.mitre.org Thu May 29 14:47:18 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id OAA14773; Thu, 29 May 1997 14:47:17 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA11969; Thu, 29 May 97 14:47:20 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id OAA1773774; Thu, 29 May 1997 14:44:52 -0400 Received: from mbunix.mitre.org by sw-eng.falls-church.va.us (8.7.1/) id SAA21225; Thu, 29 May 1997 18:44:07 GMT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id OAA09962; Thu, 29 May 1997 14:47:07 -0400 (EDT) Received: (from eachus@localhost) by spectre.mitre.org (8.8.5/8.8.5) id OAA23537; Thu, 29 May 1997 14:47:06 -0400 (EDT) Date: Thu, 29 May 1997 14:47:06 -0400 (EDT) From: "Robert I. Eachus" Message-Id: <199705291847.OAA23537@spectre.mitre.org> To: asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su In-Reply-To: <9705291303.AA25196@nile.gnat.com> (dewar@gnat.com) Subject: Re: RADICAL! Re: String/Wide_String problem Content-Length: 2052 Status: OR Robert Dewar said: > No, this is quite incorrect. First it misses my point. The types > Character and Wide_Character are *encodings* of the relevant > sets. The statement in the RM, let's look at the relevant one: > 4 The character repertoire for the text of an Ada program consists > of the collection of characters called the Basic Multilingual > Plane (BMP) of the ISO 10646 Universal Multiple-Octet Coded > Character Set, plus a set of format_ effectors and, in comments > only, a set of other_control_functions; the coded representation > for these characters is implementation defined (it need not be a > representation defined within ISO-10646-1). This is correct. An Ada 95 program can have all of the BMP graphic characters in literals, but there is nothing that requires they not be used elsewhere in the source. (Well actually there is a rule about using them in Indentifiers, but a Japanese or Chinese compiler could easily recognize other encodings of begin and end, and a nice anglocentric compiler would recognize alternative representations of quotations and apostrophes.) And of course, in the mainframe world or elsewhere, EBCDIC is still acceptable as an encoding. All this may argue that we do have to bite the bullet and require explicit conversions from ASIS_String to String or Wide_String. (Incidently, I think Robert Dewar misunderstood some of what I said. If we have an ASIS_String type, it should be an ADT with conversions to String and Wide_String provided, and a way for, say EBCDIC, implementations to add other conversions. The actual implementation strategy is well outside the standard, I was just pointing out the advantages of making it private without discriminants. (An implementation can trivally use Unbounded_String or Unbounded_Wide_String to implement such an ADT, but that implementation should be required to be hidden.) Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From dewar@gnat.com Thu May 29 15:03:11 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA14784; Thu, 29 May 1997 15:03:11 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA12297; Thu, 29 May 97 15:03:06 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id PAA2123330; Thu, 29 May 1997 15:00:29 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id SAA21575; Thu, 29 May 1997 18:59:44 GMT Received: by nile.gnat.com (5.0/1.20) id AA27532; Thu, 29 May 97 15:00:42 EDT Date: Thu, 29 May 97 15:00:42 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705291900.AA27532@nile.gnat.com> To: asis-technical@sw-eng.falls-church.va.us, eachus@spectre.mitre.org, fofanov@such.srcc.msu.su Subject: Re: RADICAL! Re: String/Wide_String problem Content-Length: 1002 Status: OR << All this may argue that we do have to bite the bullet and require explicit conversions from ASIS_String to String or Wide_String. (Incidently, I think Robert Dewar misunderstood some of what I said. If we have an ASIS_String type, it should be an ADT with conversions to String and Wide_String provided, and a way for, say EBCDIC, implementations to add other conversions. The actual implementation strategy is well outside the standard, I was just pointing out the advantages of making it private without discriminants. (An implementation can trivally use Unbounded_String or Unbounded_Wide_String to implement such an ADT, but that implementation should be required to be hidden.)>> I still prefer this not be hidden -- seems too heavy, and if you are going to require conversions to wide string, and if in fact the program will be working with the wide strings, why not just get right there. What is the valkuye in this extra abstraction -- seems to just add complexity with no gain to me. From rybin@possum.srcc.msu.su Thu May 29 15:43:35 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA14936; Thu, 29 May 1997 15:43:35 -0400 Received: from crocus.gamma.ru by ida.org (4.1/SMI-4.1) id AA13381; Thu, 29 May 97 15:44:06 EDT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id XAA00650; Thu, 29 May 1997 23:43:16 +0400 (MSD) Received: by gamma.srcc.msu.su; Thu, 29 May 1997 23:43:03 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Thu, 29 May 1997 23:36:06 +0400 To: asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, roby@ida.org, rybin@possum.srcc.msu.su Cc: asis-technical@sw-eng.falls-church.va.us References: <9705291843.AA23014@nile.gnat.com> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Thu, 29 May 97 23:36:06 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: String/Wide_String - The Approach for ASIS 2.0.N Lines: 67 Content-Length: 2629 Status: OR > < ASIS and the technical discussion aimed at finding some better > technical solution.>> > > There is no rushing enforced by the formal situatoin. On the contrary, > any impression of rushing is likely to derail the formal process. > In this particular case, I suspect we need just a day or two more to > resolve this. We definitely do not have a consensus here, and we definitely need it. Let's try to take the time we have to resolve the issue, because, after some thoughts conserning my previous message I've found it a bit silly to say "yes" to the Currie's solution and to be going to prepare the official comment which should say "no" soon. First, at least two of us - Robert and me - do not like the proposed solution now. Second, I think, now we have the only alternative to discuss - to use Wide_String for all the string-related queries, and not to use String at all (and this would eliminate all the problems with overloading). What are the strong points of this alternative: 1. It is *very* simply to make this change. It is easier to introduce and to understand, that what has been suggested by Currie. 2. Wide_String is enough to represend any legal lexical element and any fragment of the source code of any legal Ada stuff. 3. This eliminates all the problems with overloading and ambiguoty. 4. ASIS needs Wide_String anyway. 5. ??? What are (possible) week points of this alternative: 1. String will disappear from ASIS. - but what's wrong or bad from this? Who needs namely the predefined String type, and if somebody needs it, what for? - as for the ASIS-83-based legacy code (if any!?), the conversion functions from Ada.Characters.Handling could give at least some "first quick solution"; 2. Wide_String is of very limited use in today's Ada programming. - again, what's wrong or bad from this - what about tomorrow; - what about Japan, Europe with different acsents, China and Russia (why not? you never know where you are with this country :) 3. Wide_String is too expensive - is it really so? 4. ?? Questions to discuss: 1. "External" representation and encoing/decoding. I think, in no case this should be the busyness of the ASIS definition. The general rule may (should) be: if a symbol is from the legal Ada source, it should have the counterpart in Wide_Character, and this counterpart should be returned by an ASIS query. 2. Wide_String or its "renaming" by subtyping in Asis_String? I have no opinion... Sergey From dewar@gnat.com Thu May 29 15:46:01 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA14951; Thu, 29 May 1997 15:46:01 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA13446; Thu, 29 May 97 15:46:40 EDT Received: by nile.gnat.com (5.0/1.20) id AA10168; Thu, 29 May 97 15:44:29 EDT Date: Thu, 29 May 97 15:44:29 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705291944.AA10168@nile.gnat.com> To: asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, roby@ida.org, rybin@possum.srcc.msu.su Subject: Re: String/Wide_String - The Approach for ASIS 2.0.N Cc: asis-technical@sw-eng.falls-church.va.us Content-Length: 565 Status: OR <<2. Wide_String is of very limited use in today's Ada programming. - again, what's wrong or bad from this - what about tomorrow; - what about Japan, Europe with different acsents, China and Russia (why not? you never know where you are with this country :) 3. Wide_String is too expensive - is it really so?>> regarding 2, it is in limited use, but is fully implemented in Ada 95 compilers, since it is part of the core. regarding 3, the extra expense is very small, pretty much zero on most RISC machines, apart from the extra space required. From Alain.LeGuennec@enst-bretagne.fr Thu May 29 16:42:35 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id QAA15046; Thu, 29 May 1997 16:42:35 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA14619; Thu, 29 May 97 16:42:13 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id QAA1773812; Thu, 29 May 1997 16:39:32 -0400 Received: from melimelo.enst-bretagne.fr by sw-eng.falls-church.va.us (8.7.1/) id UAA24490; Thu, 29 May 1997 20:38:39 GMT Received: from icare.enst-bretagne.fr (icare.enst-bretagne.fr [192.44.75.138]) by melimelo.enst-bretagne.fr (8.8.5/8.8.5) with SMTP id WAA43356; Thu, 29 May 1997 22:41:12 +0200 Received: by icare.enst-bretagne.fr (SMI-8.6/SMI-SVR4) id WAA14262; Thu, 29 May 1997 22:41:10 +0200 To: dewar@gnat.com (Robert Dewar) Cc: asis-technical@sw-eng.falls-church.va.us Subject: Re: RADICAL! Re: String/Wide_String problem References: <9705291020.AA01817@nile.gnat.com> From: Alain Le Guennec In-Reply-To: dewar@gnat.com's message of Thu, 29 May 97 06:20:33 EDT Date: 29 May 1997 22:41:08 +0200 Message-Id: Lines: 38 X-Mailer: Gnus v5.4.55/Emacs 19.34 Content-Length: 2018 Status: OR Robert Dewar wrote: > In other words here, I am agreeing that it makes sense to have only one > set of queries where the string values involved are source related. This > really is in agreement with the idea of having only the Wide_Character > enquiries, but clarifies why that makes perfect sense in this case, and > why it makes no sense to have String enquiries in this case. That's exactly the issue I was trying to explain: Having 2 sets of queries was very confusing to me. Now the main difference between 2 of the proposed solutions with one set of queries (ie Wide_String (or Source_String) vs String+encoding) is that using Wide_String indeed _forces_ the applications to correctly handle the non-latin1 characters occurences, whereas a call to Is_Encoded_String plus the associated processing could _very_ easily be neglicted or forgotten, leading for example to complete junk being displayed on the screen. So I find the idea of having a "Source_String" type really appealing. Still, I don't know what is best between a public subtyping of Wide_String or a private type. By using a private type, the actual choice between Wide_String, or String+encoding, or whatever, can be hiden as an implementation detail, as suggested by Robert I. Eachus. But then there might be too much overhead because of conversion routines (couldn't inlining help here ?) > ASIS applications should work on Ada programs. Ada programs are allowed > to have comments and strings that have non-Latin1 graphics. ASIS > applications should therefore handle such graphics, and if you have > only the Source_String version, these applications will naturally be > encouraged to be wide string inclusive, rather than accidentally > restricting themselves to subsets. > > Note that the approach of encoded strings using type String will NOT > accomplish this. That's because, although the queries will return the > appropriate encodings, the program has to be prepared to handle the > queries, which it easily may not bother to do. From eachus@spectre.mitre.org Thu May 29 16:49:33 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id QAA15064; Thu, 29 May 1997 16:49:33 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA14762; Thu, 29 May 97 16:49:26 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id QAA2123478; Thu, 29 May 1997 16:46:40 -0400 Received: from mbunix.mitre.org by sw-eng.falls-church.va.us (8.7.1/) id UAA24554; Thu, 29 May 1997 20:45:45 GMT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id QAA28323; Thu, 29 May 1997 16:48:45 -0400 (EDT) Received: (from eachus@localhost) by spectre.mitre.org (8.8.5/8.8.5) id QAA23881; Thu, 29 May 1997 16:48:41 -0400 (EDT) Date: Thu, 29 May 1997 16:48:41 -0400 (EDT) From: "Robert I. Eachus" Message-Id: <199705292048.QAA23881@spectre.mitre.org> To: dewar@gnat.com Cc: asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su In-Reply-To: <9705291900.AA27532@nile.gnat.com> (dewar@gnat.com) Subject: Re: RADICAL! Re: String/Wide_String problem Content-Length: 2353 Status: OR Robert Dewar said: > I still prefer this not be hidden -- seems too heavy, and if you > are going to require conversions to wide string, and if in fact > the program will be working with the wide strings, why not just > get right there. What is the value in this extra abstraction -- > seems to just add complexity with no gain to me. The advantage to a private ADT can be seen in the EBCDIC case, or for that matter a compiler for a Latin/Cyrillic environment. Normal useage in such an environment would be to convert from ASIS_String to EBCDIC_String or whatever. While the text would be heavy, the actual work done would be trivial. However if ASIS required conversion to ASCII (or BMP) then the user needed to backconvert...Ugh! There is also a reason in the vanilla environment. Since the Unbounded_String type is available as an option, this allows those functions to be called in a loop in a program without heavy visible semantic weight: My_String: ASIS_String; ... loop My_String := ASIS_Operation(Parameters); Do_Something(My_String); exit when... end loop; instead of: loop declare My_String: String := ASIS_Operation(Parameters); begin Do_Something(My_String); exit when... end; end loop; (Almost) semantically equivalent, but much messier. Now I don't argue that these reasons--in and of themselves--justify the overhead in other situations. But it does completely and correctly deal with the issue at hand. It might not be the right solution here but it is nice to have at least one CORRECT solution on the table. And yes, the hidden implementation could be a tagged type, with String, Wide_String, and EBCDIC subclasses. Very heavy for most users, for some it might be just what the doctor ordered. This is why I feel that hiding the solution chosen from the user feels right. On the other hand, I think that having String, Wide_String, and ASIS_String versions of every operation would be way too heavy. As Robert Dewar said we are converging. And I think that just knowing that at least one completely correct solution exists is a lot of progress. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From moorej@mail04.mitre.org Thu May 29 17:03:48 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA15088; Thu, 29 May 1997 17:03:48 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA15049; Thu, 29 May 97 17:03:31 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id RAA1765264; Thu, 29 May 1997 17:00:51 -0400 Received: from mbunix.mitre.org by sw-eng.falls-church.va.us (8.7.1/) id UAA24963; Thu, 29 May 1997 20:59:53 GMT Received: from TGATE1 (tgate1.mitre.org [128.29.154.210]) by mbunix.mitre.org (8.8.5/8.8.5/mitre.0) with SMTP id RAA00326; Thu, 29 May 1997 17:02:55 -0400 (EDT) Received: from mail04.mitre.org (128.29.101.3) by tgate1.mitre.org (EMWAC SMTPRS 0.60) with SMTP id ; Thu, 29 May 1997 17:02:51 -0400 Received: by mail04.mitre.org; (5.65v3.0/1.1.8.2/22Jun94-0628PM) id AA14860; Thu, 29 May 1997 17:02:54 -0400 Subject: Re: String/Wide_String - The Approach for ASIS 2.0.N From: moorej@mail04.mitre.org (James W. Moore, reply to moorej@acm.org) To: colket@smtp-gw.spawar.navy.mil (Currie Colket), asis@sw-eng.falls-church.va.us (ASISWG/ASISRG), colket@smtp-gw.spawar.navy.mil (Currie Colket) Message-Id: <970529170252.9800@mail04.mitre.org.0> Date: Thu, 29 May 97 17:02:52 -0400 X-Mailer: MailWorks 2.0-4 Content-Length: 352 Status: OR Currie, >I plan to discuss this issue with WG9 at their meeting on 2 June for their >thoughts. Don't make the mistake of asking WG9 to make a decision for you. You do not have the time available to you for proper consideration, and there's no way that I can give you more. > >v/r >Currie Colket >Chair ASISWG/Chair ASISRG > > Regards, Jim Moore From dewar@gnat.com Thu May 29 18:36:03 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id SAA15512; Thu, 29 May 1997 18:36:03 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA16383; Thu, 29 May 97 18:36:08 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id SAA1765372; Thu, 29 May 1997 18:33:39 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id WAA27368; Thu, 29 May 1997 22:32:43 GMT Received: by nile.gnat.com (5.0/1.20) id AA22105; Thu, 29 May 97 18:33:41 EDT Date: Thu, 29 May 97 18:33:41 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705292233.AA22105@nile.gnat.com> To: Alain.LeGuennec@enst-bretagne.fr, dewar@gnat.com Subject: Re: RADICAL! Re: String/Wide_String problem Cc: asis-technical@sw-eng.falls-church.va.us Content-Length: 668 Status: OR <> I still don't understand the advantage. if you have to provide the conversion routine anyway, and if people have to call the conversoin routine to use the thing, what is the advantage of the extra level of abstraction. From dewar@gnat.com Thu May 29 18:36:52 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id SAA15517; Thu, 29 May 1997 18:36:51 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA16397; Thu, 29 May 97 18:36:59 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id SAA1786698; Thu, 29 May 1997 18:34:24 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id WAA27380; Thu, 29 May 1997 22:33:33 GMT Received: by nile.gnat.com (5.0/1.20) id AA22140; Thu, 29 May 97 18:34:33 EDT Date: Thu, 29 May 97 18:34:33 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705292234.AA22140@nile.gnat.com> To: dewar@gnat.com, eachus@spectre.mitre.org Subject: Re: RADICAL! Re: String/Wide_String problem Cc: asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su Content-Length: 577 Status: OR << The advantage to a private ADT can be seen in the EBCDIC case, or for that matter a compiler for a Latin/Cyrillic environment. Normal useage in such an environment would be to convert from ASIS_String to EBCDIC_String or whatever. While the text would be heavy, the actual work done would be trivial. However if ASIS required conversion to ASCII (or BMP) then the user needed to backconvert...Ugh!>> I don't see this, the ASIS program would be using Wide_String, it would be completely unaware that the compiler used EBCDIC internally, and would not need to be aware. From eachus@spectre.mitre.org Thu May 29 19:35:50 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id TAA15541; Thu, 29 May 1997 19:35:49 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA16896; Thu, 29 May 97 19:35:54 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id TAA1760334; Thu, 29 May 1997 19:33:20 -0400 Received: from mbunix.mitre.org by sw-eng.falls-church.va.us (8.7.1/) id XAA28478; Thu, 29 May 1997 23:32:28 GMT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id TAA14416; Thu, 29 May 1997 19:35:28 -0400 (EDT) Received: (from eachus@localhost) by spectre.mitre.org (8.8.5/8.8.5) id TAA24633; Thu, 29 May 1997 19:35:28 -0400 (EDT) Date: Thu, 29 May 1997 19:35:28 -0400 (EDT) From: "Robert I. Eachus" Message-Id: <199705292335.TAA24633@spectre.mitre.org> To: dewar@gnat.com Cc: asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su In-Reply-To: <9705292234.AA22140@nile.gnat.com> (dewar@gnat.com) Subject: Re: RADICAL! Re: String/Wide_String problem Content-Length: 2191 Status: OR Robert Dewar said: > I don't see this, the ASIS program would be using Wide_String, it > would be completely unaware that the compiler used EBCDIC > internally, and would not need to be aware. I don't see that. Well in the GNAT implementation, there is no need to access GNAT created files for most of ASIS. But with "traditional" Ada compilers there must be some interface between the compiler created data structures and the ASIS implementation. If the compiler vendor provided ASIS interface had to convert to match the ASIS defined interface, then the user needed to backconvert to print you would get exactly that behavior. In fact what would happen with GNAT and an ASIS implementation on an EBCDIC machine? Someone would have to read Ada source files in EBCDIC, and convert to Latin1 to meet the spec. In my version those conversions don't have to happen unless the user's program actually needs to look into the Latin1 representation. (For those who haven't dealt with these issues, the time saved or not saved is trivial. The problem is that you need to insure that the EBCDIC to Latin1 and Latin1 to EBCDIC conversions are one-to-one and onto. This is hard enough for 7-bit ASCII and EBCDIC, but is made much worse by "national" versions of EBCDIC and ASCII (actually ISO-646). How do you translate the 10 "national use" positions in say Denmark into EBCDIC. I don't know and don't want to have to find out if there is a way to pass the EBCDIC through unmolested.) Less it seem that I am arguing too strenuously for this position, let me repeat, that I think that the current problems are not serious enough to justify this big a change at this stage of the process. However, if we do have political problems with the easier fixes, let's at least have what we would do with a clean sheet of paper in front of us. (But I would be very happy with a solution which did one of the minimal fixes to the current version, and added an informative annex explaining how to extend ASIS in non-BMP environments. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From dewar@gnat.com Thu May 29 19:52:40 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id TAA15558; Thu, 29 May 1997 19:52:39 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA17039; Thu, 29 May 97 19:52:45 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id TAA1856628; Thu, 29 May 1997 19:50:17 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id XAA28699; Thu, 29 May 1997 23:49:24 GMT Received: by nile.gnat.com (5.0/1.20) id AA22734; Thu, 29 May 97 19:50:24 EDT Date: Thu, 29 May 97 19:50:24 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705292350.AA22734@nile.gnat.com> To: dewar@gnat.com, eachus@spectre.mitre.org Subject: Re: RADICAL! Re: String/Wide_String problem Cc: asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su Content-Length: 2523 Status: OR << I don't see that. Well in the GNAT implementation, there is no need to access GNAT created files for most of ASIS. But with "traditional" Ada compilers there must be some interface between the compiler created data structures and the ASIS implementation. If the compiler vendor provided ASIS interface had to convert to match the ASIS defined interface, then the user needed to backconvert to print you would get exactly that behavior. In fact what would happen with GNAT and an ASIS implementation on an EBCDIC machine? Someone would have to read Ada source files in EBCDIC, and convert to Latin1 to meet the spec. In my version those conversions don't have to happen unless the user's program actually needs to look into the Latin1 representation. >> Internally GNAT would convert everything to ASCII/ISO in any case in such a compiler. And if it did, not, it still has to implement the conversion. In practice in ASIS applicatoins if you go get a comment, you probably want to look at it. I don't mind terribly adding the extra level of complexity and abstraction but (a) it considerably complicates the existing definition and changes it (b) if this was a good idea it would already have been done. Discussoins about Character/Wide_Character are really completely orthogonal to this kind of abstraction. (c) there is no hope of doing this big a chnage in the interface without causing a big delay (d) the advantage is at most minimal (in practice you know perfectly well that there will never b4e an EBCDIC implementation of Ada 95, and if there is, minor worries about efficiency in the ASIS interface hardly seem significant (e) the switch to use wide_character/wide_string exclusively is a very easy one, even easier, as Sergey points out, than Currie's suggested solution. Bob (Eachus), it really seems like you are trying to add a completely new feature, one that has essentially already been rejected (by abandoning ASIS_Character and ASIS_String). Why do you feel that the addition of this feature is suddely necessary at this stage? We are trying to solve a problem, not make improvements at this stage. Are you really sure that this is important enough to hold things up, because that is the effect of your argument at this stage. Please don't get into a lets-discuss-for-the-sake-of-discusion mode, since it can do a lot of damage at this stage. Let's look for a minimal acceptable solution to an awkaward problem, let's NOT try to sneak in new features at this late stage. From eachus@spectre.mitre.org Thu May 29 20:25:22 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id UAA15584; Thu, 29 May 1997 20:25:22 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA17438; Thu, 29 May 97 20:25:28 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id UAA1777388; Thu, 29 May 1997 20:22:57 -0400 Received: from mbunix.mitre.org by sw-eng.falls-church.va.us (8.7.1/) id AAA29301; Fri, 30 May 1997 00:22:10 GMT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id UAA17224; Thu, 29 May 1997 20:25:15 -0400 (EDT) Received: (from eachus@localhost) by spectre.mitre.org (8.8.5/8.8.5) id UAA24731; Thu, 29 May 1997 20:25:15 -0400 (EDT) Date: Thu, 29 May 1997 20:25:15 -0400 (EDT) From: "Robert I. Eachus" Message-Id: <199705300025.UAA24731@spectre.mitre.org> To: dewar@gnat.com, asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su In-Reply-To: <9705292350.AA22734@nile.gnat.com> (dewar@gnat.com) Subject: Re: RADICAL! Re: String/Wide_String problem Content-Length: 2378 Status: OR Robert Dewar said: > Why do you feel that the addition of this feature is suddely necessary > at this stage? I don't. > Are you really sure that this is important enough to hold things > up, because that is the effect of your argument at this stage. Definitely not my objective. I'm the one who has been saying that we can fix the problem with little real change, and the approach chosen is acceptable to me. (In fact my largest objection to that solution is just the point Robert Dewar is making here--reviewing it may hold things up if it is seen as major.) My discussion is vis-a-vis Robert's all Wide_String solution, which I don't think will fly politically. If we do decide that the generality is required, and WG9 finds the current multiple interface proposal is unacceptable, then Robert and I can have at it about which "full" solution is better. But for now the only reason i am expounding/perfecting the ASIS_String solution is that we need to be able to see how far from perfect the current proposal is. In my opinion it isn't all that far. Compilers for Chinese and other large alphabet markets which don't use Unicode, and compilers for obsolete EBCDIC mainframes will need to extend the standard. I am quite comfortable with that. But I do think that political acceptance will require showing that we considered the issue and are willing to allow the extentions if anyone ever provides them. In other words, for some (unknown today) implementation, there might be a need for both JIS and Unicode version of the functions. Fine. It takes is a line or two in the standard, and maybe a paragraph to explain why it is there: ("Implementations are allowed to provide addition subprograms which support other string types, such as the four-octet form in ISO 10646. Where subprograms with Wide_Character parameters or results have the prefix Wide_ these additional suprograms must have a different prefix such as Quad_. Where String and Wide_String suprograms have the same name, additional overloadings are permitted.") > Let's look for a minimal acceptable solution to an awkaward > problem, let's NOT try to sneak in new features at this late > stage. Amen. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From dewar@gnat.com Thu May 29 20:44:18 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id UAA15596; Thu, 29 May 1997 20:44:18 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA17613; Thu, 29 May 97 20:40:35 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id UAA1775940; Thu, 29 May 1997 20:38:02 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id AAA29606; Fri, 30 May 1997 00:37:16 GMT Received: by nile.gnat.com (5.0/1.20) id AA22908; Thu, 29 May 97 20:38:16 EDT Date: Thu, 29 May 97 20:38:16 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9705300038.AA22908@nile.gnat.com> To: asis-technical@sw-eng.falls-church.va.us, dewar@gnat.com, eachus@spectre.mitre.org, fofanov@such.srcc.msu.su Subject: Re: RADICAL! Re: String/Wide_String problem Content-Length: 1571 Status: OR << My discussion is vis-a-vis Robert's all Wide_String solution, which I don't think will fly politically. If we do decide that the generality is required, and WG9 finds the current multiple interface proposal is unacceptable, then Robert and I can have at it about which "full" solution is better. But for now the only reason i am expounding/perfecting the ASIS_String solution is that we need to be able to see how far from perfect the current proposal is. In my opinion it isn't all that far.>> I thought this at first too (that wide string only would not fly politically). That was before I realized that the RM is quite specific in making the connection between source representation character set and WIDE_CHARACTER, NOT CHARACTER. This is quite unambiguous in the relevant para, and it seems clear that the use of Wide_Character (alone) is the only appropriate reaction to the RM para that says 4 The character repertoire for the text of an Ada program consists of the collection of characters called the Basic Multilingual Plane (BMP) of the ISO 10646 Universal Multiple-Octet Coded Character Set, plus a set of format_ effectors and, in comments only, a set of other_control_functions; the coded representation for these characters is implementation defined (it need not be a representation defined within ISO-10646-1). This para does not have the slightest hint that it would be appropriate to restrict tools dealing with this domain to type Character, it is quite explicit that BMP is the appropriate collection, and that is Wide_Character in Ada! From fofanov@such.srcc.msu.su Mon Jun 2 09:46:45 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id JAA20306; Mon, 2 Jun 1997 09:46:44 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA24841; Mon, 2 Jun 97 09:46:50 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id JAB1763212; Mon, 2 Jun 1997 09:40:51 -0400 Received: from such.srcc.msu.su by sw-eng.falls-church.va.us (8.7.1/) id NAA07468; Mon, 2 Jun 1997 13:39:07 GMT Received: from uumars.UUCP (uucp@localhost) by such.srcc.msu.su (8.8.5/8.8.3) with UUCP id RAA22223 for asis-technical@sw-eng.falls-church.va.us; Mon, 2 Jun 1997 17:41:55 +0400 (MSD) Received: by mars.srcc.msu.su (UUPC/@ v6.14g, 04Jan96) id AA31213; Mon, 2 Jun 1997 17:36:42 +0400 (MSD) To: asis-technical@sw-eng.falls-church.va.us References: <9705291647.AA19955@nile.gnat.com> Message-Id: Date: Mon, 2 Jun 97 17:36:41 +0400 X-Mailer: BML [MS/DOS Beauty Mail v1.36h] Organization: Science Research Computer Center, Moscow State University From: fofanov@such.srcc.msu.su (Vasiliy A. Fofanov) Subject: String/Wide_String Discussion - final vote Lines: 19 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 651 Status: OR Dear ASIS WG, Upon further consideration, I vote for Wide_String-only solution (perhaps overlaid by Source_String, ASIS_String or whatever). A bit late for ASIS WG meeting (could not get hold on my mailbox earlier), just to inform you all of my final decision and conclude my participation in the discussion at hand. Personal thanks to Robert Dewar and Sergey Rybin for explaining to me the error of my ways ;-) Sincerely Yours, Vasiliy. --- ------------------------------------------------------------------- Vasiliy A. Fofanov Email: fofanov@such.srcc.msu.su Ada Programmer WWW: http://such.srcc.msu.su/fofanov/ From dewar@gnat.com Mon Jun 9 07:16:10 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id HAA01488; Mon, 9 Jun 1997 07:16:10 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA08799; Mon, 9 Jun 97 07:16:22 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id HAA1372536; Mon, 9 Jun 1997 07:13:33 -0400 Received: from wormhole.mtc.iitri.com by sw-eng.falls-church.va.us (8.7.1/) id LAA27505; Mon, 9 Jun 1997 11:12:36 GMT Received: from nile.gnat.com by mtc.iitri.com (4.1/3.1.090690-IITRI-MTC) id AA01743; Sat, 7 Jun 97 07:12:10 EDT Received: by nile.gnat.com (5.0/1.20) id AA29264; Sat, 7 Jun 97 07:07:12 EDT Date: Sat, 7 Jun 97 07:07:12 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9706071107.AA29264@nile.gnat.com> To: asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su Subject: Re: String/Wide_String Discussion - final vote Content-Length: 472 Status: OR <> Well a lot of us (including me) got this wrong first time around (I was not the one who originall suggested the wide character only solution). The whole point of email discussion is to learn :-) From dewar@gnat.com Mon Jun 16 17:44:09 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA11101; Mon, 16 Jun 1997 17:44:09 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA29924; Mon, 16 Jun 97 17:44:55 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id RAA1375102 for ; Mon, 16 Jun 1997 17:44:40 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id VAA01915; Mon, 16 Jun 1997 21:41:29 GMT Received: by nile.gnat.com (5.0/1.20) id AA13332; Mon, 16 Jun 97 17:42:09 EDT Date: Mon, 16 Jun 97 17:42:09 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9706162142.AA13332@nile.gnat.com> To: ASIS-officers@sw-eng.falls-church.va.us, cooper@longshot.ds.boeing.com, dewar@gnat.com, rybin@possum.srcc.msu.su Subject: Re: Restarting String/Wide_String discussion (Re: Draft ASIS Announcement!!!! Please Comment ASAP!!!! Content-Length: 217 Status: OR <> I do not understand, in what sense is this a compromise? From rybin@possum.srcc.msu.su Tue Jun 17 08:26:24 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA11632; Tue, 17 Jun 1997 08:26:23 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA06259; Tue, 17 Jun 97 08:27:09 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id IAA1757322 for ; Tue, 17 Jun 1997 08:26:53 -0400 Received: from crocus.gamma.ru by sw-eng.falls-church.va.us (8.7.1/) id MAA17352; Tue, 17 Jun 1997 12:23:43 GMT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id QAA10979; Tue, 17 Jun 1997 16:26:40 +0400 (MSD) Received: by gamma.srcc.msu.su; Tue, 17 Jun 1997 16:25:45 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Tue, 17 Jun 1997 15:04:57 +0400 To: ASIS-officers@sw-eng.falls-church.va.us, cooper@longshot.ds.boeing.com, dewar@gnat.com References: <9706162142.AA13332@nile.gnat.com> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Tue, 17 Jun 97 15:04:56 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: Restarting String/Wide_String discussion (Re: Draft ASIS Announcement!!!! Please Comment ASAP!!!! Lines: 21 Content-Length: 859 Status: OR > < the participants agreed, that Wide_String-only solution was the best > compromise. > >> > > I do not understand, in what sense is this a compromise? Sorry, I was not quite correct in technical sense. For me, it was a compromise in some "emotional" sense - I did not like the problem itself, I did not like any of the proposed solutions, and I did not like the situation when (before the ISO meeting) we had to discuss this problem in hurry. And for me Wide_String-only approach was the best solution choosen from not very good solutions. Now, after some thoughts, and when we are not in hurry, I'm sure, that the solution used in 2.0.N chould be changed, and I do not have any idea better then Wide_String-only solution. And, for sure, it is not a compromise Sergey From dewar@gnat.com Tue Jun 17 08:32:19 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA11641; Tue, 17 Jun 1997 08:32:18 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA06374; Tue, 17 Jun 97 08:33:03 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id IAA2252408 for ; Tue, 17 Jun 1997 08:32:48 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id MAA17517; Tue, 17 Jun 1997 12:29:37 GMT Received: by nile.gnat.com (5.0/1.20) id AA12151; Tue, 17 Jun 97 08:30:18 EDT Date: Tue, 17 Jun 97 08:30:18 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9706171230.AA12151@nile.gnat.com> To: ASIS-officers@sw-eng.falls-church.va.us, cooper@longshot.ds.boeing.com, dewar@gnat.com, rybin@possum.srcc.msu.su Subject: Re: Restarting String/Wide_String discussion (Re: Draft ASIS Announcement!!!! Please Comment ASAP!!!! Content-Length: 1082 Status: OR To summarize, the viewpoint is the following (the wide string only viewpoint) The Ada 95 RM says that "teh character repertoire for the text of an Ada program consistes .. of .. BMP ..." (this is RM 2.1(4)) Thus it is clear that any enquiry that returns a string of such characters must use a reprsentation that can encompass the stated domain, namely BMP. Obviously using String/Character is inappropriate, since these cannot encompass the required domain. Thus the only possibilities are: a) Wide_String b) a type derived from Wide_String c) a (possibly private type) independent of Wide_String The argument for choice a) is that there are is a significant library of utilities for dealing with Wide_String that must be present in all compilers since they are part of Annex A. Be very sure to remember this in all our discussions. ALL ADA 95 COMPILERS MUST SUPPORT WIDE_STRING. This is not some kind of option that might not be present in some compilers. All Ada 95 compilers must fully suport Wide_String, including providing all the routines mentioned in Annex A. From rybin@possum.srcc.msu.su Tue Jun 17 09:47:09 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id JAA11675; Tue, 17 Jun 1997 09:47:09 -0400 Received: from crocus.gamma.ru by ida.org (4.1/SMI-4.1) id AA08196; Tue, 17 Jun 97 09:47:47 EDT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id RAA12180; Tue, 17 Jun 1997 17:47:12 +0400 (MSD) Received: by gamma.srcc.msu.su; Tue, 17 Jun 1997 17:46:41 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Tue, 17 Jun 1997 17:41:51 +0400 To: asis-technical@sw-eng.falls-church.va.us Cc: ASIS-Officers@sw-eng.falls-church.va.us, Cooper@Boeing.Com, dewar@gnat.com, roby@ida.org References: <199706162106.RAA10981@cronus.csed.ida.org> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Tue, 17 Jun 97 17:41:51 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: Restarting String/Wide_String discussion Lines: 87 Content-Length: 3500 Status: OR > Sergey and all, > > > > the email deluge stopped because the urgency suddenly disappeared! At the > > > WG9 meeting, we recognized that the decision was a stop gap decision that > > > very well might not be the final one, but there is time to consider the > > > proper solution carefully now. > > > > If I remember right, just before the interruption many (the most???) of > > the participants agreed, that Wide_String-only solution was the best > > compromise. > > > > Let's restart from this point. Should we move in asis-technical again? > > I agree with Sergey's suggestion of resuming the discussion > in ASIS-Technical, starting with the above statement. > > Clyde That's what I'm doing in this message. Sergey ----------------------------------------------------------------------------- Asis-Technical, I hope you remember the discussion concerning queries with String/Wide_String parameter or result in ASIS 2.0.M. The solution taken in 2.0.N is far from being ideal - we still have couples of queries with String/Wide_String parameters or results, and having the same or different names. This solution was taken as some "fast compromise" before the ISO meeting at Ada-Europe, it addresses the problem, but it does not solve it. Now we have the ability to discuss this problem without hurry, and we still have the subject for discussion. Overloaded queries for String/Wide_String still make a problem with natural ways of overloading resolution (how do you like String'(Diagnosis)) and a problem for using string constants (how do you like if Name_Image (El) = String'("My_Variable") then Queries returning string images and having String as a returned type are ill-defined in case if the image to be returned actually is in Wide_String. And, finally, there is no any justification for having this "duplication" in functionality. The previous discussion was interrupted (by Ada-Europe), when many of its participants came to "Wide-String-only" approach (that is, to have Wide_String as the only string type used in ASIS). Below is Robert Dewar's summary of the previous discussions sent to ASIS-Officers: : To summarize, the viewpoint is the following (the wide string only viewpoint) : : : The Ada 95 RM says that "teh character repertoire for the text of an Ada : program consistes .. of .. BMP ..." (this is RM 2.1(4)) : : Thus it is clear that any enquiry that returns a string of such characters : must use a reprsentation that can encompass the stated domain, namely BMP. : : Obviously using String/Character is inappropriate, since these cannot : encompass the required domain. : : Thus the only possibilities are: : : a) Wide_String : b) a type derived from Wide_String : c) a (possibly private type) independent of Wide_String : : The argument for choice a) is that there are is a significant library of : utilities for dealing with Wide_String that must be present in all compilers : since they are part of Annex A. : : Be very sure to remember this in all our discussions. ALL ADA 95 COMPILERS : MUST SUPPORT WIDE_STRING. This is not some kind of option that might not : be present in some compilers. All Ada 95 compilers must fully suport : Wide_String, including providing all the routines mentioned in Annex A. I would add only a few points: - there is no advantages in choosing b), but all the Annex A stuff will be lost. - if we choose c) we would have problems with string literals. Any opinions? Sergey Rybin. From colket@smtp-gw.spawar.navy.mil Wed Jun 18 18:17:38 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id SAA13131; Wed, 18 Jun 1997 18:17:37 -0400 Received: from opal.spawar.navy.mil by ida.org (4.1/SMI-4.1) id AA06668; Wed, 18 Jun 97 18:18:22 EDT Received: from smtp-gw.spawar.navy.mil by opal.spawar.navy.mil (5.x/SMI-SVR4) id AA14012; Wed, 18 Jun 1997 18:08:31 -0400 Received: from ccMail by smtp-gw.spawar.navy.mil (IMA Internet Exchange 1.04b) id 3a859810; Wed, 18 Jun 97 17:56:17 -0400 Mime-Version: 1.0 Date: Wed, 18 Jun 1997 17:55:48 -0400 Message-Id: <3a859810@smtp-gw.spawar.navy.mil> From: colket@smtp-gw.spawar.navy.mil (Currie Colket) Subject: Restart of String/Wide_String Discussion [for 2.0.N] To: ASIS-Technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil (Currie Colket), "Dan Cooper" Cc: roby@ida.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Length: 3307 Status: OR Dear ASIS_Technical, Dan Cooper writes => >> This mechanism will be used to better address our approach to the >> Wide_String issue (I#064). > I was wondering what became of this. The email deluge simply stopped! Let's resume the discussion with everybody understanding tha approach used in ASIS Version 2.0.N. As we were trying to resolve the issue, slightly less than half favored an overloading approach while slightly less than half favored the Wide_XXX approach. Of couse there were an infinite set of permutations and combinations identified with everyone changing their minds as often as a new approach was mentioned. The approach used for 2.0.N is described below. When it was made, several of us viewed it as a compromise between the two major camps. After the approach was made, it appears to have favor with neither camp, and may have alienated both camps. A technical solution was needed for ASIS 2.0.N to satisfy WG9 timing requirements. It was useful from that perspective and ASIS 2.0.N will be used for SC22 CD Balloting. We now have an opportunity to identify a preferred technical solution. Such an approach can be fed into a comment for an SC22 National Ballot. The SC22 balloting process will commence shortly after the SC22 meeting in August and depending on the WG9 Convener's discretion complete circa December 1997. Hence we now have the time which we did not have in May. The 2.0.N approach for the String/Wide_String issue will be frozen as a baseline until the Ballots are closed. This is advantageous to the ASIS implementors as it will provide an extremely high degree of stability for the ASIS implementations. String/Wide_String Approach for ASIS 2.0.N => The following text appears in Clause 3: -- The ASIS interface uses both String and Wide_String as parameters to -- many function and procedure calls. Overloaded function calls are provided -- where use would be unambiguous based on the context of the type returned -- for the function call. For other subprogram calls, a separate interface is -- provided using the Wide_ prefix. All String calls are overloaded with the exception of: 6.6 Initialize now has also Wide_Initialize 6.8 Finalize now has also Wide_Finalize 6.10 Set_Status now has also Wide_Set_Status 8.3 Associate now has also Wide_Associate 10.6 Library_Unit_Declaration now has also Wide_Library_Unit_Declaration 10.7 Compilation_Unit_Body now has also Wide_Compilation_Unit_Body 10.29 Has_Attribute now has also Wide_Has_Attribute 10.31 Attribute_Values now has also Wide_Attribute_Values 11.4 Attribute_Time now has also Wide_Attribute_Time Let the discussion continue. At this time, it would be practical to start over with a clean slate using the above 2.0.N solution as the baseline for discussion. As close to 100 String/Wide String messages were received, this will allow us to focus on those after 16 June as being relevant. Hence I ask those who have made points they still believe are valid to please resend them to asis-technical. I apologize for any inconvenience, but at lease the emails will be to a common baseline. Thank you! v/r Currie Colket Chair ASISWG/ASISRG Note for implementors: This is the only technical change between version 2.0.M and version 2.0.N. From rybin@possum.srcc.msu.su Thu Jun 19 17:17:20 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA15583; Thu, 19 Jun 1997 17:17:19 -0400 Received: from crocus.gamma.ru by ida.org (4.1/SMI-4.1) id AA23268; Thu, 19 Jun 97 17:17:59 EDT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id BAA21273 for roby@ida.org; Fri, 20 Jun 1997 01:17:49 +0400 (MSD) Received: by gamma.srcc.msu.su; Fri, 20 Jun 1997 01:17:20 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Fri, 20 Jun 1997 00:32:57 +0400 To: asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, cooper@longshot.ds.boeing.com Cc: roby@ida.org References: <3a859810@smtp-gw.spawar.navy.mil> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Fri, 20 Jun 97 00:32:57 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: Restart of String/Wide_String Discussion [for 2.0.N] Lines: 40 Content-Length: 1839 Status: OR > We now have an opportunity to identify a preferred technical solution. Such an > approach can be fed into a comment for an SC22 National Ballot. The SC22 > balloting process will commence shortly after the SC22 meeting in August and > depending on the WG9 Convener's discretion complete circa December 1997. Hence > we now have the time which we did not have in May. The 2.0.N approach for the > String/Wide_String issue will be frozen as a baseline until the Ballots are > closed. This is advantageous to the ASIS implementors as it will provide an > extremely high degree of stability for the ASIS implementations. > > String/Wide_String Approach for ASIS 2.0.N => > > ... > > Let the discussion continue. Well, at least one point is out of the discussion - ASIS 95 definitely needs Wide_String in all the situation when a string value should be accepted as a parameter value or returned as the result of a query. Strictly speaking (as Robert Dewar mentioned in a "small" restarting of this discussion in Asis-Officers), ASIS needs something covering BMP, but Wide_String is the natural solution, and it allows to use all the string-related stuff from Annex A (which should be supported by every Ada 95 compiler). So I cannot see any advantage of choosing something else. The first question to discuss is: Do ASIS really needs for all or for some of the queries having Wide_String as a parameter or result type the "counterpart" for the String type? I would concentrate on this question, because if the answer in "NO", we will have nothing else to discuss, and the only thing to do will be to remove all the string-related queries from 2.0.O. I myself think, that ASIS does not need queries for String, so Wide_String should be the only string type used by ASIS. Sergey Rybin, ASIS-for-GNAT progect From eachus@mitre.org Thu Jun 19 18:02:35 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id SAA15904; Thu, 19 Jun 1997 18:02:35 -0400 Received: from mbunix.mitre.org by ida.org (4.1/SMI-4.1) id AA23869; Thu, 19 Jun 97 18:03:17 EDT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id SAA13101; Thu, 19 Jun 1997 18:03:16 -0400 (EDT) Received: from blofeld (blofeld.mitre.org [129.83.63.79]) by spectre.mitre.org (8.8.5/8.8.5) with SMTP id SAA23604; Thu, 19 Jun 1997 18:03:15 -0400 (EDT) Message-Id: <3.0.1.32.19970619180418.00954100@spectre.mitre.org> X-Sender: eachus@spectre.mitre.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 19 Jun 1997 18:04:18 -0400 To: "Sergey I. Rybin" From: "Robert I. Eachus" Subject: Re: Restart of String/Wide_String Discussion [for 2.0.N] Cc: asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, cooper@longshot.ds.boeing.com, roby@ida.org In-Reply-To: References: <3a859810@smtp-gw.spawar.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Length: 1662 Status: OR At 12:32 AM 6/20/97 +0400, Sergey I. Rybin wrote: > Do ASIS really needs for all or for some of the queries having Wide_String > as a parameter or result type the "counterpart" for the String type? >I would concentrate on this question, because if the >answer in "NO", we will have nothing else to discuss, and the only thing to do >will be to remove all the string-related queries from 2.0.O. There are two issues, technical adequacy and performance. The technical part is easy, the performance issue is not. Are there processors out there where converting a String to a Wide_String and vice-versa is difficult even in the all Latin1 case? Yes. can some "magic" algorithm help? Probably, especially for "classic" RISC architectures. Can I think of such an algorithm off-hand? No. And I won't be happy with the all Wide_String solution until I know what it will really cost on an UltraSPARC, a PowerPC 603e, and a Pentium II. Think about the Latin1 --> BMP mapping. You have to mask the first eight bits, copy into another register and shift. Repeat this process four slightly different times, store one (64-bit) word and repeat. Add special casing for strings which are not a multiple of eight characters long and you are done. The back conversion is similar. A lot of work, when the corresponding operations without the conversion just return a pointer. I think we need either to keep the Character versions, or use one of the BMP encodings. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From dewar@gnat.com Fri Jun 20 08:50:38 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA16799; Fri, 20 Jun 1997 08:50:37 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA00353; Fri, 20 Jun 97 08:51:24 EDT Received: by nile.gnat.com (5.0/1.20) id AA12646; Fri, 20 Jun 97 08:48:45 EDT Date: Fri, 20 Jun 97 08:48:45 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9706201248.AA12646@nile.gnat.com> To: eachus@mitre.org, rybin@possum.srcc.msu.su Subject: Re: Restart of String/Wide_String Discussion [for 2.0.N] Cc: asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, cooper@longshot.ds.boeing.com, roby@ida.org Content-Length: 1332 Status: OR Robert Eachus said << I think we need either to keep the Character versions, or use one of the BMP encodings.>> I think Robert's concerns about performance are misplaced. For the cases where the string in question is derived from the source characters -- these are the ONLY cases that I think the all wide string approach is appropriate for, a character by character transformation will be required in any case, since undoubtedly the source will be stored in some encoded form, not in wide character form. But if you precscrive one of the BMP encodings, then converting from the form used internally to the "standard" encoding chosen for ASIS will be just as expensive as converting to wide string. Plus according to my estimates, I cannot see this conversion being measurable in impact at tjhe 0.1% level in a typical ASIS application. Second, and more important, if you choose a BMP encoding, then dealilng with it in an ASIS application all over the place will be a huge pain in the neck. For example, answering the query: show me all the identifiers with names longer than 30 characters in this unit now involves tricky programming. In practice people will just ignore this, and we will get ASIS applications which by default do not handle other than latin-1, and therefore handle only a subset of possible programs. From eachus@mitre.org Fri Jun 20 15:13:48 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA18208; Fri, 20 Jun 1997 15:13:48 -0400 Received: from mbunix.mitre.org by ida.org (4.1/SMI-4.1) id AA07758; Fri, 20 Jun 97 15:14:27 EDT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id PAA24194; Fri, 20 Jun 1997 15:14:25 -0400 (EDT) Received: from blofeld (blofeld.mitre.org [129.83.63.79]) by spectre.mitre.org (8.8.5/8.8.5) with SMTP id PAA25502; Fri, 20 Jun 1997 15:14:20 -0400 (EDT) Message-Id: <3.0.1.32.19970620151525.0095f370@spectre.mitre.org> X-Sender: eachus@spectre.mitre.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 20 Jun 1997 15:15:25 -0400 To: dewar@gnat.com (Robert Dewar) From: "Robert I. Eachus" Subject: Re: Restart of String/Wide_String Discussion [for 2.0.N] Cc: eachus@mitre.org, rybin@possum.srcc.msu.su, asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, cooper@longshot.ds.boeing.com, roby@ida.org In-Reply-To: <9706201248.AA12646@nile.gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Length: 3953 Status: OR At 08:48 AM 6/20/97 EDT, Robert Dewar wrote: >I think Robert's concerns about performance are misplaced. And I think that Robert Dewer is an optimist, but that is why there are horse races. Robert Dewar is right to be concerned about vendors not supporting Wide_Character/Unicode/ISO-10646 BMP, but to me the weights I assign to performance and compatibility are different. I can be convinced that Wide_String only is the right way to go, but as of now I (personally) see little benefit from it, and that benefit is cancelled if it encourages vendors to store string literals in non-optimal ways. I don't see compiler vendors storing all strings as Wide_Strings, but I can see that happening for some literals. (For example, using Wide_String representation for enumeration literal names that are returned by 'Image. (Yes, I know that there is a 'Wide_Image attribute. The problem is that, with this proposal, vendors will use it a lot. Will they come to see 'Image as a special and not often used version and deterimine their representations accordingly? Possibly. Should they? If we vote Wide only, I think they should.) >For the cases where the string in question is derived from the source >characters -- these are the ONLY cases that I think the all wide string >approach is appropriate for, a character by character transformation will >be required in any case, since undoubtedly the source will be stored in >some encoded form, not in wide character form. But if you precscrive one >of the BMP encodings, then converting from the form used internally to the >"standard" encoding chosen for ASIS will be just as expensive as converting >to wide string. Right now, I expect compiler vendors to store Strings in eight-bits, and Wide_Strings in 16. I think that Robert understates the degree to which a vote for "all Wide" will encourage vendors to build all Wide compilers. There are markets where that would be a reasonable decision, especially in the Far East. I have no problem with that. But I want/need compilers that handle eight bit strings well. (No cultural imperialism here, I also need compilers that handle eight bit AND mulitple sixteen bit character types well. I'm still waiting, although GNAT does a pretty good job if you need only one wide type.) >Plus according to my estimates, I cannot see this conversion being measurable >in impact at tjhe 0.1% level in a typical ASIS application. I am worried about distributed overhead. If I thought this would not impact non-ASIS users, I'd have no objection. But I see several places where a compiler developer will be likely to choose the same representations for ASIS and the compiler run-time. >Second, and more important, if you choose a BMP encoding, then dealing with >it in an ASIS application all over the place will be a huge pain in the neck. Couldn't agree more. But I am arguing for a representation which is identical to what the program author wrote. >For example, answering the query: >show me all the identifiers with names longer than 30 characters in this >unit >now involves tricky programming. No, it involves a costly, but not very tricky algorithm. Just keep the actual length as part of the value. >In practice people will just ignore this, and we will get ASIS applications >which by default do not handle other than latin-1, and therefore handle >only a subset of possible programs. This is a valid concern, but different vendors will see it differently. Someone selling compilers in Asia will have a very different perspective from some with a US-only market. However, Robert is attacking a straw man I don't support. I want ASIS to require Wide support where it is necessary to cover Ada. That should be a minimum. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From dewar@gnat.com Fri Jun 20 18:20:39 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id SAA18972; Fri, 20 Jun 1997 18:20:38 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA10776; Fri, 20 Jun 97 18:21:25 EDT Received: by nile.gnat.com (5.0/1.20) id AA28631; Fri, 20 Jun 97 18:18:40 EDT Date: Fri, 20 Jun 97 18:18:40 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9706202218.AA28631@nile.gnat.com> To: dewar@gnat.com, eachus@mitre.org Subject: Re: Restart of String/Wide_String Discussion [for 2.0.N] Cc: asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, cooper@longshot.ds.boeing.com, roby@ida.org, rybin@possum.srcc.msu.su Content-Length: 656 Status: OR I find Robert Eachus' response completely incomprehensible. Why on earth should details of the ASIS implemntation have any effect on the compiler at all. They certainly won't at ACT, they are completely distinct concerns. As for << And I think that Robert Dewer is an optimist, but that is why there are horse races. Robert Dewar is right to be concerned about vendors not supporting Wide_Character/Unicode/ISO-10646 BMP, but to me the weights I assign to performance and compatibility are different. I can be convinced>> Robert has no such concern. All Ada 95 compilers MUST support Wide_Character. This is part of the core, and is not optional. From fofanov@such.srcc.msu.su Mon Jun 23 05:53:20 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id FAA20963; Mon, 23 Jun 1997 05:53:20 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA26423; Mon, 23 Jun 97 05:53:35 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id FAA1764062; Mon, 23 Jun 1997 05:53:00 -0400 Received: from such.srcc.msu.su by sw-eng.falls-church.va.us (8.7.1/) id JAA05313; Mon, 23 Jun 1997 09:49:23 GMT Received: from uumars.UUCP (uucp@localhost) by such.srcc.msu.su (8.8.5/8.8.3) with UUCP id NAA01399 for asis-technical@sw-eng.falls-church.va.us; Mon, 23 Jun 1997 13:52:22 +0400 (MSD) Received: by mars.srcc.msu.su (UUPC/@ v6.14g, 04Jan96) id AA29980; Mon, 23 Jun 1997 13:38:36 +0400 (MSD) To: asis-technical@sw-eng.falls-church.va.us References: <9706202218.AA28631@nile.gnat.com> Message-Id: Date: Mon, 23 Jun 97 13:38:35 +0400 X-Mailer: BML [MS/DOS Beauty Mail v1.36h] Organization: Science Research Computer Center, Moscow State University From: fofanov@such.srcc.msu.su (Vasiliy A. Fofanov) Subject: Re: Restart of String/Wide_String Discussion [for 2.0.N] Lines: 21 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 825 Status: OR Dear ASIS WG, Am I right in assuming that no ASIS application will use massive operations with ASIS queries that use strings (of any sort)? It seems that most of the work goes on the Element level, and we only need Element images when the job is actually done and we are generating some output. If so (and it seems like that), the problem of perfomance is of less importance than compatibility. (This is, BTW, one of the reason I have shifted my original allegiance with the idea of using String and not Wide_String wherever possible and am now supporting a Wide_String only approach) Sincerely, Vasiliy Fofanov. --- ------------------------------------------------------------------- Vasiliy A. Fofanov Email: fofanov@such.srcc.msu.su Ada Programmer WWW: http://such.srcc.msu.su/fofanov/ From dewar@gnat.com Mon Jun 23 10:12:25 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id KAA21324; Mon, 23 Jun 1997 10:12:25 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA00480; Mon, 23 Jun 97 10:12:37 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id KAA1902700; Mon, 23 Jun 1997 10:12:05 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id OAA10764; Mon, 23 Jun 1997 14:09:16 GMT Received: by nile.gnat.com (5.0/1.20) id AA18669; Mon, 23 Jun 97 10:09:49 EDT Date: Mon, 23 Jun 97 10:09:49 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9706231409.AA18669@nile.gnat.com> To: asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su Subject: Re: Restart of String/Wide_String Discussion [for 2.0.N] Content-Length: 1194 Status: OR regarding performance here, in practice on RISC machines, messing with a string of 16-bit values is about the same number of instructions as messing with 8-bit characters. The performance effect, if there is one is simply from increased cache pressure. In practice, given the kind of profile of a typical ASIS application, which as Vasiliy suggests will be more likely spending its time messing with elements, I think the hit of using wide strng will simply not be noticeable at all. Furthermore, if you do allow srting querieis, you have to introduce a new exception to handle the case of a wide character that cannot be represented as character, and/or canonicalize a specific encoding, either of which adds complexity and design time, to both the ASIS design and the programs that use it. Actually I must say that ASIS is rather a nice application of wide character, and makes me pleased that we insisted that this go in the core. The reason for this insistence was primarily the very reasonable demand from the Japanese delegation that wide character be a first class citizen in all respects, but here with the ASIS interface, we see the advantage of having made this support universal. From eachus@mitre.org Mon Jun 23 12:15:12 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id MAA21579; Mon, 23 Jun 1997 12:15:12 -0400 Received: from mbunix.mitre.org by ida.org (4.1/SMI-4.1) id AA02789; Mon, 23 Jun 97 12:14:36 EDT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id MAA16357; Mon, 23 Jun 1997 12:13:34 -0400 (EDT) Received: from blofeld (blofeld.mitre.org [129.83.63.79]) by spectre.mitre.org (8.8.5/8.8.5) with SMTP id MAA04762; Mon, 23 Jun 1997 12:13:26 -0400 (EDT) Message-Id: <3.0.1.32.19970623121437.009301c0@spectre.mitre.org> X-Sender: eachus@spectre.mitre.org (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 23 Jun 1997 12:14:37 -0400 To: asis-technical@sw-eng.falls-church.va.us From: "Robert I. Eachus" Subject: A conversion benchmark Cc: colket@smtp-gw.spawar.navy.mil, cooper@longshot.ds.boeing.com, roby@ida.org, rybin@possum.srcc.msu.su, dewar@gnat.com In-Reply-To: <9706202218.AA28631@nile.gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Length: 4072 Status: OR Let's start discussing reality not guesses. Here is a test program using Ada.Characters.Handling.To_String and Ada.Characters.Handling.To_Wide_String. Since these are the implementation provided conversion routines, we have to expect that at least the user side of any conversions will be done with these routines. The numbers I have gotten with it so far are enough to justify concern, but not panic, which is my position. If there is a way to improve on these algorithms great, then there is no problem. Otherwise I stand by the position that there is a performance concern here on certain processors, mostly 64-bit native processors, and in some systems with relatively slow processors relative to the disk subsystems. (I guess I should provide a standard source file to use in testing. Anyone want to pick one of the GNAT source or run-time files?) For instance on spectre, a non-Ultra SPARC I get: spectre% wide_test ~/RMAIL File /home/eachus/RMAIL has 59643 lines. Read 345373 blanks. Read 160580079 characters. Text only took 6.753 seconds. Converting took 8.608 seconds. A difference of 1.855 seconds. spectre% Noticable, but certainly tolerable. On a reasonably fast processor, I think that less than one second per megabyte can be safely ignored, one minute per meg would be intolerable, and most results will be in the one to three second range--based on my observations. Note that the disk access times will dominate everything else without a decently buffered disk subsystem, so this is a very fair test. with Ada.Text_IO; use Ada.Text_IO; with Ada.Characters.Handling; use Ada.Characters.Handling; with Ada.Calendar; use Ada.Calendar; with Ada.Command_Line; use Ada.Command_Line; procedure Wide_Test is package Duration_IO is new Ada.Text_IO.Fixed_IO(Duration); Input: Ada.Text_IO.File_Type; Buffer: String(1..80); Length: Natural; Lines: Natural := 0; Characters, Save_Char, Blanks, Save_Blanks: Integer := 0; Start, Stop: Ada.Calendar.Time; No_Conversion, Conversion: Duration; procedure Do_Counts(Text: in String) is begin for I in 1..Text'Length loop if Text(I) = ' ' then Blanks := Blanks + 1; end if; Characters := Characters + Text'Length; end loop; end Do_Counts; begin Open(Input,In_File,Argument(1)); -- first read the file to get any buffering to occur. while not End_Of_File(Input) loop Get_Line(Input, Buffer, Length); Lines := Lines + 1; end loop; Put_Line(" File " & Argument(1) & " has " & Integer'IMAGE(Lines) & " lines."); Reset(Input); Start := Clock; while not End_Of_File(Input) loop Get_Line(Input, Buffer, Length); Do_Counts(Buffer(1..Length)); end loop; Stop := Clock; while not End_Of_File(Input) loop Get_Line(Input, Buffer, Length); Do_Counts(Buffer(1..Length)); end loop; Stop := Clock; Save_Blanks := Blanks; Blanks := 0; Save_Char := Characters; Characters := 0; No_Conversion := Stop-Start; Reset(Input); Start := Clock; while not End_Of_File(Input) loop Get_Line(Input, Buffer, Length); Do_Counts(To_String(To_Wide_String(Buffer(1..Length)))); end loop; Stop := Clock; Conversion := Stop-Start; if Save_Blanks /= Blanks then Put_Line(" Mismatch in blanks count."); else Put_Line(" Read " & Integer'IMAGE(Blanks) & " blanks."); end if; if Save_Char /= Characters then Put_Line(" Mismatch in character count."); else Put_Line(" Read " & Integer'IMAGE(Characters) & " characters."); end if; Put(" Text only took "); Duration_IO.Put(No_Conversion,6,3,0); Put_Line(" seconds."); Put(" Converting took "); Duration_IO.Put(Conversion,6,3,0); Put_Line(" seconds."); Put(" A difference of "); Duration_IO.Put(Conversion-No_Conversion,6,3,0); Put_Line(" seconds."); Close(Input); end Wide_Test; Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From dewar@gnat.com Mon Jun 23 12:22:18 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id MAA21689; Mon, 23 Jun 1997 12:22:17 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA02892; Mon, 23 Jun 97 12:23:04 EDT Received: by nile.gnat.com (5.0/1.20) id AA20396; Mon, 23 Jun 97 12:16:34 EDT Date: Mon, 23 Jun 97 12:16:34 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9706231616.AA20396@nile.gnat.com> To: asis-technical@sw-eng.falls-church.va.us, eachus@mitre.org Subject: Re: A conversion benchmark Cc: colket@smtp-gw.spawar.navy.mil, cooper@longshot.ds.boeing.com, dewar@gnat.com, roby@ida.org, rybin@possum.srcc.msu.su Content-Length: 721 Status: OR These timings are bogus. They assume that the text inside the compiler is held in Character (String) form. This is impossible. Eiyther a compiler stores program text in wide string format, or, as in GNAt, it stores it in encoded String form, with one of six user selected encoding schemes. In ASIS, if we use type String, we have to decide on a standard encoding. This means that the timinings that should be looked at are: String with implementation dependent encoding => ASIS string with standard encoding with String with iplementation dependent encoding => Wide string These timings will be highly comparable, and in fact, depending on what encodings are used, ythe wide strin g solution may actually be faster. From eachus@mitre.org Mon Jun 23 15:01:47 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA22413; Mon, 23 Jun 1997 15:01:46 -0400 Received: from mbunix.mitre.org by ida.org (4.1/SMI-4.1) id AA05984; Mon, 23 Jun 97 15:02:29 EDT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id PAA11944; Mon, 23 Jun 1997 15:01:45 -0400 (EDT) Received: from blofeld (blofeld.mitre.org [129.83.63.79]) by spectre.mitre.org (8.8.5/8.8.5) with SMTP id PAA05382; Mon, 23 Jun 1997 15:01:44 -0400 (EDT) Message-Id: <3.0.1.32.19970623150255.0097ec20@spectre.mitre.org> X-Sender: eachus@spectre.mitre.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 23 Jun 1997 15:02:55 -0400 To: dewar@gnat.com (Robert Dewar) From: "Robert I. Eachus" Subject: Re: A conversion benchmark Cc: asis-technical@sw-eng.falls-church.va.us, eachus@mitre.org, colket@smtp-gw.spawar.navy.mil, cooper@longshot.ds.boeing.com, dewar@gnat.com, roby@ida.org, rybin@possum.srcc.msu.su In-Reply-To: <9706231616.AA20396@nile.gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Length: 1448 Status: OR At 12:16 PM 6/23/97 EDT, Robert Dewar wrote: >These timings are bogus. They assume that the text inside the compiler is >held in Character (String) form. This is impossible. Eiyther a compiler >stores program text in wide string format, or, as in GNAt, it stores it >in encoded String form, with one of six user selected encoding schemes. Not bogus, they bound the (potential) problem. If you want to provide a version that translates from, say UTF1 instead, go for it. As it is, this program tells me that on many of the platforms of interest, I don't see a problem. But on some, there may be one. >In ASIS, if we use type String, we have to decide on a standard encoding. >This means that the timinings that should be looked at are: >String with implementation dependent encoding => ASIS string with standard >encoding Okay. >with > >String with iplementation dependent encoding => Wide string > >These timings will be highly comparable, and in fact, depending on what >encodings are used, ythe wide strin g solution may actually be faster. But you missed one. String with encoding to ASCII string with (possible but does not occur) exception. That is a very real case to be concerned with, and it should be almost identical to what I measure. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From eachus@mitre.org Mon Jun 23 15:55:14 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA22459; Mon, 23 Jun 1997 15:55:13 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA06983; Mon, 23 Jun 97 15:55:23 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id PAA2555904; Mon, 23 Jun 1997 15:54:41 -0400 Received: from mbunix.mitre.org by sw-eng.falls-church.va.us (8.7.1/) id TAA19186; Mon, 23 Jun 1997 19:51:48 GMT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id PAA20416; Mon, 23 Jun 1997 15:54:25 -0400 (EDT) Received: from blofeld (blofeld.mitre.org [129.83.63.79]) by spectre.mitre.org (8.8.5/8.8.5) with SMTP id PAA05500; Mon, 23 Jun 1997 15:54:24 -0400 (EDT) Message-Id: <3.0.1.32.19970623155535.00978550@spectre.mitre.org> X-Sender: eachus@spectre.mitre.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 23 Jun 1997 15:55:35 -0400 To: dewar@gnat.com (Robert Dewar) From: "Robert I. Eachus" Subject: Re: Restart of String/Wide_String Discussion [for 2.0.N] Cc: asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su In-Reply-To: <9706231409.AA18669@nile.gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Length: 2490 Status: OR At 10:09 AM 6/23/97 EDT, Robert Dewar wrote: >regarding performance here, in practice on RISC machines, messing with >a string of 16-bit values is about the same number of instructions as >messing with 8-bit characters. The performance effect, if there is one >is simply from increased cache pressure. In practice, given the kind of >profile of a typical ASIS application, which as Vasiliy suggests will >be more likely spending its time messing with elements, I think the hit >of using wide strng will simply not be noticeable at all. In general, yes. But here we are talking about 8 => 16 expansion, and 16 => 8 compaction. Older hardware often had specialized support for such mappings, more modern RISCs don't. (For example, on a lot of CISC machines, check a string to see if the high-order bit is set for any character can be done with one instruction, Translate_and_Test. This can even be used to translate LatinX for X /= 1 to Unicode/BMP as well on some hardware. >Furthermore, if you do allow srting querieis, you have to introduce a >new exception to handle the case of a wide character that cannot be >represented as character, and/or canonicalize a specific encoding, either >of which adds complexity and design time, to both the ASIS design and >the programs that use it. For the guys who use all of Wide_Character, sure. But those users should be calling the Wide_ versions. For code that stays within Latin1, or with some encoding schemes, within the lower 128 characters, there won't be a problem. >Actually I must say that ASIS is rather a nice application of wide character, >and makes me pleased that we insisted that this go in the core. The reason >for this insistence was primarily the very reasonable demand from the >Japanese delegation that wide character be a first class citizen in all >respects, but here with the ASIS interface, we see the advantage of having >made this support universal. Agreed. The Wide_String queries will be really nice, especially if fully supported. In other words, if I have a mixture of components, some writen in Latin1 and others in Latin/Cyrillic, it will be nice if cross-reference tools, etc. display the actual names used, not some junk translation. This, of course goes beyond the Ada standard, but in a reasonable way. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From dewar@gnat.com Mon Jun 23 18:20:12 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id SAA22776; Mon, 23 Jun 1997 18:20:12 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA09263; Mon, 23 Jun 97 18:20:59 EDT Received: by nile.gnat.com (5.0/1.20) id AA23677; Mon, 23 Jun 97 18:18:08 EDT Date: Mon, 23 Jun 97 18:18:08 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9706232218.AA23677@nile.gnat.com> To: dewar@gnat.com, eachus@mitre.org Subject: Re: A conversion benchmark Cc: asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, cooper@longshot.ds.boeing.com, roby@ida.org, rybin@possum.srcc.msu.su Content-Length: 543 Status: OR << But you missed one. String with encoding to ASCII string with (possible but does not occur) exception. That is a very real case to be concerned with, and it should be almost identical to what I measure. >> The way I see it, whatever choice we make, the work to be done in an ASIS implementation (which in any case I challenge RObert Eachus to show will take more than 5% of total processing time) is about the same whether we choose the wide string or string choices. In each case a character by character translation is necessary. From dewar@gnat.com Mon Jun 23 18:24:33 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id SAA22815; Mon, 23 Jun 1997 18:24:32 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA09323; Mon, 23 Jun 97 18:24:47 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id SAA1361740; Mon, 23 Jun 1997 18:24:15 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id WAA22310; Mon, 23 Jun 1997 22:21:28 GMT Received: by nile.gnat.com (5.0/1.20) id AA23766; Mon, 23 Jun 97 18:22:01 EDT Date: Mon, 23 Jun 97 18:22:01 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9706232222.AA23766@nile.gnat.com> To: dewar@gnat.com, eachus@mitre.org Subject: Re: Restart of String/Wide_String Discussion [for 2.0.N] Cc: asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su Content-Length: 668 Status: OR << In general, yes. But here we are talking about 8 => 16 expansion, and 16 => 8 compaction. Older hardware often had specialized support for such mappings, more modern RISCs don't. (For example, on a lot of CISC machines, check a string to see if the high-order bit is set for any character can be done with one instruction, Translate_and_Test. This can even be used to translate LatinX for X /= 1 to Unicode/BMP as well on some hardware. >> Even on modern CISC machines (really you mean the x86 when you say this, there is no other CISC machine around of interest), you NEVER use these fancy instructions, they are MUCH slower than doing things RISC style. From eachus@mitre.org Mon Jun 23 19:25:45 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id TAA22847; Mon, 23 Jun 1997 19:25:45 -0400 Received: from mbunix.mitre.org by ida.org (4.1/SMI-4.1) id AA10231; Mon, 23 Jun 97 19:26:26 EDT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.8.5/8.8.5/mitre.0) with ESMTP id TAA14873; Mon, 23 Jun 1997 19:25:57 -0400 (EDT) Received: from blofeld (blofeld.mitre.org [129.83.63.79]) by spectre.mitre.org (8.8.5/8.8.5) with SMTP id TAA05930; Mon, 23 Jun 1997 19:25:56 -0400 (EDT) Message-Id: <3.0.1.32.19970623192707.00992a00@spectre.mitre.org> X-Sender: eachus@spectre.mitre.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 23 Jun 1997 19:27:07 -0400 To: dewar@gnat.com (Robert Dewar) From: "Robert I. Eachus" Subject: Re: A conversion benchmark Cc: dewar@gnat.com, eachus@mitre.org, asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, cooper@longshot.ds.boeing.com, roby@ida.org, rybin@possum.srcc.msu.su In-Reply-To: <9706232218.AA23677@nile.gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Length: 1893 Status: OR At 06:18 PM 6/23/97 EDT, Robert Dewar wrote: >The way I see it, whatever choice we make, the work to be done in an >ASIS implementation (which in any case I challenge RObert Eachus to show >will take more than 5% of total processing time) is about the same whether >we choose the wide string or string choices. In each case a character by >character translation is necessary. Where it is necessary, the issue I am interested in involves expansion and compaction of strings. Translation in place, or more to the point validation in place, is significantly cheaper. Incidently, I am now looking at whether translation by table will help on the processors where shifting and masking is painful. Of course, I suspect that not only is the best way to do this is to use the MMX technology on Pentiums that have it, but that it is one reason that technology was added. I'll be in meetings most of the next three days, so don't take silence for disinterest. If anyone wants to post timings, using my program, go right ahead. I hope to have some definitive results on Pentiums by the end of the week, but right now I have some inconsistancies to check, due I think to disk caching behavior. And please remember, I am not someone sitting here frantically defending a position on this. I count myself as undecided, and if I can convince myself that the performance impact is not significant, I'll probably end up voting for the Wide only solution. Right now, my tests are worrying but not seriously so. If it turns out that my "bad" numbers are due to cache collisions or some such fine. But that will take more testing. (The SPARC results are more normal. Noticable, but not terrible.) Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From dewar@gnat.com Mon Jun 23 23:17:21 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id XAA22983; Mon, 23 Jun 1997 23:17:20 -0400 Received: from nile.gnat.com by ida.org (4.1/SMI-4.1) id AA13053; Mon, 23 Jun 97 23:18:08 EDT Received: by nile.gnat.com (5.0/1.20) id AA25772; Mon, 23 Jun 97 23:15:24 EDT Date: Mon, 23 Jun 97 23:15:24 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9706240315.AA25772@nile.gnat.com> To: dewar@gnat.com, eachus@mitre.org Subject: Re: A conversion benchmark Cc: asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, cooper@longshot.ds.boeing.com, roby@ida.org, rybin@possum.srcc.msu.su Content-Length: 196 Status: OR MMX is no help at all for the translations that are required. Robert, I still think you are comparing (a) with (b) where (b) is of no interest at all to the actual reality of an ASIS application. From rybin@possum.srcc.msu.su Tue Jun 24 05:16:51 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id FAA23251; Tue, 24 Jun 1997 05:16:50 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA14874; Tue, 24 Jun 97 05:17:00 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id FAA1366418; Tue, 24 Jun 1997 05:16:27 -0400 Received: from crocus.gamma.ru by sw-eng.falls-church.va.us (8.7.1/) id JAA03589; Tue, 24 Jun 1997 09:13:26 GMT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id NAA10091 for asis-technical@sw-eng.falls-church.va.us; Tue, 24 Jun 1997 13:16:30 +0400 (MSD) Received: by gamma.srcc.msu.su; Tue, 24 Jun 1997 13:15:36 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Tue, 24 Jun 1997 12:56:49 +0400 To: asis-technical@sw-eng.falls-church.va.us References: <9706231409.AA18669@nile.gnat.com> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Tue, 24 Jun 97 12:56:49 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: Restart of String/Wide_String Discussion [for 2.0.N] Lines: 29 Content-Length: 1471 Status: OR > Furthermore, if you do allow srting querieis, you have to introduce a > new exception to handle the case of a wide character that cannot be > represented as character, and/or canonicalize a specific encoding, either > of which adds complexity and design time, to both the ASIS design and > the programs that use it. May be, I'm a bit late responding this, but this point is really important from the ASIS standardization perspective. If not only ASCII, but all (or almost all) the BMP characters may be found in the Ada source, then these characters should be returned by the queries from Asis.Text and by Xxx_Image queries from some other ASIS packages. If ASIS has versions of these queries returning _STRINGS_, we really are in trouble. All these String-returning queries become ill-defined, and it would be a huge pain to find the fix for this hole in their definition which would satisfy all of us. I do not think, that we would be able to canonicalize some encoding, and I am afraid, we really do not have enough time to find a good technical solution for String queries (if we would like to have them in ASIS). If the practice shows, that the prformance really is an issue, and that some applications really needs fast and memory-unexpensive String versions of Xxx_Image queries, ASIS vendors can (easily?) provide the corresponding queries as ASIS extensions. But I do not think, that we could (and that we should) standartize them. Sergey Rybin From dewar@gnat.com Tue Jun 24 07:50:43 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id HAA23332; Tue, 24 Jun 1997 07:50:43 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA15549; Tue, 24 Jun 97 07:50:57 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id HAA08820; Tue, 24 Jun 1997 07:50:23 -0400 Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id LAA06243; Tue, 24 Jun 1997 11:47:06 GMT Received: by nile.gnat.com (5.0/1.20) id AA13160; Tue, 24 Jun 97 07:47:37 EDT Date: Tue, 24 Jun 97 07:47:37 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9706241147.AA13160@nile.gnat.com> To: asis-technical@sw-eng.falls-church.va.us, rybin@possum.srcc.msu.su Subject: Re: Restart of String/Wide_String Discussion [for 2.0.N] Content-Length: 668 Status: OR <> We could not standardize them. The reason is that the only way to get the performance increase that Robert Eachus is so worried about is to return the internal representation of the program unchanged (assuming that it is indeed a string internally). But this by its nature would yield implementation dependent handling of wide characters. From colket@smtp-gw.spawar.navy.mil Wed Jun 25 18:18:07 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id SAA26971; Wed, 25 Jun 1997 18:18:06 -0400 Received: from mail.acm.org by ida.org (4.1/SMI-4.1) id AA14263; Wed, 25 Jun 97 18:18:22 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id SAA1361354; Wed, 25 Jun 1997 18:16:44 -0400 Received: from opal.spawar.navy.mil by sw-eng.falls-church.va.us (8.7.1/) id WAA21118; Wed, 25 Jun 1997 22:13:02 GMT Received: from smtp-gw.spawar.navy.mil by opal.spawar.navy.mil (5.x/SMI-SVR4) id AA01072; Wed, 25 Jun 1997 18:06:22 -0400 Received: from ccMail by smtp-gw.spawar.navy.mil (IMA Internet Exchange 1.04b) id 3b193300; Wed, 25 Jun 97 17:52:48 -0400 Mime-Version: 1.0 Date: Wed, 25 Jun 1997 17:48:32 -0400 Message-Id: <3b193300@smtp-gw.spawar.navy.mil> From: colket@smtp-gw.spawar.navy.mil (Currie Colket) Subject: Re[2]: Restart of String/Wide_String Discussion [for 2.0.N] To: asis-technical@sw-eng.falls-church.va.us, fofanov@such.srcc.msu.su (Vasiliy A. Fofanov), colket@smtp-gw.spawar.navy.mil (Currie Colket) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Length: 1012 Status: OR Dear asis-technical, Vasiliy has raised an interesting point: > Am I right in assuming that no ASIS application will > use massive operations with ASIS queries that use strings > (of any sort)? It seems that most of the work goes on the > Element level, and we only need Element images when the > job is actually done and we are generating some output. > If so (and it seems like that), the problem of perfomance > is of less importance than compatibility. This is my understanding as well. If this is the case, then any performance impact could easily be counterbalanced by the extra processing to ascertain whether Wide_String or regular String processing should take place. This begs the question => Is there anyone who has an ASIS application where there would be a projected *serious* performance penalty should Wide_Strings be used exclusively? If so, then the performance issue could be important; otherwise it is simply academic. Discussion?? v/r Currie