Re: [Scheme-reports] WG1 Scheme as a language for CS1

[Alaric Snell-Pym <alaric@x>]

On 05/09/11 02:45, Vincent Manis wrote:
> The small version of R7RS is supposed to be suitable as a teaching
> language. Now that the draft has been out for review for a few weeks,
> I feel ready to comment on the degree to which the WG1 language meets
> that requirement.

I think that depends on what you want from a teaching language. Some
might want the kitchen sink so they can teach networking and GUI
development :-) I'd say that WG1 should be enough to encode algorithms
practically and clearly which, among other benefits, is useful for
teaching fundamentals of programming up to algorithms courses.

> My criterion is: would the WG1 language be usable, unaugmented, for
> about 80 hours of instruction taking a student from essentially no
> background in programming and computer science to writing and testing
> substantial multi-module programs using interesting data structures?

That sounds a good target!

> Similarly, could someone use a book that used only the WG1 language
> to learn programming on their own? (Disclaimer: I once co-authored an
> introductory computer science text that used Scheme. That was getting
> on for 20 years ago, I have no intention of doing it again.)

What was it called? I'd love to read a copy if it's still about...

> 1. WG1 quite properly eschews any kind of formatting language.
> Unfortunately, the Draft as provided makes it impossible to display a
> number with a fixed number of decimal places. Not only does this make
> output look ugly, but it causes the sin of False Accuracy (`Captain,
> the Enterprise will enter the black hole in exactly 17.867 seconds').
>
> This may sound like a cosmetic issue, but I have sat through a LOT of
> computer science curriculum meetings in my life, and it's exactly the
> kind of detail someone opposed to Scheme will drag out. Similarly, if
> someone is considering learning Scheme, this `trivial' detail can be
> enough to discourage them.
>
> I would therefore like to suggest augmenting NUMBER->STRING to accept
> a keyword indicating the kind of conversion expected. So
>
> (number->string 1.2345 'fixed 2)  => "1.23"
>
> This doesn't break any existing programs, because a non-numeric radix
> isn't currently allowed. WG2 extensions to this could allow for
> E-notation, polar representation of complex numbers, etc. FIXED is
> the only conversion specifier I am requesting in WG1. (I'm not wedded
> to the particular symbol FIXED.)
>
> Alternatively, WG1 could provide another procedure, e.g.
>
> (number->string-custom-format 1.2345 'fixed 2)
>
> (I don't have time to think of a shorter name.)
>
> This doesn't do the entire numeric formatting job (for example, it
> doesn't offer the ability to set a field width). But it does enough
> to be useful in real programs.

That's an interesting possibility. I wonder if it should be in
number->string, or in a rounding operation? I mean, exact numbers should
be represented exactly by number->string, so displaying them with a
specified number of digits rings a small alarm bell, compared to
explicitly rounding them to a specified number of digits before display.

Why make decimal special? Perhaps it would be good to add an optional
extra argument to round/floor/ceiling/truncate that's a precision given
as an actual number (use 0.01 to get two decimal places; 0.25 for two
binary places), defaulting to 1.

> One might argue that NUMBER->STRING(-CUSTOM-FORMAT) can be written in
> Scheme. Indeed it can; so can SQRT, so one can just give learners
> some code. But this violates the pedagogical principle that you never
> show code that the student can't understand, and students often have
> serious trouble with understanding representations and conversions
> anyway. (One student, in a second-year course, once asked me, `I
> understand how the program converts from the string "01A2" to
> hexadecimal, but how exactly do you convert the result to binary?')

Yeah, I've seen people get tangled on "computers represent things as
binary" - at the programming language level, an integer is an integer,
and binary is a matter of internal representation; there's a core lesson
in abstraction there!

> Third, the rationale. I'd be curious to know if anyone has read this
> far in the message :)

;-)

> - `For the record, I don't think we need randomness in WG1. A user
> can roll their own, given good integers etc. Yes, they can do it
> wrongly. But the same argument applies to all sorts of algorithms. I
> have textbooks full of algorithms that, at first sight, are
> overcomplicated, but fix all sorts of subtle problems in the
> 'obvious' approach (if there even is one). Why are random numbers
> special?' (Alaric Snell-Pym)
>
> Answer 1: Why is SQRT special? NUMBER->STRING? APPEND? *?

I'd be quite happy if SQRT went off to WG2 in a numerical algorithms
module, personally... but I'm a bit odd like that. Likewise with append:
let that all come from a nice srfi-1 library! NUMBER->STRING and *, I
feel, are part of the core utilities required for numbers and strings...
which is purely subjective, I admit. SQRT is sort of on the border for
me in that respect.

I'd really like to see reference implememntations of all of the R7RS
procedures and macros in terms of some well-chosen minimal subset,
actually. It would probably be largely impractical to implement by
providing the subset and slapping on the standard library, as most
implementations will have access to better ways to implement strings
than vectors of characters, but it'd have explanatory value and parts of
it can be used in implementations where convenient.

> - Can you make the RNG a parameter, so that it works correctly in
> multi-threaded programs?
>
> Threads aren't in WG1. If WG2 includes threads, it can decide how
> that impacts basicrandom. I have an opinion on that, but won't
> express it here, because I want to rule WG2 out completely as an
> issue in designing basicrandom's interface.

Threads aren't in WG1, but I've been taking care to spot and highlight
things that might cause pain in the presence of threads (eg, global
state), as implementations are likely to provide them!

However, for a basic RNG, I'd be inclined to either make it potentially
non-repeatable (in which case, just have a global state and be done with
it; no need for RANDOMIZE! then either), or to mandate that it's
something continuation-local like a parameter (and implementations *may*
then use an actual parameter, and a WG2 standard might even say which
one to use).

> - Why the implementation violation?
>
> It's conceivable (though extremely unlikely) that a particular
> platform has no sources of random bits (other than doing what DEC
> FOCAL was apocryphally claimed to do, namely keeping a count of the
> number of iterations of the `waiting for a key' routine, and
> returning that; I was just looking at the PDP-8 FOCAL manual (on
> bitsavers.org), which describes the random number generator as
> `nonstatistical'). If an implementer doesn't feel they can truly
> produce a nondeterministic seed, they have the option of reporting a
> violation, rather than producing a (possibly biased) result. I doubt
> many implementations would take that option.

I think that a WG1 RNG, if one should appear (and I'd still rather not,
personally... I don't see why teachers should limit themselves to not
pulling from WG2 as well) should just say that there's a procedure that
returns random numbers, and not get into the details of state, or
quality, or reproducability. Any implementation, even the simplest,
wouldn't be too far put out to provide an LCRNG or better with a single
thread-safe global state, or per-continuation state if that's easier,
seeded from some system source of randomness or semi-randomness or, if
*all* else fails, a constant. But that's only after you've exhausted
such tricks as hashing your stack segment and the like! Embedded systems
may always start from ROM with a clean RAM and have no clock... but you
won't be using them for teaching. The presence of such systems is why
I'd like RNGs to be an optional WG2 module, but hey, I'm willing to be
argued down ;-)

But as soon as you start worrying about finnicky details of an RNG, you
start to get a complexity explosion, and before you know it, you have a
special random-source object that sits in a parameter with
initialisation and cloning procedures and and and...

> If anyone has gotten to this point, my hearty congratulations. I hope
> that WG1 will indeed create tickets on the issues I've raised.

I've created http://trac.sacrideo.us/wg/ticket/175 for you... I'll leave
it to Alex Shinn to advise on how to handle people asking us to reopen
issues we've voted down!

> -- vincent

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/

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