guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: thoughts on ports


From: Mike Gran
Subject: Re: thoughts on ports
Date: Mon, 9 Apr 2012 12:15:31 -0700 (PDT)

> From: Andy Wingo <address@hidden>
>  
>Hi all,
>
>I have been thinking about ports recently.  I know other folks have had
>some thoughts here too, so it's probably good to have a discussion about
>how they should look.

...
 
>Obviously we need ports implemented in C because of bootstrapping
>concerns.  But can we give Scheme access to buffering and the underlying
>fill (read) / drain (write) / wait (select) operations?
>
>So, the idea: refactor the port buffers (read, write, putback) to be
>Scheme bytevectors, and internally store offsets instead of pointers.
>Give access to some internal port primitives to a new (ice-9 ports)
>module.

Hi Andy,
 
I haven't looked at your eports, yet.
 
Let me just throw out some tangential info from when I played with
ports a couple of years ago.
 
The most awkward thing I did had to do with pushing back to
ports.  As you know, when you putback to file port, you're not really
unreading the character from the device.  You're allocating a memory
buffer to pretend to be the device.  (At the time push back buffers were
8-bit locale encoded, so every unget operation involved a conversion.)
 
So, you're abstracting the unget operation so that any port can do it,
even a read-only file's port.
 
The C version of the reader used (uses?) pushback a lot.  At least once
per parenthesized expression.
 
Anyway, here's an idea.  Let's call the C code for ports 'base ports'.
 
1. Refactor the C reader so that it took on the responsibility of
storing the putbacked (ungotton?) characters.
 
2. This would let you simplify the base ports to make read, write,
and unget into those operations that the underlying device could
provide.  During bootstrap, a read-only base file port would error on
unget, for example.  Base ports would not longer have pushback buffers.
There would be no such thing as string base ports since they aren't
a device.
 
3. Then you could get through bootstrap and create scheme ports on top
of the base port primitives.
 
Just an idea.
 
-Mike



reply via email to

[Prev in Thread] Current Thread [Next in Thread]