From kh@athens.cs.waikato.ac.nz Fri Feb 18 05:22:41 1994 Received: from grace.waikato.ac.nz by dkuug.dk with SMTP id AA00432 (5.65c8/IDA-1.4.4j for ); Thu, 17 Feb 1994 04:34:11 +0100 Message-Id: <199402170334.AA00432@dkuug.dk> Received: from athens.cs.waikato.ac.nz by waikato.ac.nz; Thu, 17 Feb 94 16:20 +1300 Received: by athens.cs.waikato.ac.nz (16.6/16.2) id AA14976; Thu, 17 Feb 94 16:22:41 +1300 Date: Thu, 17 Feb 94 16:22:41 +1300 From: Keith Hopper Subject: Lost message characters! To: SC22@dkuug.dk Cc: SC22WG13@dkuug.dk, SC22WG15@dkuug.dk X-Charset: ASCII X-Char-Esc: 29 Greetings, This is my second attempt to send a long mail message to you in response to comments made on our character-less programming paper. Hope this one succeeds! - - - - - - - - - - - - - - - - Greetings, We have noted with interest the generally favourable reception which has been accorded our draft paper on 'Character-less Programming' and are not unnaturally flattered at some comments. Thanks are, however, due to all who took the trouble to indicate errors or concerns which we had not addressed -- as well as to those who made no technical remarks. This note is intended to address those comments which have been made and explain our considered response to the concerns they addressed. It is our intention thereafter to revise the draft, broadening it to give more detailed content and forward to SC22 Secretariat for distribution as an NZ position paper -- as well as to those WGs which have expressed specific interest. Comment No 1 ------------ The comment which interested us perhaps the most came from two sources suggesting that we were really re-inventing the wheel. This was indeed our intention -- well, perhaps not the re-invention term but the use of existing invention in a new way. Our aim was not to suggest that we had invented something new (I was involved in the heady days of early Algol60 compilers which had this kind of technique), rather to propose the use of an extant idea in a new way to improve almost 'at a stroke of the pen' application portability. We are perhaps suggesting that the problem faced by early compilers that each machine probably had an unique character encoding as a hardware limitation has now raised its ugly head in reverse as it were -- each culture wishes perhaps to use its own notation for meeting cultural needs this time, rather than hardware ones. Comment No 2 ------------- Again in slightly different terms from two sources came the suggestion that our ideas would not solve the age old problem of word order differences between different natural languages. We believed that we had indicated this in our draft paper, but obviously inadequately. The revision will address this a little further. We appreciate that for some programming languages the unnatural order is more of a hindrance to programmers than others, but in our experience with the very simple phrases involved in programming the use of the correct word is more important to human understanding than the impeccably correct syntax. It is, perhaps, worth suggesting that this second-level problem is one which should be addressed in some research activity. At present the limitation of the proposals so far as programming languages is concerned rests here. Comment No 3 ------------ One commenter indicated that a human programmer had to be involved in modification of source code and as such there would be need of a rendering engine which accepted the encodings and made them understandable to human eyes/ears. We cannot but agree this, of course, but that does not mean that every single machine which is involved in using a source text need have such a rendering engine unless the source is to be modified. We can envisage the provision of an editor which makes use of some cross-mapping utility for such purposes should this be desired (as was suggested in slightly different terms by another commenter). Once the separation between compiler implementation and lexical mapping has been made then a wide variety of such techniques is possible. Comment No 4 ------------ One comment indicated that we had possibly ambiguously stated our suggestions in relation to the provision of the mapping description and the provision of the compiler itself. The view we intended to convey was that the implementer of a compiler would need to have a local mapping facility for testing and evaluation purposes, which it was intended he may wish to market independently -- or to retain solely for the use of his staff. Of course a scenario where his staff came from several cultures and used different mappings in preparing different separately translatable sections of the compiler is also possible and certainly not excluded fom the model. It is our intention, however, that it be readily possible to prepare a new culturally-dependent mapping for a user on a particular machine in a particular execution environment -- in essence an extension of the POSIX charmap into a sort of 'lexmap' facility but with fixed map size and order for each programming language involved. Whether the supplier of a compiler produces and markets a selection or the supplier of an operating system or the local seller of machines -- or indeed a knowledgeable user for his/her own machine is completely open ---- once the language standard has defined the names in order for the map and the common (across all languages!!) mapping description file contents format. In this way many tools can more easily be ported to an individual local "dialect". As an example if it were me, even using Table 1 of 10646 as a base I would probably wish to replace the ":=" used in many programming languages with "<-" which I find more understandable for a language Becomes-symbol. Comment 5 --------- A suggestion has also been made that language is a continually evolving mechanism for communication and that we should not therefore cast such things in concrete so that they will never change. We were a little mystified by this comment since it actually seemed to be this very kind of thing that we hoped our suggestion would help us to get away from. We hope that all of the suggestions in regard to programming language definitions and to the need for provisions in all languages to use libraries of ADTs which embody cultural concepts which in turn make use of appropriate mapping facilities to representation are directed away from the concrete and towards the abstract. A closely related comment suggested that we had proposed a Word ADT as a possible candidate for standardisation -- which was inappropriate because there are orthographies in which such a concept (officially at least) is synonymous with character. It will be remembered that one of the important points we were trying to make about the ADTs to be worked on was that they embodied an abstract concept, irrespective of the necessary cultural implementation or any applicable rendering description mapping. The use of such a concept may of course only be carried out where two entities share the same concept, irrespective of what it looks like or how it is implemented. Perhaps a small example may offer some insight. Within both POSIX work and WG20s Framework drafting there is the concept of 'date'. However, both of the documents involved are solely concerned with what we may call the syntax of a date. If, however, we had a Date abstraction available we could define operations such as Today, Compare, etc. Take this together with a subordinate ADT called Duration we could have operation Difference which returned a difference between two dates ----- and so on. There is no need to know how a date is produced, what the mapping between its bit-pattern and some humanly readable representation may be. Provided that each abstraction provide Put and Get operations at least then input and output of date can be carried out. With the addition of Convert-style operations it would also be possible to convert to, say, an ADT called String if this were needed or possible. The same is true of Duration of course. Implementation of such an ADT would ideally have access at execution time to a syntax description of a humanly-readable form of date. In the absence of that then an implementation would have to have that built-in as it were. What it would not have to do, however, is have built-in a particular encoding for the eventual externally visible/audible form --- this is provided by exactly the same sort of mapping description as was used for the compiler lexemes, thus enabling a program executing in an environment which provides dynamic binding to produce within instants of each other July, 4th 1999 le 4eme juillet 1999 1999.7.4 4 Juli 1999 and possibly hundreds of other variants -- providing that the descriptions are available -- in all sorts of visible and audible forms. Comment 6 --------- One or two typographic errors inevitably remained (why is it that someone always finds one after years of re-reading?) and one error in the use of lexeme in contrast to phoneme when we should of course have used grapheme. We hope you will approve of our revised paper. Keith Hopper