Re: [racket-users] whither `splicing-parameterize`? or am I doing it wrong?

[Alexis King]

Here is an implementation of a version of splicing-parameterize that
uses local-expand, a la other forms in racket/splicing:

#lang racket

(require (for-syntax syntax/kerncase)
 (for-meta 2 racket/base)
 syntax/parse/define)

(begin-for-syntax
  (define-syntax (syntax/loc/props stx)
(syntax-case stx ()
  [(_ src-expr template)
   #`(let ([src src-expr])
   (datum->syntax (quote-syntax #,stx)
  (syntax-e (syntax template))
  src
  src))])))

(define-syntax-parser splicing-parameterize
  [(_ ([{~var param (expr/c #'parameter?)} value:expr] ...)
  body ...)
   (if (eq? (syntax-local-context) 'expression)
   #'(parameterize ([param.c value] ...)
   body ...)
   #'(begin
   (define new-parameterization
 (parameterize ([param.c value] ...)
   (current-parameterization)))
   (do-splicing-parameterize new-parameterization body)
   ...))])

(define-syntax-parser do-splicing-parameterize
  [(_ parameterization:expr body:expr)
   (syntax-parse (local-expand #'body (syntax-local-context)
   (kernel-form-identifier-list))
 #:literal-sets [kernel-literals]
 [(begin new-body ...)
  (syntax/loc/props this-syntax
(begin
  (do-splicing-parameterize parameterization new-body)
  ...))]
 [(define-values ids rhs)
  (syntax/loc/props this-syntax
(define-values ids
  (call-with-parameterization parameterization
  (thunk rhs]
 [({~or begin-for-syntax define-syntaxes module module*
#%require #%provide #%declare}
   . _)
  this-syntax]
 [expr
  (syntax/loc/props this-syntax
(call-with-parameterization parameterization
(thunk expr)))])])

I have not extensively tested it, but it seems to work okay for simple
programs. For example, given the following program:

(define my-param (make-parameter #f))

(splicing-parameterize ([my-param #t])
  (my-param)
  (define x (my-param))
  (define (f) (my-param)))

x
(f)

...the output is:

#t
#t
#f

...which I believe makes sense, since the dynamic adjustment of my-param
does not affect its use within the internal definition of a procedure.

Additionally, mutating a parameter does the right thing, so this
program:

(splicing-parameterize ([my-param #t])
  (my-param 42)
  (my-param))

(my-param)

...produces:

42
#f

This seems like something that would make sense in racket/splicing,
though it’s different from the other forms, since they are all lexical
binding forms (even splicing-syntax-parameterize), whereas parameterize
is not.

Alexis

-- 
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] Path to file in dynamic-place

[Philip McGrath]

When the thing you want to refer to at runtime is specifically a module,
using define-runtime-module-path-index or
define-runtime-module-path (also from racket/runtime-path) may be even
better choice than define-runtime-path.

-Philip

On Tue, Jan 23, 2018 at 10:03 PM, Jack Firth  wrote:

> A rule of thumb you can follow to avoid tricky bugs like this: *never use
> string literals as dynamic module names.* Anywhere you see a dynamic /
> reflective function on modules called with a literal string, a
> contradiction exists between the programmer and the dynamic function:
>
> 1. The programmer intends to use a specific module referenced in the
> context of the program source code.
> 2. The dynamic function intends to operate on an arbitrary unknown module
> referenced in the context of the program execution environment.
>
> This is why define-runtime-path exists. It acts as a bridge between the
> two worlds of the module system used to compile a program source and the
> module system that compiled program interacts with at runtime. The two
> systems cannot be assumed identical because 1) a program may be compiled on
> one machine and executed on another and 2) modules only used at compilation
> time may be excluded from the compiled form of a program.
>
> The "place-worker.rkt" example in the places docs is somewhat misleading
> since it refers to the place-launching code as if it wasn't in a module
> (note that no file names are mentioned in the example other than
> "place-worker.rkt"). It would be clearer if it named the launcher code
> "place-launcher.rkt", clarified that "place-launcher.rkt" and
> "place-worker.rkt" must be in the same directory, and used
> (define-runtime-path worker-mod "place-worker.rkt") to refer to the worker
> module from the launcher module.
>
>
> --
> 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] Path to file in dynamic-place

[Jack Firth]

A rule of thumb you can follow to avoid tricky bugs like this: *never use 
string literals as dynamic module names.* Anywhere you see a dynamic / 
reflective function on modules called with a literal string, a 
contradiction exists between the programmer and the dynamic function:

1. The programmer intends to use a specific module referenced in the 
context of the program source code.
2. The dynamic function intends to operate on an arbitrary unknown module 
referenced in the context of the program execution environment.

This is why define-runtime-path exists. It acts as a bridge between the two 
worlds of the module system used to compile a program source and the module 
system that compiled program interacts with at runtime. The two systems 
cannot be assumed identical because 1) a program may be compiled on one 
machine and executed on another and 2) modules only used at compilation 
time may be excluded from the compiled form of a program.

The "place-worker.rkt" example in the places docs is somewhat misleading 
since it refers to the place-launching code as if it wasn't in a module 
(note that no file names are mentioned in the example other than 
"place-worker.rkt"). It would be clearer if it named the launcher code 
"place-launcher.rkt", clarified that "place-launcher.rkt" and 
"place-worker.rkt" must be in the same directory, and used 
(define-runtime-path worker-mod "place-worker.rkt") to refer to the worker 
module from the launcher module.


-- 
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] whither `splicing-parameterize`? or am I doing it wrong?

[Matthias Felleisen]

You want to head expand not just look at the raw words, because an expression 
can expand to (define-values (x …) …). You may wish to look at how modules, 
units, and classes are expanded — Matthias




> On Jan 23, 2018, at 8:15 PM, Matthew Butterick  wrote:
> 
> 
>> On Jan 22, 2018, at 7:22 PM, Matthew Flatt > > wrote:
>> 
>> I think I've never considered `splicing-parameterize` because
>> parameters can be mutated, but a `splicing-parameterize` form does make
>> sense. I imagine that it would be implemented by creating a
>> parameterization once, then pushing the parameterization over multiple
>> expressions using `call-with-parameterization`.
> 
> IIUC, to use `call-with-parameterization`, each expression needs to become 
> the body of a thunk. This works for expressions that return a value. But 
> forms like `define` and `require` can't be used as the body of a thunk. So 
> one has to specially pluck them out. The example below works, albeit 
> brutally. Is there a more elegant pattern for picking out identifiers that 
> cannot appear as the body of a thunk?
> 
>  
> ;;;
> 
> #lang racket/base
> (require racket/splicing
>  (for-syntax racket/base racket/syntax))
> 
> (define-syntax (splicing-parameterize stx)
>   (syntax-case stx ()
> [(_ ([PARAM VAL] ...) . BODY)
>  (with-syntax* ([PZATION (generate-temporary)]
> [NEW-BODY (map (λ (stx)
>  (syntax-case stx ()
>[(ID ARG0 . ARGS)
> (memq (syntax->datum #'ID) '(define 
> define-values)) ; ... and others
> #'(ID ARG0 
> (call-with-parameterization PZATION (λ () (begin . ARGS]
>[(ID . ARGS)
> (memq (syntax->datum #'ID) '(require 
> provide splicing-let)) ; ... and others
> #'(ID . ARGS)]
>[OTHER #'(call-with-parameterization 
> PZATION (λ () OTHER))])) (syntax->list #'BODY))])
>#'(splicing-let ([PZATION (parameterize ([PARAM VAL] ...) 
> (current-parameterization))]) . NEW-BODY))]))
> 
> (define my-param (make-parameter 0))
> 
> (splicing-parameterize ([my-param 42])
>(add1 (my-param))
>(sub1 (my-param))) ; prints 43 and 41 to repl
> 
> (splicing-parameterize ([my-param 42])
>(define x (my-param))
>(check-equal? x 42)
>(define-values (y z) (values (add1 (my-param)) (sub1 
> (my-param)
> 
> (splicing-parameterize ([my-param 42])
>(require rackunit))
> 
> (check-equal? x 42)
> (check-equal? y 43)
> (check-equal? z 41)
> 
> 
> 
> 
> 
> 
> -- 
> 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] whither `splicing-parameterize`? or am I doing it wrong?

[Matthew Flatt]

If you want `splicing-parameterize` to compose with other macros that
might implement definition forms, there's no fixed set of definition
forms.

The other splicing forms use `local-expand` to detect definition forms,
since the small set of core definition forms can be reliably detected
in expanded code. See `splicing-let-body` within the implementation of
`racket/splicing`.

At Tue, 23 Jan 2018 17:15:10 -0800, Matthew Butterick wrote:
> 
> > On Jan 22, 2018, at 7:22 PM, Matthew Flatt  wrote:
> > 
> > I think I've never considered `splicing-parameterize` because
> > parameters can be mutated, but a `splicing-parameterize` form does make
> > sense. I imagine that it would be implemented by creating a
> > parameterization once, then pushing the parameterization over multiple
> > expressions using `call-with-parameterization`.
> 
> IIUC, to use `call-with-parameterization`, each expression needs to become 
> the 
> body of a thunk. This works for expressions that return a value. But forms 
> like `define` and `require` can't be used as the body of a thunk. So one has 
> to specially pluck them out. The example below works, albeit brutally. Is 
> there a more elegant pattern for picking out identifiers that cannot appear 
> as 
> the body of a thunk?
> 
>  
> ;;;
> 
> #lang racket/base
> (require racket/splicing
>  (for-syntax racket/base racket/syntax))
> 
> (define-syntax (splicing-parameterize stx)
>   (syntax-case stx ()
> [(_ ([PARAM VAL] ...) . BODY)
>  (with-syntax* ([PZATION (generate-temporary)]
> [NEW-BODY (map (λ (stx)
>  (syntax-case stx ()
>[(ID ARG0 . ARGS)
> (memq (syntax->datum #'ID) '(define 
> define-values)) ; ... and others
> #'(ID ARG0 
> (call-with-parameterization 
> PZATION (λ () (begin . ARGS]
>[(ID . ARGS)
> (memq (syntax->datum #'ID) '(require 
> provide splicing-let)) ; ... and others
> #'(ID . ARGS)]
>[OTHER #'(call-with-parameterization 
> PZATION (λ () OTHER))])) (syntax->list #'BODY))])
>#'(splicing-let ([PZATION (parameterize ([PARAM VAL] ...) 
> (current-parameterization))]) . NEW-BODY))]))
> 
> (define my-param (make-parameter 0))
> 
> (splicing-parameterize ([my-param 42])
>(add1 (my-param))
>(sub1 (my-param))) ; prints 43 and 41 to repl
> 
> (splicing-parameterize ([my-param 42])
>(define x (my-param))
>(check-equal? x 42)
>(define-values (y z) (values (add1 (my-param)) (sub1 
> (my-param)
> 
> (splicing-parameterize ([my-param 42])
>(require rackunit))
> 
> (check-equal? x 42)
> (check-equal? y 43)
> (check-equal? z 41)

-- 
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] whither `splicing-parameterize`? or am I doing it wrong?

[Matthew Butterick]

> On Jan 22, 2018, at 7:22 PM, Matthew Flatt  wrote:
> 
> I think I've never considered `splicing-parameterize` because
> parameters can be mutated, but a `splicing-parameterize` form does make
> sense. I imagine that it would be implemented by creating a
> parameterization once, then pushing the parameterization over multiple
> expressions using `call-with-parameterization`.

IIUC, to use `call-with-parameterization`, each expression needs to become the 
body of a thunk. This works for expressions that return a value. But forms like 
`define` and `require` can't be used as the body of a thunk. So one has to 
specially pluck them out. The example below works, albeit brutally. Is there a 
more elegant pattern for picking out identifiers that cannot appear as the body 
of a thunk?

 
;;;

#lang racket/base
(require racket/splicing
 (for-syntax racket/base racket/syntax))

(define-syntax (splicing-parameterize stx)
  (syntax-case stx ()
[(_ ([PARAM VAL] ...) . BODY)
 (with-syntax* ([PZATION (generate-temporary)]
[NEW-BODY (map (λ (stx)
 (syntax-case stx ()
   [(ID ARG0 . ARGS)
(memq (syntax->datum #'ID) '(define 
define-values)) ; ... and others
#'(ID ARG0 (call-with-parameterization 
PZATION (λ () (begin . ARGS]
   [(ID . ARGS)
(memq (syntax->datum #'ID) '(require 
provide splicing-let)) ; ... and others
#'(ID . ARGS)]
   [OTHER #'(call-with-parameterization 
PZATION (λ () OTHER))])) (syntax->list #'BODY))])
   #'(splicing-let ([PZATION (parameterize ([PARAM VAL] ...) 
(current-parameterization))]) . NEW-BODY))]))

(define my-param (make-parameter 0))

(splicing-parameterize ([my-param 42])
   (add1 (my-param))
   (sub1 (my-param))) ; prints 43 and 41 to repl

(splicing-parameterize ([my-param 42])
   (define x (my-param))
   (check-equal? x 42)
   (define-values (y z) (values (add1 (my-param)) (sub1 
(my-param)

(splicing-parameterize ([my-param 42])
   (require rackunit))

(check-equal? x 42)
(check-equal? y 43)
(check-equal? z 41)





-- 
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] SIMPLE top-level binding semantics question

['John Clements' via Racket Users]

Many thanks.



> On Jan 23, 2018, at 1:56 PM, Matthew Flatt  wrote:
> 
> Sure, with whatever improvements you'd like to make.
> 
> At 23 Jan 2018 16:53:15 -0500, "John Clements" wrote:
>> Permission to paste this summary on Stack Exchange?
>> 
>> 
>>> On Jan 23, 2018, at 1:20 PM, Matthew Flatt  wrote:
>>> 
>>> At 23 Jan 2018 15:57:34 -0500, "'John Clements' via Racket Users" wrote:
 despite being inside of a binding of the name map
>>> 
>>> That's the essence of the problem. Which things are in the scope of a
>>> top-level definition?
>>> 
>>> For example, is the reference to `f` in the scope of a binding of `f`
>>> in
>>> 
>>> (define (g x) (f x))
>>> (define (f x) x)
>>> 
>>> ?
>>> 
>>> How about in
>>> 
>>> (begin
>>>   (define (g x) (f x))
>>>   (define (f x) x))
>>> 
>>> ? 
>>> 
>>> Or in 
>>> 
>>> (expand '(define (f x) x))
>>> (define (g x) (f x))
>>> 
>>> or
>>> 
>>> (begin
>>>  (expand '(define (f x) x))
>>>  (define (g x) (f x)))
>>> 
>>> ?
>>> 
>>> The rule in Racket is that a top-level `define` doesn't change the
>>> binding of an identifier until the `define` is evaluated. So, in
>>> 
>>> (define (map x) ... map ...)
>>> 
>>> the reference to `map` is expanded/compiled at a point where `map`
>>> refers to a module import, not a variable named `map`. By the time the
>>> definition is evaluated, it's too late to redirect the meaning of `map`
>>> as a reference to an import.
>>> 
>>> There are other choices, but I don't think there are going choices that
>>> end up being significantly better or more consistent. The top level is
>>> hopeless.
>>> 
>>> Modules behave significantly better, in part because the scope of a
>>> definition is clear: from the start of the module to the end.
>>> 
 When I try doing the same thing with a value defined in the empty program 
 (with the name’f’), I see the error 
 
 define-values: assignment disallowed;
 cannot re-define a constant
 constant: f
 
 Which leads me to the suspicion that maybe possibly this message is 
>> supposed 
 to be shown for the re-definition of ‘map’, as well?
>>> 
>>> The difference is that `f` starts out bound to the variable `f`, not to
>>> an `f` import. For various reasons, we have decided that definitions
>>> are allowed to shadow imports.
>>> 



-- 
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] SIMPLE top-level binding semantics question

['John Clements' via Racket Users]

> On Jan 23, 2018, at 1:03 PM, Matthias Felleisen  
> wrote:
> 
> 
> Huh? Serves you right for using the top level. It works fine if you place it 
> in the definitions window :-) 

Of course, and that’s what I told the poster on Stack Exchange. I was befuddled 
by the existing behavior, but I explicitly mentioned that the solution was not 
to use the top-level.

John

> 
>> Welcome to DrRacket, version 6.11.0.4--2017-12-18(-/f) [3m].
>> Language: racket, with debugging; memory limit: 256 MB.
>>> (map '() add1)
>> '()
>>> (map '(1) add1)
>> '(2)
>>> (map '(1 2) add1)
>> '(2 3)
>>> (map '(1 2 3) add1)
>> '(2 3 4)
>>> 
> 
> 
> — Matthias
> 
> 
> 
>> On Jan 23, 2018, at 3:57 PM, 'John Clements' via Racket Users 
>>  wrote:
>> 
>> Stack overflow today led me to something … very strange. I feel like I must 
>> be missing something crushingly obvious.
>> 
>> To reproduce: start racket at the command line or hit “run” on a definitions 
>> window containing only “#lang racket”.
>> 
>> Then, paste:
>> 
>> (define map (lambda (l f)
>>   (cond
>>   ((null? l) '())
>>   (else (cons (f (car l)) (map (cdr l) f)))
>>   )
>> ))
>> 
>> (Note that this version of map takes the function last.) Then, paste:
>> 
>> (map '(3 4 5) add1)
>> 
>> See this error:
>> 
>> map: contract violation
>> expected: procedure?
>> given: '(4 5)
>> argument position: 1st
>> other arguments…:
>> 
>> Note that the error occurs on the recursive call. This means that despite 
>> being inside of a binding of the name map, the function is using the 
>> built-in function.
>> 
>> When I try doing the same thing with a value defined in the empty program 
>> (with the name’f’), I see the error 
>> 
>> define-values: assignment disallowed;
>> cannot re-define a constant
>> constant: f
>> 
>> Which leads me to the suspicion that maybe possibly this message is supposed 
>> to be shown for the re-definition of ‘map’, as well?
>> 
>> Very confused,
>> 
>> John
>> 
>> 
>> 
>> 
>> 
>> -- 
>> 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] SIMPLE top-level binding semantics question

['John Clements' via Racket Users]

Permission to paste this summary on Stack Exchange?


> On Jan 23, 2018, at 1:20 PM, Matthew Flatt  wrote:
> 
> At 23 Jan 2018 15:57:34 -0500, "'John Clements' via Racket Users" wrote:
>> despite being inside of a binding of the name map
> 
> That's the essence of the problem. Which things are in the scope of a
> top-level definition?
> 
> For example, is the reference to `f` in the scope of a binding of `f`
> in
> 
>  (define (g x) (f x))
>  (define (f x) x)
> 
> ?
> 
> How about in
> 
>  (begin
>(define (g x) (f x))
>(define (f x) x))
> 
> ? 
> 
> Or in 
> 
> (expand '(define (f x) x))
> (define (g x) (f x))
> 
> or
> 
> (begin
>   (expand '(define (f x) x))
>   (define (g x) (f x)))
> 
> ?
> 
> The rule in Racket is that a top-level `define` doesn't change the
> binding of an identifier until the `define` is evaluated. So, in
> 
>  (define (map x) ... map ...)
> 
> the reference to `map` is expanded/compiled at a point where `map`
> refers to a module import, not a variable named `map`. By the time the
> definition is evaluated, it's too late to redirect the meaning of `map`
> as a reference to an import.
> 
> There are other choices, but I don't think there are going choices that
> end up being significantly better or more consistent. The top level is
> hopeless.
> 
> Modules behave significantly better, in part because the scope of a
> definition is clear: from the start of the module to the end.
> 
>> When I try doing the same thing with a value defined in the empty program 
>> (with the name’f’), I see the error 
>> 
>> define-values: assignment disallowed;
>> cannot re-define a constant
>>  constant: f
>> 
>> Which leads me to the suspicion that maybe possibly this message is supposed 
>> to be shown for the re-definition of ‘map’, as well?
> 
> The difference is that `f` starts out bound to the variable `f`, not to
> an `f` import. For various reasons, we have decided that definitions
> are allowed to shadow imports.
> 



-- 
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] SIMPLE top-level binding semantics question

[Matthew Flatt]

At 23 Jan 2018 15:57:34 -0500, "'John Clements' via Racket Users" wrote:
> despite being inside of a binding of the name map

That's the essence of the problem. Which things are in the scope of a
top-level definition?

For example, is the reference to `f` in the scope of a binding of `f`
in

  (define (g x) (f x))
  (define (f x) x)

?

How about in

  (begin
(define (g x) (f x))
(define (f x) x))

? 

Or in 

 (expand '(define (f x) x))
 (define (g x) (f x))

or

 (begin
   (expand '(define (f x) x))
   (define (g x) (f x)))

?

The rule in Racket is that a top-level `define` doesn't change the
binding of an identifier until the `define` is evaluated. So, in

  (define (map x) ... map ...)

the reference to `map` is expanded/compiled at a point where `map`
refers to a module import, not a variable named `map`. By the time the
definition is evaluated, it's too late to redirect the meaning of `map`
as a reference to an import.

There are other choices, but I don't think there are going choices that
end up being significantly better or more consistent. The top level is
hopeless.

Modules behave significantly better, in part because the scope of a
definition is clear: from the start of the module to the end.

> When I try doing the same thing with a value defined in the empty program 
> (with the name’f’), I see the error 
> 
> define-values: assignment disallowed;
>  cannot re-define a constant
>   constant: f
> 
> Which leads me to the suspicion that maybe possibly this message is supposed 
> to be shown for the re-definition of ‘map’, as well?

The difference is that `f` starts out bound to the variable `f`, not to
an `f` import. For various reasons, we have decided that definitions
are allowed to shadow imports.

-- 
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] SIMPLE top-level binding semantics question

[Matthias Felleisen]

Huh? Serves you right for using the top level. It works fine if you place it in 
the definitions window :-) 

> Welcome to DrRacket, version 6.11.0.4--2017-12-18(-/f) [3m].
> Language: racket, with debugging; memory limit: 256 MB.
> > (map '() add1)
> '()
> > (map '(1) add1)
> '(2)
> > (map '(1 2) add1)
> '(2 3)
> > (map '(1 2 3) add1)
> '(2 3 4)
> > 


— Matthias



> On Jan 23, 2018, at 3:57 PM, 'John Clements' via Racket Users 
>  wrote:
> 
> Stack overflow today led me to something … very strange. I feel like I must 
> be missing something crushingly obvious.
> 
> To reproduce: start racket at the command line or hit “run” on a definitions 
> window containing only “#lang racket”.
> 
> Then, paste:
> 
> (define map (lambda (l f)
>(cond
>((null? l) '())
>(else (cons (f (car l)) (map (cdr l) f)))
>)
> ))
> 
> (Note that this version of map takes the function last.) Then, paste:
> 
> (map '(3 4 5) add1)
> 
> See this error:
> 
> map: contract violation
>  expected: procedure?
>  given: '(4 5)
>  argument position: 1st
>  other arguments…:
> 
> Note that the error occurs on the recursive call. This means that despite 
> being inside of a binding of the name map, the function is using the built-in 
> function.
> 
> When I try doing the same thing with a value defined in the empty program 
> (with the name’f’), I see the error 
> 
> define-values: assignment disallowed;
> cannot re-define a constant
>  constant: f
> 
> Which leads me to the suspicion that maybe possibly this message is supposed 
> to be shown for the re-definition of ‘map’, as well?
> 
> Very confused,
> 
> John
> 
> 
> 
> 
> 
> -- 
> 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.

[racket-users] SIMPLE top-level binding semantics question

['John Clements' via Racket Users]

Stack overflow today led me to something … very strange. I feel like I must be 
missing something crushingly obvious.

To reproduce: start racket at the command line or hit “run” on a definitions 
window containing only “#lang racket”.

Then, paste:

(define map (lambda (l f)
(cond
((null? l) '())
(else (cons (f (car l)) (map (cdr l) f)))
)
))

(Note that this version of map takes the function last.) Then, paste:

(map '(3 4 5) add1)

See this error:

map: contract violation
  expected: procedure?
  given: '(4 5)
  argument position: 1st
  other arguments…:

Note that the error occurs on the recursive call. This means that despite being 
inside of a binding of the name map, the function is using the built-in 
function.

When I try doing the same thing with a value defined in the empty program (with 
the name’f’), I see the error 

define-values: assignment disallowed;
 cannot re-define a constant
  constant: f

Which leads me to the suspicion that maybe possibly this message is supposed to 
be shown for the re-definition of ‘map’, as well?

Very confused,

John





-- 
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: The Birth and Death of Units

[ben.rudgers]

To me, one of the redeeming qualities of units in Racket is that they make 
"the tent" bigger. Modules may usually be the right way in Racket, but the 
grace of Racket is that modules are not "The one true way" because the 
Racket community tends to eschew the OTW concept when it comes to computer 
languages (while tending to embrace it when it comes to teaching languages).

One way of putting it is that by linking Racket to ML, Units enrich the 
Racket ecosystem. Conceptually, Units provides an outbound pointer rather 
than an internal/self-referential one. Units provide greater diversity in 
the way I can think about programming and allow me to explore their 
abstractions within the Racket ecosystem in the same way Racklog does. If 
nothing else the Units documentation is good reading. Racket would be 
poorer without Units...but I don't have to maintain them.

Ben

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