ap

Richard A. O'Keefe ok at goanna.cs.rmit.oz.au
Sat Jun 15 17:26:14 AEST 1991


In article <1991Jun11.173907.28331 at metro.ucc.su.OZ.AU>, tml at extro.ucc.su.OZ.AU (Tim Long) writes:
>      NAME
> 	  ici  -  General purpose interpretive programming language
> 
>      SYNOPSIS
> 	  ici [	file ] [ -f file ] [ -i	prog ] [ -digit	] [ -l lib ] [ args... ]
> 
> 	  -f file   The	file is	parsed as an ICI module.
> 
> 	  -i prog   The	prog argument is parsed	directly as an ICI
> 		    module.

I for one would find it rather less confusing if you used the same option
name as AWK and sed, namely "-e", as in the following examples I just tried:
	awk -e 'END {print "Hello, world."}' </dev/null
	(echo a; echo b; echo c) | sed -n -e 1p -e 2p

> 	  -digit    An ICI module is read from the file	descriptor
> 		    digit.

May I suggest a slightly more long-winded but rather prettier scheme?
Allow a file name (anywhere at all) to have the form
	/dev/fd#
where # is an integer with however many digits it needs.  Some research
versions of UNIX already support this directly.  People familiar with it
won't thank you for introducing a new notation.  And it takes less than
half a page of code to implement your own "f_or_fd_open(string, mode)"
function in C, and then use that throughout the implementation of ICI
instead of fopen().  [I have done this, and know what I'm talking about.]

> 	  structure) can be obtained.  Several of the intrinsicly
That's intrinsically				      ^^^^^^^^^^^

> 	  int  Integers	are 32 bit signed integers.  All the usual C
> 	       integer operations work on them.	 When they are
> 	       combined	with a float, a	promoted value is used in the
> 	       usual C style.  Integers	are atomic.

Oh *no*!  What's the good of using an interpreted language if it only
gives me 32-bit integers?  If you use any of the PD or redistributable
bignum packages around, then it is *EASY* to provide bignum arithmetic
in an interpreter.  Yes, the bitwise operations &, |, ^, ~ all make
perfect sense on integers of any size, and if we define
	x << y = floor(x * 2**y)
	x >> y = floor(x * 2**(-y))
then even the shifts make sense.  (The shifts won't agree with C, but
then shifts in C aren't as portable as you might think.)

*Please* give very serious consideration to bignums.  For a scripting
language, why the flaming xxxx should I *care* what size a register is?

> 	  Note that initialisers are constant expressions.  They are
> 	  evaluated once at parse time.	 Even initialisers of autos.

Why?  The restriction to constant initialisers for static and external
variables in C made sense, because the initialisation was done by the
linker.  But that doesn't apply to ICI.  About 80% of my initialisations
to auto variables in C are -not- constant expressions.  Why introduce a
restriction that an interpreter like ICI doesn't need and that doesn't
give the ICI programmer any extra safety?

> 	  The array's are arrays of strings, which are the fields of a
The array's what?

>      EXAMPLES
> 	  The following	shell command line will	print Hello world.
> 	       ici -p 'printf("Hello world.\n");'

The manual page said nothing about a "-p" option.

>	  The first line makes a Bourne shell pump the
> 	  program in through file descriptor 3,	and passes any
> 	  arguments to the shell script	on to the ICI program.

I tried something like that on an Apollo once.  Didn't work.  The
shell already had several descriptors other than 0, 1, and 2 open.

> A few practicalities: on my 386 the initial load image (text+data)
> comes in at around 110K (85K text + 25K data, of which a disconcerting
> amount comes from curses, even though all I want it to do is read
> a terminfo entry.

Surely you can get at a terminfo entry by using just -ltermlib;
you don't have to load -lcurses as well.  According to the SVID the
"Terminfo Level Routines" are setupterm(), tparm(), tputs(), putp(),
vidputs(), vidattr(), and mvcur().  setupterm() defines a bunch of
variables.  If you just use those routines, you shouldn't get much
else from Curses.  If not, complain.
-- 
Q:  What should I know about quicksort?   A:  That it is *slow*.
Q:  When should I use it?  A:  When you have only 256 words of main storage.



More information about the Comp.unix.shell mailing list