This page is part of the web mail archives of SRFI 52 from before July 7th, 2015. The new archives for SRFI 52 contain all messages, not just those from before July 7th, 2015.
Record based text common on some pda's cell phones, etc. aren't files they're simple data base fields which are access through distinct api's which have no relationship to conventional C file functions for example. You'll like this (therefore), it's likely ideally necessary to define a common convention by which scheme may call C and/or Java foreign procedures ala a c-lambda function and implied related facilities for example, through which formatted text, numerical, and/or binary objects which may represent encoded images and/or icon values (in whatever format they require) may be passed back and forth. (back to srfi-50 I guess) -paul- > From: "Bradd W. Szonye" <bradd+srfi@xxxxxxxxxx> > Date: Fri, 13 Feb 2004 17:08:10 -0800 > To: srfi-52@xxxxxxxxxxxxxxxxx > Subject: Re: Encodings. > Resent-From: srfi-52@xxxxxxxxxxxxxxxxx > Resent-Date: Sat, 14 Feb 2004 02:08:20 +0100 (NFT) > >> On Fri, 13 Feb 2004, Bradd W. Szonye wrote: >>> Yes, you get out what you put in. However, when a system provides no >>> "binary mode" or "stream mode" for text files, there is no way to >>> implement a text port in terms of a binary port. > > On Fri, Feb 13, 2004 at 05:06:09PM -0800, bear wrote: >> This is popping up a lot now in wireless devices; lots of them have >> record-based text and stream-based audio for example. As a 'small' >> language scheme is a good candidate for embedded systems given a good >> compiler; so it's probably not time just yet to abandon the idea of >> record-based text as something that ought to be buried with the >> dinosaurs. > > I wondered if there was anything like this in embedded devices, or if > the only "niche" for record-based text was in the big iron machines. > Good to know that I'm not just playing the "be friendly to dinosaurs" > advocate. > -- > Bradd W. Szonye > http://www.szonye.com/bradd >