Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!psuvax1!psuvm!VCUVAX!HAMER From: HAMER@VCUVAX.BITNET (ROBERT M. HAMER) Newsgroups: bit.listserv.sas-l Subject: Compiled SAS code Message-ID: Date: 11 Jan 90 22:05:00 GMT Sender: "SAS(r) Discussion" Reply-To: "ROBERT M. HAMER" Lines: 26 Approved: NETNEWS@PSUVM Gateway Original_To: BITNET%"sas-l@vtvm2" Deb Hawley 319-335-6321 writes: > I apologize to the list if this is too technical of a question, > but I can't help but think others might be interested, too. > > If SAS can handle unresolved references as you suggest, why > did they stop with just the DATA step? There's no reason why > references couldn't be resolved at run time to a library > containing the SAS procs? (instead of copying in the entire > thing and storing it in object code, as someone mentioned that > was the reason SAS didn't include PROCS). That's the way I > understand our PL/I libraries to work. Can you explain more? Deb: The PROCs are basically already compiled subroutines. They are written in C (I'm going to stick to version 6 but things hold pretty much the same conceptually for 5) and are called by the SAS supervisor. (Except for a couple of wierd procs procs like NLIN I think that actually have compilable statements.) The various options and statements one uses with a PROC like the PROC, VARIABLE, BY, etc statement really just set parameters which the already compiled proc. SAS probably could have a run-time library designed in like PL/I etc, but if they did, it would have to be huge. They probably chose not to. Some PROCS are a half meg or more just by themselves. If you do it with a run-time library you have a huge library; if you include the compiled code in your program you have a huge load module.