Dear Matt, I appreciate your answer! I add some comments below. ---------- Mensagem encaminhada ---------- > From: Matt Gushee <[email protected]> > To: chicken-users <[email protected]> > Cc: > Date: Mon, 8 Apr 2013 22:53:38 -0600 > > > It is clear that Scheme/Chicken values informative names for procedures > > (call-with-current-continuation, call-with-values, with-input-from-file, > > etc.). Wouldn't it be more informative to (use lists) instead of (use > > srfi-1) or (use hash-table) instead of (use srfi-69)? > > Sounds good in principle. I have no particular thoughts about the > specific names you propose. >
The names are just a suggestion. > > These SRFIs could provided as eggs. The data-structures unit could be > > dissolved and its procedures spread according to the new specified unit. > So > > these new units could contain the SRFI and more. > > That might not be such a good idea. I believe the rationale for the > SRFI system is to provide a *portable* way to extend the language. > 'SRFI-plus' libraries would tend to create confusion as to what is > portable. At the very least, the documentation for such eggs would > need to be very clear as to which functions are from the SRFI and > which are extra. > I've taken a look at srfi-1.scm and it has a lot of ##sys#* and specialized operators, which I believe are Chicken modifications. I understand that adherence to SRFIs demands us to have the same procedures signatures with the same expected results as from the SRFI document, but the implementation is specific to the Scheme system at stake. Wouldn't it be possible to implement as eggs all the SRFIs Chicken wants to provide and that the new units just (use ...) them and extend their syntax with Chicken peculiarities? The big advantage I see is to have a cleaner core system, with less units, but that relate SRFI to Chicken's related procedures (SRFI-1 + Chicken's list procedures in 'list' unit, or as a part of a 'data-structures' unit, for example). I know http://api.call-cc.orgprovides an easy way to know in which unit determined procedure is implemented, but to have related procedures implemented inside one unit makes much more sense to me. I imagine this would require a great effort, but couldn't it be one when porting core units to modules? Thanks for your opinion, Matt!! -- > Matt Gushee >
_______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
