--- "Richard G. DAVIS" <[EMAIL PROTECTED]> wrote: > Greg..... > > Is the VistA KERNEL an example of what you have in mind? >
Indeed, the VistA Kernel could serve as a foundation for an implementation of the standard library. > What, if any, are the distinctive characteristics of the library you > propose > that are not present in the VA KERNEL implementation of platform > independent > services? There are a few things. For one, given that the library would be supported by a special syntax, it would not be necessary to use extrinsic functions or ask users to load third party libraries (like VA Kernel). It would also not be possible for users (programmers) to make illicit use of internal entry points. It would free the implementers to avoid writing implementations in MUMPS when it is awkward, inefficient, or simply impossible to do so. The programmer would not have to know or care whether his/her library call was really "MUMPS under the hood" or not. > > Moreover, why push these solutions down into the 'language' level of > abstraction? Would it not be wiser to create a HIGHER level of > abstraction ... I don't see a conflict here. Providing access to basic functionality like UDP, device handling, asynchronous interrupts, etc. has nothing to do with implementing high level abstractions. They're just different pieces of the language puzzle. > in which these services reside, and where the generality of these > services > can have a wider scope than just within the MUMPS (sic) context? > I'm not sure that I follow you here. By "generality" do you mean I higher level of abstraction, or are you speaking of availability that goes beyond MUMPS code? In fact, I have some thoughts about incorporating high level abstractions into the MUMPS language, but did not mention it here because I see it as an entirely different issue. If you are referring to issues like linking MUMPS into applications written in other languages, allowing classes to be implemented in MUMPS but used in other environments (like Java, Python or C++) then, again I agree that this would be a good thing, but it's also quite a separate issue -- that is except insofar as a standard library would facilitate linking (in the technical sense) code modules written in MUMPS with other applications. > I prefer thinking that attempts to cast the problem at a level that > makes > the next solution, the last solution needed for the foreseeable > future, and > perhaps beyond. > I guess it just depends on the problem you're trying to solve. If I want to write a TCP/IP application in MUMPS, then I have to use features of implementations that go beyond the standard. I don't consider that an acceptable option. If cannot receive notification that data has arrived on a socket and am, instead, forced to poll for data, my implementation will be awkward, slow, and difficult to maintain. These are the types of issues I believe that could be appropriately addressed through a standard library. But I suspect you are talking about something rather different, such as beinf forced to write relatively low level procedural code when an application could more naturally be built using a functional or object oriented language. And as I said before, those are also issues I'd like to see addressed, but it's best to take them one at a time. > Regards, > > Richard. > === Gregory Woodhouse <[EMAIL PROTECTED]> "Interaction is the mind-body problem of computing." --Philip L. Wadler ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
