Re: [racket-users] Re: questions about top-level-bind-scope in root-expand-context
Oops, I'm afraid things are getting off topic. Just to clarify, my question is really as the title states, about top-level-bind-scope, which is used by the expander to achieve certain effects when expanding define-values/define-syntaxes forms at the top level. I'm mainly trying to get a better understanding of those effects, and whether top-level-bind-scope is necessary to implement them. On Mon, Mar 23, 2020 at 8:11 PM Hendrik Boom wrote: > On Mon, Mar 23, 2020 at 05:55:14PM -0400, George Neuner wrote: > > On Mon, 23 Mar 2020 16:57:26 -0400, Hendrik Boom > > wrote: > > > > >On Mon, Mar 23, 2020 at 02:46:53PM -0400, George Neuner wrote: > > >> On Mon, 23 Mar 2020 01:45:40 -0700 (PDT), Yongming Shen > > >> wrote: > > >> > > >> >I have the following as `module-that-defines-fib`: > > >> > > > >> > #lang racket > > >> > (provide fib) > > >> > (define fib "fib") > > >> > > > >> >And this is the error that I got (using Racket 7.6): > > >> > > > >> > ; application: not a procedure; > > >> > ; expected a procedure that can be applied to arguments > > >> > ; given: "fib" > > >> > ; [,bt for context] > > >> > > >> > > >> I've run into this problem before ... I don't recall the official > > >> explanation, but my takeaway was that Racket does not permit you to > > >> directly *export* a value - you have to export a function or macro > > >> that produces the value. > > > > > >That seems like an extremely arbitrary restriction. > > > > Well, Racket considers exported objects to immutable. You can export > > a simple value (e.g., "foo" or 42) but it can only be used as a > > constant. If what you need is a module variable then the only way to > > expose it is via an access function. > > That makes sense. > > Or I suppose you could build a one-element mtable array and export that. > The you still can't change the variable, but can change teh value inside > it. > > -- hendrik > > > > AFAIHS, the OP has not shown us the code which uses the provided > > object, so we really don't know what it was trying to do when the > > error occurred. > > > > 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. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/p9bi7fpigiqm3tc3togm4vmontlv5v70ti%404ax.com > . > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Racket Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/racket-users/7Y-a1r9oRPI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/20200324001128.u5rp6pw677lbhleg%40topoi.pooq.com > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAAFrGrSRHzqvZuX6QOYdYPrB54i%3D%3DOQzBGja8qXeaTNUfB9Syg%40mail.gmail.com.
Re: [racket-users] Re: questions about top-level-bind-scope in root-expand-context
On Mon, Mar 23, 2020 at 05:55:14PM -0400, George Neuner wrote: > On Mon, 23 Mar 2020 16:57:26 -0400, Hendrik Boom > wrote: > > >On Mon, Mar 23, 2020 at 02:46:53PM -0400, George Neuner wrote: > >> On Mon, 23 Mar 2020 01:45:40 -0700 (PDT), Yongming Shen > >> wrote: > >> > >> >I have the following as `module-that-defines-fib`: > >> > > >> > #lang racket > >> > (provide fib) > >> > (define fib "fib") > >> > > >> >And this is the error that I got (using Racket 7.6): > >> > > >> > ; application: not a procedure; > >> > ; expected a procedure that can be applied to arguments > >> > ; given: "fib" > >> > ; [,bt for context] > >> > >> > >> I've run into this problem before ... I don't recall the official > >> explanation, but my takeaway was that Racket does not permit you to > >> directly *export* a value - you have to export a function or macro > >> that produces the value. > > > >That seems like an extremely arbitrary restriction. > > Well, Racket considers exported objects to immutable. You can export > a simple value (e.g., "foo" or 42) but it can only be used as a > constant. If what you need is a module variable then the only way to > expose it is via an access function. That makes sense. Or I suppose you could build a one-element mtable array and export that. The you still can't change the variable, but can change teh value inside it. -- hendrik > > AFAIHS, the OP has not shown us the code which uses the provided > object, so we really don't know what it was trying to do when the > error occurred. > > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/p9bi7fpigiqm3tc3togm4vmontlv5v70ti%404ax.com. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20200324001128.u5rp6pw677lbhleg%40topoi.pooq.com.
Re: [racket-users] questions about top-level-bind-scope in root-expand-context
> On Mar 23, 2020, at 13:46, George Neuner wrote: > > I've run into this problem before ... I don't recall the official > explanation, but my takeaway was that Racket does not permit you to > directly *export* a value - you have to export a function or macro > that produces the value. > > E.g., > #lang racket > (provide fib) > (define (fib) "fib") I’m not sure what issue you may have run into in the past, but Racket certainly has no issue with exporting a value. (After all, functions are values.) The issue described in this thread is (a) entirely syntactic (it’s an issue of binding/scoping, not runtime behavior), and (b) only occurs at the top-level (i.e. in the REPL, outside of a module). Matthew has already provided a detailed explanation of why the issue occurs. It’s true that you cannot set! imported bindings, but that’s quite separate from the problem discussed in this thread (which appears to be resolved). -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/DB94641E-A018-4A1D-BEE3-47DD183D7B54%40gmail.com.
[racket-users] Re: questions about top-level-bind-scope in root-expand-context
On Mon, 23 Mar 2020 16:57:26 -0400, Hendrik Boom wrote: >On Mon, Mar 23, 2020 at 02:46:53PM -0400, George Neuner wrote: >> On Mon, 23 Mar 2020 01:45:40 -0700 (PDT), Yongming Shen >> wrote: >> >> >I have the following as `module-that-defines-fib`: >> > >> > #lang racket >> > (provide fib) >> > (define fib "fib") >> > >> >And this is the error that I got (using Racket 7.6): >> > >> > ; application: not a procedure; >> > ; expected a procedure that can be applied to arguments >> > ; given: "fib" >> > ; [,bt for context] >> >> >> I've run into this problem before ... I don't recall the official >> explanation, but my takeaway was that Racket does not permit you to >> directly *export* a value - you have to export a function or macro >> that produces the value. > >That seems like an extremely arbitrary restriction. Well, Racket considers exported objects to immutable. You can export a simple value (e.g., "foo" or 42) but it can only be used as a constant. If what you need is a module variable then the only way to expose it is via an access function. AFAIHS, the OP has not shown us the code which uses the provided object, so we really don't know what it was trying to do when the error occurred. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/p9bi7fpigiqm3tc3togm4vmontlv5v70ti%404ax.com.
Re: [racket-users] Gradual Typed Racket?
On Mon, Mar 23, 2020 at 12:16:45PM -0400, Ben Greenman wrote: > > Not sure about best practices, but I definitely prefer keeping typed > and untyped code in separate modules. It can be veru useful to be able to mix them while in transition from one to the other. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20200323205915.v6tj5zkzm5qmuyvu%40topoi.pooq.com.
Re: [racket-users] Re: questions about top-level-bind-scope in root-expand-context
On Mon, Mar 23, 2020 at 02:46:53PM -0400, George Neuner wrote: > On Mon, 23 Mar 2020 01:45:40 -0700 (PDT), Yongming Shen > wrote: > > >Hi Matthew, > > > >Thank you for the quick reply! > > > >I tried the example you gave for my first question and it resulted in an > >error. > >I have the following as `module-that-defines-fib`: > > > > #lang racket > > (provide fib) > > (define fib "fib") > > > >And this is the error that I got (using Racket 7.6): > > > > ; application: not a procedure; > > ; expected a procedure that can be applied to arguments > > ; given: "fib" > > ; [,bt for context] > > > I've run into this problem before ... I don't recall the official > explanation, but my takeaway was that Racket does not permit you to > directly *export* a value - you have to export a function or macro > that produces the value. That seems like an extremely arbitrary restriction. > > E.g., > #lang racket > (provide fib) > (define (fib) "fib") > > > >I think this is because `(define-values (x) ...)` expands `...` without the > >top-level-bind-scope, even when expand-context-to-parsed? is #t (according > >to expander/expand/top.rkt). Is this a bug? > >Related to your answer to my second question, `define-syntaxes` similarly > >does not add the top-level-bind-scope when expanding `...`. Does this mean > >that even for `define-syntaxes`, `...` won't use the top-level-bind-scope > >binding(s) after all? > > > >A little bit off-topic, in the definition of define-values (in > >expander/expand/top.rkt), there is `(define-match m s ...)`, but for > >define-syntaxes it is `(define-match m disarmed-s ...)`. Is this difference > >significant? Or does define-match not care whether `s` or `disarmed-s` is > >used? > > I don't know the internals so I can't evaluate your theory. > > > >Thanks, > >Yongming > > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/2l0i7flr0to9msl6sg165vptiec0qq26l7%404ax.com. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20200323205726.ccibywrggjxqticl%40topoi.pooq.com.
Re: [racket-users] Contracts on parameters
Thanks, that was exactly it. On Mon, Mar 23, 2020 at 3:51 PM Michael MacLeod wrote: > > I think you are looking for parameter/c. See > https://docs.racket-lang.org/reference/data-structure-contracts.html?q=parameterof#%28def._%28%28lib._racket%2Fcontract%2Fprivate%2Fmisc..rkt%29._parameter%2Fc%29%29 > for more information. > > Best, > Michael > > On Mon, Mar 23, 2020, 12:36 PM David Storrs wrote: >> >> (define/contract (foo x) >> (-> boolean? any) >> 'ok) >> >> (foo #t) >> 'ok >> (foo 7) >> ; foo: contract violation >> ; expected: boolean? >> ; given: 7 >> ; in: the 1st argument of >> ; (-> boolean? any) >> ; contract from: (function foo) >> ; blaming: top-level >> ;(assuming the contract is correct) >> ; at: readline-input:4.18 >> ; [,bt for context] >> >> Yup, all good. >> >> >> (define/contract foo (make-parameter #f) boolean?) >> (foo #t) >> (foo) >> #t >> (foo 7) >> #f >> >> >> This isn't what I expected. What am I missing? >> >> -- >> 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. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-users/CAE8gKocV-TC1U6g5sq7C%2BZAjSVqDc%2B4yZWobr245qx4fZ9%2Bi3w%40mail.gmail.com. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAE8gKodRytXdXTEb72RBFJ1jCiJDmHjCtgjCE6vmSZi74tQiVw%40mail.gmail.com.
Re: [racket-users] Contracts on parameters
AFK, but it looks like the contract and function on your define/contract are swapped. Maybe the contract check on the one-arg call sets the parameter and then hilarity ensues? Eric On Mon, Mar 23, 2020, 12:36 PM David Storrs wrote: > (define/contract (foo x) > (-> boolean? any) > 'ok) > > (foo #t) > 'ok > (foo 7) > ; foo: contract violation > ; expected: boolean? > ; given: 7 > ; in: the 1st argument of > ; (-> boolean? any) > ; contract from: (function foo) > ; blaming: top-level > ;(assuming the contract is correct) > ; at: readline-input:4.18 > ; [,bt for context] > > Yup, all good. > > > (define/contract foo (make-parameter #f) boolean?) > (foo #t) > (foo) > #t > (foo 7) > #f > > > This isn't what I expected. What am I missing? > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/CAE8gKocV-TC1U6g5sq7C%2BZAjSVqDc%2B4yZWobr245qx4fZ9%2Bi3w%40mail.gmail.com > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAORuSUyw8_sBLzo5B4cx2PursiVzmmM3rBe3USCNn-cPip_ytA%40mail.gmail.com.
Re: [racket-users] Contracts on parameters
On 3/23/20, David Storrs wrote: > (define/contract (foo x) > (-> boolean? any) > 'ok) > > (foo #t) > 'ok > (foo 7) > ; foo: contract violation > ; expected: boolean? > ; given: 7 > ; in: the 1st argument of > ; (-> boolean? any) > ; contract from: (function foo) > ; blaming: top-level > ;(assuming the contract is correct) > ; at: readline-input:4.18 > ; [,bt for context] > > Yup, all good. > > > (define/contract foo (make-parameter #f) boolean?) > (foo #t) > (foo) > #t > (foo 7) > #f > > > This isn't what I expected. What am I missing? 1. the contract comes first, right now foo = boolean? 2. try parameter/c -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAFUu9R6RrEG-oK1i4fOsF9qUJFrbGc5TiMHPG--38cbvfdZsjQ%40mail.gmail.com.
[racket-users] Contracts on parameters
(define/contract (foo x) (-> boolean? any) 'ok) (foo #t) 'ok (foo 7) ; foo: contract violation ; expected: boolean? ; given: 7 ; in: the 1st argument of ; (-> boolean? any) ; contract from: (function foo) ; blaming: top-level ;(assuming the contract is correct) ; at: readline-input:4.18 ; [,bt for context] Yup, all good. (define/contract foo (make-parameter #f) boolean?) (foo #t) (foo) #t (foo 7) #f This isn't what I expected. What am I missing? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAE8gKocV-TC1U6g5sq7C%2BZAjSVqDc%2B4yZWobr245qx4fZ9%2Bi3w%40mail.gmail.com.
[racket-users] Re: questions about top-level-bind-scope in root-expand-context
On Mon, 23 Mar 2020 01:45:40 -0700 (PDT), Yongming Shen wrote: >Hi Matthew, > >Thank you for the quick reply! > >I tried the example you gave for my first question and it resulted in an >error. >I have the following as `module-that-defines-fib`: > > #lang racket > (provide fib) > (define fib "fib") > >And this is the error that I got (using Racket 7.6): > > ; application: not a procedure; > ; expected a procedure that can be applied to arguments > ; given: "fib" > ; [,bt for context] I've run into this problem before ... I don't recall the official explanation, but my takeaway was that Racket does not permit you to directly *export* a value - you have to export a function or macro that produces the value. E.g., #lang racket (provide fib) (define (fib) "fib") >I think this is because `(define-values (x) ...)` expands `...` without the >top-level-bind-scope, even when expand-context-to-parsed? is #t (according >to expander/expand/top.rkt). Is this a bug? >Related to your answer to my second question, `define-syntaxes` similarly >does not add the top-level-bind-scope when expanding `...`. Does this mean >that even for `define-syntaxes`, `...` won't use the top-level-bind-scope >binding(s) after all? > >A little bit off-topic, in the definition of define-values (in >expander/expand/top.rkt), there is `(define-match m s ...)`, but for >define-syntaxes it is `(define-match m disarmed-s ...)`. Is this difference >significant? Or does define-match not care whether `s` or `disarmed-s` is >used? I don't know the internals so I can't evaluate your theory. >Thanks, >Yongming 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/2l0i7flr0to9msl6sg165vptiec0qq26l7%404ax.com.
Re: [racket-users] Gradual Typed Racket?
Hi Ben, Thank you for your answer! I'll give (sub)modules a try. The examples from the plot library are very helpful, I'll peruse them attentively. I didn't realise that (provide (contract-out)) gave better error messages than define/contract. I'm glad to have chosen to use (provide (contract-out)) in my code. - Sergiu On Monday, March 23, 2020 at 5:16:52 PM UTC+1, Ben Greenman wrote: > > On 3/21/20, unlimitedscolobb > wrote: > > Hello, > > > > I come to Racket from Haskell and so far I am quite happy, as I feel > freer > > to do some weird stuff from time to time, and I am absolutely in love > with > > the Lisp-parens syntax. > > > > As a former Haskeller, one of the first things I tried was Typed Racket. > > It worked like a charm for small examples, but started getting in my way > > too much as soon as I got to some more advanced stuff (e.g. polymorphic > > functions, generics, eval, even apply). My immediate reaction was > ditching > > types for contracts, which are rather fine and allow me to use a > familiar > > language, but I am somewhat worried about the performance penalties > > defining everything via define/contract may incur. Also, it seems weird > to > > set up runtime contract checks where a simple type annotation would do. > > I have no problem with Typed Racket not being able to type every single > one > > of my functions (after all, I came to Racket to be able to do weird > stuff), > > but so far I couldn't figure out what would be the best way to mix typed > > into two separate files. > > > > What is the standard practice for mixing typed and untyped code within a > > single module? Submodules? Typed regions within untyped code? Maybe > > there is an example somewhere I can have a look at? > > Yep, submodules and typed regions are the two ways to do this. > > The plot library uses typed submodules in untyped code in a few small > places: > > > https://github.com/racket/plot/blob/master/plot-lib/plot/private/common/contract.rkt > > > https://github.com/racket/plot/blob/master/plot-lib/plot/private/common/parameter-groups.rkt > > > I've done a similar thing to make typed parameters in untyped code. > > Not sure about best practices, but I definitely prefer keeping typed > and untyped code in separate modules. > > For contracts, though, (provide (contract-out ...)) gives better error > messages than define/contract. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/1aa90aad-c951-43a1-be7e-24df02ec5c67%40googlegroups.com.
Re: [racket-users] Gradual Typed Racket?
On 3/21/20, unlimitedscolobb wrote: > Hello, > > I come to Racket from Haskell and so far I am quite happy, as I feel freer > to do some weird stuff from time to time, and I am absolutely in love with > the Lisp-parens syntax. > > As a former Haskeller, one of the first things I tried was Typed Racket. > It worked like a charm for small examples, but started getting in my way > too much as soon as I got to some more advanced stuff (e.g. polymorphic > functions, generics, eval, even apply). My immediate reaction was ditching > types for contracts, which are rather fine and allow me to use a familiar > language, but I am somewhat worried about the performance penalties > defining everything via define/contract may incur. Also, it seems weird to > set up runtime contract checks where a simple type annotation would do. > I have no problem with Typed Racket not being able to type every single one > of my functions (after all, I came to Racket to be able to do weird stuff), > but so far I couldn't figure out what would be the best way to mix typed > into two separate files. > > What is the standard practice for mixing typed and untyped code within a > single module? Submodules? Typed regions within untyped code? Maybe > there is an example somewhere I can have a look at? Yep, submodules and typed regions are the two ways to do this. The plot library uses typed submodules in untyped code in a few small places: https://github.com/racket/plot/blob/master/plot-lib/plot/private/common/contract.rkt https://github.com/racket/plot/blob/master/plot-lib/plot/private/common/parameter-groups.rkt I've done a similar thing to make typed parameters in untyped code. Not sure about best practices, but I definitely prefer keeping typed and untyped code in separate modules. For contracts, though, (provide (contract-out ...)) gives better error messages than define/contract. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAFUu9R6NyvCz2TWL4%3DBBQ0edff18LGTQcUytkXngESvrDQYx_g%40mail.gmail.com.
Re: [racket-users] questions about top-level-bind-scope in root-expand-context
At Mon, 23 Mar 2020 01:45:40 -0700 (PDT), Yongming Shen wrote: > I tried the example you gave for my first question and it resulted in an > error. Oops --- you're right. I lost track of what we try to make work at the top level. > I think this is because `(define-values (x) ...)` expands `...` without the > top-level-bind-scope, even when expand-context-to-parsed? is #t (according > to expander/expand/top.rkt). Is this a bug? Since the behavior goes far back, I think this is the behavior that we decided to settle for. > Related to your answer to my second question, `define-syntaxes` similarly > does not add the top-level-bind-scope when expanding `...`. Does this mean > that even for `define-syntaxes`, `...` won't use the top-level-bind-scope > binding(s) after all? The way that evaluation, binding, and expansion are interleaved means that a `define-syntaxes` macro can refer to itself in expansions. The binding of an identifier in a macro template is resolved after the macro is applied. The difference with `define` is that the right-hand side is expanded/compiled before `define` binds. > A little bit off-topic, in the definition of define-values (in > expander/expand/top.rkt), there is `(define-match m s ...)`, but for > define-syntaxes it is `(define-match m disarmed-s ...)`. Is this difference > significant? Or does define-match not care whether `s` or `disarmed-s` is > used? Using `disarmed-s` in the definition of `define-values` is probably a better idea, and I'll look into that more. It think it turns out not to matter, normally, because `define-values` is transparent to syntax arming via `syntax-arm` with a #t second argument (which is what the expander does). But it would be better to not rely on that. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5e78c215.1c69fb81.5b855.0569SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
[racket-users] Just had a student ask me to do their work
On Discord. -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAGHj7-LCaWvoDZpm3YtCY0NKeWQ2CP_oDRq-k9nf%2BLsL6mWY8g%40mail.gmail.com. Hackathon_Scenario_and_Exercises.pdf Description: Adobe PDF document
Re: [racket-users] questions about top-level-bind-scope in root-expand-context
Hi Matthew, Thank you for the quick reply! I tried the example you gave for my first question and it resulted in an error. I have the following as `module-that-defines-fib`: #lang racket (provide fib) (define fib "fib") And this is the error that I got (using Racket 7.6): ; application: not a procedure; ; expected a procedure that can be applied to arguments ; given: "fib" ; [,bt for context] I think this is because `(define-values (x) ...)` expands `...` without the top-level-bind-scope, even when expand-context-to-parsed? is #t (according to expander/expand/top.rkt). Is this a bug? Related to your answer to my second question, `define-syntaxes` similarly does not add the top-level-bind-scope when expanding `...`. Does this mean that even for `define-syntaxes`, `...` won't use the top-level-bind-scope binding(s) after all? A little bit off-topic, in the definition of define-values (in expander/expand/top.rkt), there is `(define-match m s ...)`, but for define-syntaxes it is `(define-match m disarmed-s ...)`. Is this difference significant? Or does define-match not care whether `s` or `disarmed-s` is used? Thanks, Yongming On Saturday, March 21, 2020 at 9:25:01 AM UTC-4, Matthew Flatt wrote: > > At Sat, 21 Mar 2020 00:00:07 -0700 (PDT), Yongming Shen wrote: > > First, in the source file expander/expand/bind-top.rkt, there is a > comment > > that says "When compiling `(define-values (x) ...)` at the top level, > > we'd like to bind `x` so that a reference in the "..." will point back > to > > the definition, as opposed to being whatever `x` was before." Isn't this > > the exact opposite of what (define-values (x) ...) should do? > > Here's an example scenario that the current rule is meant to cover: > > > (require module-that-defines-fib) > > > fib ; refers to binding from `module-that-defines-fib` > > > (define (fib n) > (if (< n 2) > 1 > (+ (fib (- n 1)) (fib (- n 2) ; refers to this definition > > > (fib 27) ; => 514229 > > If a programmer usually expects the `fib`s in the definition's `...` > region here to refer to the new definition, not to the imported > binding, then the implemented rule is the right one. If programmers > expect that `fib`s in the `...` to refer to the imported binding, then > I'd agree with you. But I think the former is more often the case. > > Neither rule is obviously right, and if we make the example more > complicated with more macros involved, I'm pretty sure there's no way > to implement either rule consistently: the top level is hopeless. The > case of a single recursive function seems common enough that we've > picked a rule and implementation to make it work. > > > Second, ignoring the comment mentioned above, but still consider > > `(define-values (x) ...)`. It appears that the binding of `x` to `...` > with > > the top-level-bind-scope is only used by `(#%top . x)` (either explicit > or > > implicit). The only exception seems to be in contexts where neither `x` > nor > > #%top are binded, in which case `x`, not wrapped by #%top, also uses > that > > binding. The case of `(#%top . x)` is confusing because even without the > > top-level-bind-scope binding of `x`, `(#%top . x)` can still locate > > `(define-values (x) ...)`, otherwise mutually recursive functions won't > > work at the top level. As for the exception case, it seems rare enough > that > > it can be ignored. So my question is, what's benefit does the > > top-level-bind-scope bring? > > Just to restate (to make sure I understand), you're pointing out that > an unbound identifier is treated the same as a binding using the > top-level scope (i.e., both refer to a top-level variable) --- so why > bother with the top-level scope? > > Although the result is the same for variable references, it's not the > same for macro bindings or for imported bindings. And, then, there's no > way to predict in advance that an identifier will be used as a variable > and omit the top-level scope in that case. > > Stepping back a little, it may not be the right design choice to treat > an unbound identifier as a reference to a top-level variable. But some > sort of default is necessary to support the traditional top level. And > treating unbound identifiers this was avoids a[nother] special > treatment of top-level scopes, where an unbound variable could be > treated as a variable reference only if it has a top-level scope. > > Really, the only consistent approach that I know is to not have an > interactive top level, but that's not an attractive option. > > > Matthew > > -- 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. To view this discussion on the web visit
Re: [racket-users] FYI, build from HEAD fails in realloc()
Hi John, Has anyone already looked into this? I haven't seen this problem yet. If it's not solved, can you please open an issue? Thanks, Paulo Matos 'John Clements' via Racket Users writes: > Bang! I was wrong. Here’s another similar trace: > > raco setup: 6 running: > /pfds/pfds/scribblings/functional-data-structures.scrbl > raco setup: 4 running: /jbc-utils/gradeserver/gradeserver.scrbl > raco setup: 3 running: /htdp-doc/scribblings/htdp-langs/htdp-langs.scrbl > raco setup: 2 running: /images-doc/images/scribblings/images.scrbl > raco setup: 0 running: > /macro-debugger/macro-debugger/macro-debugger.scrbl > raco setup: 7 running: /math-doc/math/scribblings/math.scrbl > raco setup: 5 running: /net-doc/net/scribblings/net.scrbl > raco setup: 1 running: /compatibility-doc/mzlib/scribblings/mzlib.scrbl > raco setup: 4 running: /racket-doc/openssl/openssl.scrbl > raco setup: 4 running: > /optimization-coach/optimization-coach/scribblings/optimization-coach.scrbl > raco setup: 4 running: > /option-contract-doc/scribblings/option-contract.scrbl > raco setup: 4 running: /net-doc/net/scribblings/osx-ssl.scrbl > raco setup: 5 running: /overeasy/overeasy.scrbl > raco setup: 4 running: /parsack/parsack/parsack.scrbl > raco setup: 1 running: /parser-tools-doc/parser-tools/parser-tools.scrbl > raco setup: 5 running: /pict-doc/pict/scribblings/pict.scrbl > raco setup: 1 running: > /pict-snip-doc/scribblings/pict-snip/pict-snip.scrbl > raco setup: 4 running: > /picturing-programs/picturing-programs/picturing-programs.scrbl > raco setup: 1 running: /racket-doc/pkg/scribblings/pkg.scrbl > raco setup: 4 running: /plai-doc/scribblings/plai.scrbl > raco setup: 1 running: /planet-doc/planet/planet.scrbl > raco setup: 4 running: /plot-doc/plot/scribblings/plot.scrbl > racket(54631,0x762f) malloc: *** error for object 0x12f96cdc8: > pointer being realloc'd was not allocated > racket(54631,0x762f) malloc: *** set a breakpoint in > malloc_error_break to debug > make[2]: *** [in-place-setup] Abort trap: 6 > make[1]: *** [plain-in-place] Error 2 > make: *** [in-place] Error 2 > make 240.77s user 75.70s system 398% cpu 1:19.32 total > > >> On Mar 20, 2020, at 3:11 PM, 'John Clements' via Racket Users >> wrote: >> >> Here’s the tail of a build of racket HEAD that just failed during a call to >> realloc(). I went back far enough to be sure I had a full record of what was >> running on cores 0-7. >> >> I strongly suspect this is not reproducible, and I don’t think there’s any >> further information that would be useful here, alas. >> >> John >> >> raco setup: 1 running: >> /pfds/pfds/scribblings/functional-data-structures.scrbl >> raco setup: 0 running: >> /future-visualizer/future-visualizer/scribblings/future-visualizer.scrbl >> raco setup: 4 running: /games/scribblings/games.scrbl >> raco setup: 6 running: >> /racket-doc/scribblings/getting-started/getting-started.scrbl >> raco setup: 6 running: /games/gl-board-game/gl-board-game.scrbl >> raco setup: 0 running: /GLPK/glpk/glpk.scrbl >> raco setup: 5 running: /jbc-utils/gradeserver/gradeserver.scrbl >> read-compiled-linklet: version mismatch expected: "7.6.0.17" found: "7.6" >> in: >> /Users/clements/git-clements/pkgs/jbc-utils/gradeserver/compiled/gradeserver_scrbl.zo >> context...: >> read-linklet-or-directory >> read-dispatch >> read-syntax >> default-load-handler >> standard-module-name-resolver >> module-path-index-resolve >> module-declared? >> /Users/clements/racket/pkgs/racket-index/setup/scribble.rkt:1529:27 >> /Users/clements/racket/pkgs/racket-index/setup/scribble.rkt:904:0: >> load-doc/ensure-prefix >> /Users/clements/racket/pkgs/racket-index/setup/scribble.rkt:1162:13 >> .../parallel-do.rkt:388:17 >> >> /Users/clements/racket/racket/collects/setup/../racket/private/more-scheme.rkt:261:28 >> /Users/clements/racket/racket/collects/setup/parallel-do.rkt:441:20: loop >> >> context...: >> /Users/clements/racket/racket/collects/setup/parallel-do.rkt:332:4: >> work-done method in list-queue% >> /Users/clements/racket/racket/collects/setup/parallel-do.rkt:282:17 >> /Users/clements/racket/racket/collects/setup/parallel-do.rkt:236:4 >> /Users/clements/racket/pkgs/racket-index/setup/scribble.rkt:138:0: >> setup-scribblings >> /Users/clements/racket/racket/collects/setup/setup-core.rkt:72:0: >> setup-core >> "/Users/clements/racket/racket/collects/setup/main.rkt": [running body] >> temp35_0 >> for-loop >> run-module-instance! >> "/Users/clements/racket/racket/collects/raco/main.rkt": [running body] >> temp35_0 >> for-loop >> run-module-instance! >> perform-require! >> raco setup: 5 running: /graph-doc/graph/scribblings/graph.scrbl >> raco setup: 4 running: /htdp-doc/graphics/scribblings/graphics.scrbl >> raco setup: 6 running: /gregor-doc/gregor/scribblings/gregor.scrbl >> raco setup: 2 running: /gui-doc/scribblings/gui/gui.scrbl >> raco setup: 0 running: >>
