[racket-users] Re: how can I approximate syntax properties with `make-rename-transformer`?

[Jack Firth]

What about passing the configuration data to `other-module-begin` via 
keyword arguments or tagged expressions in the body of the 
`(other-module-begin ...)` expansion? Is there a particular reason `mb` and 
`other-module-begin` need to communicate with syntax properties?

On Tuesday, November 28, 2017 at 7:15:50 PM UTC-8, Matthew Butterick wrote:
>
> I'm making a #%module-begin macro, but I want to delegate it to an 
> existing one. 
>
> OK, let's start with a rename transformer: 
>
> (provide (rename-out [mb #%module-begin])) 
> (define-syntax mb (make-rename-transformer #'other-module-begin)) 
> (define-syntax other-module-begin (λ (stx) #'foo)) 
>
> That works, but I also need to pass some extra data to 
> `other-module-begin` that controls how it's configured during this 
> delegation. 
>
> OK, let's add a syntax property. But wrapping the property around the 
> transformer doesn't work, because a rename transformer is not `syntax?`: 
>
> (provide (rename-out [mb #%module-begin])) 
> (define-syntax mb (syntax-property (make-rename-transformer 
> #'other-module-begin) 'foo "bar")) 
> (define-syntax other-module-begin (λ (stx) #'foo)) 
>
> ;; syntax-property: contract violation 
>
>
> I can wrap the property around the target identifier, but the syntax 
> property doesn't stick: 
>
> (provide (rename-out [mb #%module-begin])) 
> (define-syntax mb (make-rename-transformer (syntax-property 
> #'other-module-begin 'foo "bar"))) 
> (define-syntax other-module-begin (λ (stx) #'foo)) 
>
> (syntax-property #'mb 'foo) ; #f 
>
>
> Other possibilities with equivalent effect?

-- 
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: #lang languages and cyclic dependencies

[Jack Firth]

Huh, I must have missed this the first time around. I've run into this sort 
of thing multiple times before and it usually brings me to this question:

What if the configuration file was the main module of your app, instead of 
something imported by your app?

Think about it. The "my-project/config/local" and 
"my-project/config/production" modules are essentially saying "to run the 
app locally, set the project config to these values". What module could 
possibly have a use for that information other than the main "app startup" 
module? It seems like all other code should only depend on modules that 
define the *schema *of configuration, rather than any modules that set that 
configuration to specific values. It seems odd for the schema definition 
module (my-project/config) to depend on modules that actually use that 
schema to set config values (my-project/config/local). The reverse sounds 
more sensible.

If you make a module written in `#lang my-project/config` expand to a 
`main` submodule that starts up your app you get some other neat Rackety 
things to show off to your colleagues: not only will they get an IDE with 
syntax highlighting and good error messages "for free",  pressing the Run 
button with a config file open will launch the app automatically! This 
might not work if launching your app is especially complicated, but I'm 
curious if you've explored this direction and what your thoughts are.

On Tuesday, November 28, 2017 at 1:28:06 PM UTC-8, Philip McGrath wrote:
>
> For the benefit of posterity, while I haven't actually solved the 
> cycle-in-loading error, I was able to get the results that I wanted in this 
> case by:
>
>1. Implementing the language as a `module` (not `module*` or 
>`module+`) submodule of "my-project/config.rkt", including a
>(module reader syntax/module-reader
>  #:language '(submod my-project/config lang))
>2. In the body of the outer `my-project/config` module, instead of 
>requiring the values from "my-project/config/local.rkt" etc. as usual, 
>getting them lazily/dynamically, which I am doing with a little wrapper on 
>top of `define-runtime-module-path-index`, though `racket/lazy-require` 
>would probably also work well.
>
> Evaluating the configuration files lazily was particularly good for me 
> because it lets me write, say, "production.rkt" assuming that various 
> things from the production server exist and just raising an error if not, 
> rather than having to make everything in every configuration file run on 
> every machine.
>
> -Philip
>

-- 
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] Unit test inner procedures

[Jack Firth]

I like it. Added an issue  to 
figure out a Rackety way to do this; feedback strongly encouraged.

On Tuesday, November 28, 2017 at 11:05:50 AM UTC-8, Benjamin Lerner wrote:
>
> (Pyret co-lead dev here.)
>
> The way nested tests work for us in Pyret is actually simpler than that: 
> As a dummy example, consider a curried addition function
>
> fun make-adder(num1 :: Number):
>   fun result(num2 :: Number):
> num1 + num2
>   where:
> result(5) is num1 + 5
> result(10) is num1 + 10
>   end
>   result
> where:
>   make-adder(3)(6) is 9
>   make-adder(4)(2) is 6
> end
>
> This definition will run *six* test cases — the two test cases for 
> make-adder will each run the two nested test cases for result. These will 
> be reported as three blocks of test cases: one block for make-adder and 
> two blocks for result. The test cases for result run in the lexical scope 
> of the body of make-adder, so they have closed over num1 as part of their 
> environment.
>
> (In practice, this can lead to many, many test cases, obviously. So when 
> running a program in Pyret, by default we only run the test cases lexically 
> present in the main module of the program.)
>
> ~ben
>
> On 11/28/2017 01:53 PM, Jack Firth wrote:
>
> BUT, one could easily imagine an extension to the unit testing framework 
>> where inner tests work, too. With a combination of coverage and unit 
>> testing, you can usually get these inner unit tests to run and record their 
>> status the same way outer ones do in module+. Pyret, for example, does 
>> exactly this, so we should be able to do it too.
>>
>
> Looking at Pyret, you're referring to the "where" syntax right? So this:
>
> fun sum(l):
>   cases (List) l:
> | empty => 0
> | link(first, rest) => first + sum(rest)
>   end
> where:
>   sum([list: ]) is 0
>   sum([list: 1, 2, 3]) is 6
> end
>
> ...means that the "where" body is composed of tests of the `sum` function. 
> I like this a lot and want it for Racket (in a way that's more direct than 
> submodules). But I have no idea how it should work for nested functions 
> that close over variables of the outer function. Would the tests specify 
> the closure bindings maybe?
> -- 
> 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.

[racket-users] how can I approximate syntax properties with `make-rename-transformer`?

[Matthew Butterick]

I'm making a #%module-begin macro, but I want to delegate it to an existing 
one. 

OK, let's start with a rename transformer:

(provide (rename-out [mb #%module-begin]))
(define-syntax mb (make-rename-transformer #'other-module-begin))
(define-syntax other-module-begin (λ (stx) #'foo))

That works, but I also need to pass some extra data to `other-module-begin` 
that controls how it's configured during this delegation. 

OK, let's add a syntax property. But wrapping the property around the 
transformer doesn't work, because a rename transformer is not `syntax?`:

(provide (rename-out [mb #%module-begin]))
(define-syntax mb (syntax-property (make-rename-transformer 
#'other-module-begin) 'foo "bar"))
(define-syntax other-module-begin (λ (stx) #'foo))

;; syntax-property: contract violation


I can wrap the property around the target identifier, but the syntax property 
doesn't stick:

(provide (rename-out [mb #%module-begin]))
(define-syntax mb (make-rename-transformer (syntax-property 
#'other-module-begin 'foo "bar")))
(define-syntax other-module-begin (λ (stx) #'foo))

(syntax-property #'mb 'foo) ; #f


Other possibilities with equivalent effect?

-- 
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] or/c, parametric->/c, and contract-first-order-passes?

[Ben Greenman]

The other day, I wanted to write a contract for a function that takes
any kind of vector and does something depending on whether the vector
is mutable. The contract was basically the one below:

```
#lang racket

(define/contract (f v)
  (parametric->/c [A]
(-> (or/c (vectorof A #:immutable #true)
  (vectorof A #:immutable #false))
any))
  (void))
```

When I try to call this function, I get an error "none of the branches
of the or/c matched".

It looks like this error is because `contract-first-order-passes?`
returns #false if the vector I pass to `f` has any elements.

Two questions:

1. Could `(contract-first-order-passes? ctc val)` return `#true` if
`ctc` is from a `parametric->/c` ? (I feel like it shouldn't but I
don't know why not)

2. If not, would `or/c` be better off using a
`contract-first-order-fails?` predicate?

-- 
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] Assigning actions to any key on a terminal

[Cleverson Casarin Uliana]

Hi, OK, I'll look for the console API, or installing Linux/BSD on a 
virtual machine, or even go experiment with racket/gui, since it's just 
a little project mostly for fun. :)


Greetings
Cleverson

--
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] Assigning actions to any key on a terminal

[Neil Van Dyke]

Cleverson Casarin Uliana wrote on 11/28/2017 05:12 PM:
Hello, I'd like a library to detect any key press on a terminal (from 
single characters to key combinations), so I can perform diverse 
actions when one is pressed. I tried the charterm package, but it 
seems not compatible with the Windows standard console, since it 
reports it cannot find /dev/tty on startuup, or maybe I don't know how 
to make it work?


Sorry, the `charterm` package only works when running on Unix-like 
systems (GNU/Linux, a BSD-derived Unix, reportedly Mac OS X), not 
Windows.  I should be clear in the docs that it doesn't work on Windows.


http://www.neilvandyke.org/racket/charterm/

For running on Windows, and responding to a Windows text command window, 
you don't want `charterm`, and might need to do something with the Win32 
console API (IIRC).  Maybe you can do this with the Racket FFI.


Or, in the less common scenario of running on Windows, and dealing with 
a terminal plugged into a serial port or other device, you'd probably 
need a Win32 serial API, or API for whatever funky terminal interface 
you're using.


(Ideally, most CS people will normally run GNU/Linux or a BSD, for 
promoting technical/engineering freedom and open science and such. But 
sometimes we have to work on other platforms.)


--
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] Assigning actions to any key on a terminal

[Cleverson Casarin Uliana]

Hello, I'd like a library to detect any key press on a terminal (from 
single characters to key combinations), so I can perform diverse actions 
when one is pressed. I tried the charterm package, but it seems not 
compatible with the Windows standard console, since it reports it cannot 
find /dev/tty on startuup, or maybe I don't know how to make it work?


Thanks,
Cleverson

--
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] unexpected behavior of parametric polymorphism in Typed Racket

[Daniel Feltey]

Sorry for the late reply to this thread, I tried to send this message
yesterday, but ran into problems with my email setup.

> I'm starting to think that my base assumption (that Typed Units are more
or
> less equivalent to ML signatures, structures, and functors) is way off.

The intent is that they are similar to ML signatures, structures, and
functors, but unfortunately, they just aren't quite there yet. I think they
support most of the uses of units you would find in the Racket codebase,
but when I was implementing them there weren't many uses of them as ways to
parameterize over different data types and I didn't make supporting that
use case a priority.

I do think that Typed Units would be significantly more useful if they
supported more of the ML module system features, but there are some
interesting questions about units and signatures with type parameters
should interact with untyped racket programs.

> The mention of `sig-type-form' in the error message suggests that it is
> possible to do this, but I'm not seeing the concrete syntax for this
> described anywhere.  Am I overlooking something?

You aren't overlooking anything. I had started trying to support
`define-type` style type alias definitions inside of signature definitions,
but at
some point this was abandoned and probably should have been removed when
support for Typed Units was added to Typed Racket. The error message here
comes from a missing set of parentheses around the list of type
declarations, but adding that doesn't fix the real problem that typed units
don't currently support type parameterization.


The documentation for typed units can be found at
http://docs.racket-lang.org/ts-reference/Typed_Units.html?q=typed%20units
I'm not sure how helpful it would be, basically only the `define-signature`
form differs in racket and typed/racket, and the typed
version of the other unit syntactic forms are mostly a subset of their
untyped versions.

I'm sorry that this probably doesn't help you solve your original problem,
I hope we can eventually improve the support for units in Typed Racket to
better match the features of ML modules.
Dan

On Tue, Nov 28, 2017 at 9:09 AM, Matthias Felleisen 
wrote:

>
> > On Nov 28, 2017, at 10:02 AM, Richard Cobbe  wrote:
> >
> > On Tue, Nov 28, 2017 at 09:43:54AM -0500, Matthias Felleisen wrote:
> >>
> >> I have forwarded your email to Daniel Felty who designed and
> implemented the typed units. I am hoping to get a response soon — Matthias
> >
> > Great, thanks.
> >
> >>> On Nov 26, 2017, at 6:11 PM, Richard Cobbe  wrote:
> >
> > 
> >
> >>> I'm starting to think that my base assumption (that Typed Units are
> more or
> >>> less equivalent to ML signatures, structures, and functors) is way off.
> >
> > Probably worth clarifying this: I'm not claiming that Typed Units *have*
> to
> > work like ML functors, merely that this is my starting assumption, since
> > they both appear to be designed to address many of the same problems.  If
> > they don't work like that, though, then I might need some additional
> > documentation.
>
>
> Yes. Units are not functors.
>
> I believe Daniel has written some documentation. Perhaps he can point us
> there.
>
>
> --
> 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: #lang languages and cyclic dependencies

[Philip McGrath]

For the benefit of posterity, while I haven't actually solved the
cycle-in-loading error, I was able to get the results that I wanted in this
case by:

   1. Implementing the language as a `module` (not `module*` or `module+`)
   submodule of "my-project/config.rkt", including a
   (module reader syntax/module-reader
 #:language '(submod my-project/config lang))
   2. In the body of the outer `my-project/config` module, instead of
   requiring the values from "my-project/config/local.rkt" etc. as usual,
   getting them lazily/dynamically, which I am doing with a little wrapper on
   top of `define-runtime-module-path-index`, though `racket/lazy-require`
   would probably also work well.

Evaluating the configuration files lazily was particularly good for me
because it lets me write, say, "production.rkt" assuming that various
things from the production server exist and just raising an error if not,
rather than having to make everything in every configuration file run on
every machine.

-Philip

On Mon, May 1, 2017 at 7:01 AM, Philip McGrath 
wrote:

> I have often done it that way, too. In this case I decided to use a #lang
> for a few reasons:
>
>- The values for some of the parameters are not readable.
>- In some cases I want to do a little bit of work to calculate the
>value. For instance, "production.rkt" reads in the values of some API keys
>from a file not tracked in the git repository.
>- I have more than just two different configurations, e.g. for local
>automated testing vs. interactive local use.
>- I have some colleagues working on other aspects of the project who
>have little to no Racket experience, but who may need to edit the
>configuration files. Especially with syntax-parse, making a small #lang
>gets some free IDE support and good, early error messages if e.g. they
>enter a string where there should have been a number. (Plus, it does show
>off how wonderful Racket is.)
>
> The #lang essentially just redefines #%module-begin so that the module
> defines and exports a function "config" (actually a struct with
> prop:procedure) that calls a thunk with the intended parameterization.
>
> Ultimately I actually found that writing a #lang was fairly comparable to
> the amount of code I would have needed to get good error reporting with the
> read-based option, so I'm pretty happy with it.
>
> Philip
>
>
>
> On Mon, May 1, 2017 at 2:59 AM, Alex Harsanyi 
> wrote:
>
>> Hi Philip,
>>
>> I don't have an answer to your problem, but I'm curious as to what do you
>> store in "local.rkt" and "production.rkt" to justify such a complicated
>> solution.
>>
>> In the projects that I worked on (Racket or otherwise), local vs
>> production differ in the values for different parameters, which are just
>> key => value mappings.  In Racket, I would just store these as association
>> lists in "local.rktd" and "production.rktd" than in the code just to a:
>>
>> (define config-file (if (prodution?) "production.rktd" "local.rktd"))
>> (define config (call-with-input-file config-file read))
>>
>> Than just use `assoc` to find the values for the parameters.
>>
>> Best Regards,
>> Alex.
>>
>> On Monday, May 1, 2017 at 9:03:45 AM UTC+8, Philip McGrath wrote:
>> > I'm working on a #lang for configuration files for a larger project I'm
>> working on, and I'm trying to find a setup that meets my (largely cosmetic)
>> goals without producing a "standard-module-name-resolver: cycle in
>> loading" error.
>> >
>> >
>> > Given the following directory structure:
>> > my-project/config.rktconfig/local.rktproduction.rkt
>> > I would like both to write "local.rkt" and "production.rkt" in "#lang
>> my-project/config" and to have "(require my-project/config)" provide
>> bindings re-exported from "local.rkt" and "production.rkt" and some extra
>> bindings for working with those values.
>> >
>> >
>> > This seems like it should be doable, because there aren't any logical
>> cyclic dependencies, but I haven't found a way to convince Racket of that.
>> >
>> >
>> > I initially tried making a "my-project/config/lang/" directory with a
>> "module-lang.rkt" and a "reader.rkt" consisting of "(module reader
>> syntax/module-reader my-project/config/lang/module-language)", then
>> having "config.rkt" require and re-export "local.rkt", "production.rkt",
>> and the appropriate exports of "module-lang.rkt", but this gave me a "cycle
>> in loading" error.
>> >
>> >
>> > My first guess was that the problem might be that Racket was looking
>> for a reader submodule of "config.rkt", so I re-wrote "module-lang.rkt" and
>> "reader.rkt" as submodules of "config.rkt" (with "module", not "module*" or
>> "module+"), but this didn't solve the problem.
>> >
>> >
>> > Is there a way to do what I want?
>> >
>> >
>> > -Philip
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe 

Re: [racket-users] Unit test inner procedures

[Benjamin Lerner]

(Pyret co-lead dev here.)

The way nested tests work for us in Pyret is actually simpler than that: 
As a dummy example, consider a curried addition function


|fun make-adder(num1 :: Number): fun result(num2 :: Number): num1 + num2 
where: result(5) is num1 + 5 result(10) is num1 + 10 end result where: 
make-adder(3)(6) is 9 make-adder(4)(2) is 6 end |


This definition will run /six/ test cases — the two test cases for 
|make-adder| will each run the two nested test cases for |result|. These 
will be reported as three blocks of test cases: one block for 
|make-adder| and two blocks for |result|. The test cases for |result| 
run in the lexical scope of the body of |make-adder|, so they have 
closed over |num1| as part of their environment.


(In practice, this can lead to many, many test cases, obviously. So when 
running a program in Pyret, by default we only run the test cases 
lexically present in the main module of the program.)


~ben

On 11/28/2017 01:53 PM, Jack Firth wrote:


BUT, one could easily imagine an extension to the unit testing
framework where inner tests work, too. With a combination of
coverage and unit testing, you can usually get these inner unit
tests to run and record their status the same way outer ones do in
module+. Pyret, for example, does exactly this, so we should be
able to do it too.


Looking at Pyret, you're referring to the "where" syntax right? So this:

fun sum(l):
  cases (List) l:
    | empty => 0
    | link(first, rest) => first + sum(rest)
  end
where:
  sum([list: ]) is 0
  sum([list: 1, 2, 3]) is 6
end

...means that the "where" body is composed of tests of the `sum` 
function. I like this a lot and want it for Racket (in a way that's 
more direct than submodules). But I have no idea how it should work 
for nested functions that close over variables of the outer function. 
Would the tests specify the closure bindings maybe?

--
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] Unit test inner procedures

[Jack Firth]

>
> BUT, one could easily imagine an extension to the unit testing framework 
> where inner tests work, too. With a combination of coverage and unit 
> testing, you can usually get these inner unit tests to run and record their 
> status the same way outer ones do in module+. Pyret, for example, does 
> exactly this, so we should be able to do it too.
>

Looking at Pyret, you're referring to the "where" syntax right? So this:

fun sum(l):
  cases (List) l:
| empty => 0
| link(first, rest) => first + sum(rest)
  end
where:
  sum([list: ]) is 0
  sum([list: 1, 2, 3]) is 6
end

...means that the "where" body is composed of tests of the `sum` function. 
I like this a lot and want it for Racket (in a way that's more direct than 
submodules). But I have no idea how it should work for nested functions 
that close over variables of the outer function. Would the tests specify 
the closure bindings maybe?

-- 
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] Unit test inner procedures

[Matthias Felleisen]

+2(that’s what the style guide says, too)

BUT, one could easily imagine an extension to the unit testing framework where 
inner tests work, too. With a combination of coverage and unit testing, you can 
usually get these inner unit tests to run and record their status the same way 
outer ones do in module+. Pyret, for example, does exactly this, so we should 
be abel to do it too. 








> On Nov 27, 2017, at 4:15 PM, Jack Firth  wrote:
> 
> I don't think you can directly test an inner procedure while keeping your 
> test code separately loadable (e.g. different file or module). It doesn't 
> seem like a good idea to me, personally. Inner procedures communicate to me 
> that I can change, reorganize, delete, and otherwise do whatever I want to 
> them without breaking any code outside the definition of the outer procedure. 
> Breaking tests in a different file with a refactoring of an inner procedure 
> would be very surprising to me.
> 
> Instead, I recommend not using inner procedures so extensively. Instead 
> define functions within modules (or possibly submodules) and use `provide` 
> with `contract-out` to declare which functions make the public API of your 
> module. You can then add a test submodule which has access to the inner 
> workings of the outer module and test "private" helper functions that way. 
> Here's an example:
> 
> #lang racket;; note that using #lang implicitly creates a module around the 
> whole file
> 
> (provide
>   (contract-out
> [my-public-function (-> input? output?)]))
> 
> (define (my-public-function input)
>   (helper2 (helper1 input)))
> 
> (define (helper1 input) ...)
> (define (helper2 input) ...)
> 
> (module+ test ;; inside this submodule we can see helper1 and helper2, even 
> though they're not provided
>   (require rackunit)
>   (check-equal? (helper1 test-input) test-output)
>   ... more tests here ...)
> 
> -- 
> 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] unexpected behavior of parametric polymorphism in Typed Racket

[Matthias Felleisen]

> On Nov 28, 2017, at 10:02 AM, Richard Cobbe  wrote:
> 
> On Tue, Nov 28, 2017 at 09:43:54AM -0500, Matthias Felleisen wrote:
>> 
>> I have forwarded your email to Daniel Felty who designed and implemented the 
>> typed units. I am hoping to get a response soon — Matthias
> 
> Great, thanks.
> 
>>> On Nov 26, 2017, at 6:11 PM, Richard Cobbe  wrote:
> 
> 
> 
>>> I'm starting to think that my base assumption (that Typed Units are more or
>>> less equivalent to ML signatures, structures, and functors) is way off.
> 
> Probably worth clarifying this: I'm not claiming that Typed Units *have* to
> work like ML functors, merely that this is my starting assumption, since
> they both appear to be designed to address many of the same problems.  If
> they don't work like that, though, then I might need some additional
> documentation.


Yes. Units are not functors. 

I believe Daniel has written some documentation. Perhaps he can point us there. 


-- 
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] unexpected behavior of parametric polymorphism in Typed Racket

[Richard Cobbe]

On Tue, Nov 28, 2017 at 09:43:54AM -0500, Matthias Felleisen wrote:
>
> I have forwarded your email to Daniel Felty who designed and implemented the 
> typed units. I am hoping to get a response soon — Matthias

Great, thanks.

> > On Nov 26, 2017, at 6:11 PM, Richard Cobbe  wrote:



> > I'm starting to think that my base assumption (that Typed Units are more or
> > less equivalent to ML signatures, structures, and functors) is way off.

Probably worth clarifying this: I'm not claiming that Typed Units *have* to
work like ML functors, merely that this is my starting assumption, since
they both appear to be designed to address many of the same problems.  If
they don't work like that, though, then I might need some additional
documentation.

Richard

-- 
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] unexpected behavior of parametric polymorphism in Typed Racket

[Matthias Felleisen]

I have forwarded your email to Daniel Felty who designed and implemented the 
typed units. I am hoping to get a response soon — Matthias




> On Nov 26, 2017, at 6:11 PM, Richard Cobbe  wrote:
> 
> Returning to this after a long delay...
> 
> On Sat, Nov 11, 2017 at 01:34:05PM -0500, Matthias Felleisen wrote:
> 
>>> (Context: I only actually intend to use `store' with a single type, but I
>>> want to define that type in a separate module.  Since the type's definition
>>> refers to `addr', I made `store' polymorphic to break the cyclical
>>> dependency.)
>> 
>> This of course calls for Typed Units, which are now available in Typed 
>> Racket thanks to Daniel Feltey.
>> 
>> It might be worth trying it out — Matthias
> 
> I started to take a look at this, and I'm having trouble seeing how this
> would work.  In particular, I'm not seeing how to include a type in a
> signature.  The following isn't syntactically correct:
> 
>(define-signature store^
>  Addr
>  Store
>  [empty-store : Store]
>  [alloc : (Store Integer -> (Values Store Addr))]
>  [alloc* : (Store (Listof Integer) -> (Values Store (Listof Addr)))]
>  [deref : (Store Addr -> Integer)]
>  [update : (Store Addr Integer -> Store)])
> 
> The presence of the bare `Addr' on the second line causes a syntax error,
> as one would expect from the docs.  Purely at random, I tried the
> following:
> 
>(define-signature store^
>  [Addr : Type]
>  [Store : Type]
>  [empty-store : Store]
>  [alloc : (Store Integer -> (Values Store Addr))]
>  [alloc* : (Store (Listof Integer) -> (Values Store (Listof Addr)))]
>  [deref : (Store Addr -> Integer)]
>  [update : (Store Addr Integer -> Store)])
> 
> This doesn't compile either (no surprise there), but it yields an
> interesting error message:
> 
>define-signature: expected sig-var-form or expected sig-type-form
>  at: Addr
>  in: ...
> 
> The mention of `sig-type-form' in the error message suggests that it is
> possible to do this, but I'm not seeing the concrete syntax for this
> described anywhere.  Am I overlooking something?
> 
> ;;;
> 
> Next: the signatures above only allow storing Integers in a Store.  I'd
> assumed that I'd eventually want to import the value type into the store@
> unit -- but then how do I include specify that type in store^ ?  In ML, I'd
> use a signature plus a 'with', but I don't see an equivalent to that here.
> 
> I'm starting to think that my base assumption (that Typed Units are more or
> less equivalent to ML signatures, structures, and functors) is way off.
> 
> Richard
> 
> -- 
> 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.