Date: 1 March 1988, 09:32:49 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Conference on Honorifics (164 lines) -------------------------------------------------------------------- From: John B. Haviland Reed College, Anthropology and Linguistics Portland State University, Department of Modern Languages announce A Conference on |HONORIFICS| to be held in Portland, Oregon April 8-10, 1988 |Precursors and topics:| Since classic early work on the social effects of pronoun choice, the respectful (or abusive) elaboration of vocabulary, and proposed universal features of the linguistic expression of politeness, there has been significant interest in the pragmatics of honorifics. Despite some programmatic optimism, these varying phenomena have not been systematically related. Nor have such studies been integrated with more recent research on natural conversation and discourse, on contextual cues, or on the pragmatics of inference, in which honorific phenomena are significant components. Similarly, detailed treatments of Asian, American, and Australian languages have shown the necessity for integrating honorific categories into the central core of grammatical description in individual cases, but work on the general theoretical significance of such categories for syntax and morphology has only recently begun. This conference proposes to direct these two complementary but divergent currents towards a more unified and general theory of honorifics in language. The prospects for significant results seem substantially heightened by a conference organized around both detailed ethnolinguistic and morpho-syntactic presentations, complemented by an explicitly comparative and theoretical workshop. We have solicited contributions which deal with the following topical areas: |A. Strategies for encoding honorific (and deprecatory)| |categories |in morphology, syntax, and the lexicon of different languages, as well as the consequences--both typological and interactive--of such strategies: Here we have in mind different possibilities for \grammaticalizing\ pragmatic aspects of language. A summary of the basic typological facts of honorific phenomena awaits more detailed descriptions of a wide range of particular languages. |B. Levels of honorifics within language structure:| their encoding within subject, object, speaker, and addressee categories; or in pronouns, classificatory elements; in lexical or phonological alternants; or in kinesic, paralinguistic, and gestural cues. In the best studied cases, honorific devices seem to range from speech levels and marked vocabulary (often, if not always, buttressed by marked kinesics as well) as in the cases of Javanese and Balinese, Australian "mother-in-law" languages, or Samoan respect vocabularies; to lexical alternation complemented by thoroughgoing syntacticization of honorific categories within verbal morphology (as in Korean or Japanese); to classification and gender-like systems incorporating honorific components (as in languages of the Americas, such as Nahuatl or Mixtec) or systems of "politeness affixes"; to familiar pronominal alternations, for example in the languages of Europe, or in a more elaborate form in the highly developed systems of address terms found in South Asia. What warrant, conceptual or analytic, is there for treating these phenomena together, either at the level of language use or language structure? |C. Honorifics (and their relatives) as tools, or fuel for| |linguistic argumentation and theory:| convincing evidence that honorific categories bear on syntactic theory derives from work on Japanese and Korean, but no doubt can be found elsewhere as well, once the syntactic and morphological facts are sufficiently well described. Recent work on the 'iconicity' (or principled motivation) of morphological encoding may need revision on the basis of fuller treatment of such ill-understood categories as honorifics. In a somewhat similar way, the seemingly inescapably indexical and situated nature of honorific usage seems to pose a challenge to current semantic theories in a way that will be useful to explore. |D. Historical change and evol||ution of honorific devices in| |language:| we have in mind such matters as: the evolution of terms of respect and disrespect; the gradual 'downgrading' of markers on honorific scales; the history of social arrangements (revolutions, or religious conversion, for example), and corresponding reflexes in the linguistic expression of honorific categories; and so on. The literature contains suggestive proposals connecting pronominal elaboration, for example, with particular political institutions or ideological movements--connections that might well be explored in the light of current ethnography. |E. Sociolinguistic and ethnographic aspec||ts of honorific| |use|, in relation to the place of language in wider social theory. Rich ethnographic description of the ethnography of deference and respect, in natural conversation and interaction, is a necessary precursor to a more widely applicable pragmatic account. Moreover, as socially potent linguistic tokens, honorifics serve as particularly striking instances of language as social action, moves in the discourse of power. |F. The interaction of honorifics with related but perhaps| |distinct phenomen||a:| candidates include politeness, respect, deference, formality, and their opposites: rudeness, insult, abuse; joking relationships, avoidance relationships; formality, informality, casual and non-casual interaction. Just as, at the level of language structure, honorific categories often attach to vehicles with different grammatical characters (pronoun and agreement systems, verbal or nominal classifiers, for example), in their social circumstances their use may be linked to specific situations, relationships, or contexts. The components of such interaction must be disentangled for a candidate theory to succeed. |G. Case studies ||of honorific systems|: we will solicit studies from various sociocultural traditions and contexts, with an emphasis on the wider ethnographic significance of honorifics, and their placement within both a general linguistic or ethnographic framework, and an adequate social theory. For further information, please contact John Haviland Linguistics and Anthropology Reed College Portland, OR 97202 (503)771-1112, 771-1197 e-mail: via Unix, end with tektronix!reed!johnh from Internet: johnh%reed%tektronix.tek.com@relay.cs.net from UUnet: reed!johnh@uunet.UU.NET *****END***** ========================================================================= Date: 1 March 1988, 09:39:01 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Magneto-optical disks (33 lines) ----------------------------------------------------- From: Humanists' Group [Taken from ``The Olympus Pursuit'', Vol. 7 No. 1 1988] Magneto-optical discs can now hold a prodigious mount within their 5 1/4-inch format. Now a magneto-optical disc drive offers the means to read, write and erase the data in these information warehouses. .. many have agreed that the future of data storage lies in the magneto- optical disc, a system that can hold as much as 500 floppy discs ... .. After four years of work, Olympus researchers have answered the demands with a new magneto-optical disc drive ... .. Momentum gathered with the development of a laser-optical pickup system. Still other contributions came from development of a new high-speed servo- motor, a linear motor, an error-correction controller and central processing unit. Since the field was new to Olympus, the project took longer than expected. The results, however, set the performance standards in an industry looking toward an estimated disc market of $2,200 million by 1990 ... For further information, contact the Optical Memory Department, Olympus, Tokyo. ========================================================================= Date: 1 March 1988, 09:43:02 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Nota Bene list (53 lines) --------------------------------------------------------- From: David Sitman Dear Colleagues, We have started a new electronic mail special interest list at Tel Aviv University, the Nota Bene discussion list. This list is intended as a forum for discussing issues related to the word processor/textbase, Nota Bene, exchanging tips, asking questions, trading programs, etc. This discussion list is made possible by the list serving software, LISTSERV. Here is how it works: A list of the members is kept in TAUNIVM. Whenever anyone sends electronic mail (or a file) to NOTABENE@TAUNIVM, the mail (or file) is automatically distributed to all list members. All requests to join the list, leave the list, etc., should be sent to LISTSERV@TAUNIVM, and NOT to NOTABENE@TAUNIVM. To join the list, or to correct your name on the list, send the SUB command: SUB NOTABENE Your Name For example, if I wanted to add my middle initial to my name (I don't), I would use the command: SUB NOTABENE David B. Sitman Note that you send your name, not your computer code. TO leave the list, send LISTSERV@TAUNIVM the command: UNS NOTABENE LISTSERV will accept the commands either as interactive messages or as mail. For example, from VM/CMS in BITNET you can send the command: TELL LISTSERV AT TAUNIVM UNS NOTABENE From VAX/VMS, you could use: SEND LISTSERV@TAUNIVM SUB NOTABENE My Name From any computer you can send electronic mail. Make sure that the command that you want to send to LISTSERV is in the mail body, not in the header (e.g., not in the SUBJECT field). The LISTSERV command processor ignores mail headers. We have also made available some programs written for Nota Bene use by Itamar Even-Zohar. Explanations of what these files are and how they can be obtained will appear shortly in the Nota Bene discussion list. David Sitman ========================================================================= Date: 1 March 1988, 09:51:40 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: SQL and Humanities Research (23 lines) --------------------------------------------------------- From: ROBERT E. SINKEWICZ (416) 926-7128 ROBERTS at UTOREPAS I am preparing a report on SQL Database Software and Humanities Research. It will be based in the first instance on our experiences in the Greek Index Project. If there are other installations of SQL software, large or small, mainframe, mini or micro being used by humanities projects, I would be interested in hearing of their existence. When my report is ready I will post it on the HUMANIST file storage area for anyone who may be interested. Robert Sinkewicz Greek Index Project Pontifical Institute of Mediaeval Studies ROBERTS@UTOREPAS ========================================================================= Date: 1 March 1988, 12:38:41 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: The Global Jewish Database and its software (133 lines) Dear Colleagues: Some time ago I made reference to the "Global Jewish Database," and in particular to its full-text retrieval software. We were, as you'll recall, discussing the specific things that humanists want to do with large amounts of text, e.g., as provided on a CD-ROM. Since I've received a few enquiries about this Database, and since my Centre is one of the few places outside Israel connected to it, I thought I'd send along the following brief description. Willard McCarty mccarty@utorepas The Global Jewish Database is a 70-million-word electronic corpus in Hebrew accessed by means of a full-text retrieval system running on an IBM mainframe at Bar-Ilan University in Israel. The largest part of this database (53 million words, 253 volumes, 53,000 documents) comes from the "Responsa literature," a collection of rabbinical answers to questions about all aspects of Jewish life and culture. This literature spans the millennium from the tenth to twentieth centuries and originates from more than 50 different countries. It thus comprises a very rich storehouse of information on Jewish law, history, philosophy, ethics, customs and folklore, and is of interest for both religious and secular scholarship. The other parts of the database include the Hebrew Bible (fully vocalized, with marks of cantillation), the Babylonian Talmud, the Midrash literature, Maimonides' Code, and various medieval biblical commentaries. By arrangement with the Institute for Information Retrieval and Computational Linguistics at Bar-Ilan, the Database is accessible to anyone with a PC and a modem via a telecommunications network such as Telenet or Datapac. To date connections have been established at the Rabbinical Court of London, at the Institute for Computers in Jewish Life (Chicago, Illinois), and the Centre for Computing in the Humanities, Univ. of Toronto, besides 25 connections at various research centers in Israel. The connection in Toronto is the only one to a research institution outside Israel; so far it has been used both by members of the local Jewish community and by academics. Computing humanists without interest in the contents of the Database will, however, likely be interested in its software. Although this full-text retrieval software was developed at the Institute in Bar-Ilan especially for the Hebrew Database, it has recently been adapted for use with English language texts. It allows searching for words and phrases with positive and negative proximity operators on the word, sentence, and paragraph levels, and for combining different queries with boolean operators. Besides a full pattern-matching component (with left, middle and right truncations, wild cards, and boolean constraints on the occurrence of strings in the pattern), it embodies a sophisticated morphological component that allows the user to retrieve all grammatically derivative forms of a word automatically by specifying merely its lemma. Through the technique of "short-context disambiguation" the system also permits most unwanted occurrences of a word to be eliminated before full retrieval: occurrences are grouped and listed with their nearest verbal neighbours, either to the left or right, and from this list the user selects which are to be retrieved. Since in general the number of different neighbors that are also relatively frequent turns out to be quite small, the user can disambiguate a large number of occurrences quickly. For example, "see" causes "see", "sees", "saw", and "seen" to be retrieved, while the difference between "he saw" and "the saw" allows the homographic noun to be identified and eliminated immediately. Experiments have shown that native speakers have a high degree of proficiency in making such choices on the basis of very limited contexts. By statistically analyzing some of the retrieved relevant documents, a local feedback module can suggest to the user new words to be included in his query. A local thesaurus element allows the user to define and later edit families of related terms to be considered equivalent and to be automatically retrieved whenever the family name is mentioned in the query. Specialized communications software with error-correction and compression modules handles all necessary protocol conversions and insures that the rapid response time of the software is practically unaffected by the relatively slow 1200-baud speed of transmission across telephone lines. Experience with the Database from North America, for example, suggests that a 10 second response is not uncommon. Research for the Database was initiated and conducted from 1966 to 1975 by Prof. Aviezri Fraenkel and developed since then at the Institute for Information Retrieval and Computational Linguistics, Bar-Ilan University, Ramat-Gan, Israel 52100, by its Head, Prof. Yaacov Choueka, and colleagues. For information contact Prof. Choueka at that address; telephone: 03-53718716; e-mail: choueka@bimacs.biu.ac.il . The following references may be of interest: Choueka, Yaacov. "Computerized Full-Text Retrieval Systems and Research in the Humanities: The Responsa Project." CHum 14 (1980): pp. 153-169. ... R. Attar, N. Dershowitz,and A.S. Fraenkel, "KEDMA--Linguistic tools for retrieval systems", J. of the Ass. Comp. Man., 25 (1978) pp 52-66. ... "Linguistic and Word-Manipulation Components in Textual Information Systems." In The Application of Mini- and Micro-Computers in Information, Documentation and Libraries. Ed. C. Keren and L. Perlmutter. Elsevier, 1983. pp. 405-17. ..., S.T. Klein and E. Neuwitz. "Automatic Retrieval of Frequent Idiomatic and Collocational Expressions in a Large Corpus." ALLCJ 4.1 (1983) pp. 34-38. ... and Serge Lusignan. "Disambiguation by Short Contexts." CHum 19 (1985) pp. 147-157. See also "List of Publications (In English)" Institute for Information Retrieval and Computational Linguistics (The Responsa Project), Bar-Ilan Univ., August 1987. *****END***** ========================================================================= Date: 1 March 1988, 12:49:12 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Computer scientists etc..... (66 lines) --------------------------------------------------------- From: Richard Giordano My original message regarding SNOBOL and large systems was not meant to attack computer scientists, nor did I even suggest that Amsler is a computer scientist. I should by way of explanation mention that I am completing a dissertation on the early history of data processing, and the emergence of computer science in the early 1960s. Some of what I have observed in my research guides the way that I approach this issue of large systems, management, and the choice of programming languages. Giampapa is absolutley correct when he states that the selection of programming languages are not always reduced to concerns of the optimal language. He then mentions such factors as "future programming support, the availability of coders and the implementation of the language on a system, and the cost of maintaining such a system are important managerial concerns." From what I've gathered, they are not important concerns--they are absolutely critical in the choice of a language. Equally important is the language that the shop is already using. You'd be surprised what has been programmed in COBOL and FORTRAN, especially after ALGOL was introduced. You'd be even more surprised to learn which features in languages (like the use of based variables in PL/I) are forbidden because of what managers considered their intinsic difficulty to learn. A fundamental difference between computer scientists and data processors is that the managers are mainly interested in getting the job done with the least amount of present or future disruption. From what I can tell, programmers and managers don't work together in selecting a language, and programmers (coders) are really something like a high-tech proletariat (but let's not take the analogy too far). Anyway, if a shop is programming in FORTRAN or COBOL, it would take an awful lot of convincing to switch to some other language. Anyhow, this was how commercial shops work--and I stand by that. Academic environments may not function in exactly the same way. But let's face it, academic shops are small potatoes in the grand scheme of things. As for computer scientists... Geeze, I wasn't trying to insult anyone, and I am surprised over the vehemence of Giampapa's reply. In fact, upon re-reading my message, I still don't think I've said anything to "alienate computer scientists." But Giampapa uses a word that is critical in understanding a computer scientist and a practitioner--that word is "professional." Nothing is intrinsically wrong with that, but what about those who do computing, but who are not computer scientists? The answer, as it has panned-out throughout the sixties and seventies, is that the others are outside of the core information circuits, outside of the means by which they self-consciously think of themselves as computer scientists, outside of the profession. C'mon, that's the nature of professions, and we all know it. What makes this relevant? Sometimes practitioners, trained in something other that computer science, come up with solutions that may not (or may) have anything to do with how computer scientists do things. What's to make one solution better than the other? Most of us on the HUMANIST are not computer scientists, and many of the solutions to our problems may seem 'unprofessional'--I'm not putting words in anyone's mouth here. That brings me to my original statement that computer scientists are not always right. In one environment they may be right, but the world's a big place, and there is often more than one way to skin a cat. ========================================================================= Date: 1 March 1988, 12:52:25 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: PostScript non-standard fonts? (19 lines) --------------------------------------------------------- From: Susan Hockey Does anybody know of any PostScript versions of non-standard fonts which are either public domain or available on a site-licence? We are particularly interested in Greek, Hebrew, Arabic and Cyrillic as well as an extended Latin alphabet including Old English characters. Susan Hockey SUSAN@VAX.OXFORD.AC.UK ========================================================================= Date: 1 March 1988, 20:08:45 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Apology (21 lines) --------------------------------------------------------- From: Joe Giampapa To Rich Giordano and HUMANISTs: I would like to apologize for my reply to Rich's [2-26 12:33] letter. Also, I would like to retract the last paragraph of that letter -- it clearly renders me a hypocrite. I should not have responded with such strong language to something of which I did not know the full context. With sincere regrets, Joe Giampapa giampapa@brandeis.bitnet ========================================================================= Date: 1 March 1988, 20:15:24 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Prolog and Lisp (72 lines) --------------------------------------------------------- From: Joe Giampapa Joergen Marker recently asked about what tasks Prolog and LISP are better suited for. Here is a brief description and attempted explanation off the top of my head. If people would like a more thorough explanation and some examples of code from each, I will have to get back to them after digging up some archived programs and notes. Prolog first: (see also "Programming in Prolog" by Clocksin and Mellish, Springer-Verlag) Prolog creates and manages a database of facts. The command structure analogous to other language's "procedures" and "functions" is the prolog "predicate" which basically evaluates to "true" or "false". The arguments to the predicate are the objects you are looking for. A common warm-up exercise is to create a prolog geneology: human(Mary,female). human(John,male). human(Bill,male). parent_of(Mary,Bill). parent_of(John,Bill). offspring(Bill). parent(X) :- human(X) and parent_of(X,Y) and human(Y) and offspring(Y). ?- parent(Z). Z=Mary etc. A package that comes with Prolog are DCG's, which correspond roughly to context free grammars. They are a sort of "macro" for prolog, which use the above-described structure for doing parsing. Here is an example of a DCG grammar which will parse a Pascal program. The lower case names are literals which the parser looks for in the program text, the upper case names are further DCG expansion rules. Pascal --> program NAME ( DEVICE-LIST ) ; const CONSTANTS type TYPES var VARIABLES begin BODY end. NAME --> [_] ; means accept anything . . . BODY --> .... With some limited success, you can achieve versatility in parsing English (or any other "natural language") sentences. LISP is an nth-order language, which means you can derive any language from it (including Prolog). Prolog is only 1st-order and cannot be designed to write a LISP interpreter (that is, without extreme hacks and "unpure" Prolog constructs). For this reason, you can write anything you want in LISP. However, LISP code usually does not conceptualize some constructs as elegantly as Prolog does. I hope this helps out. I can fill in any specific "holes" people have questions about. Joe Giampapa giampapa@brandeis.bitnet ========================================================================= Date: 1 March 1988, 20:19:12 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: More on the Global Jewish Database (28 lines) --------------------------------------------------------- From: John J. Hughes Perhaps those HUMANISTs who inquired about IRCOL's Global Jewish Database and the Responsa Project might find the detailed review of those projects in the June 1987 _Bits & Bytes Review_ (pp. 7-12) helpful. That review was written with the cooperation and assistance of Yaacov Choueka, so it is both up-to-date and accurate. I'll be glad to send a free copy to any interested HUMANISTs. They may contact me as XB.J24@Stanford or c/o Bits & Bytes Computer Resources 623 Iowa Ave. Whitefish, MT 59937. John J. Hughes ========================================================================= Date: 1 March 1988, 23:29:30 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Programmers (47 lines) --------------------------------------------------------- From: amsler@flash.bellcore.com (Robert Amsler) There are two usages of the word programmer which need to be clarified. In the Data Processing/Business world, the term `programmer' is used for the basic generic worker; akin to `secretary'; who does what they are told the way they are told to do it. These people do indeed work in `shops' and in horrible languages on business machines (i.e. IBM's) a lot. They make the bank payroll programs (and the phone system and its billings) work. The other use is that commonly employed in academia, which refers to anyone who writes programs. Typically such people ALSO originate the task the program is trying to accomplish (in the DP world this would mean they are more like ``system analysts'' than ``programmers''). These people have varied backgrounds and may hold advanced degrees in all sorts of fields. The term `hacker' and `wizard' are used to refer to the most revered members of the group--hacker meaning someone who figures out how to do things without being told how and wizard being someone who KNOWS how things can be done (having perhaps figured them out via hacking). The discussion about programmers and computer scientists seems plagued by a misunderstanding as to which group of `programmers' are being discussed. A language such as SNOBOL or LISP or PROLOG would have very little use among the members of the ``programming shop'' community. However, among the members of the latter group, these languages might be at least equal in their use to those of FORTRAN, COBOL, etc. It would be inappropriate to describe the ``programmers'' in EITHER environment as not amounting to much. On the business side, the world would cease to run if those programmers stopped doing their daily routine programming tasks. On the academic side, nearly all the advances in computer science have come from university environments. This includes time-sharing, computer graphics, several computer languages, database management, information science, etc. Robert Amsler ========================================================================= Date: 2 March 1988, 12:53:00 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: CD-ROM Configurations (43 lines) --------------------------------------------------------- From: Bob Kraft A week ago, Joe Giampapa asked for information about using CD-ROM technology, and John Gleason (PHI) responded to part of Joe's question by outlining the steps in preparing a laser disk. The costs of such mastering fluctuate, but seem to be in the neighborhood of $2000 to $3000 at present (John would know more accurately). That, of course, does not include the countless hours of formatting the files, preparing the ID tables, etc., prior to sending it off for mastering. As for hardware and software to access a CD-ROM from an IBM type microcomputer, one needs a reader (we use the Sony, which is also a standard component of the micro-IBYCUS Scholarly Computer) and an interface/controller card. The cost here is around $750, unless it has dropped recently, and doubtless varies from manufacturer to manufacturer or dealer to dealer. To use the new "High Sierra" format TLG "C" disk or the PHI/CCAT demonstration disk, one also needs the "DOS Extension" software from MicroSoft that is available from various sources at minimal cost (we paid $10). Finally, for the aforementioned CD-ROMs, software to decode the IDs in the text, etc., is necessary to make things work effectively. CCAT is preparing such software, and plans to make it available as a basis for further cooperative development and/or use at fairly nominal cost (hopefully under $100). Of course, for those fortunate enough to have purchased a complete IBYCUS SC system ($4000, including Sony CD-ROM reader), all the necessary hardware and software comes with the package and works efficiently and impressively from the start. It will take some time before people with IBMs or other machines can come anywhere close to the IBYCUS standard. Bob Kraft (CCAT) ========================================================================= Date: 2 March 1988, 21:03:05 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: More on Prolog (70 lines) --------------------------------------------------------- From: Joe Giampapa I have received a few questions relating to my posting on Prolog, yesterday. Here they are: 1. "Has Prolog been standardized?" As far as I can tell, the most "standard" description of the language is that given by Clocksin and Mellish, "Programming in Prolog" (Springer-Verlag). All implementations must satisfy the minimum requirements as stated there. Some implementations may have more features, but that book is the bare-bones. I think people at the University of Edinbergh would be better authorities on what is the language "standard". 2. "Can it 'deal well' with non-Western-European languages?" I assume that this makes reference to the difficulties imposed by strings of characters in a non-Roman character set. What one would have to do is include in their Prolog code routines which would map from an ASCII character set (or whatever your machine supports) to their own character fonts. The Prolog interpreter does not care what symbols it manipulates, so you could conceivably run Prolog in a special character display package. The degree of "well"ness or efficiency depends on how well this has been implemented at your site, and the sophistication of your tools. I do not know of any "alternate character set" packages which will keep your system "standard" in a portable way, if you do need them. 3. "Will it really be worth it to make the effort of learning Prolog?" Some tasks are easily suited for Prolog, and the concise representation it can give you would be well worth while. Whether it is "worth it" depends on the nature of your work. It might well be worth some time and effort to become more familiar with it for future reference. 4. "Where is Prolog's strong point?" In a simplistic way, the strength of a Prolog system is in the way it searches for items in its database. As long as it can find something to satisfy its goals, it will proceed down to the next level, look there, and continue. If it cannot find something to satisfy its goal, it will "backtrack", which is a little complicated to explain. In practice, if you are parsing a sentence which can be parsed in more than one way, Prolog will automatically return the alternate parse trees. 5. "Could you offer a sample of [...] something that all of us might find useful - and explain what all the little nick-nacks mean? Then could you do the same for Lisp in another posting?" OK. What would be useful to all? A complete parsing program with full documentation? Something else? Send me some suggestions and I will pick something from them. Finally, I would like to throw the door wide open for additional commentary. Some people know Prolog, and have sent me notes in response to my posting. Please, publicly correct me and add to what I say. ========================================================================= Date: 3 March 1988, 00:51:30 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Request for announcements of conferences; plan for same (20) Would anyone with an announcement of an upcoming conference or call for papers please send me the notice so I can post it on our file-server? My request applies to all such notices, whether they have been circulated on HUMANIST or not, except for notices of conferences that have already taken place. My plan is to keep current announcements on the server and to distribute to all of you only a brief summary of the upcoming events. Comments, objections, shouts of relief? Willard McCarty mccarty@utorepas ========================================================================= Date: 3 March 1988, 09:18:29 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Software for "roots"? (33 lines) --------------------------------------------------------- From: Tom Flaherty I have recently been bequeathed the "family tree" for my mother's side of my family. My uncle worked on it quite vigorously for about 40 years, so it now contains thousands of names/dates and a great deal of narrative information. I would like to organize all of this stuff (the amount of paper is incredible) into a "database" that will make it less forbidding and more accessible. Also, should I ever have the time and energy, I would like to be able to fill in a blank or two in the historical information, and I am now obligated to update the near end of the tree with current events -- births, deaths, etc. So, my question is: Does anyone know of any *good* system for genealogical record keeping? Ideally, it should provide for a virtually infinite number of entries and links AND be able to hold textual information (biographies) in some organized way. Probably, one of the off-the-shelf database packages could be used. I just don't know enough about them to choose the most likely products to investigate. Is this a hyper/card/text application? I have a PC clone but would like to hear about systems for any hardware. My main concern is to get the material into a "permanent" system. There is room in a life to do this sort of thing only once. Any advice will be greatly appreciated. Thanks. --Tom Flaherty flaherty@ctstateu.bitnet ========================================================================= Date: 3 March 1988, 19:23:00 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Software for roots (24 lines) --------------------------------------------------------- From: Francois-Michel Lang This may sound like an odd idea, but I know that the Mormon church has investigated precisely this problem and invested quite a lot of time and money into developing genealogical software. I have never seen or read about any of their methods, but I spoke with some LDS (Latter-Day Saints) Church members at a Logic Programming conference in Salt Lake City a couple of years ago, and learned of the LDS Church's interest in this sort of thing. That might be a place to start... Francois-Michel Lang Paoli Research Center, Unisys Corporation lang@prc.unisys.com (215) 648-7469 Dept of Comp & Info Science, U of PA lang@cis.upenn.edu (215) 898-9511 ========================================================================= Date: 3 March 1988, 19:27:57 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Genealogy (24 lines) --------------------------------------------------------- From: Mark Olsen Tom Flaherty's request for info on geneology systems may be of more general interest, since historians frequently have to represent family linkages on large amounts of data. The best system for this seems to be GENESYS, developed by Mark Skolnick et al. You might consult "A Computerized Family History Data Base System" *Sociology and Social Research* 63 (April, 1979): 506-523. There is a good description of the application of this system in the Saguenay project by Ge/rard Bouchard, "The Processing of Ambiguous Links in Computerized Family Reconstruction" *Historical Methods* 19 (Winter, 1986): 9-19. Nominal record linkage and family reconstruction are areas where historians (bless our souls) have been developing computer methods in innovative and interesting ways, just in case we were getting to worried about the "literary ghetto" some HUMANISTS are afraid of. ========================================================================= Date: 3 March 1988, 19:33:27 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Prolog and logic, Prolog and parsing (76 lines) --------------------------------------------------------- From: Michael Sperberg-McQueen Two points worth stressing about Prolog for humanists who think they may be interested in learning it: 1 Prolog, as its name implies, is an attempt to make it possible, or nearly possible, to write 'programs' that are nothing more than sets of statements expressed in first-order predicate calculus. While the relations between Prolog and symbolic logic as you may have learned it in Philosophy 150 are not always obvious, they are there, and for people interested in symbolic logic Clocksin and Mellish's Chapter 10 ('The Relation of Prolog to Logic') makes fascinating reading. It clarifies the nature of the inferences a Prolog system can make, points out the various ways in which Prolog's version of logic loses nuances that can be important to the logical form of propositions in the predicate calculus, and develops a method for reducing predicate-calculus statements to Prolog clauses. (An appendix gives Prolog programs that will do the transformation for you, but it's worth doing it manually on some samples first.) That is, the logical underpinnings of Prolog as a system are almost as interesting as what you can do with it as a language. ***If you think symbolic logic is or can be beautiful, I think you'll like Prolog.*** It should be noted, though, that it can be hard to switch from the procedural, step by step style of analysis one acquires from other programming languages, to the non-procedural, declarative interpretation of Prolog programs. There turn out to be lots of things I know how to do step by step, that I cannot define readily in predicate calculus. And since Prolog programs have both a declarative and a procedural interpretation (that is, they *are* programs that are supposed to *do* things), working with Prolog can induce some intellectual dizziness. 2 Prolog provides a convenient way to parse expressions using Chomsky-like rewrite rules, and many implementations provide facilities for working with a special notation for such rewrite rules. (This is the 'definite-clause grammar' notation mentioned by Joe Giampapa.) I am less enthusiastic about this than most people seem to be, because these facilities enforce a specific left-to-right parsing strategy that seems on the whole better suited for things like Pascal programs or SGML document component hierarchies than for natural language texts. (And even for such unnatural grammars I am having trouble finding a definite clause notation that correctly parses an SGML document -- maybe my fault and not that of the notation, but still frustrating. Has anyone else done this sort of thing with better success? Write me if you have.) But even if one ignores the builtin 'grammar' notations and writes one's own parser, Prolog handles a lot of the details more conveniently (*NOT* faster!) than other languages. To parse a lot of text, I'd almost surely want to write a parser in some other language, for speed. But only after working out the parsing strategy with Prolog. ***For developing a parser, Prolog has a lot of advantages.*** Finally, a note on products: Borland's Turbo Prolog is very nice, seems to run fast, and has a convenient (though complicated) multiwindow interface. But they achieved the speed by leaving out some of the key features of Prolog, qua logical system. You may not feel that you've thrown your money away by buying Turbo Prolog, but if you are interested in logic, then you will eventually want a fuller implementation. (I have not compared them all, but have been happy with Arity on the PC and the Waterloo Core Prolog interpreter on our IBM mainframe.) Michael Sperberg-McQueen, University of Illinois at Chicago ========================================================================= Date: 3 March 1988, 19:41:06 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Software for roots (28 lines) --------------------------------------------------------- From: David Nash I would like to second the inquiry of Tom Flaherty (message of 3 March 1988, 09:18:29 EST). For MS-DOS, and the Mac, the main contenders I know about are: (1) Quinsept's Family Roots (Mac version reviewed favourably in Feb. 1988 MacWorld pp.213-4, but not mentioning that the complete equivalent of the MS-DOS version is not yet available); (2) Personal Ancestral File from the Church of the Latter-Day Saints. I would like to hear any information about the latter, not having yet tried to pursue it through Salt Lake City. There was a newsletter "Genealogical Computing" published in Virginia; maybe still exists. -DGN ========================================================================= Date: 3 March 1988, 19:45:22 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: More roots to follow.... (15 lines) --------------------------------------------------------- From: cbf%faulhaber.Berkeley.EDU@jade.berkeley.edu (Charles Faulhaber) I have seen advertised (but know nothing about) a program which I believe was originally developed for the Mormon Church; and I suspect that inquiries to their genealogical society in Salt Lake City might be fruitful. ========================================================================= Date: 3 March 1988, 23:32:15 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: More roots (20 lines) --------------------------------------------------------- From: Norman Zacour I used to see advertisements for a product called Family Tree, which began: "Trace 10 generations of ancestors or pet pedigrees." It was sold by Systems Consultants, Inc., P.O.Box 37076, Raleigh, NC 27627, ph. 800-334-0854, ext.508. But all this was two years ago, and for all I know the company may have disappeared since then. I should think that historians might be interested in some good software for pet pedigrees. Do tell us what you find out. Norman Zacour (Zacour@Utorepas) ========================================================================= Date: 3 March 1988, 23:34:59 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Of the tracing of roots there is no end (18 lines) --------------------------------------------------------- From: Norman Zacour Now there is a program called Roots II, recently advertised in PC Magazine. "Organize your family tree and print camera-ready family books containing charts, text and indexes. Store, retrieve and display thousands of family facts with biographical sketches and source documentation. Lightning-fast searches and sorts. 250 page manual. Free brochure. Price: $195 (US)." Commsoft, 2257 Old Middlefield Way, Ste.A, Mountain View, CA 94043 (ph. 415-967-1900). ========================================================================= Date: 4 March 1988, 09:24:39 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Computer-mediated communication (22 lines) --------------------------------------------------------- From: RD_MASON@VAX.ACS.OPEN.AC.UK I wonder if I might use this forum to announce a conference hosted by the Open University, U.K. on computer-mediated-communication in distance education. It is to take place Oct. 8 - 11 and will consist of a workshop on the Open Universities' large scale use of the conferencing system, CoSy on an Information Technology course with 1500 distance students, and a colloquium with invited educators and researchers involved in a variety of educational applications of CMC. Because of limited accommodation here, numbers will be limited to 100 participants. If you are interested and want more details, please send a mail message to RD_Mason@uk.ac.ou.acsvax. [that's rd_mason@vax.acs.ou.ac.uk for those on Bitnet &c. -- WM] ========================================================================= Date: 4 March 1988, 09:31:39 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Prolog and Lisp (24 lines) --------------------------------------------------------- From: Hans Joergen Marker In my earlier note I posed the question "what kind of tasks are so much better handled in Prolog and Lisp than in C....?". In Joe Giampapa's answer I see no reference to C. An important question (at least to me) is the performance of the generated code. What I find in the answer is examples of specific program syntax, which naturally could not be used unaltered in C, but which on the other hand could be replaced by structures, pointers and functions in a quite legible way. The performance of a C solution to a specific problem would be considerably better (I suspect) than the solution to the same problem in Lisp or Prolog. So the question remains: "Are there problems out there that you can't solve in C, but only in other languages?" ========================================================================= Date: 4 March 1988, 09:35:08 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Overwhelmed by the roots-software (32 lines) --------------------------------------------------------- From: Tom Flaherty I am overwhelmed! To my posting to HUMANIST requesting information about computerizing a family tree, I have received 23 replies (in less than 24 hours). Most of them have suggested sources of programs, a few have asked me to share my findings with them. Given the apparent interest, I will compile a list of the suggested software and sources thereof and post it to HUMANIST. I have only had time to glance at the responses so far, but I can report that the "Personal Ancestral File" software from the Church of Latter Day Saints was the most frequently suggested program. (Why didn't I think of them? It seems so obvious now.) It may be a short time before I have the opportunity to sort this out and report back, but I do want to express my appreciation to all of those who have responded or may yet do so. It seems that HUMANISTs really are just that. Many Thanks. --Tom p.s. Please do continue to send me ideas. I will include all I receive in my "list." ========================================================================= Date: 4 March 1988, 09:51:19 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Selecting a programming language (71 lines) --------------------------------------------------------- From: John C. Hurd The remark about lack of humor on the network a while ago and the current discussion of the merits of various programming languages reminded me of the appended analysis. It includes APL, one of my favorite languages, but omits SNOBOL4(+), my very favorite. John Hurd HURD@UTOREPAS Selecting a Programming Language Made Easy Daniel Solomon & David Rosenblueth Department of Computer Science, University of Waterloo Waterloo, Ontario, Canada N2L 3G1 With such a large selection of programming languages it can be difficult to choose one for a particular project. Reading the manuals to evaluate the languages is a time consuming process. On the other hand, most people already have a fairly good idea of how various automobiles compare. So in order to assist those trying to choose a language, we have prepared a chart that matches programming languages with comparable automobiles. Assembler - A Formula I race car. Very fast, but difficult to drive and expensive to maintain. FORTRAN II - A Model T Ford. Once it was king of the road. FORTRAN IV - A Model A Ford. FORTRAN 77 - A six-cylinder Ford Fairlane with standard transmission and no seat belts. COBOL - A delivery van. It's bulky and ugly, but it does the work. BASIC - A second-hand Rambler with a rebuilt engine and patched upholstry. Your dad bought it for you to learn to drive. You'll ditch the car as soon as you can afford a new one. PL/I - A Cadillac convertible with automatic transmission, a two- tone paint job, white-wall tires, chrome exhaust pipes, and fuzzy dice hanging in the windshield C - A black Firebird, the all-macho car. Comes with optional seat belts (lint) and optional fuzz buster (escape to assembler). ALGOL 60 - An Austin Mini. Boy, that's a small car. Pascal - A Volkswagon Beetle. It's small but sturdy. Was once popular with intellectuals. Modula II - A Volkswagon Rabbit with a trailer hitch. ALGOL 68 - An Astin Martin. An impressive car, but not just anyone can drive it. LISP - An electric car. It's simple but slow. Seat belts are not available. PROLOG/LUCID - Prototype concept-cars. Maple/MACSYMA - All-terrain vehicles. FORTH - A go-cart. LOGO - A kiddie's replica of a Rolls Royce. Comes with a real engine and a working horn. APL - A double-decker bus. Its takes rows and columns of passengers to the same place all at the same time. But, it drives only in reverse gear, and is instrumented in Greek. Ada - An army-green Mercedes-Benz staff car. Power steering, power brakes and automatic transmission are all standard. No other colors or options are available. If it's good enough for the generals, it's good enough for you. Manufacturing delays due to difficulties reading the design specification are starting to clear up. ========================================================================= Date: 4 March 1988, 14:41:21 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Hyper-roots (19 lines) --------------------------------------------------------- From: Mary Peterson I've read the materials about software for family trees, etc., and I still think HyperCard on the Macintosh is the best choice for this application. Mary Peterson University of New Hampshire M_PETERSON@UNHH ========================================================================= Date: 4 March 1988, 14:43:00 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Reply to Hans Joergen Marker (27 lines) --------------------------------------------------------- From: Joe Giampapa Q: "Are there problems out there that you can't solve in c, but only in other languages?" [emphasis on performance] I would say not. C gives one amazing control over a computer system. The other languages stress "conceptual control" to the program designer. Lisp and Prolog hide the pointers and lower level features from the programmer, directing concentration on the higher-level objects and constructs, themselves. C allows the clever programmer to do practically anything in the most efficient way as the programmer sees fit (but gives enough rope to hang inexperienced programmers). I have seen some pretty fast Lisp systems, whose time-lag behind C systems is not that noticeable. I have not seen too many fast Prolog systems. Joe Giampapa giampapa@brandeis.bitnet ========================================================================= Date: 4 March 1988, 14:45:34 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Prolog (56 lines) --------------------------------------------------------- From: Leslie Burkholder (1) Are there problems you can't solve in C but only in other programming languages, eg Prolog or Lisp? Answer: No. C, Prolog, and Lisp (and other standard computer programming languages, eg, Basic) are of equivalent computational capacity. What you can do in one you can always find a way to do in another. Indeed, there are versions of Lisp and Prolog written in C. This is suffient to show that whatever you can do in either Lisp or Prolog you can do in C. The relevant question is ease of accomplishing the task. Take one of the examples provided by Mr Giampapa, writing a CFPSG and a top-down parser. That's available in most Prologs (Turbo Prolog does not have it). But you can build it in C with more work. (2) Prolog and predicate logic. People should know that the Prolog language hasn't the same expressive power as any language for first-order predicate logic. There are some things you can say in a predicate logic language for which there is no translation in Prolog. The translator in Ch 10 of Clocksin and Mellish, Programming in Prolog, translates from the predicate logic language into a clausal form language. But there are some legal sentences in a clausal form language not translatable into the more restrictive Prolog language. People should also know that the inference engine in Prolog is incomplete. For example, a complete inference engine for things sayable in the Prolog language should be able to infer b from a if b. b if a. a. but the inference engine in Prolog will not return a "yes, it can be inferred". It will go into a loop. None of these things will make those who find logic beautiful very happy. (3) CFPSG's and DCG's. DCG's are availble in most Prologs. What is also available is a top-down parsing mechanism to make use of DCG rewrite rules. This is available because the DCGs are just notational variants of regular Prolog code and the parsing mechanism is just Prolog's inference engine put to use on this code. DCG's are more powerful than CFG's. CFG's are composed of rewrite rules of the form X --> Y where X is a Prolog atom and Y one or more Prolog atoms (that is, there is a restriction on what X and Y can be). DCG's expand what X and Y can be in two ways: they can have arguments and Y can include executable Prolog goals. There are examples of these extensions in Clocksin and Mellish, Programming in Prolog, secs 9.4 and 9.5 respectively. ========================================================================= Date: 4 March 1988, 14:47:49 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Computable solutions (57 lines) --------------------------------------------------------- From: Michael Sperberg-McQueen Hans Joergen Marker asks whether there are problems that simply cannot be solved in certain languages (e.g. in C), but which require other languages. Computer scientists on the list may wish to correct me if I am wrong, but I am fairly sure the answer is no. If your language allows you to say "Subtract X from Y and if the result is negative, branch to location Z" (or the logical equivalent), and the problem you want to solve can be solved in some other computer language, then you can solve it in your language. This follows, does it not, from Turing's discussion of computable numbers. Of course, no one is claiming that working with a language this primitive will be any fun, or that the program will be readable. There is an analogous theorem in sentential logic, which demonstrates that the operators of sentential logic ('and,' 'or,' 'not,' 'if,' 'if and only iff' and so on are all superfluous and every sentence of sentential logic can be expressed using only one operator: the 'Sheffer stroke' (named for its inventor), which means 'not both.' If we write the Sheffer stroke with '|', then 'A|B' means 'A and B are not both true,' and we can paraphrase the other operators thus: not A A|A A or B (A|A)|(B|B) if A then B A|(B|B) A and B (A|B)|(A|B) But although an interesting result (and perhaps profoundly significant in symbolic logic), Sheffer's notation is not nearly as convenient for practical logic as is the conventional notation. And so it is not used. The difference between Prolog and Lisp on the one hand and languages like C or assembler on the other is similarly one of notation, not power. It is easier, many find, to think in Lisp or Prolog terms and let the scut work of translation into machine terms be handled by the compiler or interpreter. The logical structure of the program is easier to display -- and easier to implement because you don't have to write all your own procedures for handling unusual data objects. To be sure, it's possible to display the logical structure of a solution in Pascal or C or Assembler, too -- but it's likely to be harder to change it, since you will have to change your underlying procedures. For this reason some AI shops develop programs in Prolog, and then translate the finished product into C for the production version. The simple rule: use an 'AI Language' to optimize programmer productivity; use a lower level language to optimize machine time. ========================================================================= Date: 4 March 1988, 14:49:01 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Snobol as an automobile (20 lines) --------------------------------------------------------- From: amsler@flash.bellcore.com (Robert Amsler) How about..... snobol4 - A Winnabago camper. Needs lots of space, very comfortable inside when exploring the countryside; but neither built for speed nor tight parking. ICON - A modern version of the Winnabago, shipped as a kit. Claims to get good gas mileage, but older Winnabago owners seem unconvinced. ========================================================================= Date: 4 March 1988, 14:51:53 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: French --------------------------------------------------------- From: Jacques Julien OVERTURE (alla Water music, but a bit slower and somewhat pomposo) I have been watching the river flow for a while now and it is very interesting. I would describe the show as a colourful pageant of boats, some of them quite impressive, fast and powerful and a very small population of surfers. My residence is too far away from the Maritimes and all that I can think of to join the stream is a bottle, a good and cosy one, let's say Chianti Ruffino. It has been on my desk for years. So, I take away the candle I used to decipher my manuscripts at night and I kick the vessel into the channel. FIRST MOVEMENT (French aria, double dotted) I operate in a rare, monstruous, extravagant area called French. And it is not even the good Burgundy of blue, white and red French, but its sparkling and lighter version: French-Canadian! I have a feeling of always looking at the dark face of the moon. In fact, and to keep on with the same staging, French seems to be as repulsive to the Computing Hegemony as garlic is/was? to Dracula. It reacts in the same way: horror or evasion but it can never get to swallow the *!!!* bulb.... For example, what do we do with accents on mainframes? SECOND MOVEMENT: The merry widow at her simultaneous windows I would like to list certain items on which I am sure the network can be very helpful. As stated in my *hagiography *, I am working in French-Canadian literature and popular culture (songs). The tools I am looking for are: 1. Database. One, or more. Relational, must be open to data stricto sensu and to added text like: annotations, commentaries, full transcript of lyrics. 2. Stylistic analysis device. I am thinking of Deredec and its sub-products, which I have not tried yet. In the long term, I would like to build an analysis that would integrate (not simply place side by side) lyrics AND music. When I read the report from the Conservatorio di Musica L. Cherubini, I tried to catch the next plane to Italy, but planes heading for sunny countries never land on my iceberg. 3. Access to large collections of texts in French from France and from North America, literature and references like dictionaries. 4. CAI. "What do you do for a living, besides watching the river flow?" Well, I must confess, I teach French. That is why I am interested in software dealing with interactive writing in ..... French! CONCLUSION coda/cauda, and no venenum I appreciate HUMANIST very much. It is a welcomed network, much needed and improving with use. Do not send me too many bottles back: I do not want to block the channel. Julien@Sask ========================================================================= Date: 4 March 1988, 15:06:44 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion Comments: From: Charles Young, Philosophy, The Claremont Graduate School From: MCCARTY@UTOREPAS Subject: Displaying and printing Classical Greek (19 lines) --------------------------------------------------------- From: Charles Young (youngc@clargrad) Over the past year or so I have maintained a list of packages that claim to support the printing and display of classical Greek. It has finally occurred to me that other HUMANISTS might be interested in the list.... [This list has been posted to the file-server. It should be available by this coming Monday, under the name GREEK SOFTWARE. -- W.M.] ========================================================================= Date: 4 March 1988, 15:12:23 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Addendum (46 lines) --------------------------------------------------------- From: Joe Giampapa I would like to post an addendum to what I said previously about computer languages. Every once in a while, the question pops up in computer circles about "what IS the best language" to program in. Most times it does not attempt to be so cut-and-dry, yet, the variants do not really stray too much from this. In the search for the optimal answer, the question almost never gets answered the way the question was originally posed. The tendency I have observed, is that when programmers are faced with a project, and several languages to choose from for doing the project, their "decision algorithm" proceeds roughly as follows: First: What restrictions on languages are imposed by the problem? Ie. you better not consider a number-crunching language for text-intensive operations. Second: Of the languages available (what they know, or what they are willing to learn), which are more aesthetically pleasing? Sometimes, aesthetics override the first concern. (Once, a friend who was nuts about BASIC wrote programs to simulate recursion. They were slow, and not particularly elegant from my point of view, but they worked.) Third: What are other people, with whom the programmer has regular contact, likely to use? Most people do not want to program alone. If they get stuck, or in a "rut", who can help them out of the bind? Also, programming in an environment where there are a lot of experts in a language helps keep the momentum of a project going. In short, then, I think the "ultimate answer" to the question is, "whatever the programmer wants to use", ... or "42". Joe Giampapa giampapa@brandeis.bitnet ========================================================================= Date: 4 March 1988, 15:14:14 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: c.s. graduates are people too (44 lines) --------------------------------------------------------- From: Dan Bloom My appologies in advance for several things; 1) Unlike most of you, I am not erudite. 2) I may not be timely or on topic. 3) my degree was in computer science. Given the above; Yes, many people of the computer faith do tend to consider themselves above such considerations as ease of use, and prefer elegance over readability/useability. Such will be the case of most whom started computing in the long gone dusty era of punched cards and 256k mainframes where elegance, compactness of code, and speed of execution were paramount. Others of the lofty profession, who take themselves less seriously, such as myself consider the computer a rather advanced tool. As a tool, it must suit the users purpose and not the designers. However, as with any advanced tool, it requires a learning curve, both on the part of the user and of the creators. There also seems to be a mindset of the micro computer industry wherein they feel obligated to recreate every error made in the development of mainframes. In conclusion, if you consider the above to have presented a thesis of any sort, I have put forth the proposition that not *ALL* people who are in the computer industry are inhumane pretentious soothe sayers, some of us are people too. (I have not really taken any offence: in general I agree with most of what has been said in reference to the above and quite enjoy the different view of the field). And in retort, if this network is any indication, Humanists seem to have an obsession with what should be, not what is. Hope I haven't taken too much time....Dan (Improbable) Dan Bloom Senior Consultant Academic Computing Services York University ========================================================================= Date: 4 March 1988, 15:18:25 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: C vs. Prolog (43 lines) --------------------------------------------------------- From: Stephen J. DeRose In reply to Hans Joergen Marker's note: > So the question remains: "Are there problems out there that you can't > solve in C, but only in other languages?" No, there are no such problems. In fact, there are no problems which can be dealt with in only a particular subset of programming languages. The more formal theorem for this is known in CS circles as "Church's Hypothesis" (among other names). All serious computer languages are "functionally complete", and so inter-translatable. Thus, the more relevant questions are: 1) How *easy* is it to learn/use language X? 2) How *fast* can I program problem Y in language X? 3) How *efficient* will my code in language X be? And here we have major differences. For example, right now I'm putting the finishing touch on a program to handle an annotated natural-language dictionary of about 50,000 words. It takes about 3,000 lines of C, because of the need to provide detailed control of storage allocation and data structures. I think I could write the same functionality in about 10,000-15,000 lines of Assembler, or in 750-1,000 lines of Icon or Prolog. It is roughly true that a programmer can write the same number of (working) lines of program per day, regardless of language. So it makes sense to use the most compact language available for the particular problem at hand. Unfortunately, in this case I had to use C rather than Icon or Prolog, because the last 2 do not deal with memory as efficiently by themselves as I can by myself, and I can't afford 8 Meg of RAM for my Mac. Steven J. DeRose ========================================================================= Date: 4 March 1988, 19:06:40 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Family tree software (50 lines) --------------------------------------------------------- From: dow@husc6.BITNET (Dominik Wujastyk) I have used both the Mormon product, Personal Ancestral File (PAF), and the Pine Cone one (is it FTetc for Family Tree Etc?). Both for DOS. I am doing this note from memory, since I am at present in the USA, and all my notes and manuals are back at home in the UK. FTetc (if that's it) was slicker and somewhat faster, since it was compiled. The PAF (Pers Anc. File) was Basic code, and needed fiddling with to set the correct defaults for use on a hard disk. This was clearly described in the manual, but seemed unnecesary in these days of setup menus. PAF has a companion program that can store biographical data about individuals; FTetc includes this in the main prog, but if I remember rightly, PAF allows larger files for this. FTetc had one huge advantage: it allowed you to print a BIG chart piecemeal on several sheets of ordinary computer paper, for gluing together. PAF can handle 135 col paper (I think) but that's it. One bit of the tree at a time. The manual of PAF is written in the style of an obsessive. Everything is hyper neat and repeated several times. I found dealing with PAF (program and documentation) worried me at some deep level: was the author still sane? Nevertheless, he wrote me a nice letter when I sent a query, and probably fits into his community very well (no offence intended in any quarters). By comparison, FTetc is just another good shareware prog. The capabilities are very similar. I had a lot of data in PAF before I heard of FTetc, and I am reluctant to change over. But if I were starting today I think I'd go for FTetc. Of course a lot depends on where the programs go, what upgrades are made, maintenance etc. Imponderables. Dominik. bitnet: user DOW on the bitnet node HARVUNXW arpanet: dow@wjh12.harvard.edu csnet: dow@wjh12.harvard.edu uucp: ...!ihnp4!wjh12!dow ========================================================================= Date: 4 March 1988, 19:16:12 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Summary of conference notice on the file-server (28 lines) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * International Conference on Symbolic and Logical Computing Dakota State College Madison, South Dakota April 21-22,1988 The third International Conference on Symbolic and Logical Computing (ICEBOL3) will present papers and sessions on many aspects of non-numeric computing: artificial intelligence, analysis and printing of texts, machine translation, natural language processing, the use of dangerously powerful computer languages, SNOBOL4, SPITBOL, Icon, Prolog, and LISP. There will be a series of concurrent sessions (some for experienced computer users and others for interested novices). ========================================================================= Date: 4 March 1988, 19:19:08 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Computer language intertranslatability (49 lines) --------------------------------------------------------- From: Sheldon Richmond Are computer languages intertranslatable? There is a discussion in the Talmud that God understands every language, but Angels only understand the Holy Language of the Torah. So, if you want to speak to the Angels, you have to speak in the Holy Language, but God doesn't care what language you speak. Computers are somewhere between Angels and God. Mathematically, computers are God; practically, they are neither. Turing argued that every computer is formally identically: every Turing machine is a Universal Turing Machine. So every computing languague ideally is formally identical. The operative terms are 'ideally' and 'formally'. In practice, not every computing language permits recursion--i.e. statements which call themselves; or functions which define operations in terms of themselves. This is not only important for convenience, and for performing certain algorithms, but for AI simulation. So, then, in the real world, computer languages are not completely intertranslatable. The upshot is that, depending on what one wants to do with computers, one will have to use different languages, and different hardware/software systems. The technology of computers has not done away with the Tower of Babel, or the requirement for multilingualism. Though every few years, new Holy Languages for our computer/angels--PASCAL, C, PROLOG-- are produced. In reality, computers are neither angels nor God. Different languages are required for different purposes, no one language can do all, and some languages are more suited to some tasks than other languages. The proper attitude toward computer systems and languages, is the one that states 'when in Rome do as the Romans do'. You can't expect that one system of manners or etiquette will please all people regardless of cultural background. So, rather than search for the Holy Language, or just use one language regardless of task, choose the language that is most pleasing to the crowd you will be hanging around with for the task at hand. Use the language that the crowd who is working on the project one is interested in for the moment uses--and in that way you will be included in the chit-chat and problem/solution sharing talk. ========================================================================= Date: 4 March 1988, 20:06:10 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Server security (82 lines) --------------------------------------------------------- From: Mark Olsen Security for Kermit3 SERVER operation Kermit3.EXE (2.30) has a number of new features, many of which enhance REMOTE operation. It is now relatively easy to SEND and GET files, etc. (between, say, home and school) by setting one machine in SERVER mode before leaving for the other location. The problem with Kermit3 SERVER operation is security: somebody chancing on your remote machine and erasing your files, putting an infected COMMAND.COM in it, etc. The following is a solution to this problem, offering you a fairly high degree of safety. This technique make use of Kermit3's ENABLE and DISABLE commands. It requires the following: A file much like SECRET, below, which is run on the REMOTE (HOST) machine before it is put in SERVER mode; A file much like PASSWORD (but using your own secret filename!), which must be available on the machine you are using as a terminal. Host file: SECRET: DEFINE SRV OUTPUT ATS0=1\15,SET PARITY NONE,SET BAUD 1200,DO SR2 DEFINE SR2 CWD \XX\XX,DELETE PASSWORD,DISABLE ALL,DO SR3 DEFINE SR3 ENABLE FIN,SERVER,TAKE PASSWORD,SERVER,DO SR2 Terminal file: PASSWORD: ENABLE ALL To use this system: 1) Set up the values you want on the machine which is to run in SERVER mode, then add the commands: TAKE SECRET DO SRV 2) Later, from the second machine, call the number of the SERVER, and you will be connected, but with all services DISABLED; enter the commands: SEND PASSWORD FIN This will cause the host computer to TAKE PASSWORD and reenter SERVER mode. Since PASSWORD contains the command ENABLE ALL, you are now in business. When you are through, you must be sure to DISABLE all services; to do this, type: FIN This will cause the host to rerun SRV2, disabling all services and erasing PASSWORD. notes: Be sure to arrange the host machine so that Kermit3 is looking at an empty subdirectory; Do not use the word PASSWORD! Change every occurrence to a word known only to you. If you find strange files in your /xx/xx subdirectory, it is probably best to erase them, to fend off infection. No guarantees; good luck! *****END***** ========================================================================= Date: 4 March 1988, 21:39:57 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Unix "user-friendly" shell (20 lines) --------------------------------------------------------- From: Vicky A. Walsh Rumor has it that at the Unix conference UNIFORUM held this last February in Dallas, TX. someone dicussed a user friendly shell for unix that works with the Macintosh. Did anyone attend this meeting and/or can they provide any information about the shell? American management Systems is the company name associated with this project. I'd be grateful for any information and/or experience on this. Thanks. Vicky Walsh ========================================================================= Date: 4 March 1988, 21:43:11 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Computer language intertranslatability (18 lines) --------------------------------------------------------- From: Bob Krovetz I've heard on more than one occasion that you cannot write a Lisp interpreter in Prolog. Is this really true? If so, why? -bob Krovetz@umass.bitnet or Krovetz@umass.edu (internet) ========================================================================= Date: 4 March 1988, 23:29:08 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Choices of programming languages (67 lines) --------------------------------------------------------- From: amsler@flash.bellcore.com (Robert Amsler) Something strange seems to be creeping into the discussion, the quest for the ``best'' programming language devoid of knowing what computer one is running on. To say a programming language is INHERENTLY slow is somewhat strange; like saying that electric-powered vehicles are inherently slower than gasoline-powered vehicles (electric trains do much better than most cars) First, some basic CS. There are computers. Computers have very elemental things called `instruction sets' which are primitive `languages' often referred to as assembly code or machine language, in which one can talk to the computer. These languages are the fastest things the computers can execute. Videogames, for instance, are often written in this level of language to absolutely positively optimize what can be done as rapidly as possible. However, such languages are awful most of the time. They keep saying things like `load and carry contents of register XXX to Register YYY'; which bears as much relationship to making a concordance of a text as the wiring diagram of your TV set has to how the on-off switch works. So... people write `higher level' programming languages which will run on the same computer. But how can they do that? Simply by telling the computer what to do with the statements in the higher level language to translate them into the original language the computer understood. This introduces some inefficiency, for a couple reasons. One is that the user of the higher level language doesn't necessarily know whether what he is asking for is efficient for the computer he is asking it of. Most people want computers to run their favorite languages. This may or may not be easy to do on some computers---``Mr. Spock, can we program the tricorder to become a TV set receiver?'' ``Yes, captain, but it will take a little time and won't work very well for long'' ``I don't care if it is efficient''... That sort of thing. So... we get BASICs and FORTRANs and PASCALs and LISPs and PROLOGs and lots of languages for lots of machines. Each is an IMPLEMENTATION written by someone with a varying degree of attention to how efficient it will be (and hence someone could write a LISP for a certain machine which runs faster than someone else's PASCAL (or visa versa)). The speed of a language is thus a matter of first and foremost what computer it is running on. Then, it is a matter of how efficiently it has been implemented for that computer. Now that computers are things the size of postage stamps (all that other stuff it comes surrounded with is just for the sake of your bulky human fingers and poor input/output capabilities) the possibility of a computer chip that can run your favorite language is very real. (For instance, TI just announced a chip to run LISP for the MacIntosh II's). Every time they change the chip, they change the possible speed of the computer; and saying that any language is slower is very problematic since you have to know on what computer it has been implemented and at what level of design (i.e. as software or hardware). ========================================================================= Date: 5 March 1988, 10:13:52 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Notice of ALLC/AIBI conference posted to file-server (25 lines) Association for Literary and Linguistic Computing 5 - 9 June 1988 XVth International ALLC Conference The Fifteenth International ALLC Conference is being held at Jerusalem, Israel, and will be immediately followed by the Second International Conference of the Association Internationale Bible et Informatique from June 9 until June 13, 1988. The major topics of the Conference to be covered will be: textual databases and corpora; mechanised morphology, lexicography, and dictionaries; statistical linguistics, stylistic analysis and authorship studies; encoding and formatting techniques; critical editions, collations and variants; computational linguistics; and data entry, typesetting and text processing. ========================================================================= Date: 5 March 1988, 22:59:03 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Summary of posting to the fileserver (19 lines) UNIVERSITY OF EXETER FROM VALOIS TO BOURBON December 14-16 1988. To coincide with the quatercentenary of the Blois assassination of the Duke and Cardinal de Guise, which in turn prompted the assassination of Henri de Valois, a residential Conference/Colloquium has been arranged for December 1988 at the University of Exeter. ========================================================================= Date: 5 March 1988, 23:03:16 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: French (26 lines) --------------------------------------------------------- From: Jean-Claude Guedon En reponse a Jacques Julien: La question des diacritiques sur les ordinateurs est effectivement troublante. Il n'aurait pas ete tres difficile en effet de prevoir un nombre suffisant de signes diacritiques pour, au moins, prevoir l'utilisation des ordinateurs par des francophones, hispanophones et autres germanophones ou italophones, etc. And this is why I write the beginning of this message in French, just to remind all that might forget it that although English is a useful language as a kind of lingua franca, it should limit its role to this functional level and not impose itself as if it were THE language of the world, be it computerized or otherwise. This is not meant as an aggressive statement; but simply as a reminder of the marvellous variety that characterizes humanity. Cheers Jean-Claude Guedon ========================================================================= Date: 5 March 1988, 23:38:20 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Languages on HUMANIST (30 lines) As a member of HUMANIST I'm grateful for Jean-Claude Guedon's reminder of monolingual perils. I, too, rejoice in variety and difference. Doctrinally imposed uniformity is dangerously prevalent these days, and (may I hasten to add) it is promulgated by both sexes, by many if not all nationalities, and in many if not all languages. As editor of HUMANIST (for what it's worth) I welcome notes in all languages, whether or not I can read them. Many HUMANISTs read if not write French, not a few must know some German and Italian, and so forth. So, let me suggest that if anyone is moved to write in a language other than English, let him or her do so, let us say providing that a translation into English is appended. After all, a lingua franca (or lingua anglica) is a fine thing, nicht wahr? Would it be reasonable to establish some kind of convention for diacritics, say that the appropriate symbol follow the letter it belongs with? Comments or suggestions? Willard McCarty mccarty@utorepas ========================================================================= Date: 6 March 1988, 16:44:56 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Two pleas and a request from your editor (41 lines) Plea the first. When you want to fetch any file from HUMANIST's file-server, you must communicate by whatever means with LISTSERV, not with HUMANIST. Thus, in interactive mode, for example, you would TELL LISTSERV at UTORONTO GET HUMANIST FILELIST, *not* TELL HUMANIST.... &c.; and if embedding your request in a message, this message would be sent to LISTSERV, not to HUMANIST. When you send requests to HUMANIST, they just come to me, which means that either I have to request the file and send it to you or that I have to write to you and say something helpful. Right now, for example, I have 101 messages in my reader, and it's Sunday afternoon.... Plea the second. Several of you, intending a message for HUMANIST, send it to me directly, knowing that I must deal with it anyhow. True enough, but this procedure can cause two problems: (1) occasionally I cannot tell if the message is meant for me only or for everyone; I usually decide it's meant for everyone, but this may not always be the case; and (2) at such time as I decide no longer to interpose myself between incoming and outgoing mail, HUMANIST messages sent to me will get delayed. Actually, I will be away from about mid May to mid July, and during this time we may decide to return to the automatic mode rather than to ask someone to assume my daily duties with HUMANIST. So, *please* send HUMANIST mail only to HUMANIST. Request. Would all of you who redistribute HUMANIST mail to others send me a brief description of how this is done and, if you have it, a list of those to whom the mail is sent, or a count of the number of people? Thank you all for making HUMANIST such an interesting creature. Willard McCarty mccarty@utorepas ========================================================================= Date: 6 March 1988, 17:09:38 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Diacritically speaking... (23 lines) --------------------------------------------------------- From: Norman Zacour One way to prevent linguistic "imposition" might be to provide a glossary of technical computer terms in French, German and Italian. Reading manuals in one's own language, whatever that might be, is difficult enough; what sort of garbage words (interface), compressed descriptions (cut-and-paste), diverse borrowings (macro, default, root, library, directory), slightly out-of-focus terms (routine), to say nothing of out-and-out neologisms are likely to cause us trouble in a language other than our own? At the moment, for quite selfish reasons, I could use a good short glossary of English-French and English-German. If HUMANISTs can't contribute to its making, who can? Shall we dance? Norman Zacour (Zacour@Utorepas) ========================================================================= Date: 7 March 1988, 10:48:39 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: English and French (32 lines) --------------------------------------------------------- From: Richard Goerwitz I think most of us realize that the use of English as a lingua franca for things like international air-traffic control, radio, etc. is a rather ar- bitrary choice, based on practical political and economic considerations. We had Latin at one time, then French, now English. What next, Japanese? With computers, the phenomenon runs a bit deeper than this. English doesn't use a lot of diacritics, and can be represented comfortably, using a 7-bit coding scheme. Note also that entire languages like Prolog are tuned to an English-like syntactic scheme. Prolog does not work well with languages that have few word-order constraints or lots of discontinuous morphemes. I suppose that with a little fussing, we could all post to the HUMAN- IST in French or German, or some other W. European (left-to-right, alphabetic, syntactically rigid) language. That would be a lot of fun. -Richard L. Goerwitz goer@sophist.uchicago.edu !ihnp4!gargoyle!sophist!goer ========================================================================= Date: 7 March 1988, 10:50:45 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Help for Penn OT users (44 lines) --------------------------------------------------------- From: Richard Goerwitz I've been playing with the OT and NT texts I got from Bob Kraft now for a year and a half, and they have served my quite well. I've been able to determine with great precision many things about the OT that would have taken months to do by hand. Many thanks! One problem keeps coming up with these texts, however: They are coded using TLG-style (i.e. "Betacode") counters. So, instead of marking each chapter and verse reference explicitly (e.g. chapter 10, verse 1 [in Beta- code language ~~x10y1]), they merely tell us to increment (e.g. "increase chapter counter by one, verse counter by one [in Betacode ~~xy]). This means that you can't take verses here and there out of context. I had a friend who uses LBASE (a nice language-database package allowing grammatical searches) complain to me that, on account of this coding pro- blem, he could not slice out separate documents for LBASE to analyze (he wanted to work on the supposed "priestly" document only). So I wrote him a program in Icon that does this. Basically, the program allows one to a) collect a corpus by excising verses and chapters from a larger work, and b) mark them explicitly as to chapter and verse (while still remaining within the definition of the TLG Betacode level-marking scheme). Now the program is just sitting around, and I was wondering if any HUMANISTs wanted it. NB: It's written in Icon, so it's not going to work on any sys- tem that doesn't have Icon installed. I haven't tested it under v6, though it should work fine. -Richard L. Goerwitz goer@sophist.uchicago.edu !ihnp4!gargoyle!sophist!goer ========================================================================= Date: 7 March 1988, 10:54:04 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: In search of a search engine (106 lines) --------------------------------------------------------- From: Robin C. Cover I'm looking for a search engine which probably does not exist, but I would like advice from those more knowledgable about text retrieval systems. It is a text retrieval system optimized for literary-critical and linguistic study. The major requirements for the search engine are as follows: (1) Literary texts should be "understood" by the system in terms of the individual document structure, as indicated by markup elements. The user should be able to specify within a search argument that proximity values, positional operators, comparative operators and logical operators govern the search argument and the textual units to-be-searched IN ACCORDANCE WITH THE HIERARCHICAL STRUCTURE OF THE DOCUMENT. That is, if a document is composed of books, chapters, pericopes, verses and words, then expressions within the search argument must be able to refer to these particular textual units. If another document (or the *same* document, viewed under a different hierarchical structure) contains chapters, paragraphs, sub-paragraphs, (strophes), sentences and words, then expressions in the search argument should be framed in terms of these textual units. To borrow a definition of "text" from the Brown-Brandeis-Harvard CHUG group: the text retrieval system must be capable of viewing each of its documents or texts as an "ordered hierarchy of content objects (OHCO)." (2) The database structure must be capable of supporting annotations (or assigned attributes) at the word level, and ideally, at any higher textual level appropriate to the given document. Most record-based retrieval systems cannot accommodate the word-level annotations that textual scholars or linguists would like to assign to "words." More commonly, if such databases can be modified to accommodate annotations at the word level, the record-field structure is thereby contorted in ways that introduce new constraints on searching (inability to span record boundaries, for example). Preferably, even the definition of "word" ought not to be hard-coded into the system. Hebrew, for instance, contains "words" (graphic units bounded by spaces) which contain three or four distinct lemmas. Minimally, the database must support annotations at the word level (e.g., to account for the assignment of lemma, gloss, morphological parse, syntactic function, etc) and these annotations must be accessible to the search engine/argument. Though not absolutely required, it is desirable that attributes could be assigned to textual units above "word," and such attributes should be open to specification in the search argument. Linguists studying discourse, for example, might wish to assign attributes/annotations at the sentence or paragraph level. (3) The search engine should support the full range of logical operators (Boolean AND, OR, NOT, XOR), user-definable proximity values (within the SAME, or within "n" textual units), user-definable positional operators (precedence relations governing expressions or terms within the search argument) and comparative operators (for numerical values). The search argument should permit nesting of expressions by parentheses within the larger Boolean search argument. Full regular-expression pattern matching (grep) should be supported, as well as macro (library/thesaurus) facilities for designating textual corpora to be searched, discontinuous ranges or text-spans within documents, synonym groups, etc. Other standard features of powerful text retrieval systems are assumed (set operations on indices; session histories; statistical packages; etc). Most commercial search engines I have evaluated support a subset of the features in (3), but do very poorly in support of (1) and (2). The text retrieval systems which claim to be "full text" systems actually have fairly crude definitions of "text," and attempt to press textual data into rigid record-field formats that do not recognize hierarchical document structures, or are not sufficiently flexible to account for a wide range of document types. Three commercial products which attempt to support (1) are WORDCRUNCHER, Fulcrum Technology's FUL-TEXT and BRS-SEARCH. I know of no systems which intrinsically support requirement (2), though LBASE perhaps deserves a closer look, and a few other OEM products promise this kind of flexibility. It may be possible to press FUL-TEXT or BRS-SEARCH into service since both have some facility for language definition. Another promising product is the PAT program being developed by the University of Totonto in connection with the NOED (New Oxford English Dictionary). But I may have overlooked other commercial or academic products which are better suited for textual study, or which could be enhanced/modified in some fashion other than a bubble-gum hack. It is not necessary that a candidate possess all of the above features, but that the basic design be compatible with extending the system to support these functional specs, and that the developers be open to program enhancements. Ideally, such a system would work with CD-ROM, though this is not an absolute requirement. I would like good leads of any kind, but particularly products that could be leased/licensed under an OEM agreement...for microcomputers, I should add. Thanks in advance to anyone who can suggest names of commercial packages or academic software under development which meet the major requirements outlined above, or which could be *gently* bent to do so. I will be glad to post a summary of responses if others are interested in this question. Professor Robin C. Cover ZRCC1001@SMUVM1 3909 Swiss Avenue Dallas, TX 75204 (214) 296-1783 ========================================================================= Date: 7 March 1988, 10:58:17 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: The languages of HUMANIST (25 lines) --------------------------------------------------------- From: Robin C. Cover In response to Willard's suggestion that contributions in French, German, Italian (etc) be encouraged on HUMANIST, I concur wholeheartedly. It's not clear why those who feel more comfortable writing in non-English languages ought to be required to supply an English translation; isn't that giving with one hand and taking back with the other? If there is pride among HUMANISTS that we *are* humanists, then let's reflect upon that very long tradition in humanities education which requires that we be able to read great literature in any of the world's languages. That should prepare us to deal with postings on HUMANIST. If we learn computer languages but fail to treasure human languages, have we broken with our past? Professor Robin C. Cover ZRCC1001@SMUVM1.bitnet ========================================================================= Date: 7 March 1988, 10:59:28 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: A writing convention for diacritics (32 lines) --------------------------------------------------------- From: amsler@flash.bellcore.com (Robert Amsler) I came up with this one recently while encoding phonetic symbols. Basically... {,} are used around any character which is to have diacritics associated with it. {,} is taken to mean, ``combine together the symbols inside the {,}'s, so {ae} is a ligature, {,c} a c-cedilla, {o:} an o-umlaut, etc. You may note I said {o:} for an o-umlaut, rather than {:o}. That is because the position of the punctuation dictates whether it goes ABOVE or BELOW the character. Punctuation appearing BEFORE the letters goes BELOW, punctuation appearing AFTER the letters goes ABOVE. This allows one to also represent symbols such as {:a:} which is an `a' with diaresis above and below. Note that I am not necessarily claiming this is the best final form for special symbols, but it is an easily keyboarded and read system which I find useful for rapid keying of data. Bob Amsler Bellcore ========================================================================= Date: 7 March 1988, 11:01:20 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: What can't I do with C? (92 lines) --------------------------------------------------------- From: Jeffrey William Gillette Q: Are there any tasks that cannot be handled with 'C'? A: Yes, lots! At least this is the case on my IBM PC compatible computer. Let me begin to defend my (admitedly provocative) assertion by claiming a distinction between the C programming language and all the extra "goodies" manufacturers throw into their C compiler packages. According to "The C Language" by Brian Kernighan and Dennis Ritchie (sometimes referred to as the "C Bible" because its authors are also the creators of C), C is a general-purpose programming language. It has been closely associated with the UNIX system. ... The language, however, is not tied to any one operating system or machine. ... C is a relatively "low level" language. ... C provides no operations to deal directly with composite objects... C itself provides no input-output facilities: there are no READ or WRITE statements, and no wired-in file access methods. What I earlier referred to as extra "goodies", more generally known as library functions, are the system specific and machine specific functions to which Kernighan and Ritchie claimed the C language is not tied. On most computers these library functions are written in assembly language. In fact, since K & R created C as a language without input-output facilities, many of these standard library functions could not possibly be written in the C language! Often we think of input as that which we type into a computer, and output as that which the computer displays on its screen or prints to the printer. In technical terms this is not quite correct. I/o, properly speaking, refers to everything not a part of core memory (or ROM/RAM). On IBM compatible machines (i.e. computers that use Intel microprocessors), when a key is typed the corresponding key code appears in a special door (or "port"). It does not enter core memory until the processor explicitly takes it from the port and places it into some memory location. It is precisely this facility of reading a port (and its converse - writing a code to a port that will send it to the printer) that the C language lacks. Because C cannot read from or write to ports, on my IBM compatible machine I cannot write a C program that will get a character from the keyboard, read a byte from my disk drive, print a line of text, dial a modem, send an instruction to the math co-processor, or a myriad of other tasks I want to perform many times a day. By now some provoked C enthusiast will complain that my definition of 'C' is too restrictive. The question should instead be, Q: Are there any tasks that cannot be handled within the C environment distributed by X company? A: No, but C is not unique in this respect! Pilot is a rather restrictive programming language that is optimized for creating Computer Assisted Learning drills. Given enough time, however, I could program a definite clause grammar parser in Pilot (though I've no idea why I should want to). In fact, since Pilot has the same type of assembly language escape hatch used in C, I could probably reproduce MS-DOS in Pilot! Similarly, dBase III+ is not generally thought of as a word processor, but its creators are fond of claiming that the dBase programming language can be used to write a word processor. Perhaps we should all put our C compilers on the shelf and take up dBase. Or let use cast aside UNIX and MS-DOS in favor of Pilot! After all, Q: What can I do with C that I cannot also do in dBase or Pilot? A: Nothing! Jeffrey William Gillette dybbuk at tuccvm.bitnet ========================================================================= Date: 7 March 1988, 11:05:25 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Anglophone imperialism? (45 lines) --------------------------------------------------------- From: Sterling Bjorndahl It is good that Willard will accept contributions in languages other than English. However, I must disagree with his request that a translation always be appended. I am very embarrassed by the typical native English speaker's lack of facility in foreign languages, and I fear that Willard's request will only serve to condone that attitude among us - we who are, after all, HUMANists. I think that a policy of self-editing is sufficient here. If people want to send messages in Portuguese or Japanese, they will know that they will be communicating with only a very select audience. The world knows what we English speakers are like. I doubt very much that our mailers will be filled with messages we can't understand. On a few occasions when I had time to kill, I signed up to BITNET's RELAY network - an interactive computer forum which functions somewhat like amateur radio in terms of human interaction. The main population which uses the RELAY facility consists of undergraduate computer science students involved in casual conversations. On several occasions, the link between North America and Europe went down. During that time, several people in Europe would begin a conversation among themselves in German or Dutch. When the link came back up, parts of those conversations were transmitted to the North American side of the network. More than one person on this side castigated the Eupopeans for using their own language on the network. Granted, they thought that these were simply other North American students showing off their foreign language ability. But the outrage in their "voices" that anyone would use anything other than English on BITNET (they had forgotten about EARN), made me both angry at their chauvinism and sad for the North American educational system. That many of these people will be granted a university degree without every having had to learn another natural language is, well, inhuman. Sterling Bjorndahl Institute for Antiquity and Christianity ========================================================================= Date: 7 March 1988, 11:08:34 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: French messages --------------------------------------------------------- From: David Owen Having advised, from a technical not a linguistic perspective, various instructor's about the use of computer conferencing for conversation practice in French and Spanish instruction, I think I can say that the use of special symbols to indicate accents etc probably does more harm than good. It makes messages harder to write (and thus less likely to get written), and troublesome to decipher. Such special marks are extremely useful, nay essential, when the text is to be printed and the marks are re-interpreted by the formatter, but for purposes such as HUMANIST, I vote that we ignore them. David Owen OWEN@ARIZRVAX OWEN@RVAX.CCIT.ARIZONA.EDU ========================================================================= Date: 7 March 1988, 11:10:08 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: C vs. Prolog (32 lines) --------------------------------------------------------- From: Hans Joergen Marker Answer to Steven J. DeRose I have to accept your point of the number of program lines needed to accomplish a specific task in a given language, still bearing in mind that I remain practically ignorant of the workings of Prolog and Lisp. On the other hand, your statement, that: "It is roughly true that a programmer can write the same number of (working) lines of program per day, regardless of language." would naturally be dependand on the programmer. When I started this argument I was actually trying to find out whether it would be worth my while from a productive point of view to take a closer look of Prolog or Lisp. I am still not convinced. I am still very happy with C. (Perhaps it is my very well hidden macho instincts, though in Europe we would rather symbolise that with a Porsche, Firebirds are'nt that common over here). I think that your note confirms my point of view: C can get the job done, and because of the control you have over the machine using C, it will even get the job done when using other languages impractical. Hans J%rgen Marker. ========================================================================= Date: 7 March 1988, 11:14:27 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Languages on HUMANIST (31 lines) --------------------------------------------------------- From: Hans Joergen Marker fra Hans J%rgen Marker emne: Brug af andre sprog end engelsk p} HUMANIST Jeg kan selvf%lgelig ikke have noget imod at folk skriver p} HUMANIST i sprog jeg ikke forst}r. Hvem kan det? Men det giver dobbelt arbejde for afsenderen at skulle overs{tte sine tanker for at f} dem forst}et af de andre deltagere. Hvorfor l{rer i andre ikke dansk? from Hans Joergen Marker subject: Use of other languages than English on HUMANIST Naturally I can not be againt peoble writing on HUMANIST in languages that I don't understand. Who can? But it doubles the effort for the sender to be obliged to translate his thoughts into English to make them understandable to the other participants. Why don't the rest of you learn Danish? [Editor's note: In case you haven't guessed already, the rather strange looking words (e.g., "p}") have resulted from the computer's automatic translation of accented characters.] ========================================================================= Date: 7 March 1988, 11:19:04 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Genealogical display (40 lines) --------------------------------------------------------- From: John Dawson I don't know of a package for genealogical display, but I have a suggestion which I found to reduce the problem of displaying my family tree considerably. Instead of constructing a tree with all the family members of the same generation in a horizontal line, try showing the tree turned through 90 degrees so that one generation appears in a *vertical* line. If you arrange it so that information is typed in narrow columns, and so that no one text line contains text relating to more than one person, the result is quite easy to edit and keep up-to-date. Obviously, the most recent generation can either be the left-most or the right-most column, and it is easy to add a complete new generation. A small example follows (J24 is the son of J48 and J49; J12 is the son of J24 and J25; etc.): ------------------ J48 ) ???? HICKLING ) J's ggg-gf )-| | ------------------ |-(J24 ) | (???? HICKLING ) | (J's gg-gf )-| J49 )-| | ------------------ | | ------------------ |-(J12 ) | (HENRY HICKLING ) | (Traveller? in 1915)-| ------------------ | | J50 )-| | | |-(J25 )-| | | ------------------ | ========================================================================= Date: 7 March 1988, 12:35:51 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Writs (23 lines) --------------------------------------------------------- From: Eamon Kelly Does anyone know a simple guide to the names and types of writs issued by the English (or Irish) Chancery in the 13th and 14th centuries, in partictular ones dealing with appointments and grants? Hopefully yours, Elizabeth Dowse Dept of Medieval History Trinity College Dublin Ireland e-mail: EPKELLY@cs.tcd.ie or EPKELLY@tcdcs.uucp or EPKELLY@csvax1.tcd.he PS. I have already tried all the various Guides to the Public records ========================================================================= Date: 7 March 1988, 13:00:12 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: langues autres que l'anglais (17 lines) --------------------------------------------------------- From: ANDREWO@UTOREPAS sujet: langues autres que l'anglais Je suis entierement d'accord avec Robin Cover: il n'y a strictement aucune raison pour laquelle les gens qui preferent s'exprimer dans une langue autre que l'anglais soient obliges de fournir une traduction de leur contribution. Andrew Oliver (andrewo at utorepas) ========================================================================= Date: 7 March 1988, 16:56:35 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: On chancery writs (31 lines) --------------------------------------------------------- From: Dr Abigail Ann Young [My mailer returned my attempts to send this reply direct to the enquirer, so this is with due apologies to everyone not interested in the history of English law] Re your query to HUMANIST, I think some writs are discussed in Pollock and Maitland's 2 vol History of English Law. I've also found the legal writers of the 18th and early 19th century very helpful, because the forms of many writs and other legal instruments stayed quite constant from the mediaeval period until the reform of the judicature in the 1870's: I've used Littleton, Coke and Blackstone for help in understanding 15th and 16th century actions, for instance. What writs in particular are you looking at? I hope this is helpful. Abigail Ann Young Records of Early English Drama University of Toronto bitnet:young@utorepas ========================================================================= Date: 7 March 1988, 16:59:28 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Portable computers (55 lines) --------------------------------------------------------- From: John J Hughes HUMANISTS interested in the latest side-by-side reviews of IBM-PC-compatible laptop, "luggable," and portable computers should see Nora Georgas, "Planes, Trains, & Automobiles: 12 Portables for the Road," _PC Magazine_ 7:6 (March 29, 1988): 93-143. (No, despite the review's title, Steve Martin's latest movie does not figure in this review!) The Toshiba T1000 ($1,999) and the GRiDCase 1530 ($4,695) were the editors' picks. The GRiDCase wins these "competitions" time after time. According to the various reviews I've read over the last few years, the GRiDCase is probably the most rugged MS-DOS-compatible portable on the market. According to the review: "The machine has been `ruggedized' to withstand excruciating heat, cold, humidity, vibration, and G forces." Because of their ruggedness, I believe that the U.S. military is a major purchaser of these machines. (Parenthetically, GRiD Systems Corp. invented the MS-DOS laptop.) The battery-operated GRiD 1530 is a 12.5-MHz, 80386 machine. It weighs less than 13 pounds, measures 11.5-by-15-by-3 inches, has a 72-key keyboard, is EMS compatible, and comes standard with two 1.4-megabyte 3.5-inch floppy drives and 1 MB RAM--all housed in a svelte matte-black, magnesium-alloy case. The system will accept up to 512K of user-installable ROM (two 256K slots) in a pop-up panel at the top of the keyboard. GRiD Systems will burn ROMs for customers. Options: (1) hi-res gas plasma screen (640-by-400), (2) backlit supertwist LCD (600-by-200 ??), (3) internal hard drives from 10 to 40 megabytes, (3) external 1.4-megabyte 3.5-inch drive, (4) 3270 emulation cartridge ($1,295), (5) Ethernet cartridge ($695), (6) VGA monitor interface ($695), and (7) up to 8 MG RAM in 2 MB increments. Modem--??? The picture of the hi-res gas plasma screen in the review demonstrates the GRiDCase's astounding resolution, contrast, and clarity. Compared to the GRiDCase's gas plasma screen, the Compaq Portable 386's gas plasma screen looks "muddy." All of this is great, but who has $4,695 to nearly $7,000 for this machine?! I wonder if I could convince GRiD Systems to loan me one to field test for a year or so?. . . ========================================================================= Date: 7 March 1988, 17:13:20 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Translations (32 lines) --------------------------------------------------------- From: Dan Bloom 1) it seems obvious that if someone submits a request/statement in a particular language, the audience it is intended for is those that are conversant in that language and the topic at hand. 2) we are on an international network, therefore multilingual. Therefore, one must anticipate communications in many languages, and indeed it should be encouraged, although people such as myself who know about 1.25 languages (.75 english, .50 three other languages) may have to reply in English to another languages request. Which brings me to my final point; it should be noted that a request for information will get the greatest, quantitatively, response from a request in as many languages as possible (greatest subset of the people on the network) and English is an obvious choice as one. But certainly there should be no requirement for a translation into English. let the user beware so to speak ...Dan Dan Bloom Senior Consultant Academic Computing Services York University ========================================================================= Date: 7 March 1988, 18:32:44 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: linguae bellissimae (14 lines) --------------------------------------------------------- From: Sebastian Rahtz estne facile loquare linguae latinae... (i think its been too long since i did latin...) ========================================================================= Date: 7 March 1988, 18:35:21 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Screen messages in French (26 lines) --------------------------------------------------------- From: Keith Cameron I agree with David Owen that there is no absolute need for accents when writing French on the screen although the absence of an acute or a grave can cause a temporary ambiguity and retard comprehension. I suggest that ' be used before the vowel for the acute i.e. il a 'et'e and the ` for the grave - o`u as distinct from ou. It is rare that the diaresis, the circumflex or the cedilla affect meaning. If a text however is to be published, I have found that a number placed after the vowel is efficient as it allows for the subsequent global edit to adapt the text for printing eg. 1=acute, 2=grave, 3=circumflex, 4=diaresis, 5=circumflex. Keith Cameron ========================================================================= Date: 7 March 1988, 18:37:31 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Prolog and Lisp (19 lines) --------------------------------------------------------- From: Leslie Burkholder For those interested in comparisons of Prolog and Lisp here are two references: Cohen, "The Applog language", in DeGroot and Lindstrom, Logic Programming: Functions, Relations, and Equations (Prentice-Hall 1987). Warren, Pereira, and Pereira, "Prolog - the language and its implementation compared to Lisp", ACM SIGPLAN Notices 12 (1977) and ACM SIGART Newsletter #64 (1977). LB ========================================================================= Date: 7 March 1988, 18:39:11 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Multilingual messages (27 lines) --------------------------------------------------------- From: amsler@flash.bellcore.com (Robert Amsler) While I can see some benefits to a multi-lingual mailing list, there is also the issue of what are we saying to those readers who do not understand the language in which a given message appears? If you speak two languages; one of which will be understood by everyone in a room--and one of which will only be understood by 60% of the people in the room, what does it mean that you decide to speak SOLELY in the language which is only understood by 60% of the people in the room? One might say one was being rude to those who cannot understand that language? If we look at international organizations in which several languages are acceptable, such as the United Nations; there is a strict adherence to a policy of translation into each of the languages. If you look at multi-lingual journals; there is often a policy of requiring an abstract in each of the approved languages accompany the article in only one language. ========================================================================= Date: 7 March 1988, 18:41:04 EST Reply-To: MCCARTY@UTOREPAS Sender: HUMANIST Discussion From: MCCARTY@UTOREPAS Subject: Prologs (57 lines --------------------------------------------------------- From: Bill Winder I have followed with interest the programming language debate, especially on the Prolog question. I do like logic, and that is why I turned from a shaky acquaintance with Lisp to an enthusiastic acceptance of Prolog. Turbo Prolog was all I could afford at the time, and it has proved sufficient, up to a point. I still like Prolog, but Turbo Prolog has some tragic flaws, which may ruin our relationship. In particular, there are a number of bugs, especially with the I/O. More importantly, however, is the question of having a more developed logic. What functions are needed in Tpro to make it more standard or more powerful? Obviously, a typed language has particular constraints, but I have found that it just means copying sections of code and renaming predicates for different types: there is no rethinking of the problem because of typing, just more keyboarding, at least such has been my experience. I'm willing to have the speed of Tpro, even if it means more work. (In a recent Turbo Technix article (the new Borland magazine), Tpro was shown to be faster than Turbo C for at least some functions, such as calculating the mean of a set of numbers.) The fact that it is compiled is not a problem, since you can build an interpreted level if you so desire (i.e. a prolog interpreter can be built out of a compiled program....) That might seem counter productive, but the advantage is that the interpreted level will be tailored to the specific needs of the application. For the moment, therefore, I can't find a solid argument against Tpro. This may be because I have never used sufficiently a full implementation of Prolog. Has anyone run across a damning piece of evidence against Tpro? I need but a single, convincing argument in order to abandon Tpro (even with its very pleasant development environment) and upgrade to Arity or Mprolog. (Note on Sheffer's bar: though it is true that Sheffer is given credit for it, I believe that Peirce actually proved the reduction --and used the bar, or equivalent-- some 30 years before Sheffer (I would have to check my figures, but 30 sounds right....). Don Roberts could certainly set me straight if I misunderstood Peirce's approach, and the meaning of the cut in the existential graphs. The bar is a binary connector and Peirce's cut is n-ary: it could be written in Prolog as cut([var1,var2,...]), whereas the bar would be written as bar(var1,var2). Both mean "neither, nor", only f