Re: [racket-users] define fails at runtime, where let fails at compile time

[Philip McGrath]

I think it's fair to say that the Racket style guide is not as rigid as
some other style guides for some other languages: as it says itself in the
introduction, it "isn’t complete and it isn’t perfect" and is more a set of
"guidelines and best practices" than binding universal rules. I think it is
usually right (even about some things I didn't agree with the first time I
read it), but I have a number of personal quirks in my style, as do many
others whose code I've read. (For example, I think several of us experiment
with brackets or braces instead of parentheses to distinguish
`define-values` left-hand-sides from the form of `define` with a function
header.)

In terms of `define` specifically, I think using `let` or `let*` instead
when that is your intended semantics is justifiable under the style guide,
and I sometimes do so myself. Even the guide itself

gives a `let*` that "is not easily replaced with a series of defines." The
example it calls out as "bad" uses `let` for a single, simple local
definition, which I think is a much more clear-cut case of rightward drift
with no corresponding benefit.\

On Mon, Mar 11, 2019 at 1:17 PM Greg Hendershott 
wrote:

> As a new user, it's possible to have the intuition that `define` is
> just a way to avoid indentation -- that it "writes a `let` for you,
> from the point of the define to 'the end of the enclosing scope'".


That would be a reasonable intuition and arguably a nice semantics. I'm
curious about what new users actually do think—I expect it depends on what
language they come from. Off hand, I think `letrec` semantics is fairly
common for local definitions, and I think a lot of mainstream languages
don't make `let` or `let*` semantics available at all. (For a particularly
egregious example, in Python, IIUC, it isn't always possible to even
determine whether an identifier is bound or not until runtime.)

-Philip


On Mon, Mar 11, 2019 at 1:23 PM Brian Adkins  wrote:

> Yes, I hadn't really thought through the semantics of define (i.e. whether
> it had let or letrec semantics). So, in my case, since I want let
> semantics, I will use let. I'm happy to follow the Racket style guide when
> I get to the point of contributing code that is covered by it, but I think
> I will use let, when I want let semantics, for my own code.
>
> On Monday, March 11, 2019 at 1:17:47 PM UTC-4, Greg Hendershott wrote:
>>
>> To be fair:
>>
>> As a new user, it's possible to have the intuition that `define` is
>> just a way to avoid indentation -- that it "writes a `let` for you,
>> from the point of the define to 'the end of the enclosing scope'".
>>
>> And it's possible for that intuition to seem correct for a very long
>> time -- until you hit an example like Brian did. And then you need to
>> learn about `letrec`.
>>
>> (As a non-new user, 99.9% of the time that I use a local `define` I
>> actually wish it were "like `let`" not `letrec`, but I use it anyway
>> and try to be careful.)
>>
>>
>> On Mon, Mar 11, 2019 at 12:29 PM Matthias Felleisen
>>  wrote:
>> >
>> >
>> >
>> > > On Mar 11, 2019, at 11:21 AM, Brian Adkins 
>> wrote:
>> > >
>> > > I just discovered that define will fail at runtime, where let would
>> fail at compile time. Besides helping to keep the indentation level from
>> marching to the right "too much", what are the benefits of define over let?
>> > >
>> > > --- snip ---
>> > > #lang racket
>> > >
>> > > (define (f n) (+ n 1))
>> > >
>> > > (define (foo)
>> > >   (define b (f a))
>> > >   (define a 7)
>> > >
>> > >   b)
>> > >
>> > > (define (bar)
>> > >   (let ([b (f a)]
>> > > [a 7])
>> > >
>> > > b))
>> > > --- snip ---
>> >
>> >
>> >
>> > I think your characterization is a bit misleading here.
>> >
>> > In ‘bar’ ‘a’ is not bound, something that Racket (and DrRacket)
>> properly signal at compile time.
>> >
>> > In ‘foo’ ‘a’ *is* bound, because you’ve set up a mutually recursive
>> scope. But, when Racket evaluates (foo) it notices that ‘a’ is bound but
>> uninitialized, which is two different things.
>> >
>> > If you want to compare apples to apples, use a ‘letrec' instead of a
>> ‘let' in ‘bar'. Then you have (1) the same semantics and (2) the same
>> error.
>> >
>> > — Matthias
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "Racket Users" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to racket-users...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google 

