begin vs lambda in ieee std 
Author Message
 begin vs lambda in ieee std

The IEEE Standard says that
(begin
 def1
 def2
...
)
Is equivalent to the set of definitions that form the body of the begin.  It
also says that begin (when it doesn't contain any definitions) can be thought
of as being implemented like

(begin com1 com2 ... expr)
=
(lambda () com1 com2 ... expr)

All of which has left me a little confused about what begin really does.  It
seems to me that the lambda form is misleading since it packages up the
environment, which would mean if definitions were included that they would
be local to the com1, com2, ... expr.  

My interpretation, then, is that begin is strictly a sequencing primitive
that does not close its arguments.  Is it included in the section on defini-
tions because definitions are inherently unsequenced (although I don't recall
those words anywhere but from SICP).  And if we write code that relies on the
order of definitions that we need to enclose a begin around it to be portable?

i.e instead of

(define one 1)
(define two (+ 1 one))
(define three (+ two 1))

I should write

(begin
  (define one 1)
  (define two (+ 1 one))
  (define three (+ two 1))
)

to achieve my intended affect.  Or, does the lack of sequencing only apply
to subdefinitions?

David Leasure



Sat, 08 Oct 1994 17:43:55 GMT  
 begin vs lambda in ieee std

Quote:

>The IEEE Standard says that
> ... begin (when it doesn't contain any definitions) can be thought
>of as being implemented like
>(begin com1 com2 ... expr)
>=
>(lambda () com1 com2 ... expr)

Actually it says -- note the application --
  (begin com1 com2 ... expr)
=>
  ( (lambda () com1 com2 ... expr) )

Quote:
>All of which has left me a little confused about what begin really does.  It
>seems to me that the lambda form is misleading since it packages up the
>environment, which would mean if definitions were included that they would
>be local to the com1, com2, ... expr.  

As the above explicitly forbids definitions, just how would definitions be
included?  I.e. no environmental capture takes place; sequencing *is* the
effect.

Quote:
>My interpretation, then, is that begin is strictly a sequencing primitive
>that does not close its arguments.

As BEGIN is a special-form, not an application, it has no "arguments".
Your basic intuition is correct.

Quote:
>  Is it included in the section on defini-
>tions because definitions are inherently unsequenced (although I don't recall
>those words anywhere but from SICP).  And if we write code that relies on the
>order of definitions that we need to enclose a begin around it to be portable?

Top-level definitions (those that side-effect a top-level environment)
are executed sequentially.  Internal definitions are syntactic sugar
for LETREC, so are not determinately sequenced--even if you wrap a
BEGIN around them.  See section 5.2.1.

This has been a source of confusion for some time to most people
learning Scheme.  Some people prefer to use LETREC directly and never
use internal defines.  Most people seem to be bitten once, say "oh!",
and are then inoculated against further infection.  Like many things,
once you know what is going on it is not a big thing, but until you do
it's a bear.




Sun, 09 Oct 1994 06:03:54 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. IEEE Standard Subroutines for CAMAC (ANSI/IEEE Std 758-1979)

2. (lambda ()) vs #'(lambda ())

3. Std:Cut, Std:Copy, Std:Paste - Don't work at all

4. Std:Copy, Std:Paste, Std:cut problems

5. $monitor and IEEE Std 1364

6. Precedence and associativity - ill-defined in IEEE std?

7. IEEE Std 1076.3-1996

8. IEEE std. VHDL compiler

9. IEEE Std. 754-1985

10. IEEE Std.754-1985

11. IEEE std constants package, in Ada forthcoming

12. IEEE to Mil Std 1750A Floating Point conversion

 

 
Powered by phpBB® Forum Software