jscheme-user

[Jscheme-user] modules?

[Ken A. <kan...@bb...>]

Some questions about modules.

? is there a way to export symbols?  For example, in the elf/future.scm i wanted to export future, future?, determined?, touch, and i wanted to have the other procedures not show up in the user's environment.

Rather than loading a module and seeing the exported symbols, i have to explictly import it with a prefix say, "f:".  Then i either have to say
(f:future x) or
(define future f:future)

This doesn't seem right.

[Jscheme-user] Minor nuisance/inconsistency

[Robert J. B. <ru...@bb...>]

Folks,
I  would expect that (cadr x) and (car (cdr x)) would behave identically 
in all circumstances. Yet I find that car and cdr behave like Common 
Lisp and return '() when given '() as an argument (I like this, 
personnaly) and cadr throws an exception when handed '();

I think the inconsistency is annoying -- I really prefer not to have 
(car (cdr x)) in my code.

Any recommendations?
--Rusty Bobrow

Re: [Jscheme-user] Minor nuisance/inconsistency

[Geoffrey K. <ge...@kn...>]

I ran into something similar this morning.  Both (car ()) and (cdr ()) 
returned (), while according to MIT Scheme, which I use for reference, 
feeding () to either car or cdr was a no-no.  In the case of car, I 
knew that.  In the case of cdr, I had to remember that (cdr ()) was OK 
in Lisp but not in Scheme.

Like Rusty, I don't mind that (cdr ()) returns (), but I have a small 
problem.  I have some expressions to debug that look like (caar (cddr 
X)) that I'm trying to debug by taking them apart (car (car (cdr (cdr 
X)))), and I'm getting exceptions in the former but not in the latter.

Geoffrey

On Friday, March 7, 2003, at 11:20 AM, Robert J. Bobrow wrote:

> Folks,
> I  would expect that (cadr x) and (car (cdr x)) would behave 
> identically in all circumstances. Yet I find that car and cdr behave 
> like Common Lisp and return '() when given '() as an argument (I like 
> this, personnaly) and cadr throws an exception when handed '();
>
> I think the inconsistency is annoying -- I really prefer not to have 
> (car (cdr x)) in my code.
>
> Any recommendations?
> --Rusty Bobrow

Re: [Jscheme-user] Minor nuisance/inconsistency

[Timothy H. <tim...@ma...>]

On Friday, March 7, 2003, at 11:20 AM, Robert J. Bobrow wrote:

> Folks,
> I  would expect that (cadr x) and (car (cdr x)) would behave 
> identically in all circumstances. Yet I find that car and cdr behave 
> like Common Lisp and return '() when given '() as an argument (I like 
> this, personnaly) and cadr throws an exception when handed '();
>
> I think the inconsistency is annoying -- I really prefer not to have 
> (car (cdr x)) in my code.
I've fixed that inconsistency, cadr and caddr were treated differently 
from all other cadadars

