<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:D="DAV:" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-GB link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Sean Your analysis is good, but missing the following<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal style='text-indent:36.0pt'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> You can build stuff on
class Data *<b>other than</b>* SYB. That’s a motivation for not identifying
Data with SYB.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>That’s really the argument for keeping Data in ‘base’, so that
others can build on it without depending on the full glory of SYB.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>(A weaker argument is that GHC “knows” about Data, to support ‘deriving’.
But that’s less important.)<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Simon<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org]
<b>On Behalf Of </b>Sean Leather<br>
<b>Sent:</b> 01 September 2008 21:23<br>
<b>To:</b> Claus Reinke<br>
<b>Cc:</b> José Pedro Magalhães; ross@soi.city.ac.uk; Simon Peyton-Jones;
libraries@haskell.org; generics@haskell.org; igloo@earth.li<br>
<b>Subject:</b> Re: Splitting SYB from the base package in GHC 6.10<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-right:0cm'>
<div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-right:0cm'>
<p class=MsoNormal>The issue is: SYB is being moved out of base into its own
package.<br>
However, the Data class is, in a way, tied to base since it depends on the<br>
deriving mechanism.<o:p></o:p></p>
</blockquote>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<p class=MsoNormal>My understanding is that the deriving mechanism would still
work if class 'Data' was moved into 'syb', but changes in 'Data' would still
need to be matched in the deriving mechanism (which isn't auto-generated from
'base', either). As long as 'syb' remains a core library, we can thus focus on
assigning modules to 'syb' or 'base' by functionality.<o:p></o:p></p>
</blockquote>
<p class=MsoNormal><br>
So, here's a (possible) summary from a general perspective.<br>
<br>
(1) Some people want to keep some parts of the SYB functionality in 'base',
because these parts are closely linked to some parts of GHC. This is desired
for convenience (and perhaps test coverage?).<br>
(2) Some people want to remove some parts of the SYB functionality from 'base',
because they want to be able to maintain and release SYB separately.<br>
(3) Some people in group #2 are not sure what should be left in 'base' or
extracted into 'syb.'<br>
<br>
My observations:<br>
(A) I don't see 'syb' ever becoming something other than a core library for
GHC, considering it's close family ties.<br>
(B) I expect 'syb' to get updated and released more often than GHC. This is
especially true considering the newfound interest.<br>
(C) I expect the 'syb' library will be tested using the current (and possibly
past?) release(s) of GHC, because that's what releases will use in general. If
something in a development version of GHC breaks SYB, then there may need to be
a new 'syb' release for when that version of GHC is released. At that point,
there may be a need for a temporary fork if other work is ongoing.<br>
(C) From a user's perspective I don't understand the splitting of SYB. Why is
it that I can derive Data.Generics.Data, but I cannot actually use other
functions built for it?<br>
<br>
So, given all of the above (assuming it's correct), it seems to me that the
benefit leans towards migrating everything SYB-related into the 'syb' library.
Is the motivation/argument for group #1 very strong?<br>
<br>
Hope this helps,<br>
Sean<o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>