Biep scripsit:

> (And I think "Schemest" would then be a one-syllable word.)

English is hard enough for non-native speakers to pronounce without
introducing novel consonant clusters like /mst/ into it.  The few words
which contain /mst/ today always have it broken between syllables, and
indeed between morphemes, like "brimstone", "circumstance", "homestead",
and "tombstone".  "Hamster" is a partial exception containing only one
morpheme -- it is a borrowing from German and not from "ham" + "-ster".
(Sorry, but you pushed a button.)

> (a micro Scheme might not even KNOW about, say, lower-case letters),

Though I cut my teeth on them and remember them fondly, the day of the
PDP-8 and the ASR-33 Teletype is now over.

> * The asymmmetry between multiple inputs and multiple outputs for
> procedures.  (lambda (a b - result rem quot) (quotient+remainder a b -
> quot rem) (* quot rem - result) (display result -))

I don't think this is recognizable as Scheme any more, though of course
with suitable macros it could be embedded in Scheme.  It's just Prolog
in S-expressions.

> Barely possible is "splicing in" multiple results - which would require
> them to be adjacent.  A splicing construct (+ 1 ,@(quotient+remainder
> 25 4) 6) might do - see Lua for an even more constricting solution.

For those not familiar with Lua:  If the last argument to a procedure
call returns multiple values, all of them are passed to the called
function, whereas all non-last arguments are truncated to a single value
(or 'nil' if no value is available).  The same is done for assignment to
multiple variables, calls to constructors, and tail returns.  Including a
redundant pair of parentheses around an expression also truncates it to
a single value.

The idea of using splicing is interesting, though.

> Maybe symbols should be decoupled from code text - a Chinese might use
> other names for the identifiers in a Scheme program (alpha renaming)
> than a German would - without it being another program.  There is
> simply an abstraction level difference.  Both could collaborate on a
> common program without ever even knowing what names the other uses.

This can be provided by creating a module that wraps an existing module,
exporting its German names as their Chinese translations.  Not quite as
abstract, but much easier to understand.  Of course, standard identifiers
can be remapped in the same way, including core syntax.

> As with symbols in the preceding proposal, syntax could be decoupled.
> S-expressions exist on the base level and may be used, but other
> representations are possible.  We need to hack input reading anyway
> if we want to be able to add new types with their idiosyncratic
> representations, so why not go the whole way?  In an appropriate
> context, Dylan, Lua and Algol 60 are simply different syntactic
> manifestations of Scheme.  This would help in the acceptance of Scheme
> into the mainstream as well.  Let s-expressions be the raw format,
> but allow laymen to use jpeg and the like - they'll come to raw when
> they need the full power.

This is a fine idea in general, and Racket actually provides the
infrastructure for it.  I don't think, however, that it is ripe for
standardization.  In general, I'd say this of many of your points:
they are a manifesto for an implementation, not for standardization,
at least not yet, maybe not ever.

> This would lead to mutable first-class environments.

WG1 went down this rathole in its earliest days.  The effects weren't
good.  If you want completely dynamic languages, you know where
to find them (places like Common Lisp and Smalltalk-72).  Scheme is
actually rather static for a Lisp, not even acquiring `eval` until R5RS.
(ISLisp is even more so, being apparently an attempt to push a Lisp as far
toward static nature as possible, though it does not have static typing.)

> Oh, and environments shouldn't be different from other tables, and
> should have a way to indicate where to find a location that is not
> locally available.  In that way various schemes of multiple inheritance
> would become trivially implementable.

Self-modifying code provides immense power, but it's practically impossible
to reason about, and so it has mostly been abandoned by the programming
community.

> A common interface should govern all external resources (libraries,
> files, sockets, ..).  I don't necessarily want to know whether I read
> a file or interact with a DLL or a user - and certainly don't want
> to write various copies of my code to do these different things.
> That would be like writing separate sorting routines for strings,
> numbers, etc.

A view of the user that doesn't distinguish them from a file is even
more restrictive than TTY interaction.  It is certainly obsolete today.

> Single pass with maximal deferment is the Scheme way: variables inside
> lambdas don't need to be resolved yet, resolution can be deferred
> until they are called.

I think this is a very narrow exception to an essentially static design.

> Without very strong reasons, one should not request different behaviour
> from syntax transformers.  Ease of compilation, or speed of the
> resulting system are no strong reasons.

Reasoning about code, including your own code a month after you wrote it,
is a very strong reason.

> A rewriter can be written in Scheme and then used in macro expansion -
> great, but let the rewriter then be generally available (because it
> has other possible uses),

I agree, and have added this idea to WG2's input hopper to be voted on
when WG2 reconvenes.

> and be optional in writing syntax (because there are other ways that
> sometimes may be better).

I happen to think that going beyond `syntax-rules` is a mistake, but I
know there are plenty of thoughtful people who disagree.  WG2 will
certainly have some other form of macros.

