Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!ucbvax!CIM-VAX.HONEYWELL.COM!dscargo
From: dscargo@CIM-VAX.HONEYWELL.COM ("DAVE CARGO")
Newsgroups: comp.lang.icon
Subject: Icon additions
Message-ID: <8909151357.AA03203@megaron.arizona.edu>
Date: 15 Sep 89 14:43:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 25

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
on csets should be provided.  Conversions should be available between bit
strings and strings, and possibly between bit strings and csets.  I don't
see any good way of representing bit string constants.  Translating them
to strings could be done in a combination of ways:  to a string of binary,
octal, or hex digits, and padded to full length or truncated (on the left
or right) if the remainder is zero filled.  I'm inclined to use Icon for
some graphics applications and true bit-strings would be very helpful.

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).

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.

dsc