Email list hosting service & mailing list manager

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

what is scheme's formal refinement/extension philosophy? (Re: Format strings are wrong) Paul Schlie 29 Dec 2003 01:15 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-