Re: [racket-users] define fails at runtime, where let fails at compile time

[Brian Adkins]

On Monday, March 11, 2019 at 1:22:48 PM UTC-4, Matthias Felleisen wrote:
>
>
>
> > On Mar 11, 2019, at 1:18 PM, Brian Adkins  > wrote: 
> > 
> > I want let semantics, but I've been using define more because it's 
> preferred in the Racket style guide. I don't want the behavior of define 
> above, so using letrec to get a runtime error instead of compile time error 
> doesn't make sense. 
> > 
> > Oops - I should've used let* in my example. 
>
>
> That wouldn’t change a thing in your example. 


My only point was that when using let, it fails even when ordered 
correctly, but with let* it succeeds when ordered correctly.
 

> If you meant you want a let* semantics for sequences of define, I think 
> that’s a good idea. And as the author of the Style Guide, I wholeheartedly 
> agree with this desire. When I replace let-s with define-s, I have gotten 
> used to checking for identifier sequencing and such. But perhaps a newbie 
> shouldn’t have to think that way. 


I would argue that *nobody* should have to think that way when we can have 
the compiler do it for us :) Obviously, I'm happy with a dynamically typed 
language, as I've chosen Racket over OCaml & Haskell, but I'm still happy 
to delegate some things to the compiler. 


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] define fails at runtime, where let fails at compile time

[Brian Adkins]

Yes, I hadn't really thought through the semantics of define (i.e. whether 
it had let or letrec semantics). So, in my case, since I want let 
semantics, I will use let. I'm happy to follow the Racket style guide when 
I get to the point of contributing code that is covered by it, but I think 
I will use let, when I want let semantics, for my own code.

On Monday, March 11, 2019 at 1:17:47 PM UTC-4, Greg Hendershott wrote:
>
> To be fair: 
>
> As a new user, it's possible to have the intuition that `define` is 
> just a way to avoid indentation -- that it "writes a `let` for you, 
> from the point of the define to 'the end of the enclosing scope'". 
>
> And it's possible for that intuition to seem correct for a very long 
> time -- until you hit an example like Brian did. And then you need to 
> learn about `letrec`. 
>
> (As a non-new user, 99.9% of the time that I use a local `define` I 
> actually wish it were "like `let`" not `letrec`, but I use it anyway 
> and try to be careful.) 
>
>
> On Mon, Mar 11, 2019 at 12:29 PM Matthias Felleisen 
> > wrote: 
> > 
> > 
> > 
> > > On Mar 11, 2019, at 11:21 AM, Brian Adkins  > wrote: 
> > > 
> > > I just discovered that define will fail at runtime, where let would 
> fail at compile time. Besides helping to keep the indentation level from 
> marching to the right "too much", what are the benefits of define over let? 
> > > 
> > > --- snip --- 
> > > #lang racket 
> > > 
> > > (define (f n) (+ n 1)) 
> > > 
> > > (define (foo) 
> > >   (define b (f a)) 
> > >   (define a 7) 
> > > 
> > >   b) 
> > > 
> > > (define (bar) 
> > >   (let ([b (f a)] 
> > > [a 7]) 
> > > 
> > > b)) 
> > > --- snip --- 
> > 
> > 
> > 
> > I think your characterization is a bit misleading here. 
> > 
> > In ‘bar’ ‘a’ is not bound, something that Racket (and DrRacket) properly 
> signal at compile time. 
> > 
> > In ‘foo’ ‘a’ *is* bound, because you’ve set up a mutually recursive 
> scope. But, when Racket evaluates (foo) it notices that ‘a’ is bound but 
> uninitialized, which is two different things. 
> > 
> > If you want to compare apples to apples, use a ‘letrec' instead of a 
> ‘let' in ‘bar'. Then you have (1) the same semantics and (2) the same 
> error. 
> > 
> > — Matthias 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Racket Users" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to racket-users...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] define fails at runtime, where let fails at compile time

