headers
burt rosenberg | 14 Jul 1996 18:35
Picon

bug report

Dear Richard Kelsey and Jonathan Rees,

Scheme48 and mit-scheme do not evaluate a single quoted command
in the same manner, or rather, they do not present the evaluation
result according to the same conventions.

Note the difference in the following evaluations:

ocala 4% scheme48
Welcome to Scheme 48 0.36 (made by burt on Fri Jul 12 16:18:19 EDT 1996).
Copyright (c) 1993, 1994 by Richard Kelsey and Jonathan Rees.
Please report bugs to scheme-48-bugs <at> martigny.ai.mit.edu.
Type ,? (comma question-mark) for help.
> '(a b)
'(a b)
>> ,exit

ocala 5% scheme
Scheme saved on Monday November 22, 1993 at 10:18:36 PM
  Release 7.3.0 (beta)
  Microcode 11.146
  Runtime 14.166

1 ]=> '(a b )

;Value 1: (a b)

1 ]=> (exit)

Kill Scheme (y or n)? Yes
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Galassi | 15 Jul 1996 01:28

little bug in scheme48 installation


Dear Scheme48 people,

I was just installing scheme48 (I am interested in making the libguile
API portable to scheme48), and found a couple of little annoyances.

1. the files extract in the current directory.  that's inconvenient.

2. the directory $(prefix)/lib/scheme48 is not made automatically.

You might want to look into automake (God's gift to the autoconf
user): it would do these things (and many others) for you
automatically and *the right way*.
Permalink | Reply | 1 comment |
headers
Unknown | 15 Jul 1996 01:19

Threads questions

Dear Scheme48 Community,

   I have started looking at the threads implementation. I wonder if anybody
could help me.

-  I don't get the connection between primitive-cwcc (in low.scm) & the VM.

- I that primitive-cwcc is implemented via primitive-catch

- in order to understand threads.scm what directories should I be looking
    through, i.e. rts, alt???

- where is current-continuation??

- what is teh idea behind compose-continuation??? 

Thank you,

Bill Halchin
Permalink | Reply | 0 comments |
headers
Unknown | 15 Jul 1996 01:25

VM question

Dear Scheme48 Community,

   I have spent quite a bit of time reading the VM. However, there is one the
I don't quite understand. When the VM is executing opcode with-continuation,
the code implementing this opcode is written such that it assumes the 
continuation to be restored is on the heap; however, the way the continuation
chain ends up on the heap is if "ensure-space" "trips the wire" & forces
the chain to be copied from stack to heap. I don't see how one can assume that
teh cont to be restored is on the heap!!! 

Regards,

Bill Halchin
Permalink | Reply | 0 comments |
headers
Margaret M Fleck | 15 Jul 1996 19:48
Picon

redefining quote


In Scheme48 (0.36 and 0.42), it seems to be possible to redefine
syntactic keywords but not #f or #t.  Perhaps there are good reasons
why someone might want to redefine some of the keywords, and the
scheme standard appears to allow it as an optional "feature" of an
implementation, but I don't think it is a good idea to allow quote to
be redefined.

