ddb@mrvax.DEC (DAVID DYER-BENNET MRO1-2/L14 DTN 231-4076) (01/17/85)
Of course (:-), BLISS has had a cleaner way to handle this for some time: it has a lexical function %name(), which causes its string argument to be treated as a name regardless of the normal naming rules. This can be buried in a macro to make references to these funny variables look normal. BLISS has a lot of other useful lexical functions also. In fact it makes the C pre-processor look pretty dull by comparison. Consider: %charcount(string) Number of characters in string %string(string,string,...,string) Single quoted string from many %explode(string) comma-separated list of single-char strings %identical(arg,arg) True if both args exactly same %isstring(arg) rue i True if string literal %ctce(arg) True if arg is compile-time constant expr. %ltce(arg) True if arg is link-time constant expr. %nbits(ctce,ctce...) Max number of bits needed to represent numerically largest arg in signed field %nbitsu(ctce,ctce,...) Same, unsigned field %declared(name) True if name is declared in current scope %error(string) Cause compiler to issue string as error %quote Inhibits lexical binding of the lexeme following %unquote Forces lexical binding of the lexeme following These last two are really amusing, not to mention useful; Like writing macros which, when expanded, redeclare themselves, or writing macros which expand other macros in their body at declaration time instead of at expansion time, or passing names of macros as arguments to other macros, or.... If you need either of these, there's no substitute. %remaining comma-separated list of actual parameters to macro-expansion currently being processed which aren't assigned to formal parameters. This makes expandable-tail argument lists to pass to a lower level trivial to implement. %length number of actual parameters in call etc. etc., lots more. %bpval is the number of bits per fullword value (think int). %bpunit is the number of bits per addressable unit. %bpaddr is the number of bits in the address of an addressable unit. %upval is the number of addressable units per fulword value. It was fairly easy to write code that ran on VAXen (8-bit byte oriented) and PDP-10 (36-bit word oriented) system using bliss. The particular code took a bit-stream representation of some binary data as it had existed in the memory of one kind of system, and extracted fields from it (converting them to binary formats understood by the current system) (you had to tell it where the field had been on the original system). (This was the data conversion part of DECs Data Interchange Library produce product). -- David Dyer-Bennet -- ...decwrl!dec-rhea!dec-mrvax!ddb
geoff@desint.UUCP (Geoff Kuenning) (01/20/85)
In article <248@decwrl.UUCP> ddb@mrvax.DEC (DAVID DYER-BENNET) writes: >BLISS has had a cleaner way to handle this for some >time: it has a lexical function %name(), which causes its string >argument to be treated as a name regardless of the normal naming rules. >... >BLISS has a lot of other useful lexical functions also. In fact it >makes the C pre-processor look pretty dull by comparison. Consider: >[long list of functions] This is interesting; I'd known of these at one time and forgotten them. Some of them aren't appropriate to C, but I think we should take a long look at them with a view to extending the defined(x)/undefined(x) stuff that the current preprocessor takes. Mind you, I'm not suggesting hacking these onto the standard--the standard is too far along with that. But I'd like to see some experimental compilers with some of this stuff. -- Geoff Kuenning ...!ihnp4!trwrb!desint!geoff
kendall@talcott.UUCP (Sam Kendall) (01/22/85)
> >BLISS has a lot of other useful lexical functions also. In fact it > >makes the C pre-processor look pretty dull by comparison. Consider: > >[long list of functions] > > This is interesting; I'd known of these at one time and forgotten them. > Some of them aren't appropriate to C, but I think we should take a long look > at them .... > -- > Geoff Kuenning This IS interesting; intricate macro semantics make for fun puzzles. But we can consider it a feature of C that it has a weak macro preprocessor--there are already enough tricks available to C programmers. I would hate to see the preprocessor extended beyond what the standards committee has in mind (which is not much beyond K&R), and I would particularly hate to see "deep" macro functionality added, e.g., the ability to execute preprocessor directives inside expanded macros. All who agree with me, show your support by NOT sending in your list of neat preprocessor extensions! Sam Kendall {allegra,ihnp4,ima,amd}!wjh12!kendall Delft Consulting Corp. decvax!genrad!wjh12!kendall