Re: [racket-users] Re: What is the best way to "raco make" all *.rkt files in a directory tree?

2019-03-11 Thread Ben Greenman
On 3/11/19, 'John Clements' via Racket Users
 wrote:
> I would suggest maybe just using racket here:
>
> #lang racket
>
> (require setup/parallel-build)
>
> (define racket-files
>   (for/list ([file (in-directory "/tmp")]
>  #:when (regexp-match #px"\\.rkt$" file))
> file))
>
> (parallel-compile-files racket-files
> #:worker-count 8)

Racket 6.7 and later has a globbing library. Now you can write:

(require file/glob)
(define racket-files
  (glob "/tmp/***.rkt"))


... but since this is not what you'd write in most (all?) shells,
maybe the library should treat "/**/" instead of "**" specially.

-- 
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] Re: What is the best way to "raco make" all *.rkt files in a directory tree?

2019-03-11 Thread Alex Harsanyi
To add one more answer to this thread :-)

In addition to compiling files specified on the command line, `raco make` 
will recursively compile all files referenced via `require`.  This means 
that if you have a top level file for your application, you can tell `raco 
make` to compile that file, and it will compile all the files that it 
references, the will be compiled only if they have changed.  There is also 
a `-j` option which allows compiling in parallel.  So, for example, if the 
toplevel file in your application is main.rkt you can do:

raco make -j 8 main.rkt

and all your project files will be updated.

Alex.

On Tuesday, March 12, 2019 at 3:00:34 AM UTC+8, Brian Adkins wrote:
>
> I looked over the documentation for raco make, and I didn't see anything 
> about how to recursively make all *.rkt files in a directory tree. I 
> suppose I could use something like:  find . -name \*.rkt | xargs raco make, 
> but I like being able to use all 8 "cores" with -j 8, and I *think* I'd 
> lose that with xargs.
>
> What is the best practice for making a tree of Racket code?
>
> Thanks,
> Brian
>

-- 
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] What is the best way to "raco make" all *.rkt files in a directory tree?

2019-03-11 Thread Greg Hendershott
I think the best practice (at least my usual practice these days) is
to make a package.

Say the top of your tree is /path/to/project.

Once:

  raco pkg install /path/to/project

Thereafter your "make" is:

  raco setup --pkgs project


This also works fine for c:\path\to\project.

(Making it a local package like this doesn't mean you must publish it
to pkgs.r-l.org.)

On Mon, Mar 11, 2019 at 3:00 PM Brian Adkins  wrote:
>
> I looked over the documentation for raco make, and I didn't see anything 
> about how to recursively make all *.rkt files in a directory tree. I suppose 
> I could use something like:  find . -name \*.rkt | xargs raco make, but I 
> like being able to use all 8 "cores" with -j 8, and I *think* I'd lose that 
> with xargs.
>
> What is the best practice for making a tree of Racket code?
>
> Thanks,
> Brian
>
> --
> 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] Re: What is the best way to "raco make" all *.rkt files in a directory tree?

2019-03-11 Thread 'John Clements' via Racket Users
I would suggest maybe just using racket here:

#lang racket

(require setup/parallel-build)

(define racket-files
  (for/list ([file (in-directory "/tmp")]
 #:when (regexp-match #px"\\.rkt$" file))
file))

(parallel-compile-files racket-files
#:worker-count 8)


Naturally, you could also use (current-directory) rather than “/tmp”, or 
whatever makes sense for you. You could even bundle it up as a raco command, if 
you liked.

John


> On Mar 11, 2019, at 1:02 PM, Eric Griffis  wrote:
> 
> On Mon, Mar 11, 2019 at 12:04 PM Brian Adkins  wrote:
>> 
>> Hmm...  maybe the problem was just my lack of shell skills. I think the 
>> following works:
>> 
>> raco make -j 8 */*.rkt
> 
> This will only make the rkt files in subdirectories of the current
> working directory, excluding sub-subdirectories and the current
> working directory.
> 
> You can get them all with "find":
> 
> find . -name \*.rkt -exec raco make -j 8 {} \;
> 
> But this will run a separate "raco make" for each file, which may
> defeat the purpose of your "-j 8" switch. If your shell supports the
> "globstar" (**) in file paths (e.g. bash, zsh, maybe ksh):
> 
> raco make -j 8 *.rkt **/*.rkt
> 
> Otherwise, there's always xargs:
> 
> find . -name \*.rkt -print0 | xargs -0 -- raco make -j 8
> 
> FWIW, when my projects need "make"-ing, I turn them into packages and
> install them. The installation process will "make" every rkt file in
> the project folder, and the whole thing can be rebuilt with raco
> setup:
> 
> raco setup -D 
> 
> Eric
> 
> -- 
> 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] Re: What is the best way to "raco make" all *.rkt files in a directory tree?

2019-03-11 Thread Eric Griffis
On Mon, Mar 11, 2019 at 12:04 PM Brian Adkins  wrote:
>
> Hmm...  maybe the problem was just my lack of shell skills. I think the 
> following works:
>
> raco make -j 8 */*.rkt

This will only make the rkt files in subdirectories of the current
working directory, excluding sub-subdirectories and the current
working directory.

You can get them all with "find":

find . -name \*.rkt -exec raco make -j 8 {} \;

But this will run a separate "raco make" for each file, which may
defeat the purpose of your "-j 8" switch. If your shell supports the
"globstar" (**) in file paths (e.g. bash, zsh, maybe ksh):

raco make -j 8 *.rkt **/*.rkt

Otherwise, there's always xargs:

find . -name \*.rkt -print0 | xargs -0 -- raco make -j 8

FWIW, when my projects need "make"-ing, I turn them into packages and
install them. The installation process will "make" every rkt file in
the project folder, and the whole thing can be rebuilt with raco
setup:

raco setup -D 

Eric

-- 
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] What is the best way to "raco make" all *.rkt files in a directory tree?

