donn@hp-dcd.UUCP (06/29/83)
#R:whuxlb:0:hp-dcd:24200001:37777777600:483 hp-dcd!donn Jun 22 21:46:00 1983 How about 'goes in to' (pronounced "gusinta") as a pronouncable version of shells '>' symbol. As for "!", "bang" is the only reasonable choice, not only because its becoming common in UN*X land, but because (apparantly) its read that way in both (hot lead type) typesetting and in SDS/XDS/Xerox/Honeywell/(fill in the blank) operating systems land (anyone out there remember RBM and CP/V?). (All of the above 'acronyms'(?) are probably owned by someone; I just don't know who...)
hxe@rayssd.UUCP (07/06/83)
RE: Calling the ">" a "goes in to"
The pipe is often refered to as a "guzinta" so you can't call
it that. I STILL vote for our convention, the funnel. It's
easy to describe both physically and conceptually.
Heather Emanuel, Raytheon Submarine Signal Division, Portsmouth, RI
{decvax!brunix, allegra} rayssd!hxeemjej@uokvax.UUCP (12/14/83)
#R:vax2:-81700:uokvax:9000010:000:826 uokvax!emjej Dec 12 11:56:00 1983 Russell avoids elaboration/expansion at times precisely to permit the kinds of self-referential types that could cause it to go off the deep end (such as are recommended by folks who don't like the notion of "pointer," of which I'm becoming one as time goes on). Despite this, it manages quite thorough type-checking at run time, with a surprisingly small, elegant method, too. (Said method is a hair counterintuitive in places, such as where it requires "Array[M] of Zot" to be considered different from "Array[N] of Zot" even if M and N turn out to be the same, but...) I do hope that folks more knowledgeable about Russell than I are provoked enough by my vague explanation to reply with something more thorough (so that I can send mail saying "PLEEEZE, tell me where there's a compiler for Russell!"). James Jones
benk@inmet.UUCP (05/26/84)
#R:cepu:-25900:inmet:4700016:177600:330 inmet!benk May 24 16:54:00 1984 And do you know why it generated such good code ? It had to. Back in those days compilers were looked upon with great suspicion. The only way compilers could gain any kind of acceptance among the "user community" was to produce code that was as good - or nearly as good as that written by crack asembly language hackers.
dat@hpcnoe.UUCP (dat) (11/23/84)
When I was still going to UCSD (San Diego) the Computer Science Vax had installed FP and were discussing doing some projects with them. You might try contacting someone from sdcsvax, perhaps, ummmm....try Bill Applebe (sdcsvax!applebe) Dave Taylor now at Hewlett Packard
donn@hp-dcd.UUCP (donn) (12/23/84)
Getting back to COBOL and its plethora of reserved words; a common (and usually successful) approch is that all user defined names should either be hyphenated or misspelled. I make no claim, however, about the guaranteed success of either approch :-) ! Donn Terry HP Ft. Collins, Co. hplabs!hp-dcd!donn
dat@hpcnoe.UUCP (dat) (01/01/85)
/***** hpcnoe:net.lang / uiucdcsb!wsmith / 11:39 pm Dec 16, 1984*/ > Ordinary languages like C, Pascal, etc... either make no restrictions > on case of letters in identifiers, make both cases be the same, or they > require you to use only one case. > Is there any reason that case can not be used to contain semantic > information? I am suprised no-one mentioned Prolog (versus prolog)! It does use the 'case' of the first letter of a 'variable' for semantic information! In fact, words that begin with an uppercase letter are considered to be variables in the semi-traditional programming sense, while those that are lowercase are essentially constants. For example, father_of(joe, jack)? asks if constant 'joe' is the father of constant 'jack', whereas; father_of(Joe, jack)? asks if ANYONE is the father of jack (poor fellow!). The difference is in the case of the word. Of course, a more generally followed Prolog style would have the second inquiry as; father_of(Whom, jack)? which makes it a tad easier to see that it is a variable, eh? A more interesting idea is to have the compiler dynamically analyze the input program and decide for itself whether a given lexical token (word) is a variable or not. 'C' tries to do this for generation of error messages to a small extent - consider the difference between the two code fragments; silly() { junk; } and silly() { junk(); } The first will generate an error message to the effect that variable 'junk' is not declared, while the second generates a loader error that the ROUTINE junk is undefined! (Much more straightforward that Pascal, where it's anyones guess how a compiler distinguishes between a call to a procedure with zero parameters, or perhaps a better example, a function with zero parameters, and an undeclared variable (ie function test : integer; begin test := 3; end; begin a := test; b := test1; end. does YOUR compiler generate the correct error messages?) (Probably: pascal cheats by forcing all routines to be defined BEFORE their first occurance in the program. *sigh* another half-witted fix...) Anyway, what I think would be useful would be for the compiler to be intelligent enough to figure out that a line like 'junk;' makes no sense and performs no operation if junk is a variable, so it would assume that it was a function call, outputting an appropriate warning message to the screen. In a similar vein, a casual bit of code that I once erroneously had which took HOURS to find was; i == 3; as a line in a program. This also doesn't make any sense as an independent statement, and the compiler could again flag it and change it to read 'i = 3'. Comments? Dave Taylor WARNING: (insert disclaimer here)
davies@uiucdcsb.UUCP (01/26/85)
boring!steven states that it is possible to statically insure that nil
pointers are never dereferenced. The following program provides a simple
counterexample to this claim:
program noway(input,output);
type
pointer = ^rec;
rec = record
data : integer;
next : pointer;
end;
var
p : pointer;
q : pointer;
begin
p := nil;
while not eof(input) do begin
new(q);
read(q^.data);
q^.next := p;
p := q;
end;
writeln(p^.next^.next^.next^.data);
end.
In this program, whether the "writeln" dereferences a nil pointer is
determined by the number of integers in the input data, and thus cannot be
determined at compile time.
Jimbenk@inmet.UUCP (02/21/85)
I've got to agree. Despite the many bad things which
legitmately be said about it, there are occasions when
Basic is the language of choice: e.g., little interactive
tools with a short lifetime of use, quick hacks for
microcomputers, etc. I guess what it comes down to is
that there are times at which you *want* an interactive
language, are stuck without a Lisp interpreter, and
don't have an APL keyboard on your terminal ( :-) ).
I know that PWB-Unix came with a Basic interpreter called
'bas'; I'm not sure, but I think Unix-System-V also
comes with 'bas'. I know of no Basic for Berkeley systems.
Ben Krepp
{ihnp4,harpo,ima}!inmet!benkbenk@inmet.UUCP (02/21/85)
I think that there is a PL/I for Amdahl's UTS system.
In case you don't know, UTS is a Unix look-alike for
IBM 370-type machines.
You might try giving Amdahl a call.
Ben Krepp
{ihnp4,harpo,ima}!inmet!benkbenk@inmet.UUCP (02/21/85)
Correction: I just looked into the 'PL/I compiler' I
suggested might exist for UTS. Alas, all UTS's 'pli' is
is a JCL-writing program which will take your PL/I source
along with some command line options and produce a file
consisting of your source bracketed by the correct [ :-) ]
JCL, to be handed over to send(1) which is responsible for
sending the whole shebang over to MVS -- and its ulitmate
fate, i.e. an OC4 [ :-) ].
Ben Krepp
{ihnp4,harpo,ima}!inmet!benkrpw3@redwood.UUCP (Rob Warnock) (02/22/85)
+--------------- | I've got to agree. Despite the many bad things which | legitmately be said about it, there are occasions when | Basic is the language of choice: e.g., little interactive | tools with a short lifetime of use, quick hacks for | microcomputers, etc. | Ben Krepp | {ihnp4,harpo,ima}!inmet!benk +--------------- I disagree. [Should this be in net.religion.lang?] On the PDP-8, PDP-10, and PDP-11 my choice was FOCAL. [Richie Lary, where are you?] FOCAL ran nicely on a 4K PDP-8 and included intra-line editing of programs (FOCAL/F [Doug Wrege] took 8K and added a bunch of real-time and operating system hooks). A full-functioned PDP-10 version [mine] was also 4K words, though 36-bit instead of 12-bit words. Under UNIX, my choice is Bourne Shell! (...given the usual UNIX utility commands.) Of course, if there's a lot of demand, I'd be glad to do a FOCAL in C. ;-} Actually, what we probably should do in UNIX land is create "hoc7", which would add interactive editing of functions to K & P's "hoc6". (Yes, "hoc6" already allows you to "edit" by retyping the whole function -- I'm referring to provisions for loading/listing/editing/saving function definitions. It probably should call an external editor -- in fact, "$EDITOR"!) Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404
bct@hpfcla.UUCP (bct) (07/19/85)
Discrimination is often in the eye of the beholder. As a man of the '80s, I am confident I judge people on the basis of their actions; not by their rhetoric, sex, color, age, etcetera. It is noteworthy that this confidence was established only after much effort on my part to be more open minded and conscientious about other people's cultural backgrounds and points of view. So it is with confidence that I say to you now. What does it matter if our language uses generic names like 'mankind' to refer to all of humanity? I do not see this as excluding women. Why should women take offense when I mean none? Why change the accepted meaning of such terms as 'he', when used in their generic sense? It seems to me we should be beyond such trivial pursuits. We should be moving onward towards a more enlightened attitude, wherein each person (be it man or woman) does not look for prejudice where there is none intended. Instead, spend your effort seeking out justice where it is in fact needed. A rose is, after all, a rose by any name. Just a possiblity, Taylor
alexis@reed.UUCP (Alexis Dimitriadis) (07/26/85)
In article <72200001@hpfclq.UUCP> bct@hpfcla.UUCP (bct) writes: > So it is with confidence that I say to you now. What does it matter if > our language uses generic names like 'mankind' to refer to all of > humanity? I do not see this as excluding women. Why should women take > offense when I mean none? Why change the accepted meaning of such terms > as 'he', when used in their generic sense? 1. This is net.lang. By some absurd prejudice, it is intended for the discussion of _computer_ languages. Next time try net.nlang (Natural languages), which is where followups to this posting will go. 2. Someone recently posted a nicely written piece that defended the use of "whitekind" and "whites" as a "generic" form denoting humankind and humans. It satirized exactly the argument presented above. I think it was a quotation from somewhere, not the poster's creation. At any rate, if someone has it, could you repost it, or mail a copy to the poster of the above? Alexis Dimitriadis -- _______________________________________________ As soon as I get a full time job, the opinions expressed above will attach themselves to my employer, who will never be rid of them again. alexis @ reed ...teneron! \ ...seismo!ihnp4! - tektronix! - reed.UUCP ...decvax! /
magik@wlcrjs.UUCP (Ben Liberman) (07/27/85)
[raw] In article <72200001@hpfclq.UUCP> you write: > >..... I am confident I judge people on the basis of their actions; >not by their rhetoric, sex, color, age, etcetera. It is noteworthy >that this confidence was established only after much effort on my part >to be more open minded and conscientious about other people's cultural >backgrounds and points of view..... > > Taylor There are certain points of view (bias) inherent in any language (coumputer as well as human) that are usually invisable (but no less of an influence) to anyone who isn't either multilingual (in which case they can only see the points of divergence between 2 or more languages and not their common assumptions) or has been specifically taught to see them. The result of not changing the language to eliminate these biases is that each generation must be taught to see beyond them. (evolution? of language?...naw, I prefer 15th century english any day...much more romantic :-) Granted, change isn't easy, but it seems that the long term development of culture kinda warrants it. -- ----------------------------------------- Ben Liberman {ihnp4|ihldt}!wlcrjs!magik
magik@wlcrjs.UUCP (Ben Liberman) (07/27/85)
[]
Sorry about the newsgroup on my last posting. It seems that this discussion
should be moved from net.lang (computer languages) to net.nlang (natural
language)
--
-----------------------------------------
Ben Liberman {ihnp4|ihldt}!wlcrjs!magiktower@inmet.UUCP (01/15/86)
Subject: Re: Wanted: Pascal to C Translator Newsgroups: net.lang.c,net.lang.pascal,net.lang Distribution: net References: <20@hplabsc.UUCP> > Looking for a public domain Pascal to C source code translator, > preferably written in C. If anyone has one or knows where to > get one, I would appreciate a private mail message. > > > Arvind Kumar > ...!hplabs!kumar I asked this question on USENET 4 months ago. No one knew of any public domain translators, though several commercially available translators were reported. The informative answers I received follow: Len Tower ---------------------------------------------------------------------- Date: Fri, 13 Sep 85 07:53:10 pdt From: hans@aids-unix (Hans Muller) To: tower@mit-hermes.ARPA Subject: A Pascal to C translator I picked this up off the net a few months ago. I would appreciate it if you would forward any new replies you receive. >From info-c-request@BRL.ARPA Mon Jun 17 22:48:13 1985 Relay-Version: version B 2.10.2 9/18/84; site aids-unix.ARPA Posting-Version: version B 2.10.2 9/18/84; site aids-unix.ARPA Path: aids-unix!info-c-request@BRL.ARPA From: info-c-request@BRL.ARPA Newsgroups: info-c Subject: Re: Pascal to C translator Message-ID: <5183@aids-unix.ARPA> Date: 18 Jun 85 05:48:13 GMT Article-I.D.: aids-uni.5183 Posted: Mon Jun 17 22:48:13 1985 Date-Received: 18 Jun 85 05:48:13 GMT Sender: daemon@aids-unix.ARPA Organization: AI&DS Lines: 32 From: Sean McLinden <sm@CADRE.ARPA> In article <415@yale.ARPA> stock@yale.ARPA writes: >I am looking for a Pascal to C translator, or any tools that might help >in translating Pascal source code to C source code. Please sent me >any suggestions, sources, or information that you might have to make >this task easier. > >Adam Stock at Yale Comix The CMU Andrew System which is a product of the IBM-sponsored Information Technology Center at Carnegie-Mellon University includes, among other things, a Pascal-to-C translator called "ptc". The system (which is a prototype of the user interface intended for IBM academic workstation), can be licensed to universities for $100.00 (I don't know about commercial interests) from CMU. The phone number is (412)-578-6700. For anyone with a Sun Workstation, this system is WELL worth the investment as it offers an efficient and clean working environment for interacting between networked Suns. (This in comparison to Sun Unix 4.2 Release 1.1, I haven't seen later releases, yet). To return to the Pascal-to-C issue, for a moment, it is worth stressing the fact that the large number of Pascal dialects makes it difficult to develop a general purpose translator, and some post-processing may be required with the translator, however, it has made life a lot easier for me since I rarely use Pascal enough to make it worth my while to delve into the syntax. Sean McLinden Decision Systems Laboratory Hans Muller hans@aids-unix.ARPA phone: (415) 941-3912 ---------------------------------------------------------------------- From: ihnp4!utzoo!hcrvax!hcrvx2!bobk@mit-eddie Date: 15 Sep 85 13:20:53 CDT (Sun) Subject: Re: pascal -> C translator Apparently-To: allegra!mit-eddie!mit-hermes!tower HCR sells a product called HCR/PASCAL. HCR/PASCAL is a Pascal compiler that uses C as an intermediate language. It first performs a direct translation from J&W/ANSI/ISO (level 0) Pascal to C, and then invokes the system's C compiler to complete the compilation. HCR/PASCAL allows modules to be compiled separately , it uses "Lazy I/O" and it provides a UNIX-style implementation of the UCSD string package. HCR/PASCAL has numerous UNIX-style features which include: 1) the ability to call and be called by C routines 2) the ability to integrate Pascal and C routines into runtime libraries 3) the ability to perform UNIX system calls 4) the use of the cpp macro preprocessor in Pascal programs 5) user-friendly file-handling capabilities 6) the handling of command line arguments It can even be used to translate Pascal into C if you want to throw away your Pascal source. HCR/PASCAL is available on a wide range of hardware that runs UNIX since it is written in C and since the compiler's code-generator never needs to be rewritten for new machines. HCR/PASCAL is currently available on the following hardware: IBM PC/AT, AT&T 3B2, AT&T 3B5, AT&T 3B20, PDP-11/xx, VAX-11/7xx, Intel 8086, Intel 80286/310, Perkin-Elmer, Pixel, Plexus, 68000 NCR Tower and 68010 NCR Tower. HCR/PASCAL is currently available on the following versions of UNIX: System Vr1, System Vr2.0, BSD 4.1, BSD 4.2, System III, Version 7, Xenix 2.0, Xenix 3.0, VMS/UNITY 3.0 and VMS/UNITY 4.0 Customer support for HCR/PASCAL is provided by HCR Corporation's competent support staff. For further information, you can contact me at the following address / phone number / net address: Bob A. Kyryliuk HCR/PASCAL Product Manager Human Computing Resources Corporation 10 St. Mary Street Toronto, Ontario, M4Y 1P9 Canada 416-922-1937 ext.25 ...{decvax|utzoo|ihnp4|watmath}!hcr!bobk or you may contact Emil Rapp in our California Sales Office at the following address / phone number: Emil Rapp Human Computing Resources Corporation 34700 Coast Highway Capistrano Beach, California 92624 714-493-8664 ---------------------------------------------------------------------- Date: Mon, 16 Sep 85 10:51:47 cdt From: harvard!uwvax!wisc-gumby.arpa!g-chapma@mit-eddie (Ralph chapman) To: harvard!think!mit-eddie!mit-hermes!tower@mit-eddie Subject: Re: pascal -> C translator In-Reply-To: your article <2479@mit-hermes.ARPA> Check with Whitesmiths (don't know their address, sorry-- somewhere in New York, though). They make a cheap C compiler for various minicomputer (PDP-11) operating systems. Their implementation of PASCAL originally (I don't know if it's still the same) involved translating PASCAL to C, then compiling the C code. [Len Tower's note: Whitesmiths is in Concord, MA] ---------------------------------------------------------------------- Date: Fri, 13 Sep 85 21:22:23 edt From: harvard!encore!wegrzyn@MIT-PREP.ARPA (Chuck Wegrzyn) Message-Id: <8509140122.AA29525@encore.UUCP> To: talcott!harvard!seismo!brl-tgr!tgr!tower@mit-prep.ARPA Subject: Re: unix sources archive Newsgroups: net.sources In-Reply-To: <1432@brl-tgr.ARPA> Organization: Encore Computer Corp., Wellesley Hills, MA Len, Sorry. but in the four or five years I have been on the network, no one has ever posted a Pascal to C converter. At this time the only company that sells one is Whitesmith in Lexington (or Concord??). Chuck
richw@ada-uts.UUCP (01/26/86)
"What does 'object-oriented' mean?" is a good question. I thought I knew, but now I'm not so sure. I tend to use the term to describe a style of programming (and hence avoid getting into trouble with those that know it's "real" meaning). Something which has recently affected my feel for the term is the difference between the way procedures are called in Smalltalk and in C/Clu/most-other-languages. In the latter, the basic conceptual "execution-step" involves looking at the name of the procedure being called, finding the code for it, and executing it. In Smalltalk, one FIRST looks at the OBJECT which is "receiving a message" (a message is roughly equivalent to a procedure name), then finds that code for that message in the list of messages defined for that type of object. The latter makes it somewhat easier to write code which will call one version of procedure "foo" when dealing with an object of type A, and another version of procedure "foo" when dealing with an object of type B. Emphasis on the somewhat, though; I'm not sure. In Smalltalk, it seems easier to do this because type-checking is done at run-time. Nevertheless, you can do the same in the other class of languages (where the execution revolves around finding the code based on the procedure name). In Clu and Ada, there are the notions of "parameterized clusters" and "generic packages", respectively, which help you write "generic" procedures. I'd rather not go into further detail, though. Note that the type of an object will influence the "lookup of code" (since procedure names in these languages are prefixed by type names or package names) in Clu and Ada, but my point is that this is conceptually different than what happens in Smalltalk. Smalltalk seems "more object-oriented" because the type of the object/receiver determines the code executed by a procedure-call/message-pass. Isn't it wonderful trying to talk about different langauges with different terminologies for similar, but not-quite- the-same semantics. :-) Sorry if this was impossible to read. This was written rather hastily. Hopefully some of you got the gist. Dazed-and-confused, Rich Wagner
jans@mako.UUCP (Jan Steinman) (01/31/86)
In article <15100023@ada-uts.UUCP> richw@ada-uts.UUCP writes: >"What does 'object-oriented' mean?" is a good question. > >In Clu and Ada, there are the notions of "parameterized >clusters" and "generic packages", respectively, which >help you write "generic" procedures... Note that the type of >an object will influence the "lookup of code"... Keep in mind that Ada's generic packages are fixed at compile time, more like macros than objects. When a generic package is instantiated, a copy of code appropriate for the given data type is compiled in. Contrast this to Smalltalk message sends, where the method to be executed is not determined until run time, and which, in the case of "perform:", "value:", et. al. changes on the fly. -- :::::: Artificial Intelligence Machines --- Smalltalk Project :::::: :::::: Jan Steinman Box 1000, MS 60-405 (w)503/685-2956 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::