Re: Format strings are wrong
Paul Schlie
(26 Dec 2003 18:35 UTC)
|
Re: Format strings are wrong
Alex Shinn
(28 Dec 2003 04:40 UTC)
|
LAMBDA: The Ultimate Formatter (was Re: Format strings are wrong)
Taylor Campbell
(28 Dec 2003 07:17 UTC)
|
Re: LAMBDA: The Ultimate Formatter (was Re: Format strings are wrong)
Alex Shinn
(29 Dec 2003 02:10 UTC)
|
Re: LAMBDA: The Ultimate Formatter (was Re: Format strings are wrong)
Taylor Campbell
(29 Dec 2003 04:19 UTC)
|
Re: Format strings are wrong
Taylor Campbell
(28 Dec 2003 21:24 UTC)
|
what is scheme's formal refinement/extension philosophy? (Re: Format strings are wrong) Paul Schlie (29 Dec 2003 01:15 UTC)
|
Re: what is scheme's formal refinement/extension philosophy? (Re: Format strings are wrong)
Thien-Thi Nguyen
(29 Dec 2003 11:38 UTC)
|
Re: Format strings are wrong
Alex Shinn
(29 Dec 2003 02:37 UTC)
|
Re: Format strings are wrong
Taylor Campbell
(29 Dec 2003 04:52 UTC)
|
Re: Format strings are wrong
Alex Shinn
(29 Dec 2003 07:10 UTC)
|
customizing write-char (was Re: Format strings are wrong)
Alex Shinn
(30 Dec 2003 04:07 UTC)
|
Although this may be the wrong forum for this discussion, I believe that it would likely be nice (if not imperative) to formulate a guiding idealized documented philosophy of the scheme language evolution which can be used as a criteria by which all proposed language library extensions/definitions may be judged against, as otherwise the the judgment of goodness becomes too arbitrary. Personally, it would seem to me that proposals should ideally follow the following hypothetical criteria, to preserve and ideally further simplify the language and its library's presently relatively simple and clean syntax and semantics in the following order of priority: 1 : backward compatibly extend existing syntax/semantics and/or functions to ideally generalize and extend the utility of the core language and libraries; likely by extending the type generality of exiting function's arguments and behaviors such as why does (string ...) need to be restricted to composing strings from characters, and/or refining existing behaviors which which may lead to potentially needless run- time errors such as what's the value of, define or set! or why can't they be nested, or how should function treat the result of (if #f <whatever>) as maybe it could return an #<void-or-undefined>, an ambiguous value, which are ignored by receiving functions thereby potentially simplifying the composition of some run-time composed argument lists by enabling function to ignore <undefined> arguments (Potentially providing the opportunity to simplify more restrictive functional syntax/semantics, which otherwise often only leads to complexity, often with little or no value.) 2 : introduce new functions composed as simply and generally as reasonably possible out of exiting and/or backward compatibly extended, and/or other newly introduced language features and/or functions as necessary to simplify their and ideally other function composition(s), who's argument lists should be constructed to expect as generalized as reasonable natural scheme data types, and ordered to enable their higher-order functional composition, to optimize their generalized long term utility to thereby encourage further simplified unification and extension the core language and its library's expressive power; likely by either increasing the orthogonally of the existing language and/or functions, such as why does number->string exist but boolean->string not, or why would either or string-append need to exist other than possibly in a historical-compatibility library if a more generalized (string ...) composition function were supported; which if it were, it would most likely be ideally complemented by a more sophisticated flexible pretty-string function capable of formatting its arguments as a function of their type and a format specifier list which should themselves as previously noted likely be composed of plain-old scheme data-types and ordered to optimize its potential for flexible higher-order functional composition. (I apologize for my extremely long, and likely poorly formed sentences, if they can be called that; it's merely my attempt to express a strawman outline of a semi-formal set of guiding principles/philosophy which I believe is likely necessary to establish at least some form of metric by which proposals may be more-or-less somewhat more objectively judged for goodness; which with a little luck may help accelerate the evolution and refinement of the scheme language and core libraries, by to some degree depersonalizing some of the analysis/ranking process, and could even with some work enable some type of correlation/dependence/goodness matrix to be produced to help understand more analytically the impact/benefit of a proposals relative to the existing core facilities, and each other in terms of attempting to optimize these philosophical goals.) Thanks for your collective time and consideration, -paul-