Xref: utzoo comp.unix.shell:2413 comp.lang.misc:8013 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.unix.shell,comp.lang.misc Subject: Re: ap Message-ID: <6354@goanna.cs.rmit.oz.au> Date: 15 Jun 91 07:26:14 GMT References: <1991Jun11.173907.28331@metro.ucc.su.OZ.AU> Followup-To: comp.lang.misc Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 91 In article <1991Jun11.173907.28331@metro.ucc.su.OZ.AU>, tml@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."}' -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.