Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!uwm.edu!rpi!unix.cie.rpi.edu!vicc
From: vicc@unix.cie.rpi.edu (VICC Project (Rose))
Newsgroups: comp.lang.icon
Subject: Re: Icon additions
Message-ID: <7346@rpi.edu>
Date: 15 Sep 89 15:34:48 GMT
References: <8909151357.AA03203@megaron.arizona.edu>
Sender: usenet@rpi.edu
Distribution: inet
Lines: 45

In article <8909151357.AA03203@megaron.arizona.edu>, dscargo@CIM-VAX.HONEYWELL.COM ("DAVE CARGO") writes:
> There are three things of various levels of complexity that I'd like to see
> added to Icon.

> 1) A bit-string type similar in underlying mechanisms to csets.  (In other
> words a 256-bit limit is probably acceptable.  The same operations available

This woud seem easy to do, perhaps without the need for a new data type. A few
functions would go a long way.

> 2) Formatted translation from bytestrings to integers.  Given a specification
> about width and byte order, translate a string of bytes into a list of
> integers.  Useful for cracking some arbitrary file internal formats (like
> TIFF and PCX).

Well there is ord and char, but yes, a few additional functions would be
nice.

> 3) POSIX compatibility.  In particular, if there are screen and keyboard
> interfaces specified (or drafted), make them accessible to Icon so that
> portable user interfaces for applications can be developed.  In the MS-DOS
> world alone, support for ANSI or lower-level access to video memory might
> be nice.

I have some ideas on this that I mentioned a few posts back. Basically the
idea would be to implement a function which has a string parameter specifying
the function call, and a variable number of parameters to be passed. The reason
I would have a single Icon function, is primarily to avoid generating too
many function names. Also searches for use of these I/O routines would be
easy since you would look for 1 function, not 30 or more. A system variable
such as &sysfuncs or so would be a generator like &features. There would be
a single addition to &features list.

On MS-DOS I would map these to DOS and BIOS calls. ANSI calls might be nice
but I think most MS-DOS users these days are PC BIOS compatible. (If I am
wrong let me know) The big problem will be in assigning a reasonably standard
list of I/O call names.




Frank Filz
Center For Integrated Electronics
Rensselaer Polytechnic Institute
vicc@unix.cie.rpi.edu