Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!utcsri!greg
From: greg@utcsri.UUCP
Newsgroups: comp.lang.c
Subject: Re: C vs assembler, or, Here We Go Again
Message-ID: <4680@utcsri.UUCP>
Date: Mon, 27-Apr-87 13:19:55 EDT
Article-I.D.: utcsri.4680
Posted: Mon Apr 27 13:19:55 1987
Date-Received: Tue, 28-Apr-87 00:57:12 EDT
References: <213@pyuxe.UUCP> <636@edge.UUCP> <1316@frog.UUCP> <658@edge.UUCP> <6361@mimsy.UUCP> <382@bms-at.UUCP>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Organization: CSRI, University of Toronto
Lines: 24
Summary: 

In article <382@bms-at.UUCP> stuart@bms-at.UUCP (Stuart D. Gathman) writes:
>hrs for 'C'.  The difference is that  our  'C'  library  has  not
>evolved  to  the  extent  that  the  assembler  library has.  (An
>assembler data entry program consists of some  table  definitions
>via macros and some subroutine hooks to implement deviations from
>standard features.)

>Stuart D. Gathman	<..!seismo!dgis!bms-at!stuart>

So could a 'C' data entry program (especially if ANSI decides to allow
proper compile-time initialization of unions). Few languages allow you
to create tables of pointers to functions, e.g., and many languages
(most notably standard Pascal) do not allow any kind of table to be created
at compile time.

Stuart's application is just right for one of what Brian Kernighan calls
'little languages'. It would read a special description language and
produce the tables as output. Of course this is not always worth doing,
and the macros may be good enough.

-- 
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg
Have vAX, will hack...