In particular, the following minor error braindamages scheme48 because
it redefines quote.  

   (define 'foo 3)

The conditions under which one might do this, and the resulting
brain-damage, are similar to redefining #t or #f.  This is something
that would not be written by an experienced lisp programmer, but could
easily be written by a novice or by a program or macro.  I ran into
this problem while writing a macro whose output code includes a
define.  Even by scheme48 standards, the resulting errors were
unusually mysterious.

The situation in scheme seems to be reversed from other lisp dialects

   -- common lisp:  it is easy for a novice to redefine t, because t
        is a likely name for a user-defined variable.  It's less likely
        that they will redefine quote because it looks more like a keyword.
        (defun 'foo 3) won't redefine quote because common lisp's syntax
        differs from scheme's. 

   -- scheme:  #t and #f look obviously unlike variable names, so one would
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul R. Wilson | 15 Jul 1996 20:39
Picon

Re: redefining quote

>From mfleck <at> cs.uiowa.edu Mon Jul 15 12:53:39 1996
>To: scheme-48-bugs <at> martigny.ai.mit.edu
>Cc: des <at> shasta.cs.uiowa.edu
>Subject: redefining quote
>
>
>In Scheme48 (0.36 and 0.42), it seems to be possible to redefine
>syntactic keywords but not #f or #t.  Perhaps there are good reasons
>why someone might want to redefine some of the keywords, and the
>scheme standard appears to allow it as an optional "feature" of an
>implementation, but I don't think it is a good idea to allow quote to
>be redefined.

I think this is a great feature, if the implementation of it actually
works.  It's really nice to be able to change things like the behavior
of quote (e.g., to allow you to implement systemsy things like literal
coalescing without modifying the compiler, and other weirder quasi-
reflective tricks.

>In particular, the following minor error braindamages scheme48 because
>it redefines quote.  
>
>   (define 'foo 3)
>
>The conditions under which one might do this, and the resulting
>brain-damage, are similar to redefining #t or #f.  This is something
>that would not be written by an experienced lisp programmer, but could
>easily be written by a novice or by a program or macro.  I ran into
>this problem while writing a macro whose output code includes a
>define.  Even by scheme48 standards, the resulting errors were
(Continue reading)

Permalink | Reply | 0 comments |
headers
Margaret M Fleck | 15 Jul 1996 21:07
Picon

static variables


Scheme48---specifically 0.36 and 0.42---seems not to support defines
inside other forms, a feature permitted by not required by the scheme
standard.  As a general rule, it's easy to code around this
limitation.  However, it's very annoying that, when forms like the
following are typed at top-level, the defines are regarded as not
being top-level:

   (let ((ourqueue '()))

     (define push (lambda (x) (set! ourqueue (cons x ourqueue))))

     (define pop (lambda () 
        (let ((item (car ourqueue)))
           (set! ourqueue (cdr ourqueue))
           item))))

Am I missing something, or do I have to use one of the following
work-arounds for variables that are static and/or shared?

  (a) Use the module system.  This is not portable.  Also, it's
      not convenient when the static variable is only used by
      one or two small functions.  

  (b) The following species of un-lisp-like kludge

     (define push #f)
     (define pop #f)

     (let ((....))
(Continue reading)

Permalink | Reply | 0 comments |
headers
Margaret M Fleck | 15 Jul 1996 23:50
Picon

Re: static variables


Ooops.... please disregard my last message.  I realized shortly after
sending it---<sigh>--how to solve my problem more elegantly using
call-with-values.

Margaret
Permalink | Reply | 0 comments |
headers
Margaret M Fleck | 16 Jul 1996 19:56
Picon

odd behavior (bug?) involving quote and define


The following type of construct (typed at top-level) brain-damages
scheme, apparently by redefining quote.

   (begin [something that produces an error break]
          (define 'foo ....))

To the best of my understanding, when processing a form of this type,
the interpreter should halt when the first form creates the error
break and not touch the second form.  However, in Scheme48 0.36 and
0.42, it seems to be doing something with the second form, at least in
certain cases.

I ran into this problem trying to prevent users of my system from
accidently redefining quote by mis-using one of my macros.  In this
case, the error break was created by a call to error, embedded inside
various interesting tests on the form of the input.  However, it's
easier to illustrate with the example

   (begin (/ 3 0)
          (define 'foo 5))

as in the attached transcript.  

We are running 0.36 on an IBM RS6000---we're still trying to get
0.4xxx to work---and 0.42 on a linux machine.  There is a slight
difference between 0.36 and 0.42.  0.36 prints a complaint about
division by zero, whereas 0.42 processes the form without comment.
The subsequent brain-damage in the interpreter's behavior, however,
seems to be identical.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Margaret M Fleck | 17 Jul 1996 19:38
Picon

odd behavior (bug?) involving quote and define


Henry Cejtin very nicely explained that examples like
        (begin (/ 3 0)
               (define 'foo 5)) are illegal because, strictly
speaking, everything inside a begin has to have the same type
(e.g. all defines or all commands or all syntax definitions).  Careful
inspection of R4RS suggests he's right.

However, 
   (a) I don't see why it is illegal to mix expressions and definitions
       in begin at top-level.  The semantics is obvious and would seem
       to create no difficulties:  evaluate the items in sequence just as
       if they were typed into the top-level interpreter separately in
       the same order.

   (b) Scheme48 is happy to accept such constructs at top-level and
       evaluates them in the obvious way.

       (begin (+ 2 3)
           (define a (lambda (x) (+ x 1)))
           (* 3 7))

       So there's a bug either way:  either scheme48 should give me
       an error about mixed-type begins or it should evaluate them
       consistently.

   (c) Lack of such a construct seems to mean that there is no way
       to write a macro which checks that an input (e.g. from a naive
       user) is a symbol before passing it as the first argument to define.
       In particular, when generating output of the form
(Continue reading)

Permalink | Reply | 1 comment |

Gmane