2019-03-11 Thread George Neuner



On 3/11/2019 3:00 PM, Brian Adkins wrote:
I looked over the documentation for raco make, and I didn't see 
anything about how to recursively make all *.rkt files in a directory 
tree. I suppose I could use something like:  find . -name \*.rkt | 
xargs raco make, but I like being able to use all 8 "cores" with -j 8, 
and I *think* I'd lose that with xargs.


What is the best practice for making a tree of Racket code?


I'm not a 'find' wizard, so I'm not sure the options / command to use 
... but rather than dealing with individual files, I think what you want 
to do is find the *directories* that contain the racket files and invoke 
'raco make -j 8 *.rkt' in those directories.


YMMV,
George

--
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] Re: What is the best way to "raco make" all *.rkt files in a directory tree?

2019-03-11 Thread Brian Adkins
On Monday, March 11, 2019 at 3:00:34 PM UTC-4, Brian Adkins wrote:
>
> I looked over the documentation for raco make, and I didn't see anything 
> about how to recursively make all *.rkt files in a directory tree. I 
> suppose I could use something like:  find . -name \*.rkt | xargs raco make, 
> but I like being able to use all 8 "cores" with -j 8, and I *think* I'd 
> lose that with xargs.
>
> What is the best practice for making a tree of Racket code?
>
> Thanks,
> Brian
>

Hmm...  maybe the problem was just my lack of shell skills. I think the 
following works:

raco make -j 8 */*.rkt 

-- 
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] What is the best way to "raco make" all *.rkt files in a directory tree?

2019-03-11 Thread Brian Adkins
I looked over the documentation for raco make, and I didn't see anything 
about how to recursively make all *.rkt files in a directory tree. I 
suppose I could use something like:  find . -name \*.rkt | xargs raco make, 
but I like being able to use all 8 "cores" with -j 8, and I *think* I'd 
lose that with xargs.

What is the best practice for making a tree of Racket code?

Thanks,
Brian

-- 
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

2019-03-11 Thread 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

2019-03-11 Thread 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.


[racket-users] Avoiding tail-indentation

2019-03-11 Thread Hendrik Boom
On Mon, Mar 11, 2019 at 01:17:08PM -0400, 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'".

Racket needs a way to avoid trouble with tail-indentation, just as it 
avoids trouble with tail-recursion.

Years ago I used a lisp that used / to indicate a final sublist:
(a a a
/bbb bbb bbb
/def
)
meant the same as 
(a a a
  (bbb bbb bbb
(def
)))
It was very convenient and allowed let and if to nest gracefully.

Are there any spcial characters or the like left in Racket that could 
be used for this purpose?

-- hendrik

-- 
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

2019-03-11 Thread 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

2019-03-11 Thread 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

2019-03-11 Thread 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

2019-03-11 Thread 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

2019-03-11 Thread 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

2019-03-11 Thread 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.


Re: [racket-users] Help with evaluation of examples in Scribble

2019-03-11 Thread Ryan Culpepper

On 3/10/19 4:16 PM, Matt Jadud wrote:

Oh! Thank you, Matthew.

I see. So, I'm running into the sandbox... as in, the sandbox is doing 
what it should, and as a result, it is preventing the networked accesses 
that I've added to my documentation. That's awfully obvious (now that it 
is put that way), but it wasn't obvious from the error message.


I'll think about faking it for doc build. I'll add it to the issue 
tracker for the package. I'm still learning basic things about 
scribbling docs, but will likely stub something in to simplify the doc 
build at some point. Thanks, Robby.


You might find `make-log-based-eval` useful for writing your examples. 
It lets you run the examples once (for example, on your development 
machine where your credentials are installed, etc) and save the results, 
so other people can build the docs using the recorded interactions.


For example, it's used by the db library documentation; see config.rkt 
(defines `make-pg-eval` using `make-log-based-eval`) and using-db.scrbl 
(uses `make-pg-eval`, `interaction`, and `eval:alts`) in 
https://github.com/racket/db/blob/master/db-doc/db/scribblings/.


Ryan

--
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

2019-03-11 Thread 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.


Re: [racket-users] How to fix typos in documentation?

2019-03-11 Thread Gustavo Massaccesi
I just want to clarify that if someone finds an error in the docs or a bug,
it's perfectly fine to just send a bug report:

* Inside Racket: Go to the menu > About > Submit Bug Report ...

* In Github: Submit an "Issue"

Please include enough information to reproduce the bug. For example for a
typo in the docs, I like a link to the online page of the documentation
where the typo was found, so it's completely obvious where the error is.

Someone will read the report, and make the correction. (It may take a few
month, until the next release, for the change to be visible in the online
docs.) After fixing the error, I like to reply with a link the commit that
fix the error. You can read the commit and try to understand which file was
modified, and perhaps next time send a pull request with the fix.

In the long run, it's better if you can send a pull request as discussed in
the previous messages, but every bug report with enough information is very
useful.

Gustavo

-- 
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.