[Matthias Felleisen]

> On Mar 11, 2019, at 1:18 PM, Brian Adkins  wrote:
> 
> I want let semantics, but I've been using define more because it's preferred 
> in the Racket style guide. I don't want the behavior of define above, so 
> using letrec to get a runtime error instead of compile time error doesn't 
> make sense.
> 
> Oops - I should've used let* in my example. 


That wouldn’t change a thing in your example. 

If you meant you want a let* semantics for sequences of define, I think that’s 
a good idea. And as the author of the Style Guide, I wholeheartedly agree with 
this desire. When I replace let-s with define-s, I have gotten used to checking 
for identifier sequencing and such. But perhaps a newbie shouldn’t have to 
think that way. 

— Matthias




-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] define fails at runtime, where let fails at compile time

[Brian Adkins]

On Monday, March 11, 2019 at 1:13:30 PM UTC-4, Brian Adkins wrote:
>
>
>
> On Monday, March 11, 2019 at 12:29:40 PM UTC-4, Matthias Felleisen wrote:
>>
>>
>>
>> > On Mar 11, 2019, at 11:21 AM, Brian Adkins  wrote: 
>> > 
>> > I just discovered that define will fail at runtime, where let would 
>> fail at compile time. Besides helping to keep the indentation level from 
>> marching to the right "too much", what are the benefits of define over let? 
>> > 
>> > --- snip --- 
>> > #lang racket 
>> > 
>> > (define (f n) (+ n 1)) 
>> > 
>> > (define (foo) 
>> >   (define b (f a)) 
>> >   (define a 7) 
>> >   
>> >   b) 
>> > 
>> > (define (bar) 
>> >   (let ([b (f a)] 
>> > [a 7]) 
>> > 
>> > b)) 
>> > --- snip --- 
>>
>>
>>
>> I think your characterization is a bit misleading here. 
>>
>> In ‘bar’ ‘a’ is not bound, something that Racket (and DrRacket) properly 
>> signal at compile time. 
>>
>> In ‘foo’ ‘a’ *is* bound, because you’ve set up a mutually recursive 
>> scope. But, when Racket evaluates (foo) it notices that ‘a’ is bound but 
>> uninitialized, which is two different things. 
>>
>> If you want to compare apples to apples, use a ‘letrec' instead of a 
>> ‘let' in ‘bar'. Then you have (1) the same semantics and (2) the same 
>> error. 
>>
>> — Matthias 
>>
>>
> I want let semantics, but I've been using define more because it's 
> preferred in the Racket style guide. I don't want the behavior of define 
> above, so using letrec to get a runtime error instead of compile time error 
> doesn't make sense.
>

Oops - I should've used let* in my example. 

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] define fails at runtime, where let fails at compile time

[Greg Hendershott]

To be fair:

As a new user, it's possible to have the intuition that `define` is
just a way to avoid indentation -- that it "writes a `let` for you,
from the point of the define to 'the end of the enclosing scope'".

And it's possible for that intuition to seem correct for a very long
time -- until you hit an example like Brian did. And then you need to
learn about `letrec`.

(As a non-new user, 99.9% of the time that I use a local `define` I
actually wish it were "like `let`" not `letrec`, but I use it anyway
and try to be careful.)


On Mon, Mar 11, 2019 at 12:29 PM Matthias Felleisen
 wrote:
