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.
Please take a look at their typical api's for data interface & storage, you may change your mind. > From: "Bradd W. Szonye" <bradd+srfi@xxxxxxxxxx> > Date: Fri, 13 Feb 2004 19:00:08 -0800 > To: srfi-52@xxxxxxxxxxxxxxxxx > Subject: Re: Encodings. > Resent-From: srfi-52@xxxxxxxxxxxxxxxxx > Resent-Date: Sat, 14 Feb 2004 04:00:17 +0100 (NFT) > > Paul Schlie wrote: >> 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) > > Huh? I can't parse that. I think you're saying that you'd use some text > layer on top of a foreign database function. If so: No, that's not the > best way to do it. Indeed, you can use standard I/O functions like READ > and DISPLAY on that kind of system. You just need a Scheme system that > understand the native text format, and a program that understands the > limits of the format. Cobol systems do this all the time. > > There are *much* easier ways, language-wise, than what you seem to be > suggesting here. But you can't do it with a simple text layer over > binary stream I/O. Despite the popularity of Unix, everything is *not* a > byte stream! In some ways, the binary stream model is inferior; Unix > programmers who work with block-oriented devices have known this for a > long time. > > In short, the "text over binary" abstraction is not always appropriate, > and your zeal for that model can't change that fact. > -- > Bradd W. Szonye > http://www.szonye.com/bradd >