Groups | Search | Server Info | Keyboard shortcuts | Login | Register
Groups > comp.compilers > #3314
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: Scheme is not another C-like language? was Compilers :) |
| Date | 2023-01-12 02:54 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <23-01-046@comp.compilers> (permalink) |
| References | (3 earlier) <23-01-008@comp.compilers> <23-01-016@comp.compilers> <23-01-029@comp.compilers> <23-01-033@comp.compilers> <23-01-038@comp.compilers> |
On Wed, 11 Jan 2023 11:02:56 -0000 (UTC), Kaz Kylheku
<864-117-4973@kylheku.com> wrote:
>It seems that Scheme, with its ugly (define ...) that can be used inside
>block scopes, [disallows name redefinition]!
Agree it's ugly: I never use internal defines in my own code.
Unfortunately some people love them.
>I tried (lambda () (define x 42) (define x 43)) in a Scheme
>implementation and got an error about the duplicate variable.
>
>That's completely silly since it breaks the idea that the block scoped
>define can just be desugared to nested lets.
Unfortunately the experience varies by version:
From R3RS to R5RS, a series of internal defines is treated AS IF they
all are part of a single 'letrec' with the scope being the whole body.
'letrec', of course, does not permit multiple bindings to the same
name.
In R6RS and R7RS, a series of internal defines is treated as a
'letrec*' [note trailing *]. letrec* is equivalent to nested letrec
and so does permit rebinding to the same name ... which will shadow
any previous bindings.
from R5RS 5.2.2 Internal Definitions
... The variable defined by an internal defnition is local to the
body. That is, variable is bound rather than assigned, and the region
of the binding is the entire body. For example,
(let ((x 5))
(define foo (lambda (y) (bar x y)))
(define bar (lambda (a b) (+ (* a b) a)))
(foo (+ x 3))) => 45
A body containing internal definitions can always be converted into a
completely equivalent letrec expression. For example, the let
expression in the above example is equivalent to
(let ((x 5))
(letrec ((foo (lambda (y) (bar x y)))
(bar (lambda (a b) (+ (* a b) a))))
(foo (+ x 3))))
Just as for the equivalent letrec expression, it must be possible to
evaluate each expression of every internal definition in a body
without assigning or referring to the value of any variable being
defined.
From R6RS 11.3 Bodies
The <body> of a lambda, let, let*, let-values, let*-values, letrec, or
letrec* expression, or that of a definition with a body consists of
zero or more definitions followed by one or more expressions.
<definition> ... <expression1> <expression2> ...
Each identifier defined by a definition is local to the <body>. That
is, the identifier is bound, and the region of the binding is the
entire <body> (see section [5.2]).
Example:
(let ((x 5))
(define foo (lambda (y) (bar x y)))
(define bar (lambda (a b) (+ (* a b) a)))
(foo (+ x 3))) => 45
When begin, let-syntax, or letrec-syntax forms occur in a body prior
to the first expression, they are spliced into the body; see
section [11.4.7]. Some or all of the body, including portions wrapped
in begin, let-syntax, or letrec-syntax forms, may be specified by a
macro use (see section [9.2]).
An expanded <body> (see chapter [10]) containing variable definitions
can always be converted into an equivalent letrec* expression. For
example, the let expression in the above example is equivalent to
(let ((x 5))
(letrec* ((foo (lambda (y) (bar x y)))
(bar (lambda (a b) (+ (\* a b) a))))
(foo (+ x 3))))
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar
Compilers :) "Tristan B. Velloza Kildaire" <deavmi@redxen.eu> - 2023-01-02 12:28 +0200
Re: Compilers :) Spiros Bousbouras <spibou@gmail.com> - 2023-01-02 20:52 +0000
Re: another C-like language? was Compilers :) Steve Limb <stephenjohnlimb@gmail.com> - 2023-01-03 16:24 +0000
Re: another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-03 12:52 -0800
Re: another C-like language? was Compilers :) arnold@skeeve.com (Aharon Robbins) - 2023-01-04 17:12 +0000
Re: another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-04 12:39 -0800
Re: another C-like language? was Compilers :) "marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> - 2023-01-05 06:27 -0800
Re: another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-05 16:26 -0800
Re: another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-06 15:39 +0100
Re: another C-like language? was Compilers :) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-09 17:41 +0000
Re: another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-10 17:48 +0100
Re: another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-10 15:13 -0800
Re: another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-11 13:38 +0100
Re: back in the 60s, another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-11 16:38 -0800
Re: another C-like language? was Compilers :) "marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> - 2023-01-15 04:26 -0800
Re: another C-like language? was Compilers :) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-11 11:02 +0000
Re: Scheme is not another C-like language? was Compilers :) George Neuner <gneuner2@comcast.net> - 2023-01-12 02:54 -0500
Re: another C-like language? was Compilers :) Bill Findlay <findlaybill@blueyonder.co.uk> - 2023-01-11 11:58 +0000
Re: another C-like language? was Compilers :) Thomas Koenig <tkoenig@netcologne.de> - 2023-01-11 10:49 +0000
Re: another C-like language? was Compilers :) "marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> - 2023-01-15 04:21 -0800
Re: another C-like language? was Compilers :) Andy Walker <anw@cuboid.co.uk> - 2023-01-15 22:01 +0000
Re: another C-like language? was Compilers :) "Luke A. Guest" <laguest@archeia.com> - 2023-01-13 18:25 +0000
Re: another C-like language? was Compilers :) George Neuner <gneuner2@comcast.net> - 2023-01-13 17:20 -0500
Re: another C-like language? was Compilers :) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-14 19:07 +0000
Re: another C-like language? was Compilers :) "marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> - 2023-01-07 02:14 -0800
Re: another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-08 20:21 +0100
Re: another C-like language? was Compilers :) Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-01-09 04:48 +0100
Re: C scopes, another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-09 18:12 +0100
Re: another C-like language? was Compilers :) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-09 11:24 -0800
Re: Compilers :) "Tristan B. Velloza Kildaire" <deavmi@redxen.eu> - 2023-01-13 13:41 +0200
Re: Compilers :) Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-01-05 01:12 +0100
Re: Compilers :) "Tristan B. Velloza Kildaire" <deavmi@redxen.eu> - 2023-01-13 14:17 +0200
Re: C and Java, was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-13 10:32 -0800
Re: C and Java, was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-13 12:39 -0800
Re: C and Java, was Compilers :) dave_thompson_2@comcast.net - 2023-01-28 10:37 -0500
Re: C and archtecture, C and Java, was Compilers :) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-29 19:37 -0800
Re: C and Java, was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-29 21:39 -0800
csiph-web