[dylan] Duplicated format implementation in common-dylan and io libraries

Bruce Mitchener <[email protected]> Fri, 13 Nov 2015 09:46:05 +0700
Newsgroups gmane.comp.lang.dylan.gwydion.devel
Message-ID <CA+esKjPMJDNrFSAZq60vTUQMPz8OhNNPooswQMhphRrv+XnEug@mail.gmail.com>
--===============0614577509==
Content-Type: multipart/alternative; boundary=047d7bdc9e4a9d52630524630f15

--047d7bdc9e4a9d52630524630f15
Content-Type: text/plain; charset=UTF-8

TLDR:

I propose breaking up the io library and reducing the duplication of format
code between common-dylan and io by sharing the implementation that is
currently present within io.

More details and motivation below.

Full email:

A common source of confusion is that common-dylan has one implementation of
format while the io library provides another (that is more complete).

This means that someone that is extending print-object or print-message
will have unexpected results if someone happens to use the implementation
from common-dylan, since it isn't extensible.

I'm not sure what the original motivation was for this split. Perhaps it
was that the IO library was larger, perhaps it was the usage of the FFI, or
something else entirely or just simply inertia.

In Mindy, I am prototyping a common-dylan implementation and there, I just
let common-dylan depend on the io library and use the same implementation
of format.  This seems to work out pretty well and definitely eliminates a
source of confusion.

This also shows up when I'm fixing things like "How do we print type
objects?" as I have to implement the same functionality in both
common-dylan and io.

The io library provides a number of things that not everyone needs, like
indenting streams, pretty printing, etc so it may be best to not go and
have common-dylan depend directly upon the io library in Open Dylan.

My proposal, pending further investigation, is that we look at splitting
the io functionality into 2 sets: slim-io and io.  The slim-io
functionality would either move to a separate library that both
common-dylan and io can depend upon, or it would be folded directly into
the common-dylan library.

Thoughts?

 - Bruce

--047d7bdc9e4a9d52630524630f15
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>TLDR:</div><div><br></div><div>I propose breaking up =
the io library and reducing the duplication of format code between common-d=
ylan and io by sharing the implementation that is currently present within =
io.</div><div><br></div><div>More details and motivation below.</div><div><=
br></div><div>Full email:</div><div><br></div>A common source of confusion =
is that common-dylan has one implementation of format while the io library =
provides another (that is more complete).<div><br></div><div>This means tha=
t someone that is extending print-object or print-message will have unexpec=
ted results if someone happens to use the implementation from common-dylan,=
 since it isn&#39;t extensible.</div><div><br></div><div>I&#39;m not sure w=
hat the original motivation was for this split. Perhaps it was that the IO =
library was larger, perhaps it was the usage of the FFI, or something else =
entirely or just simply inertia.</div><div><br></div><div>In Mindy, I am pr=
ototyping a common-dylan implementation and there, I just let common-dylan =
depend on the io library and use the same implementation of format.=C2=A0 T=
his seems to work out pretty well and definitely eliminates a source of con=
fusion.</div><div><br></div><div>This also shows up when I&#39;m fixing thi=
ngs like &quot;How do we print type objects?&quot; as I have to implement t=
he same functionality in both common-dylan and io.</div><div><br></div><div=
>The io library provides a number of things that not everyone needs, like i=
ndenting streams, pretty printing, etc so it may be best to not go and have=
 common-dylan depend directly upon the io library in Open Dylan.</div><div>=
<br></div><div>My proposal, pending further investigation, is that we look =
at splitting the io functionality into 2 sets: slim-io and io.=C2=A0 The sl=
im-io functionality would either move to a separate library that both commo=
n-dylan and io can depend upon, or it would be folded directly into the com=
mon-dylan library.</div><div><br></div><div>Thoughts?<br><div><br></div><di=
v>=C2=A0- Bruce</div><div><br></div></div></div>

--047d7bdc9e4a9d52630524630f15--

--===============0614577509==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers

--===============0614577509==--