suzanne.soy/racket
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

revise v3->v4 porting advice

Browse Source 
svn: r8508
This commit is contained in:
Matthew Flatt 2008-02-02 16:23:31 +00:00
parent 03f8cab5ee
commit 29ea867e59
1 changed files with 25 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
doc/release-notes/mzscheme/MzScheme_4.txt
View File

@ -138,8 +138,8 @@ you're working with.
Non-module Programs
-------------------
If the prgram is not in a module, then start by putting it into into
one. The module system is there help manage code across multiple
If the prgram is not in a module, then the best start is to put it
into one. The module system is there help manage code across multiple
dialects of Scheme, so staying outside of modules while upgrading
means that you're ignoring the main upgrade tool.
@ -152,31 +152,24 @@ MrEd script, then `#lang scheme/gui' may be the best starting point.
If you have R5RS code that won't fit (or that you don't want) in a
module, then you still have the R5RS language in DrScheme, and you can
run it in MzScheme via the `plt-r5rs' executable.
Finally, the "Pretty Big" language is still available in the "Legacy"
section of DrScheme's "Choose Language..." dialog. It remains a fusion
of traditional Lisp style (big ball of mud, no modules) and PLT-isms
(`local', immutable pairs). So, if you've moved beyond the 1980's R5RS
minimalism, but you're yet ready for the 21st century's modular
Scheme, then Pretty Big is still there for you.
run via the new `plt-r5rs' command-line executable.
Modules Using the `mzscheme' Language
-------------------------------------
If the program is (now) in a `mzscheme' module, then it might work
fine as-is, since the bindings of the `mzscheme' module in v3 and v4
are mostly the same, with two main caveats:
fine as-is. The bindings of the `mzscheme' module in v3 and v4 are
mostly the same, with two main caveats:
* Pairs are immutable in the new `mzscheme'.
Even though `cons' in `mzscheme' could produce mutable pairs while
`cons' is other languages produces immutable pairs, the two
datatypes must be distinct. Thus, leaving `cons' as `mcons' in
`mzscheme' would simply force most code to be converted to `scheme'
or `scheme/base', which can require significant work.
Even though `cons' in `mzscheme' could be defined to produce
mutable pairs, many PLT libraries expect immutable pairs. Thus,
`cons' in `mzscheme' produces immutable pairs, because it seems to
be the best compromise between backward compatibility and
interoperability.
Meanwhile, our experience is that making the result of `cons'
Indeed, our experience is that making the result of `cons'
immutable does not create many porting problems. Nevertheless, if
your code does use `set-car!' or `set-cdr!', and if converting to a
more functional style is difficult, then consider using `mcons' and
@ -204,10 +197,10 @@ mzlib/pretty)' works just as well as `(require (lib "pretty.ss"))' to
access the pretty-printing library in a `mzscheme' module.
The "mzlib" collection has become the home of legacy libraries and
legacy interfaces to still-evolving libraries. For example,
`mzlib/contract' mostly re-exports `scheme/contract', but it also
re-exports the class contracts of `scheme/class' for compatibility
with the old `(lib "contract.ss")' interface.
interfaces. For example, `mzlib/contract' mostly re-exports
`scheme/contract', but it also re-exports the class contracts of
`scheme/class' for compatibility with the old `(lib "contract.ss")'
interface.
Moving to `scheme' or `scheme/base'
-----------------------------------
@ -217,9 +210,9 @@ then you need to pick either `scheme' or `scheme/base' as a
replacement for `mzscheme'. The `scheme' language is a lot bigger than
`scheme/base'. Use `scheme' for scripts or other places where you want
the convenience of many bindings. Use `scheme/base' when you're
implementting a library that you'll distirbute to others, where a
smaller footprint and less possibility for name collisions matters
more than convenience.
implementing a library that you will distribute to others, in which
case a smaller footprint and less possibility for name collisions
matters more than convenience.
If you're moving code into a `scheme' or `scheme/base' module, you'll
usually have the change the following parts of your code:
@ -235,14 +228,14 @@ usually have the change the following parts of your code:
of `rename' and reverse the order of the names.
- Use `(all-from-out ....)' instead of `(all-from ....)', and use
`(except-out (all-from-out ....))' insteda of `(all-from-except
`(except-out (all-from-out ....))' instead of `(all-from-except
....)'. That is, compose `except-out' and `all-from-out' to get
the old `all-from-except' combination.
* Beware that `scheme/base' and `scheme' automatically print non-void
results of top-level expressions. You may have to add an explicit
`(void ....)' around an expression that is executed for a
side-effect, but that returns a non-void result.
`(void ....)' around a side-effecting expression that returns a
non-void result.
* If you use `open-output-file', `call-with-output-file', etc. with a
mode like 'exists or 'replace, you'll have to add the #:exists
@ -257,9 +250,10 @@ usually have the change the following parts of your code:
the `scheme/...' variant --- if the function or syntactic form you
need is not already provided by `scheme'/base or `scheme'.
* Pairs are immutable, and the advice the same as in `mzscheme': try
to convert to a more functional style, and as a last resort fall
back to `mcons' and the `scheme/mpair' library.
* Pairs are immutable, and the advice for handling mutation of pairs
is the same as in `mzscheme': try to convert to a more functional
style, and as a last resort fall back to `mcons' and the
`scheme/mpair' library.
* Beware of libraries that still use `mzlib/kw' for keyword
arguments. It's relatively easy to call such functions from