From: Geoffrey K. <ge...@kn...> - 2002-09-05 18:29:33
|
Maybe there could be a way to mark certain symbols against accidental overwriting. If you really wanted to reimplement or override some of the basic functions, could you unprotect them first. Geoffrey On Thursday, September 5, 2002, at 02:20 PM, Timothy Hickey wrote: > > > On Thursday, September 5, 2002, at 09:45 AM, Ken Anderson wrote: >> I'm not opposed to a module approach, but what happens in Common Lisp >> is that macros become part of the compiler's environment. So when >> the compiler compiles something it uses all the macros its seen. > > At 07:24 PM 9/4/2002, Graham Spencer wrote: > .....snip.... >> The (load "macro2.scm") works as expected, but in (macro2.load), the >> macro defined in macro1.scm is expanded but not evaluated. > > This is a bug, it should either evaluate as expected or signal an > error, the expansion is just wrong... > >> In general, I cannot get macros defined in one compiled .class file >> to work in another file. > >> Am I doing something wrong, or is this really a bug? > > We need to do something about this, whether it is a bug or not. > The brute force method is just to copy the macros you need into every > file that uses them, > but this is clearly wrong as it calls out for refactoring. > > Using an "include" statement to include the macros into the file is a > simple approach > but it could be abused if something besides macros is included. > > The Common Lisp approach is a good idea. It shouldn't require too much > of a change to implement it. > It does create problems if someone compiles a program that redefines > one of the base macros > (like cond or do) as this will break the compiler...... > With this method we would handle Graham's macro1.scm macro2.scm > example by compiling them together.. > %java jsint.Compile macro1.scm macro2.scm > > We could also automatically compile macro1.scm when the (load > "macro1.scm") expression is compiled > in macro2.scm or we could just scan through it and pull out the macro > definitions..... > > A final approach is to create a special directive for loading in > macros, e.g. > (load-macros "macro1.scm") > which the compiler could use to specify the language that should be > used during > the current compilation. > > I like the last idea. It is relatively simple to implement. It has a > simple semantics, > and it solves Graham's problem. > > On the other hand the "include" option is even simpler and its only > drawback is that > it might be dangerous for people who don't know what they are doing, > but *hey* so > are the macros we use in jscheme..... > > Ideas or Comments?? > > ---Tim--- > > > > > > >> >> At 08:51 AM 9/5/2002, Timothy Hickey wrote: >> >>> On second thought, Graham's example points out the need for modules! >>> In Dr. Scheme, one can specify a "language" when importing a module. >>> The language is a collection of macros. >>> >>> I'll take a closer look at how the jscheme compiler handles macros >>> and report back to this list. >>> >>> It would be nice to have someway of indicating in the program code >>> that the program should be compiled using some set of macros. >>> One easy way would be to add an "include" command that would simply >>> include the macro code in the source before compiling, e.g. >>> >>> ;; macro2a.scm >>> (include "macro1.scm") >>> (define-macro (myplus2 a b) >>> `(+ ,a ,b)) >>> (.println java.lang.System.out$ (myplus1 1 2)) >>> (.println java.lang.System.out$ (myplus2 1 2)) >>> >>> This is essentially the way the C handles shared type declarations, >>> by storing them in .h files which are then included whereever they >>> are needed. >>> >>> What do you think?? >>> ---Tim--- >>> >>> >>>>> At 07:24 PM 9/4/2002, Graham Spencer wrote: >>>>>> Hello, >>>>>> >>>>>> I think I've found a bug in JScheme version 5.0.0. Given the >>>>>> following two files: >>>>>> >>>>>> ;; macro1.scm >>>>>> (define-macro (myplus1 a b) >>>>>> `(+ ,a ,b)) >>>>>> >>>>>> ;; macro2.scm >>>>>> (load "macro1.scm") >>>>>> (define-macro (myplus2 a b) >>>>>> `(+ ,a ,b)) >>>>>> (.println java.lang.System.out$ (myplus1 1 2)) >>>>>> (.println java.lang.System.out$ (myplus2 1 2)) >>>>>> >>>>>> If I compile both files to .class files and then run jscheme.REPL: >>>>>> >>>>>> Jscheme 5.0 04/05/2002 http://jscheme.sourceforge.net >>>>>> > (load "macro2.scm") >>>>>> 3 >>>>>> 3 >>>>>> #t >>>>>> > (macro2.load) >>>>>> (+ 1 2) >>>>>> 3 >>>>>> #null >>>>>> >>>>>> The (load "macro2.scm") works as expected, but in (macro2.load), >>>>>> the macro defined in macro1.scm is expanded but not evaluated. In >>>>>> general, I cannot get macros defined in one compiled .class file >>>>>> to work in another file. Am I doing something wrong, or is this >>>>>> really a bug? >>>>>> >>>>>> (My apologies if I should have posted this bug report somewhere >>>>>> else.) >>>>>> >>>>>> Thanks for your help, >>>>>> >>>>>> --g >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------- >>>>> This sf.net email is sponsored by: OSDN - Tired of that same old >>>>> cell phone? Get a new here for FREE! >>>>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 >>>>> _______________________________________________ >>>>> Jscheme-user mailing list >>>>> Jsc...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/jscheme-user >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This sf.net email is sponsored by: OSDN - Tired of that same old >>>> cell phone? Get a new here for FREE! >>>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 >>>> _______________________________________________ >>>> Jscheme-user mailing list >>>> Jsc...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jscheme-user >>> >>> >>> >>> ------------------------------------------------------- >>> This sf.net email is sponsored by: OSDN - Tired of that same old >>> cell phone? Get a new here for FREE! >>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 >>> _______________________________________________ >>> Jscheme-user mailing list >>> Jsc...@li... >>> https://lists.sourceforge.net/lists/listinfo/jscheme-user >>> >> > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Jscheme-user mailing list > Jsc...@li... > https://lists.sourceforge.net/lists/listinfo/jscheme-user > > -- Geoffrey S. Knauth http://knauth.org/gsk |