Re: [racket-users] Trying to understand the module system.

[Alex Gian]

Well, I can now get a namespace out of any particular module!

e.g:
> (module->namespace 'rat/src/polynomial/polynomial)
#

Many, many thanks to those who helped clear this up.

Onward now, to see how that will work with eval.  
And then to see if those scmutils environments can be sensibly simulated.

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

off-topic: on ``[racket-users]'' not added to this subthread (Was: Re: Parameters considered often harmful (was: Re: [racket-users] Re: A (long) question regarding parameters and scope))

[Robert Girault]

Why didn't [racket-users] tag get added to John Clements' message
``Parameters considered often harmful''.  Was it because the tag was
already contained in the subject?  Is that how Google Groups avoids
always adding the tag forever?

I wonder why they don't use message headers to know whether it's a new
message (meaning it doesn't belong to an existing ``thread'', if you
would) and so it should be tagged.  Maybe that wouldn't work, but I
can't see any flaw in the idea.

Thanks!

-- 
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] parameterize and keyword - doable?

[Philip McGrath]

On Sat, Aug 4, 2018 at 3:18 PM, Sanjeev Sharma  wrote:

> but as long as one is defaulting #:unless
> PLUS #unless is common to all the for's across some arbitrary scope,
> ideally one could elide it from each of the for's within that scope.
>

Local macros might be part of what you want:

#lang racket