>
>
>
> > On Mar 11, 2019, at 11:21 AM, Brian Adkins  wrote:
> >
> > I just discovered that define will fail at runtime, where let would fail at 
> > compile time. Besides helping to keep the indentation level from marching 
> > to the right "too much", what are the benefits of define over let?
> >
> > --- snip ---
> > #lang racket
> >
> > (define (f n) (+ n 1))
> >
> > (define (foo)
> >   (define b (f a))
> >   (define a 7)
> >
> >   b)
> >
> > (define (bar)
> >   (let ([b (f a)]
> > [a 7])
> >
> > b))
> > --- snip ---
>
>
>
> I think your characterization is a bit misleading here.
>
> In ‘bar’ ‘a’ is not bound, something that Racket (and DrRacket) properly 
> signal at compile time.
>
> In ‘foo’ ‘a’ *is* bound, because you’ve set up a mutually recursive scope. 
> But, when Racket evaluates (foo) it notices that ‘a’ is bound but 
> uninitialized, which is two different things.
>
> If you want to compare apples to apples, use a ‘letrec' instead of a ‘let' in 
> ‘bar'. Then you have (1) the same semantics and (2) the same error.
>
> — Matthias
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] define fails at runtime, where let fails at compile time

[Brian Adkins]

On Monday, March 11, 2019 at 12:29:40 PM UTC-4, Matthias Felleisen wrote:
>
>
>
> > On Mar 11, 2019, at 11:21 AM, Brian Adkins  > wrote: 
> > 
> > I just discovered that define will fail at runtime, where let would fail 
> at compile time. Besides helping to keep the indentation level from 
> marching to the right "too much", what are the benefits of define over let? 
> > 
> > --- snip --- 
> > #lang racket 
> > 
> > (define (f n) (+ n 1)) 
> > 
> > (define (foo) 
> >   (define b (f a)) 
> >   (define a 7) 
> >   
> >   b) 
> > 
> > (define (bar) 
> >   (let ([b (f a)] 
> > [a 7]) 
> > 
> > b)) 
> > --- snip --- 
>
>
>
> I think your characterization is a bit misleading here. 
>
> In ‘bar’ ‘a’ is not bound, something that Racket (and DrRacket) properly 
> signal at compile time. 
>
> In ‘foo’ ‘a’ *is* bound, because you’ve set up a mutually recursive scope. 
> But, when Racket evaluates (foo) it notices that ‘a’ is bound but 
> uninitialized, which is two different things. 
>
> If you want to compare apples to apples, use a ‘letrec' instead of a ‘let' 
> in ‘bar'. Then you have (1) the same semantics and (2) the same error. 
>
> — Matthias 
>
>
I want let semantics, but I've been using define more because it's 
preferred in the Racket style guide. I don't want the behavior of define 
above, so using letrec to get a runtime error instead of compile time error 
doesn't make sense.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] define fails at runtime, where let fails at compile time

[Matthias Felleisen]

> On Mar 11, 2019, at 11:21 AM, Brian Adkins  wrote:
> 
> I just discovered that define will fail at runtime, where let would fail at 
> compile time. Besides helping to keep the indentation level from marching to 
> the right "too much", what are the benefits of define over let?
> 
> --- snip ---
> #lang racket
> 
> (define (f n) (+ n 1))
> 
> (define (foo)
>   (define b (f a))
>   (define a 7)
>   
>   b)
> 
> (define (bar)
>   (let ([b (f a)]
> [a 7])
> 
> b))
> --- snip ---



I think your characterization is a bit misleading here. 

In ‘bar’ ‘a’ is not bound, something that Racket (and DrRacket) properly signal 
at compile time. 

In ‘foo’ ‘a’ *is* bound, because you’ve set up a mutually recursive scope. But, 
when Racket evaluates (foo) it notices that ‘a’ is bound but uninitialized, 
which is two different things. 

If you want to compare apples to apples, use a ‘letrec' instead of a ‘let' in 
‘bar'. Then you have (1) the same semantics and (2) the same error. 

— Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] define fails at runtime, where let fails at compile time

[Brian Adkins]

I just discovered that define will fail at runtime, where let would fail at 
compile time. Besides helping to keep the indentation level from marching 
to the right "too much", what are the benefits of define over let?

--- snip ---
#lang racket

(define (f n) (+ n 1))

(define (foo)
  (define b (f a))
  (define a 7)
  
  b)

(define (bar)
  (let ([b (f a)]
[a 7])

b))
--- snip ---

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.