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

[Alex Gian]

(new links, old ones not working after refactoring)

> 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 49   (I intend to use the chez one which is commented out 
(just for the build))

Oops,  I forgot to put in the message.  Here it is:-  (when trying to run 
rules.rkt)

Welcome to DrRacket, version 6.12 [3m].
Language: racket, with debugging; memory limit: 1024 MB.
rule:make: unbound identifier;
 also, no #%app syntax transformer is bound in: rule:make
> 

*Why would the system give back this message re an identifier KNOWN to be 
bound?*
All requires appear set correctly.
It is bound here 
 
- 'rule-syntax.rkt' line 24, and also invoked in line 54 in the same file. 

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

Looking over the Racket namespace routines, I think I can get them to map 
pretty much exactly to the way *scmutils* uses environments.  Not as bad as 
I expected, in fact I think it might be relatively easy.  I have never 
worked with namespaces in this way before, but even so everything seems 
reasonably clear.

As Philip said there may be far better ways to do this, but I want to get 
the code up and working, as close to the *scmutils* original as is 
practical, and only from then start improving / refactoring / modularising 
/ substituting or whatever.   (Racket/serialize sounds interesting)

On Sunday, August 5, 2018 at 3:16:34 AM UTC+1, Alex Gian wrote:
>
> 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.

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.

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.

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