Menu
▾
▴
jscheme-user
|
From: Ken A. <kan...@bb...> - 2002-09-05 01:24:18
|
I think Tim can answer this. 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 > |
|
From: Timothy H. <tim...@ma...> - 2002-09-05 02:46:53
|
On Wednesday, September 4, 2002, at 09:23 PM, Ken Anderson wrote:
> I think Tim can answer this.
Hmmmm. This is a bug in the sense that the compiled and interpreted
versions
of the code behave differently. However.... I think it is somewhat
subtle.
The problem arises because the compiler assumes that the only macros it
must use to compile the program are the ones that appear in the program
itself.
I think what you want is some way of specifying that a program (say
test.scm)
should be compiled using some specified set of macros (e.g. those in
macro1.scm).
We could modify the compiler to do this, e.g. add a -macro switch,
% java jsint.Compile -v -macro mymacro1.scm test.scm
and this would be equivalent to adding all macros in mymacro1.scm to the
beginning
of the test.scm file.
Does this seem like a reasonable solution to the problem?
---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
>
|
|
From: Timothy H. <tim...@ma...> - 2002-09-05 12:51:44
|
>> 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 > |
|
From: Ken A. <kan...@bb...> - 2002-09-05 13:45:34
|
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 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 > |
|
From: Geoffrey K. <ge...@kn...> - 2002-09-05 14:33:57
|
In DrScheme, when you select another "language," it seems to forget any acquired language features and revert to a base level of functionality before loading on the new functionality. 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 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 |
|
From: Timothy H. <tim...@ma...> - 2002-09-05 18:21:47
|
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
>>
>
|
|
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 |
|
From: Graham S. <fo...@pa...> - 2002-09-05 20:56:50
|
Timothy Hickey wrote: > 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..... I like this sort of approach better than an include statement because it means that as a user of a library, I don't have to remember which definitions are functions and which are macros. If macros and functions are handled differently, then a library provider would have to create two separate files so that the user could do: (include "mylib-macros.scm") (load "mylib.scm") Ideally, the macro definitions would be saved in the java file so that they would work even if the user was loading a compiled .class file, e.g. (mylib.load). This would guarantee that (load "mylib.scm") and (mylib.load) always had the same semantics. It would also allow JScheme libraries to be distributed as .class/.jar files. --g |
|
From: Timothy H. <tim...@ma...> - 2002-09-05 21:16:54
|
On Thursday, September 5, 2002, at 04:55 PM, Graham Spencer wrote:
> Timothy Hickey wrote:
>
> > 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.....
>
> I like this sort of approach better than an include statement because
> it means that as a user of a library, I don't have to remember which
> definitions are functions and which are macros. If macros and functions
> are handled differently, then a library provider would have to create
> two separate files so that the user could do:
>
> (include "mylib-macros.scm")
> (load "mylib.scm")
>
> Ideally, the macro definitions would be saved in the java file so that
> they would work even if the user was loading a compiled .class file,
> e.g. (mylib.load). This would guarantee that (load "mylib.scm") and
> (mylib.load) always had the same semantics. It would also allow JScheme
> libraries to be distributed as .class/.jar files.
This is an interesting point. It would be nice to be able to distribute
libraries as class files
and to have
(load F.scm)
be equivalent to
(F.load).
but this suggests that the compiled class should provide a way of
accessing the defined macros
so that the compiler can extract the macros from the .class file as
easily as from the .scm file, e.g.
(F.getMacros)
could return a hashtable containing the macros defined in the Swing.scm
library.
---Tim---
|
|
From: Ken A. <kan...@bb...> - 2002-09-05 21:38:37
|
No. (F.load) should install the value of all top level symbols, macros or not. IE the effect of (F.load) and (load "F.scm") should be the same, except that the macros and procedures are compiled. k At 05:16 PM 9/5/2002, Timothy Hickey wrote: >On Thursday, September 5, 2002, at 04:55 PM, Graham Spencer wrote: >>Timothy Hickey wrote: >> >> > 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..... >> >>I like this sort of approach better than an include statement because it >>means that as a user of a library, I don't have to remember which >>definitions are functions and which are macros. If macros and functions >>are handled differently, then a library provider would have to create two >>separate files so that the user could do: >> >> (include "mylib-macros.scm") >> (load "mylib.scm") >> >>Ideally, the macro definitions would be saved in the java file so that >>they would work even if the user was loading a compiled .class file, e.g. >>(mylib.load). This would guarantee that (load "mylib.scm") and >>(mylib.load) always had the same semantics. It would also allow JScheme >>libraries to be distributed as .class/.jar files. > >This is an interesting point. It would be nice to be able to distribute >libraries as class files >and to have > (load F.scm) >be equivalent to > (F.load). >but this suggests that the compiled class should provide a way of >accessing the defined macros >so that the compiler can extract the macros from the .class file as easily >as from the .scm file, e.g. > (F.getMacros) >could return a hashtable containing the macros defined in the Swing.scm >library. > >---Tim--- > > > >------------------------------------------------------- >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 > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X