See below. --- Michael Zacharias <[EMAIL PROTECTED]> wrote:
> see my inline responses below... > > > Michael > > --- James Gray <[EMAIL PROTECTED]> wrote: > > > I do not understand the value or point of this. Both examples seem > more > > complicated than either of the two one line statements that Kevin > has below. > > I guess it comes down to personal preference. I have to agree with > what Greg > said about the level of abstraction. To me, I find it easier to say: > > S NAM=Pat.name > > This way, I don't have to know in what global/piece the data is > stored, what > the IEN is, etc. When I code, I like to build the programming > language up to > the application. [Greg] That's an interesting phrase (I like it). To me, this is a bit of balancing act, because simplicity in language design is also important. However, I believe the fundamental abstractions (or maybe meta-abstractions?) with which you work *should* be incorporated into the language itself. MUMPS is powerful, in large measure, due to its arrays and global subsystem, which eliminate a lot of complexity that would be present in languages where these data structures need to be built "from scratch". The problem, though, is that files and globals are different things, with very different properties. The language supports one, but the other can only be handled through libraries (like the DBS API). The downside to supporting abstractions of this type is that des involve a certain syntactic and semantic overhead, leading to languages that can be complex and difficult to use. I think that one reason I tend to prefer functional languages over others is the simplicity. > To me, the level of abstraction of my example is > one step > higher than using the Fileman API. [Greg] Yes. Perhaps one issue is that syntax that looks at all SQL-like does tend to provoke a bit of a visceral reaction, at least for some members of this list, and that may be a bit of what you're seeing. But, in any case, I'm not really sure that the relational abstraction is the right one, at least at the language level. I've considered alternatives ranging from trying to incorporate an ODMG type data model into the base language (and, yes, I know what C.J. Date has to say about ODMG!) to a simpler list based syntax. Right now, I'm especially interested in explicitly typed functional languages (like ML or Haskell) though, frankly, I feel more at home with LISP. I'm also intrigued by AllegroCache, perhaps because it seems so MUMPS-like. An idea I've floated before (and am still exploring) is functional Fileman. Though I once thought an ODMG type approach would be best, I'm now leaning toward an explicitly typed functional approach. > > > > I do not understand how this is connected to Greg concept of making > Fileman > > language independent. > > I took Greg's comments of making Fileman language independant to mean > not > dependant on knowing the ins-and-outs of how Fileman works. [Greg] Exactly. > The API > does a > nice job of this, but I think it could be better. I don't think this > higher > abstraction can be achieved through ANSI M programming constructs. [Greg] I don't know. I *do* think a lot more could be done to support the necessary abstractions through ANSI M, simply by enhancing the Fileman API. However, this does not mean I don't think the language needs to change, and I certainly don't see libraries of extrinsic functions as a viable substitute for updating the langguage. > You could > do quite well using a functional programming style, but I think to > achieve a > seperation from "programming with the knowledge of how Fileman > works", to just > programming, some kind of a compiler/macro facility is needed. [Greg] That sounds like a good approach to me, too. > > In my examples, I used a '&&' notation to indicate a macro. In my > mind, this > would translate into a macro expansion that would contain the code to > return > the patient's name. As an application level programmer, I didn't > have to know > that the patient's name was in file number 200 of the ^DD global at > piece > number 1, etc...That was all handled by the macro. > > === Gregory Woodhouse <[EMAIL PROTECTED]> "All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident." --Arthur Schopenhauer ------------------------------------------------------- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
