|
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-