[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MacApp with Mac CL
(Sorry about the previous duplicate posting - gnus is so slow, I thought it
Jonathan (firstname.lastname@example.org) says:
> Even if FF-LOAD could handle C++, MACAPP 3.0 still depends on
> loading object pascal binaries which FF-LOAD cannot handle.
Oh, darn! However, quoting from the MACL version 1.2 manual (1989), "Any
compiler which produces object files of the MPW format may be used."
But I guess that doesnt say any code that such a compiler produces may
Others wondered whether loaded code could have its own global variables.
But the same manual says, "Each call to ff-load produces a distinct foreign
function environment, with its own global space, function code, etc." So
I would presume so, but does it work?
Daniel Ranson (email@example.com) suggests:
> You might consider a MCL engine with a MacApp front-end, but I don't
> think it will be better than a MCL-only design.
This is an intriging idea. Can MCL be used as an extension language
for another program, such as one using MacApp? This would be a fine
solution, provided I could still get some of the advantages of the
common lisp programming environment at runtime. Alternatively can MCL
produce a library of machine code linkable with another application?
National Center for Supercomputing Applications