(define (f unless?)
  (define-syntax-rule (for/sum/unless ([id rhs]
   for-clause ...)
body ...)
(for/sum ([id rhs]
  #:unless (unless? id)
  for-clause ...)
  body ...))
  (list (for/sum/unless ([x '(1 2 3 4 5)])
  x)
(for/sum/unless ([y '(6 7 8 9 10)]
 [2y (in-value (* 2 y))])
  (displayln y)
  (add1 2y

(f odd?)

(f even?)

-- 
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: SICM, scmutils, MIT-Scheme, CAS systems, etc, etc...

[Alex Gian]

I shouldn't have, really, it was in no state to be uploaded, but out of 
consideration to the many folks that have helped me so far, I've put it up 
here .

Actually, although it's quite the mess now, once I've sorted out what to do 
about the "environments" (modules) and cleaned up and added the generic 
dispatching, it will almost work as a proof of concept.  The generic 
dispatching already works fine, I haven't included it in the upload yet, I 
want to make some decisions about tuples and matrices first.  
Polynomial-gcd (for simplification) seems to be working.  Logic rules for 
simplification should be OK but have snagged on scoping of eval and modules 
(hence the upload).  

Once all that is done, I can move to the interesting stuff, literals and 
literal-functions and calculus!

Unless you have a particularly strong interest in this project I recommend 
you don't look at anything yet!
For the rest, there are a couple of dots/pdfs of the program structure (a 
lot of refactoring) and a skeleton of the documentation.

Be gentle!

-- 
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] parameterize and keyword - doable?

[Sanjeev Sharma]

the specific case I had in mind was near this

(let ([unless? odd?]) 
  (for/sum ([x '(1 2 3 4 5)] 
#:unless (uless? x)) 
x)) ;6 

but as long as one is defaulting #:unless 
PLUS #unless is common to all the for's across some arbitrary scope, 
ideally one could elide it from each of the for's within that scope. 

your current-unless looks a good candidate for another place. 



On Saturday, August 4, 2018 at 3:47:42 PM UTC-4, Greg Hendershott wrote:
>
> Do you mean that in something like this: 
>
> (for/sum ([x '(1 2 3 4 5)] 
>   #:unless (odd? x)) 
>   x) ;6 
>
> You have many occurrences of the `(odd? x)` and you'd like to define 
> that in one place that you can vary? 
>
> If so: 
>
> First, if they're in the same local scope, you could use `let`: 
>
> (let ([unless? odd?]) 
>   (for/sum ([x '(1 2 3 4 5)] 
> #:unless (uless? x)) 
> x)) ;6 
>
> Or (same difference) if they're in the same function definition, you 
> could use a function parameter: 
>
> (define (f unless?) 
>   (for/sum ([x '(1 2 3 4 5)] 
> #:unless (unless? x)) 
> x)) 
> (f odd?) ;6 
>
> Or -- and maybe this is what you're asking? -- you could define a 
> Racket parameter: 
>
> (define current-unless? (make-parameter (const #f))) 
>
> (define (f) 
>   (for/sum ([x '(1 2 3 4 5)] 
> #:unless ((current-unless?) x)) 
> x)) 
>
> (parameterize ([current-unless? odd?]) 
>   (f)) ;6 
>
> I think this is the best you can do; the `for` macros don't provide a 
> parameter to inject an #:unless clause. 
>

-- 
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] parameterize and keyword - doable?

[Greg Hendershott]

Do you mean that in something like this:

(for/sum ([x '(1 2 3 4 5)]
  #:unless (odd? x))
  x) ;6

You have many occurrences of the `(odd? x)` and you'd like to define
that in one place that you can vary?

If so:

First, if they're in the same local scope, you could use `let`:

(let ([unless? odd?])
  (for/sum ([x '(1 2 3 4 5)]
#:unless (uless? x))
x)) ;6

Or (same difference) if they're in the same function definition, you
could use a function parameter:

(define (f unless?)
  (for/sum ([x '(1 2 3 4 5)]
#:unless (unless? x))
x))
(f odd?) ;6

Or -- and maybe this is what you're asking? -- you could define a
Racket parameter:

(define current-unless? (make-parameter (const #f)))

(define (f)
  (for/sum ([x '(1 2 3 4 5)]
#:unless ((current-unless?) x))
x))

(parameterize ([current-unless? odd?])
  (f)) ;6

I think this is the best you can do; the `for` macros don't provide a
parameter to inject an #:unless clause.

-- 
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] Trying to understand the module system.

[Alex Gian]

Well, here we are: the essence of the problem lies in that scmutils defines 
certain modules, "environments" as it calls them, which it then proceeds to 
augment or access from other locations with gay abandon.  One use of this, 
for instance, is switching between the genericised and the explicit forms 
of arithmetical operations, e.g.  '+' and 'g:+'  I don't care too much 
about this, I'd be happy for the genericised form to be on constantly, if 
this was the only use I'd scrap it altogether.  

However, it is also used for memoization of functions, which is critical to 
system speedup, especially in calculus, and also used to import a ton of 
the logic rules used in the simplifier.  Can't do without that, I'm 
afraid.  So far I just avoided it by commenting all that out, by now at 
last it has to be tackled...  

My code upload, if you can call that, is here 
.

I've refactored a lot of the dependencies, so they work OK now, and it's 
fairly obvious which the key modules are.  what I'm less sure about, is how 
to play the fast and loose game of fiddling with the modules behind the 
user's back. If you look in Notes/Diagrams there are a couple of pdfs and 
dots showing the require/provide dependencies 

The Guile port code, by Daniel Guildea, which is mainly what I'm using as a 
guide is here .

The Chez, code, which I recently discovered, and which is probably closest 
to the Racket philosophy is here .  
  In fact, it's helped me understand quite a bit of what I have to do, 
though not necessarily how. 

The Sussman code is here 
 amongst other 
places , great for understanding Scheme archaeology, but I try to avoid any 
parts of it that are not actually maths!

Any further conversation on the subject (except for this, viz. how to 
handle the modules) I will put up on the CAS thread I created, to avoid 
cluttering.


The offending code is here 
 - 
'rules.rkt'  ca. line 173  
Once it tries to execute the 'rule-system' macro, in order to load up the 
rules, it crashes with the following message.
The macro is defined here 
 - 
'syntax.rkt' line 39   (I intend to use the chez one which is commented out 
(just for the build))


-- 
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] Trying to understand the module system.

[Alex Gian]

Hi Greg

Maybe I've got this wrong, but the way I understand it is that (apart from 
an actual language) #lang can be used for a development environment that is 
independent in some unique way.  If I'm not mistaken even SICP is a #lang, 
and some old Scheme books too, never mind the heaps of educational 
languages inluded out of the box.

Since scmutils was initially directed at readers of SICM, I kind of imagine 
(ultimate target) that such a reader could just grab DrRacket without 
knowing much else about it, plonk a *#lang SICM*  (or whatever the final 
name is) and proceed with the exercises in the book(s) - since there's FDG 
now, too.   Tutorial material for both the books and any other general 
mathematics / physics educational stuff could be released under the *#lang 
SICM* label, too.

Hope I haven't got the wrong end of the stick.

Anyway, I've uploaded something now (with apologies ;) )  See my next post.

Regards


On Saturday, August 4, 2018 at 8:29:10 PM UTC+1, Greg Hendershott wrote:
>
> Hi, Alex. 
>
> This sounds fun! 
>
> > - re rat:  just humour me on this, it's a temporary name anyway, until 
> the full deployment of the project, which incidentally, is the Racket port 
> of scmutils 
> > - following from the above, so yes, it will certainly have to be a 
> #lang, no questions there. 
>
> Apologies if I missed this from an earlier message or thread, but: 
>
> What feature or aspect of scmutils means it will need to be 
> implemented as a Racket language? 
>
> AFAIK MIT Scheme doesn't have anything like #lang, so I'm surprised. 
>
> I recall some mention of scmutils using MIT Scheme application hooks. 
> But AFAICT this is equivalent to Racket's `prop:procedure`. That is, 
> you can can define `struct`s that are applicable like procedures. On a 
> shallow read, it even looks like prop:procedure has both variants of 
> MIT Schemes' application hooks ("apply hooks" and "entities")? 
>
> So: If one reason for doing a lang was to define your own #%app -- you 
> probably don't need to. 
>
> Is there something else? 
>
> > Ho hum, I see there is probably no other way, I'll have to upload.  I'll 
> let you know soon as I do.  That way, more issues can be raised on github 
> too, amongst those interested and contribute to less noise on this list. 
>
> That would probably help a lot! 
>

-- 
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] Trying to understand the module system.

[Greg Hendershott]

Hi, Alex.

This sounds fun!

> - re rat:  just humour me on this, it's a temporary name anyway, until the 
> full deployment of the project, which incidentally, is the Racket port of 
> scmutils
> - following from the above, so yes, it will certainly have to be a #lang, no 
> questions there.

Apologies if I missed this from an earlier message or thread, but:

What feature or aspect of scmutils means it will need to be
implemented as a Racket language?

AFAIK MIT Scheme doesn't have anything like #lang, so I'm surprised.

I recall some mention of scmutils using MIT Scheme application hooks.
But AFAICT this is equivalent to Racket's `prop:procedure`. That is,
you can can define `struct`s that are applicable like procedures. On a
shallow read, it even looks like prop:procedure has both variants of
MIT Schemes' application hooks ("apply hooks" and "entities")?

So: If one reason for doing a lang was to define your own #%app -- you
probably don't need to.

Is there something else?

> Ho hum, I see there is probably no other way, I'll have to upload.  I'll let 
> you know soon as I do.  That way, more issues can be raised on github too, 
> amongst those interested and contribute to less noise on this list.

That would probably help a lot!

-- 
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] Racket PEG parser library release 0.3

[rain1]

Hello!

Released by PEG parser library version 0.3 today. It has got semantic 
actions now, which lets you parse and transform at the same time.


I hope the code is useful and interesting to you. It can easily be 
installed via the racket package manager as "peg" and there are docs 
here:

- https://pkgs.racket-lang.org/package/peg

There is also a example of using it quickly mock up a new #lang
- https://github.com/rain-1/nand-lang

--
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] Trying to understand the module system.

[Alex Gian]

Thanks for the reply Phillip

- re rat:  just humour me on this, it's a temporary name anyway, until the 
full deployment of the project, which incidentally, is the Racket port of 
scmutils

- following from the above, so yes, it will *certainly* have to be a *#lang*, 
no questions there.

- re whether the 'provide's work.  They do.  In trying to keep the 
irrelevant stuff out of my question, I neglected to mention that I also 
provide racket.  It works.  I have been using it like that for weeks and 
testing all sorts of stuff.  I sort of mention that I had no problem up to 
that point.

- re whether I realist that #lang rat is already a module.  Yes, of course 
I do.  The thing is, I need modules within that module to be modules too.

> As long as files start with #lang and your package is installed, 
`(require rat/polynomial)` will import the module that lives in a 
"polynomial.rkt" file 
> in the same directory as the "main.rkt" file imported by `(require rat)`.

I would like to be free of the constraint of the directory location, if 
possible.  If not, never mind, but it seems a bit limiting and outside the 
spirit of Racket.  It's just that the current directory structure is not 
laid out that way.

> You almost certainly do not want to use `eval`. 

Actually, I bloody certainly do not want to use eval, especially inside a 
macro.  Unfortunately the author of the original software has, so I have to 
find a way to work around it!  ;)

> I say this from some personal experience: when I was new to Racket and 
trying to figure out how to serialize structs, 
> I hacked up a monstrosity of a serialization implementation based on 
`eval` and `print`, which I used for months
> before I discovered that `racket/serialize` had already solved this 
problem reliably. Because of that, 
> I know a little bit about functions like `namespace-anchor->namespace` 
that start to address the problems you're finding, 
> but my advice is that you should describe the problem you're trying to 
solve by using `eval` so that the community can point you towards a better 
solution.

Now you're talking.  I'm not tied to any particular way of doing things, 
and I would like the end result to be as idiomatic Racket as can be.
However, I am also keen to have the thing up and running as quivckly as 
possible, and from then on anyone that wants to, can help at leisure.

Ho hum, I see there is probably no other way, I'll have to upload.  I'll 
let you know soon as I do.  That way, more issues can be raised on github 
too, amongst those interested and contribute to less noise on this list.

Cheers!



On Saturday, August 4, 2018 at 4:28:15 PM UTC+1, Philip McGrath wrote:
>
> There are several different issues here, but I'll try to touch on a few of 
> them.
>
> On Sat, Aug 4, 2018 at 9:33 AM, Alex Gian 
> > wrote:
>
>> Say I have written a little library, perhaps of various maths utilities. 
>> …  I have also made this an installable #lang, lets's call it '#lang rat' 
>> (for rational, of course) by adding the line
>>  
>>
>> (module reader syntax/module-reader rat)
>>
>>  
>> to the top of the main.rkt file, and also 
>>
>> (provide (all-defined-out) #%module-begin #%app #%datum #%top-interaction)
>>
>>
> This already brings up several different problems, ranging from trivial to 
> significant:
>
>- On a very minor point, I think `rational` would be a better name 
>than `rat`, both in keeping with the Scheme tradition of using real words 
>and because of practical namespace issues: if your package uses the `rat` 
>collection for rational numbers, it could conflict with another package 
>that might want to use `rat` for small rodents.
>- It is a matter of judgement to determine when a library should be 
>usable as a #lang, but my advice would be to avoid it unless there is 
>something you want to do that is possible for a #lang but not for a module 
>imported using `require`—and I don't see any signs of that. If you don't 
>provide a #lang, you can ignore the next bullet point.
>- Writing `(provide (all-defined-out) #%module-begin #%app #%datum 
>#%top-interaction)` probably doesn't do what you want. Using 
>`(all-defined-out)` exports only those things which have been `define`d in 
>that specific module, not things imported with `require` or from the 
>module's own language. In your example, a module in `#lang rat` would not 
>be able to use `define` or `lambda`, and, if the client module uses an 
>unbound identifier, a syntax error will be raised blaming the `rat` 
>implementation for failing to provide a `#%top` binding.
>Most language will want something like `(all-from-out racket/base)` in 
>their `provide` statements, perhaps using `except-out` to replace some 
>specific bindings with your own versions.
>
> I want the user to have to (require rat/polynomial) [but to be free of 
>> having to specify the file-path, which may be intricate].  Only the 

Re: [racket-users] Re: parameterize and keyword - doable?

[George Neuner]

On 8/4/2018 7:24 AM, Philip McGrath wrote:
On Sat, Aug 4, 2018 at 5:26 AM, George Neuner > wrote:


On Sat, 4 Aug 2018 00:08:46 -0500, Philip McGrath
mailto:phi...@philipmcgrath.com>> wrote:

>and you can create a function that accepts arbitrary or
>dynamically-calculated keyword arguments (which is rarely
desirable) using
>make-keyword-procedure

But this creates a procedure that accepts anything.  This seems worse
than the solution using the plist: the keyword accepting variant of
the function can't have named positional arguments.


Actually, the function passed to `make-keyword-procedure` can have 
required and/or optional named positional arguments. You can use 
`procedure-reduce-keyword-arity` to further specialize what arguments 
the resulting function requires and/or accepts.


Ok, but it's really confusing ... the more so because there isn't a 
relevant example in the docs.  The signature:


 (((listofkeyword?)list?)()#:restlist?. ->*.any)

doesn't readily indicate to me that additional arguments are possible.  
Playing with it, it seems that the function in fact can have its own 
positional arguments, but the 1st and 2nd arguments always will receive 
the keyword and keyarg lists - the function's own positional arguments 
(if any) must begin with the 3rd argument.


Whether this is a doc issue or an issue with my brain is a toss up.  If 
that empty list in the signature is meant to represent the function's 
own arguments, I'd have expected some indication of that: something 
like  (listof name)?, or (formals*), or something instead of ().


Racket's built-in keyword argument system is fully dynamic (though 
admittedly not always convenient to use dynamically out of the box), 
but it also provides great support for the common case where the 
keywords to be applied are statically visible, which an ad-hoc 
symbols-as-"keywords" system can't.


It's the uncommon cases that are interesting.  I'm going to have to play 
much more with it.  Thank you for the examples - I'm trying to 
understand them.


George

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

Re: [racket-users] Trying to understand the module system.

[Philip McGrath]

There are several different issues here, but I'll try to touch on a few of
them.

On Sat, Aug 4, 2018 at 9:33 AM, Alex Gian  wrote:

> Say I have written a little library, perhaps of various maths utilities.
> …  I have also made this an installable #lang, lets's call it '#lang rat'
> (for rational, of course) by adding the line
>
>
> (module reader syntax/module-reader rat)
>
>
> to the top of the main.rkt file, and also
>
> (provide (all-defined-out) #%module-begin #%app #%datum #%top-interaction)
>
>
This already brings up several different problems, ranging from trivial to
significant:

   - On a very minor point, I think `rational` would be a better name than
   `rat`, both in keeping with the Scheme tradition of using real words and
   because of practical namespace issues: if your package uses the `rat`
   collection for rational numbers, it could conflict with another package
   that might want to use `rat` for small rodents.
   - It is a matter of judgement to determine when a library should be
   usable as a #lang, but my advice would be to avoid it unless there is
   something you want to do that is possible for a #lang but not for a module
   imported using `require`—and I don't see any signs of that. If you don't
   provide a #lang, you can ignore the next bullet point.
   - Writing `(provide (all-defined-out) #%module-begin #%app #%datum
   #%top-interaction)` probably doesn't do what you want. Using
   `(all-defined-out)` exports only those things which have been `define`d in
   that specific module, not things imported with `require` or from the
   module's own language. In your example, a module in `#lang rat` would not
   be able to use `define` or `lambda`, and, if the client module uses an
   unbound identifier, a syntax error will be raised blaming the `rat`
   implementation for failing to provide a `#%top` binding.
   Most language will want something like `(all-from-out racket/base)` in
   their `provide` statements, perhaps using `except-out` to replace some
   specific bindings with your own versions.

I want the user to have to (require rat/polynomial) [but to be free of
> having to specify the file-path, which may be intricate].  Only the name
> should be necessary.  If I've understood correctly, my polynomials.rkt file
> will have to be made a module (or a submodule).
>

When you say "my polynomials.rkt file will have to be made a module", I
wonder if you realize that any file that begins with #lang is already a
module. For example, a file that consists of:

#lang racket/base

(provide x)

(define x 1)

is equivalent to a file containing the single s-expression:

(module inferred-from-filename racket/base
  (provide x)
  (define x 1))

If you actually do mean that some of your code is currently in files that
are not modules, you will almost certainly want to put them into modules
straight away.

As long as files start with #lang and your package is installed, `(require
rat/polynomial)` will import the module that lives in a "polynomial.rkt"
file in the same directory as the "main.rkt" file imported by `(require
rat)`.

Furthermore, this is going to become even more important to me soon, as I
> have cases where I have to 'eval' expressions expressions inside syntax,
> and that syntax is not in the same file as my evaluation environment.  I
> know that if I have the handle of the module I can do (module->namespace
> 'polynomial) and then use that namespace as the second parameter to eval,
> but how do I get the module handle in the first place?
>

You almost certainly do not want to use `eval`. There's a post on the
Racket blog that goes into much detail on why `eval` "should be avoided":
https://blog.racket-lang.org/2011/10/on-eval-in-dynamic-languages-generally.html
The takeaway is that there is almost always a better mechanism (unless you
are, say, implementing DrRacket, where dynamically evaluating arbitrary
programs really is exactly what you want to do).

I say this from some personal experience: when I was new to Racket and
trying to figure out how to serialize structs, I hacked up a monstrosity of
a serialization implementation based on `eval` and `print`, which I used
for months before I discovered that `racket/serialize` had already solved
this problem reliably. Because of that, I know a little bit about functions
like `namespace-anchor->namespace` that start to address the problems
you're finding, but my advice is that you should describe the problem
you're trying to solve by using `eval` so that the community can point you
towards a better solution.

Overall, I would suggest that you try to find some small Racket package and
look at the way its implementation is organized. I think that will help to
clarify some of the confusion.

-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 

[racket-users] Re: Trying to understand the module system.

[Alex Gian]

In fact, even this

(module polynomial racket
  (require "pcf.rkt" "fpf.rkt" "rcf.rkt" "pcf-fpf.rkt")
  (provide (all-from-out "pcf.rkt" "fpf.rkt" "rcf.rkt" "pcf-fpf.rkt"))
)

(require 'polynomial)
(define ns (module->namespace ''polynomial))
(eval '(poly/make-from-dense 1 '(1 -1)) ns)


which is as near as dammit to the the example in the Racket Guide, 15.1.3
does not seem to work, giving

Welcome to DrRacket, version 6.12 [3m].
Language: Determine language from source; memory limit: 1024 MB.
. Module Language: there can only be one expression in the definitions 
window in: (require (quote polynomial))

Interactions disabled.


I'm intrigued.
 

-- 
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] current build instructions for racketcs?

[Sanjeev Sharma]

I haven't done this in a while & the config / build from 

src/cs/c/

using racket 7 source with built packages  failed this morning. 

Are the READMEs still up to date? 

-- 
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] Trying to understand the module system.

[Alex Gian]

A simplified view of the problem I am trying to sort out:

Say I have written a little library, perhaps of various maths utilities.
There are several files all providing different features.  I make them 
available to the user by 'requiring' them and 'providing' them all from the 
top-level main.rkt file.  
No problems there.  I have also made this an installable #lang, lets's call 
it '#lang rat' (for rational, of course) by adding the line
 

(module reader syntax/module-reader rat)

 
to the top of the main.rkt file, and also 

(provide (all-defined-out) #%module-begin #%app #%datum #%top-interaction)

 
So far so good.

Now, say I want some of the modules to have special treatment.  For 
instance, say I don't want the polynomials module to be available 
straightaway when "#lang rat" is fired up, but I want the user to have to 
(require rat/polynomial) [but to be free of having to specify the 
file-path, which may be intricate].  Only the name should be necessary.  If 
I've understood correctly, my polynomials.rkt file will have to be made a 
module (or a submodule).  So I go to that file and instead of #lang racket, 
at the top, I put

(module polynomial racket

  ;; these are all the various polynomial modules:
  (require "pcf.rkt" "fpf.rkt" "rcf.rkt" "pcf-fpf.rkt")
  (provide (all-from-out "pcf.rkt" "fpf.rkt" "rcf.rkt" "pcf-fpf.rkt")
 ; do I need more here? perhaps any of these...
 ; #%module-begin #%app #%datum #%top-interaction
 )
)


This does not seem to help much.  

Furthermore, this is going to become even more important to me soon, as I 
have cases where I have to 'eval' expressions expressions inside syntax, 
and that syntax is not in the same file as my evaluation environment.  I 
know that if I have the handle of the module I can do (module->namespace 
'polynomial) and then use that namespace as the second parameter to eval, 
but how do I get the module handle in the first place?

The example given in the docs:

> (module m racket/base
(define x 11))
> (require 'm)
> (define ns (module->namespace ''m))
> (eval 'x ns)
11


only works in file scope, but if I try to call the "polynomial" module from 
another file, either say the main file, or elsewhere in the code, or even 
in the DrRacket definitions, or the REPL 'polynomial or 'rat/polynomial is 
not recognised (not that I really expected it would)
Trying to specify it by file name is just a disaster.  So how do I define a 
module (or submodule) in one of my files and have it accessible to the rest 
of the program?

I have also read that modules and submodules can be nested, so I thought 
perhaps this was the cause of its failin -, it should should be nested in 
my main.rkt file - but as I said, my module line in main.rkt is merely 
(module reader syntax/module-reader rat), and all the functionality of the 
main file follows it, IOW it's not enclosed, in the (module ...) scope, as 
that is occupied by the 'rat' keyword.

Any hints suggestion tips corrections pointers most welcome, I am off to 
read the documents once again, but it's a bit of a rough slog.  A simple 
tutorial explaining this stuff by example would be most welcome.

The thing is, as I have occasionally mentioned, I am porting old Scheme 
code and as you know, r5rs does not really support modules, so between them 
MIT-Scheme, Guile, and Chez come up with some really imaginative and wild 
ideas to compensate for this.  Environments (the equivalent of modules) get 
augmented and switched - sometimes haphazardly -  and trying to muster it 
all into correct Racket is certainly an educational endeavour...

My apologies for not including actual code.  I have some stuff ready to go 
up on github, but frankly it's still a bit too messy to made public imho.  
I'd like to get some of the basic-basics sorted out first.  If needs 
absolutely must, I will, but I think (that for now at least) I can still 
express the problem clearly enough to be understood in words.

TIA

-- 
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] Using ->i to allow only valid Sneetches for the McBean machine

[Sage Gerard]

Just following up to say thank you. I especially appreciated seeing several
iterations of this to clarify things.

On Mon, Jul 30, 2018 at 6:40 AM Philip McGrath 
wrote:

> Since #t and #f can be used as contracts that recognize only themselves,
> you can get a step better in terms of concision:
>
> #lang racket
>
> (module+ test (require rackunit))
>
> ; Normalizes sneetches depending on belly-star demand.
> (define/contract (convert-sneetches stars-upon-thars? sneetches)
>   (->i
>([demand boolean?]
> [inputs (demand) (non-empty-listof (not demand))])
>[_ (demand inputs)
>   (and/c
>(non-empty-listof demand)
>(compose (curry = (length inputs)) length))])
>   (map (lambda (s) stars-upon-thars?) sneetches))
>
> (module+ test
>   (check-equal? (convert-sneetches #true (list #false)) (list #true))
>   (check-equal? (convert-sneetches #false (list #t #t)) (list #f #f)))
>
> Also, using `_` instead of `result` means that "the range contract
> expressions are evaluated when the function is called instead of when it
> returns." My recollection is that this can be desirable for performance
> reasons.
>
> -Philip
>
> On Mon, Jul 30, 2018 at 4:30 AM, Matthias Felleisen <
> matth...@felleisen.org> wrote:
>
>>
>> Here is a version that is slightly more concise than yours (due to the
>> use of `curry`) and expresses a stronger property. As our introduction to
>> contract illustrates (used to illustrate?) contracts can express a spectrum
>> of properties, all the way from type-like ones to full-fledged correctness.
>> Developers need to acquire a sense of taste to pic the right level of
>> defensiveness. In the end, contracts are really about factoring out the
>> defensive part of modules from the functionality ones and you need to know
>> how defensive you must be in your context. — Matthias
>>
>>
>>
>> #lang racket
>>
>> (module+ test (require rackunit))
>>
>> ; Normalizes sneetches depending on belly-star demand.
>> (define/contract (convert-sneetches stars-upon-thars? sneetches)
>>   (->i
>> ([demand boolean?]
>>  [inputs (demand) (non-empty-listof (and/c boolean? (curry boolean=?
>> (not demand])
>> (result (demand inputs)
>> (and/c
>>  (non-empty-listof (and/c boolean? (curry boolean=? demand)))
>>  (compose (curry = (length inputs)) length
>>   (map (lambda (s) stars-upon-thars?) sneetches))
>>
>> (module+ test
>>   (check-equal? (convert-sneetches #true (list #false)) (list #true))
>>   (check-equal? (convert-sneetches #false (list #t #t)) (list #f #f)))
>>
>>
>> On Jul 29, 2018, at 7:45 PM, Sage Gerard  wrote:
>>
>> Continuing study of contracts, specifically ->i.
>>
>> I am trying to model the machine from *The Sneetches* with the most
>> fleshed out contract possible. Assuming a Sneetch is reduced to a boolean
>> as per the story's problem statement, we can model McBean's machine as:
>>
>> (define (convert-sneetches stars-upon-thars? sneetches)
>>   (map (lambda (s) stars-upon-thars?) sneetches))
>>
>> The demand for stars upon thars or the contrary is a separate parameter
>> to make the problem applicable to ->i, because in the story the machine
>> is only configured to accept Sneetches of the opposite persuasion. That is,
>> if the demand is for stars upon thars, only Plain-Bellies enter the
>> machine. So applications like (convert-sneetches #t '(#t #t #f)) are
>> violations.
>>
>> Here's my attempt at handling this:
>>
>> #lang racket
>>
>> ; Normalizes sneetches depending on belly-star demand.
>> (define/contract (convert-sneetches stars-upon-thars? sneetches)
>>   (->i
>> ([demand boolean?]
>>  [inputs (demand)
>>(non-empty-listof
>>  (and/c
>>boolean?
>>(lambda (b) (equal? b (not demand)])
>> (result (demand inputs)
>>   (non-empty-listof
>> (and/c boolean? (lambda (b) (equal? b demand))
>>   (map (lambda (s) stars-upon-thars?) sneetches))
>>
>> It *appears* to work, but is this correct? I'm not 100% on the binding
>> rules inside a contract body. If this is correct, was there a simpler way
>> to do this?
>>
>> Thanks,
>> Sage
>>
>>
>> --
>> 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.
>>
>
>

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

Re: [racket-users] Re: parameterize and keyword - doable?

[Philip McGrath]

I remembered there is also a paper by Matthew Flatt and Eli Barzilay about
the design of Racket's keyword argument system, including some of the
limitations of symbols-as-keywords systems (especially in sections 6 and 7,
"Experience" and "Related Work"). I obviously found it very persuasive.

http://www.cs.utah.edu/plt/publications/scheme09-fb.pdf

To skip to the conclusion:

Scheme’s  “rest”  arguments  and case-lambda allow flexible
> handling  of  procedure  arguments,  and  they  easily  accommodate
> keyword-like patterns using symbols and lists. When a pattern is
> used widely enough, however, converting the pattern to a language
> construct offers many advantages: better readability, clearer docu-
> mentation, better error messages, easier composition of libraries,
> and a central point of control for implementation details of the pat-
> tern. For all of these reasons, we believe that specific constructs
> for keyword and optional arguments are appropriate for dialects of
> Scheme.
> The essential elements of our design are (1) keywords that are
> distinct from symbols, as in many Scheme systems, (2) a form for
> creating  keyword-based  procedures  that  matches  the  application
> syntax, similar to SRFI-89, (3) disallowing unquoted keywords as
> literal expressions, which is novel in our design, and (4) passing
> keyword arguments to a procedure in a way that reliably separates
> them from by-position arguments, which is also novel.
>

-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] Re: parameterize and keyword - doable?

[Philip McGrath]

On Sat, Aug 4, 2018 at 5:26 AM, George Neuner  wrote:

> On Sat, 4 Aug 2018 00:08:46 -0500, Philip McGrath
>  wrote:
>
> >You can call a function with dynamically calculated keyword arguments
> using
> >keyword-apply
> > keyword-apply#%28def._%28%28lib._racket%2Fprivate%
> 2Fbase..rkt%29._keyword-apply%29%29>,
>
> But the called function has to accept the keyword(s) passed.  The
> issue would seem to be defining functions without using keyword
> literals.
>

This is true of the built-in `keyword-apply`, but using other parts of the
API, particularly `procedure-keywords`, you can dynamically determine what
keywords some function accepts and filter out extraneous ones, either in a
new `keyword-apply`-like function or in a wrapper for the original
function. Either the library author or a client can do this without special
cooperation from the other.


> >and you can create a function that accepts arbitrary or
> >dynamically-calculated keyword arguments (which is rarely desirable) using
> >make-keyword-procedure
>
> But this creates a procedure that accepts anything.  This seems worse
> than the solution using the plist: the keyword accepting variant of
> the function can't have named positional arguments.
>

Actually, the function passed to `make-keyword-procedure` can have required
and/or optional named positional arguments. You can use
`procedure-reduce-keyword-arity` to further specialize what arguments the
resulting function requires and/or accepts.

Racket's built-in keyword argument system is fully dynamic (though
admittedly not always convenient to use dynamically out of the box), but it
also provides great support for the common case where the keywords to be
applied are statically visible, which an ad-hoc symbols-as-"keywords"
system can't.

I've included some examples of working dynamically with keyword functions.
I'm still not sure if this addresses Sanjeev's question, though: he asked
about "a similar #:unless cause for  a bunch of for expressions", which is
a completely different use of syntactic keywords.

#lang racket

(define (keyword-apply-accepted proc kws kw-args by-pos-args)
  (define-values (required-kws accepted-kws/false)
(procedure-keywords proc))
  (define-values (kws* kw-args*)
(cond
  [(list? accepted-kws/false)
   (for/lists (kws* kw-args*)
  ([kw (in-list kws)]
   [arg (in-list kw-args)]
   #:when (memq kw accepted-kws/false))
 (values kw arg))]
  [else ;; -> proc already accepts any keyword
   (values kws kw-args)]))
  (keyword-apply proc kws* kw-args* by-pos-args))

(define (add x #:base [base 0])
  (+ x base))

;; Returns 1:
(keyword-apply-accepted add '(#:dynamic-kw) '(ignored) '(1))

(define add/show
  ;; accepts exactly one named positional argument
  (make-keyword-procedure
   (λ (kws kw-args x)
 (printf "Given Keywords:\n")
 (for ([kw (in-list kws)]
   [arg (in-list kw-args)])
   (printf "  ~v ~v\n" kw arg))
 (keyword-apply-accepted add kws kw-args (list x)))
   add))

;; Returns 1:
(add/show #:ignored "any value" 1)

;; Returns 3:
(add/show 1 #:base 2 #:other "also ignored")


(define add/show/base-required
  ;; Like add/show, but #:base is required
  (procedure-reduce-keyword-arity
   add/show
   (procedure-arity add/show)
   '(#:base)
   #f))

;; Raises an exception:
(add/show/base-required 42)

-- 
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: parameterize and keyword - doable?

[George Neuner]

Hi Philip,

On Sat, 4 Aug 2018 00:08:46 -0500, Philip McGrath
 wrote:

>I'm still not sure that I understand what the original questioner is trying
>to do. It might help to see an example in code to be clear that we're all
>talking about the same thing.

I'm not really certain either, but Sanjeev wrote: 

  "make a keyword useable as the parameter-expr in a parameterize
   expression."

There is there no problem with passing parameter as keyword arguments
or making parameters from keyword arguments.  So I figured he must
somehow be asking about the keyword symbol itself.  

Perhaps he wants to define a set of functions that will take the same
keyword, but he wants the keyword *name* to be settable rather than a
code literal.

There's no way to do that in Racket - at least not any simple way.
Define won't let you use a variable (or parameter) in a formal
position.



>A few points for the list, though:
>
>On Fri, Aug 3, 2018 at 10:53 PM, George Neuner  wrote:
>
>>   (define mykey (make-parameter (string->keyword "#:unless")))
>>
>
>Using (string->keyword "#:unless") will produce the same keyword value as
>(quote #:#:unless), which is *not* the same as the value of (quote
>#:unless).
>
>
>> One thing you might do is define the functions to take a plist "rest"
>> argument, use ordinary symbols for keywords, and parse the arguments from
>> the list.  …
>>   (define (f x y . keys ) ... )
>>   (f 1 2)
>>   (f 1 2 'unless #t )
>>
>
>This is absolutely possible, but I would strongly advise against it.
>
>You can call a function with dynamically calculated keyword arguments using
>keyword-apply
>,

But the called function has to accept the keyword(s) passed.  The
issue would seem to be defining functions without using keyword
literals.


>and you can create a function that accepts arbitrary or
>dynamically-calculated keyword arguments (which is rarely desirable) using
>make-keyword-procedure
>.

Ok, I didn't know about make-keyword-procedure.

But this creates a procedure that accepts anything.  This seems worse
than the solution using the plist: the keyword accepting variant of
the function can't have named positional arguments.

Obviously, you can supply the "plain proc" variant and chain to it
from the keyword list variant - but it seems that the only use for
make-keyword-procedure is to create keyword aware wrappers for other
functions.  IOW: do it twice.


>These support essentially the same interface as an ad-hoc "keyword" system
>using symbols, but take advantage of Racket's (current and future)
>optimizations and features for keyword functions. Perhaps most importantly,
>clients that *don't *need to dynamically calculate keywords can use the
>normal calling conventions without having to worry about all this.
>
>-Philip

YMMV,
George

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