On Monday 12 August 2002 18:58, you wrote: > Charles: > > [In RE: multiparadigm programming, some thoughts relevant to your remarks > follow...] > > %% Charles Hexton wrote: > > %% The problem that I have with many of those paradigms, is that > %% they don't easily support the idea of data files. Particularly > %% of data files that may be looked at and changed in some other > %% language. ... > Well at the binary level most of the data types in all languages are > reducible to bytes, or some compound thereof; I'm not exactly sure I guess > what you mean. Oz for instance treats all serialized file system objects as > standard "pickles," and under the hood, being developed as it is in > templatized ANSI C++, it ultimately uses data structures that are quite > compatible with C/C++ and any language that has analogous data structures. > Not sure I understand your point here... > I have some things I want to do (quite a large number, actually) that can be completely specified at compile time. Others where I at least know the type and length of the parameters. And others where things are pretty open, where I can be reading a piece of data, and be expecting the data to tell me itself whether it's a number, or a word definition, or a picture, or... When it gets in, I want it to be living in an object of the appropriate type. So far the languages that I can see how to do this in are C, Python, and Ruby. And in C it's too clumsy for words. But I was taught that when you can specify things at compile time, then you should do so, because it facilitates both efficiency and error catching (and correction). > %% I assume that there actually are ways to address this in Mozart, > > Yes, the Pickle functor. There are also some contributed funtors that > handle file system abstractions rather painlessly based on Pickle. Pickled > "Files" are URL based in Oz thus easily accessed over standard internet > protocols as URLs. And since Oz abstracts network protocols to a very high > level, one needn't worry about the specific file system on which a Pickle > resides - that's a low level detail dealt with by the Oz emulation VM, in > much the same way Java deals with file streams at an I/O level. Except the > network abstractions aren't as transparent in Java as they are in Oz. It's been awhile since I looked at OZ, perhaps a year, so the details are fuzzy. I know that I ran into the "Pickle functor", but I also know that I couldn't quickly figure out how to use it in the way that I wanted. (Perhaps it has trouble with random IO? A part of what I want to do is build an ISAM file with accompanying indicies.) > > ... > > Well, every language has its rationale, and the semantics of each language > is usually and quite rightly influenced heavily by the problem domain or > domains that its author had in mind originally when he/she invented the > language. That's certainly the case (though I would argue that some of them, e.g., Basic, are poorly designed even for their intended areas of use). > > At the extreme end are languages like Eiffel and Ada, which have an > explicit reason for just about every feature and non-feature imaginable. (I > would hypothesize that if you like Eiffel with its "Design by Contract" > paradigm enforced by the compiler, you probably dig (or have love-hate > relationship with) Ada too, with its brutal compile-time type checking.) Right you are. I really like Ada, but it's basically impossible to do anything flexible with it. >... > Efficiency gains of compiled vs. interpreted code are often overstated, > ... I had thought that, and then I encountered Java and Visual Basic. That renewed my belief. > > That having been said, one side project I'm working on to make it easier to > experiment with different object-code generators based on Ruby syntax is a > generic Ruby parser DLL, based on the parse.y file in the standard Ruby > distro, but modified to expose the hooks into the parser in a more generic, > back-end-neutral fashion through a DLL. Once operational, it should > theoretically be possible to write any number of backends for the parser: A > java bytecode generator, a C code generator, native assembly code > generator, .NET CLR generator, you name it. Any language that can interface > to stdcall C functions in a DLL or SO should be able, moreover, to make use > of it. Sort of like the inverse of "Languages for the JavaVM"? > > %% Unfortunately, it usually needs to work with at least some > %% modules that aren't. Currently the only choice seems to be C > %% (and probably a few C mimics .. I wonder how I would link Ruby > %% with Ada95[gnat]?). > > Aha! I knew you liked Ada! You were totally right. I not only love it, I also hate it. But at least it doesn't have those $#%#^%& pointer casts that C and C++ have. > > Well, GNAT specifically is a variant of the GCC compiler, and as such it > boasts (and delivers) complete binary interoperability with GCC C/C++. I > would guess a binary extension between Ruby and Ada would be fairly > straightforward, assuming it was really something somebody wanted badly > enough to invest some time in developing. That's why I was hoping that it might be reasonably simple. Perhaps one could just pretend that the called module was a C module. Or at worst have a simple C module that just acted as a delegator. But I wouldn't be the one who wrote such a thing. Still, i understand that soon after gcc3.0 is released, that gnat is expected to be rolled into the compiler collection. > > I'm currently working on such a binary interoperability package between > Ruby and Java, which I'm calling Arubica, using the Ruby C API and the Java > native interface. With Arubica, you can create an instance of the Ruby > interpreter and call into the Ruby ObjectSpace to call existing Ruby > modules and define new classes and modules on the fly, in Java. And vice > versa: you can create an instance of the JVM and call into a custom class > loader and create pure Java objects on the fly. That sounds interesting, but I'm having trouble visualizing what is going on. Still, it might make a lot of Java GUI builder output available at not too much additional cost. > > ... > My point is: Where there's a will, there's a way. :) The problem is, which is the best one, since there are usually dozens. > > Sincerely, > Bob Calco >...