> Something else is lost here.  Scheme was about the right thing, but
> also about the minimal thing.  Scheme provided a basis which was like a
> semantic assembly language: it provided primitives with which to build.
> Yes, certain complex systems ease programming - so let's make sure
> such systems can be written in Scheme, but let's not make them the
> basis of Scheme!

As I have often said before, there is nothing tiny or jewel-like about
Scheme's standard procedure library, and never has been.  It has been
patched together over time from a subset of what MacLisp provided.

What is more, it's not clear that standardizing a facade and not its
underlyinng layers is the Right Thing.  WG2 will standardize TCP library
routines, but not a general Posix mechanism.  The `error` procedure
in R7RS may (in the absence of exception catchers) drop the program
into a debugger, terminate it with an error message, or do something else.

> Having explicit mutable locations (say, ML style), would allow efficient
> compilation where they aren'n used.  And explicit mutable locations can
> be used as a base level on which to build Scheme-as-we-know-it, with
> lambda binding its variables to mutable locations, so that backward
> compatibility is maintained.  It would help both with parallelism
> (fewer locks needed) and with inlining.

Steele pointed out very early on (maybe in the comments to the Rabbit
compiler, I forget) that cells would have been better than mutable
variables, but it would have taken more time than he had to base Scheme on
them.  It's important not to forget how much of Scheme's fundamentals are
based on sheer contingency.  It was not deep theoretical considerations
that allowed Steele and Sussman to deduce the equivalence of actors and
procedures under tail recursion, but the discovery that two pieces of
code were exactly the same.

> And other locations, such as the car and cdr of a pair, already excape,
> so why have an artificial difference between those and variable
> locations?

Well, why not provide both escaping and non-escaping locations?  They have
different applications.

> Full parallelism is problematic, so some kind of locking will be
> necessary.  I think locations are the natural place for that: this
> function wants to update a location, so no-one else should do an update
> in parallel.

The experience with threaded code over the decades has been that a single
location is far too fine-grained for comprehensibility.  Programmers are
only human.

> Just reading or writing is no problem, but writing a value that is
> computed from a read is.

Alas, knowing whether a value to be written is computed from a value
read is Turing-complete.

> This should include load: the value of load would then be the value of
> the last expression in the file loaded.  If one wants anything else,
> it is trivial to wrap something around an efficient load, whereas the
> inverse is not possible.

A few implementations take this approach, but it can't now be standardized.

>
> Other thoughts
>
> * Write/read invariance.  IO is library material, but the library
> provided ought to allow write/read invariance on closures and
> environments.  A unique tag provides unification if the object is
> already present; if not, it is produced.  In that way two running
> Schemes can exchange procedures, including ones capturing variables.
> The unification scheme for environments allows one to reconstruct
> environment inheritance incrementally.

Providing this feature across arbitrary Schemes running on arbitrarily
different machines constrains every Scheme to the same open-ended
implementation strategy.  That serves some people's purposes,
but definitely not everybody's.  It's important to realize that
standardization is for all users (and library authors in especial,
because they have the worst problems from lack of portability), not
just for users who are willing to sacrifice every other consideration
to programming flexibility.  Scheme is an extremely flexible language,
but it is not, per se, the language of (run-time) flexibility.

> The principle of least surprise is already violated with macros.  Macros
> must be bound before use; there is no equivalent to anonymous lambdas.

What's the point of that?  Macros exist so that the code you write can be
transformed into code the system understands.  If the rewrite rules stand
next to the original code, you might as well avoid them altogether.

> Flushing an output port is the symmetric opposite of peeking at an
> input port - or it ought to be.  I think lazy streams could make ports
> more Schemey - I don't like the built-in necessity to deal imperatively
> with ports.  But I am not clear on all this - I only feel Scheme could
> have a clean mathematical notion of ports which is unlike what other
> languages have.

There's an interesting idea, but I don't know what to do with it either.

> * Time.  Time is an elusive concept.

It certainly is.

What you describe here (snipped) is an interesting idea, but by no means
core, to say nothing of jewel-like.  WG2 will have a date-time library
that may owe something to these notions.

> Wouldn't a Schemish string be a sequence of character objects (soco),

If you want general vectors of user-defined objects, we now have those.
Strings are a convenient base for many use cases, and we can't remove
them entirely in favor of lists or general vectors due to the IEEE
restriction (we would have to prove that they are actually harmful, a
very high bar).

> In other words: Scheme should not prescribe one crippling string
> format, but rather a set of specifiers which which people can define
> the strings they need.  A classical ASCII-like one is obligatory,
> the others are optional.

R7RS-small has classical strings, but allows implementations to provide
anything between ASCII and full Unicode as they see fit.

--
Deshil Holles eamus.  Deshil Holles eamus.  Deshil Holles eamus.
Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x)
Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy, hoopsa!
  --Joyce, Ulysses, "Oxen of the Sun"       cowan@ccil.org

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports