headers
Heath Putnam | 10 Dec 2005 16:58

Problem in INTEGRATE-JUMP-PROCS!


The following is a procedure that the prescheme compiler fails on. I'm
not what it should do when given such a procedure --
e.g. automatically "lambda lift" FAIL's LEN parameter, give an error
saying that FAIL can't be turned into a jump, etc. 

I do think the error that appears is quite cryptic:

"Error: variable #{Variable len 326} has no vector location
  (compiler error)
       (&error)"

As far as I can tell, the problem happens when PROCS->JUMPS tries to
turn LOOP and FAIL into jumps. It winds up moving FAIL above the
binding for LEN, which is an error. Changing FAIL (and applications of
FAIL) so that len is not free fixes things.

Here's the procedure, derived from my real program, and as simplified
as I can get it:

;; This is about as small as it gets, and still breaking things.
(define (bad-proc)
  (let loop ()
    ;; try to get a new result buffer if it is missing
    (let ((len ((external "dummy" (=> () integer)))))
      (let ((fail (lambda () 
		    ((external "output" (=> (integer) unit)) len))))
	(if ((external "b" (=> () boolean)))
	    (if (= 2 (unsigned-byte-ref (address+ (address+ null-address 2) 1)))
		(loop)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Heath Putnam | 10 Dec 2005 22:22

Seemingly related problem with the Prescheme Compiler 1.3


I reported a problem in the Pre-Scheme compiler version 1.3 earlier
today.

Here's a related program, where rather than giving a cryptic error
message, the compiler produces a program that looks OK but fails to
initialize some data. The program uses the data for a test, which is
really tricky.

In the generated .c file, the routine fails to move the result of the
call to DUMMY into the LEN variable. Later LEN gets used as if it were
valid.

The cause seems to be the same as before: INTEGRATE-JUMP-PROCS! hoists
the use of LEN above the thing that binds it. But this time the thing
gets simplified into something the compiler can deal with. 

I don't know if the funny-looking name, "len_<erased>" appearing in
the PP-CPS'd tree is important.

I'm sorry the program is so complicated -- it is a simplified version
of a macro-expanded program.

I believe changing FAIL to take len as a paramter, and passing around
LEN, makes it work.

(define (dummy x)
  (if ((external "foo" (=> (integer) boolean)) x)
      12
      (dummy (- x))))
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Sperber | 12 Dec 2005 17:44
Picon

Re: Problem with read-write files in Scheme 48 1.3


Hi Heath,

sorry for the huge delay---I'm back, but still busy sifting through
the swamp I'm in ...

Heath Putnam <hp <at> heathputnam.com> writes:

> Either I misapplied the patch, or scheme48 is still not working the
> way I think it should.

Probably---on the development version, your code works, at least for
me.  (Otherwise, I'm probably not quite up to speed on the issue and
you'll need to kick me again.)  Here is the relevant code verbatim:

scheme/posix/dir.scm:

(define (open-file path options . mode)
  (let* ((input? (file-options-on? options (file-options read-only)))
	 (channel (call-imported-binding posix-open
					 path
					 options
					 (if (null? mode)
					     #f
					     (car mode))
					 input?)))
    (if input?
	(input-channel-≥port channel)
	(output-channel-≥port channel))))
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Sperber | 12 Dec 2005 18:46
Picon

Re: VM exceptions closing socket output channels


Working through my stack of bug reports ...  Again, sorry for the
delay.

Brian Templeton <bpt <at> tunes.org> writes:

> I'm getting sporadic errors closing socket output channels, e.g.:
>
>   Error: vm-exception
>          os-error
>          (call-external-value "s48_close_socket_half" 22 "Invalid argument")

First off, I can reproduce the problem, but looking at a system-call
trace, it seems it's coming from the OS, and Scheme 48 is just
reporting what the OS is telling it.  I don't know if it's just the
way "ab" does its work, but I see no funny business on the Scheme 48
side.

Now, the reason you're seeing it in your program is this:

(define (handle-request in out)
  (let ((close-connection
         (lambda ()
           (if (open-input-port? in) (close-input-port in))
           (if (open-output-port? out) (close-output-port out)))))
    (with-error-handler
     (lambda (condition punt)
       (close-connection) ; <-- (2)
       (punt))
     (lambda ()
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Sperber | 20 Dec 2005 09:41
Picon

Re: scheme48-1.3 install segmentation error


Sorry for taking so long to get back to you---I've finally located a
Fedora Core machine to try and reproduce this, when I realized:

Doug Telford <doug <at> dougtelford.com> writes:

> Target: x86_64-redhat-linux

Unfortunately, we currently don't support 64 bits---you need to be
compiling in 32-bit mode.  (And I need to check this in a configure
test and a note in the next-generation installation instructions.)

--

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
Permalink | Reply | 0 comments |
headers
James Graves | 29 Dec 2005 17:34
Favicon
Gravatar

First order functions vs. macros


There's an interesting thread with the subject "Why aren't THEY using
Bigloo" going on in comp.lang.scheme, if you haven't seen it already.

One of the interesting sub-threads has a couple posts by Ray Dillinger
about his idea for replacing the need for macros with a more general
first-order function call scheme.

There are definitely some issue with his description, the first among
them being performance, because you are doing the equivalent of macro
expansion at runtime instead of compile time.

However, the biggest concern I have is about security and object-level
encapsulation.  Instead of passing a fully evaluated function argument,
we could instead be passing the unevaluated argument, and the calling
environment.

Currently in Scheme 48, (from my understanding), the macro code expands
in the environment where it is called, though it does have access to the
 environment of the module where it was defined.

Does Ray's proposed first order function semantics circumvent the
security of Scheme's current system?  Am I interpreting things
correctly?   I would like to get a little feedback from the S48 group
before I discuss it further on comp.lang.scheme.

Thanks,

James Graves
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Sperber | 29 Dec 2005 17:57
Picon

Re: First order functions vs. macros


James Graves <ansible <at> xnet.com> writes:

> However, the biggest concern I have is about security and object-level
> encapsulation.  Instead of passing a fully evaluated function argument,
> we could instead be passing the unevaluated argument, and the calling
> environment.
> [...]

I'm not sure what one has to do with the other.  All bear seems to be
proposing is to implicitly turn arguments into promises.  This could
easily be done via a syntactic mechanism as well.  (I see how this
covers one trivial use of macros, but leaves most uncovered.)

> Currently in Scheme 48, (from my understanding), the macro code expands
> in the environment where it is called, though it does have access to the
> environment of the module where it was defined.

There are many possible meanings to that sentence, depending on what
you mean by "macro code".  The transformer, generally, is evaluated in
the environment where it occurs.

There are security issues with macros, to be sure, but I haven't
studied them in detail.  The PLT folks are doing something with
"syntax certificates" which you may find instructive.

--

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
(Continue reading)

Permalink | Reply | 0 comments |

Gmane