I have however kept that behavior for second and third.
So (second '(a)) --> error
       (cadr '(a)) --> ()
Perhaps it would be better to have second and third adhere to the same 
semantics of cadr and caddr,
but in a way it makes sense for second/third to give errors if the lists 
are too short....
I'd also like to add third, fourth, fifth, .... up to tenth or so....

What do you think?
---Tim---

Re: [Jscheme-user] Minor nuisance/inconsistency

[Robert J. B. <ru...@bb...>]

Tim,
I am comfortable with second and third showing an error -- their 
intended semantics is to treat the sequence of linked pairs as a linear 
structure and get the numbered element. It is an "implementation detail" 
that second is the same as cadr. I also support having symbolic methods 
fourth, ... tenth -- I keep getting burned by their absense.
Thanks,
Rusty


Timothy Hickey wrote:

>
> On Friday, March 7, 2003, at 11:20 AM, Robert J. Bobrow wrote:
>
>> Folks,
>> I  would expect that (cadr x) and (car (cdr x)) would behave 
>> identically in all circumstances. Yet I find that car and cdr behave 
>> like Common Lisp and return '() when given '() as an argument (I like 
>> this, personnaly) and cadr throws an exception when handed '();
>>
>> I think the inconsistency is annoying -- I really prefer not to have 
>> (car (cdr x)) in my code.
>
> I've fixed that inconsistency, cadr and caddr were treated differently 
> from all other cadadars
>
> I have however kept that behavior for second and third.
> So (second '(a)) --> error
>       (cadr '(a)) --> ()
> Perhaps it would be better to have second and third adhere to the same 
> semantics of cadr and caddr,
> but in a way it makes sense for second/third to give errors if the 
> lists are too short....
> I'd also like to add third, fourth, fifth, .... up to tenth or so....
>
> What do you think?
> ---Tim---
>
>

[Jscheme-user] Re: modules?

[Timothy H. <tim...@ma...>]

On Friday, March 7, 2003, at 11:15 AM, Ken Anderson wrote:

> Some questions about modules.
>
> ? is there a way to export symbols?
Currently, everything is exported....
>  For example, in the elf/future.scm i wanted to export future, future?, 
> determined?, touch, and i wanted to have the other procedures not show 
> up in the user's environment.
>
> Rather than loading a module and seeing the exported symbols, i have to 
> explictly import it with a prefix say, "f:".
or you can import everything without a prefix ...
>  Then i either have to say
> (f:future x) or
> (define future f:future)
The current implementation allows either a prefixed importation
(environment-import "abc.scm" "f:")
or a non-prefixed import
(environment-import "abc.scm")
There is currently no way to import only a selected subset
or to export a selected subset...

Actually, you can "hack" export using set!,
The set! makes the assignment occur in the toplevel
environment and the (let () ...) hides all the other
assignments ...

> (
>   (let ()    ;;; define future, future? etc inside a let() environment
>     (define (future x) ...)
>     (define (future? x) ...)
>      ...
>     (list future future? ...))
>
>   (lambda R  ;;; use set! to lift these definitions to the global 
> environment
>     (set! future (first R))
>     (set! future? (second R))
>     ...)
> )

We could easily write a little macro which implements this style
of export:

>   (export (future future? ...)
>     (define (future x) ...)
>     (define (future? x) ...)
>     ...
>   )
>


Similarly, we could wriite a macro to import just a few values from a 
file
> (import "elf/future.scm" (future future?  ...))

which could expand to
>  (import "elf/future.scm" "HIDDEN:")
>  (define future HIDDEN:future)
>  (define future? HIDDEN:future?)
>  ...

Other variations could be implemented as well (import-all-but ....) etc.

---Tim---

Re: [Jscheme-user] Re: modules?

[Timothy H. <tim...@ma...>]

On Friday, March 7, 2003, at 11:35 AM, Timothy Hickey wrote:
> We could easily write a little macro which implements this style
> of export:
>
>>   (export (future future? ...)
>>     (define (future x) ...)
>>     (define (future? x) ...)
>>     ...
>>   )
>>
>

;; Here is a version of the macro that implements "export"
;; I create the "bigsym" symbol to strictly include all other symbols
;; and hence be different from them, kind of a gensym....

(define (export Symbols . Body)
   ; this bigsymbol is guaranteed to be different from all individual 
symbols
   (define bigsym (string->symbol (apply string-append (cons "R_" (map 
.toString Symbols)))))
   (define (make-defines N S)
      (if (null? S) ()
          (cons `(set! ,(first S) (list-ref ,bigsym ,N))
                 (make-defines (+ N 1) (rest S)))))
   `((lambda (,bigsym)
        ,@(make-defines 0 Symbols))
     (let () ,@Body ,(cons 'list Symbols))
    ))

e.g.

(export '(R S) (set! R 1) (set! S 2))

  -->

(  (lambda (R_RS)
          (set! R (list-ref R_RS 0))
          (set! S (list-ref R_RS 1)))

     (let () 1 2 (list R S))
)

Oh... but this will still have problems if list-ref is one of the symbols
being exported.... This is why hygeniec macros are nice....

---Tim---



>
> Similarly, we could wriite a macro to import just a few values from a 
> file
>> (import "elf/future.scm" (future future?  ...))
>
> which could expand to
>>  (import "elf/future.scm" "HIDDEN:")
>>  (define future HIDDEN:future)
>>  (define future? HIDDEN:future?)
>>  ...
>
> Other variations could be implemented as well (import-all-but ....) etc.
>
> ---Tim---
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The 
> debugger for complex code. Debugging C/C++ programs can leave you 
> feeling lost and disoriented. TotalView can help you find your way. 
> Available on major UNIX and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Jscheme-user mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>