Will@cup.portal.com (Will E Estes) (01/02/90)
In the AREXX-L conference a user made the comment: < I agree, the expose facility just isn't good enough. On the other hand, < I don't think that pointers are the right answer for this problem. < Generally, I think that the most serious fault in REXX is the fact that < you CAN'T pass compound variables as arguments (anyway, I haven't been < able to do so). Neither is returning stem variables supported. If this < omission were fixed, I think that one could do without pointers. Okay! So let's make an attempt at coming up with a reasonable syntax/semantics for a facility that approximates pointers in REXX. Others please jump in and improve on this. You just never know who may be watching this, and it might just end up in a commercial product someday. For REXX newcomers: none of the code that follows is real REXX. So don't try to use any of the following. It won't work with REXX as it stands today. I'm just trying to get people thinking about how REXX could be changed to get some of the sophistication that pointers add to a language like C. Now, the suggested changes to REXX: (i) use & to mean that you are passing the name - not the physical address - of a variable or node and * to mean that you are receiving the name into a variable or stem. (ii) & in combination with () would mean that you are passing the name - not the physical address - of a function and * in combination with () would attempt to execute a function by reference. Function invocations through the *() mechanism could be through stems as well as variables (to allow for tables of function pointers). Here are some examples: Example I /* some code to pass a variable by reference in REXX */ call test parm1 &parm2 ... test:procedure parse arg NewParm1 *NewParm2 ... So in the above example NewParm1 is a local variable, and NewParm2 is NOT local to the test subroutine. It points to the same data area referenced by parm2. Changes made to NewParm2 in the test subroutine change parm2 even after the test subroutine finishes executing. Example II /* some code to pass an arbitrary node in a stem to another stem */ call test parm1 &OriginalStem.down.the.tree. ... test:procedure parse arg parm1 *NodePseudoPointer. ... So in the above code NodesPseudoPointer would point to the node of OriginalStem that begins at the level of tree. So issuing the statement: NodePseudoPointer.id.3 = 'NewValue'; would be the same as issuing the statement: OriginalStem.down.the.tree.id.3 = 'NewValue'; outside of the test subroutine. Example III /* some code to return a stem */ *ReturnedStem. = test() ... test:procedure ... return &SomeStemIWantToReturn. Example IV /* some code to build a table of function pointers */ FuncPointers.1 = &test1() FuncPointers.2 = &test2() FuncPointers.3 = &test3() ... *FuncPointers.keypressed() /* invokes the function that * corresponds to the key that * was pressed */ So, anyway, does this work? Would others find this sort of change to REXX useful? Are there other ways of accomplishing the same thing that would be better? Thanks, Will (sun!portal!cup.portal.com!Will)
cosc6bp@elroy.uh.edu (A JETSON News User) (01/16/90)
Ummm, I don't think that using & is such a good idea. One reason is that IBM's EXEC and EXEC2 languages required you to use &'s in front of variable names. It was messy. REXX was a vast improvement on the EXEC languages and the fact that you didn't have to use &'s was one of the reasons it became such a success. However, the need for pointers, or a pointer substitute is a good idea. Ignacio Valdes
Will@cup.portal.com (Will E Estes) (02/02/90)
A month ago I made a suggestion to this list that REXX needed a capability that approximates pointers in C in terms of its functionality. I suggested a mechanism for adding both function and data pointers that involved passing a reference to variable or function (but NOT the actual machine address). There were a lot of good responses to the original posting, and I want to summarize the responses and try to give answers. Be forewarned that this posting runs about 200 lines before you start reading. First, to review, my original suggestion for a modified syntax and semantics was as follows: (i) use & to mean that you are passing the name - not the physical address - of a variable or node and * to mean that you are receiving the name into a variable or stem. (ii) & in combination with () would mean that you are passing the name - not the physical address - of a function and * in combination with () would attempt to execute a function by reference. Function invocations through the *() mechanism could be through stems as well as variables (to allow for tables of function pointers). Why make these changes? There are several reasons: 1) to allow a way to pass variables, arrays, and arbitrary *portions* of arrays by reference to a subroutine. There is simply no other way to allow REXX to become a language where you can build general-purpose subroutines that act on a kind of data rather than hard-coding in the name of a *particular* data structure through EXPOSE. I dare anyone to write in REXX a general purpose binary sort routine that acts on *any* REXX array. Without some changes to the *language* it can't be done, and I think that should cause some serious concern to anyone who wants to use REXX as more than a shell language. 2) to allow a way to *return* arrays, and arbitrary *portions* of arrays by reference. There are some problems with the way I originally suggested doing this, and I'm not convinced of the utility of it, but it would give a way to return very complex subroutine results that can't be well-handled by something like: parse value MyFunction() with retcode1 retcode2 etc 3) to give you an *elegant* way to build tables of function pointers. (I don't count use of INTERPRET as elegant because of its overhead, its absence from the compiler, and because it can sometimes be difficult to read.) Here were the responses I received: Steve Bacher responds: < First of all, the & and * prefix syntax is fine for C, but won't < work in REXX. This is because, in REXX, abutment of expressions < is a feature of the language. That this means is that you would < be introducing an ambiguity. Consider the statement < say foo *bar &baz < Does this mean to display the value of foo concatenated with the < value of the expression [foo times bar] logical_and baz ??? That's a very good point. Can't argue with it. & and * will definitely have to go. But this is just a syntax ambiguity that can be easily resolved by choice of a different set of operators. For now put up with the incorrect symbolism just because of the fact that it looks familiar to C programmers and for purposes of this discussion will help out. < Second of all, exactly what would be the "address" of a REXX < variable? When you say "say &myvar", what gets displayed? < Depending on the implementation, there may not be a "machine < address" associated with the variable. In MVS/TSO, for example, < the REXX variables may get bumped around the tree from statement < to statement (this is all internal OCO stuff anyhow). Hold on now. I specifically said as part of the original suggestion that & did NOT reference a machine address of any sort. In fact, what & does reference is not defined at all, and you should never modify it in any way. Practically, saying &test would probably get you a handle. How that handle is used by the interpreter is implementation-dependent and is of no concern to the user. Ed Nilges responds: < The trouble here is that you are receiving this information into < a REXX procedure. This means that the dereferencing in the < parse arg statement conceptually takes place outside the "test" < procedure. But PARSE ARG currently grabs copies of variables "outside" the test procedure. What is so far-fetched about also having it grab handles to variables and stems at the same time? It's really a question of what the language semantics allow for. The variable environment that a subroutine works with is a function of the arguments to a subroutine call and the EXPOSE statement; that is true both before and after my suggested change, and I don't see how the new semantics I'm proposing involve a contradiction here. < While this is probably implementable, it is almost unexplainable < to all but the REXX aficiando. I have enough trouble getting < REXX programmers to use PROCEDURE for good information hiding < and disciplined use of variables. Well, I agree most programmers won't use the feature. The issue is what features need to be added to REXX to make it fully capable to do professional-quality applications. A professional-quality application assumes a professional-quality programmer, unfortunately ( :) ). I would hate to see someone take pointers out of C just because most programming students don't understand the concept! Let me put the problem a little differently and a little more emotionally: REXX as it stands today cannot be used to build commercial-quality applications unless you are willing to put up with some pretty crummy code (e.g., hard-coding array names into subroutines). That's a shame because I think REXX has the potential to become the application development language of choice, preferable even to C for most applications. But it "ain't gonna happen" without some serious changes to the language. < But a solution exists. This is to add the EXPOSE clause, < currently limited to procedures, as a new statement: < EXPOSE <stuff> < where stuff would be a list of variables AND asterisk < representing everything. I hate to overstate, but here it goes: EXPOSE is grotesque. One of the key reasons for my suggested changes was to be able to do away with the need to use this facility. The idea that I should hard code in the name of global variables to my subroutine is, from a structured programming perspective, obscene. It gets programmers into very bad habits and it severely limits the power of the language. Now I understand that you are suggesting an extension to EXPOSE that would allow for dynamic EXPOSEs, but frankly I think that amounts to patching up something that is just wrong to begin with (a little like putting smooth edges on an ugly pipe sticking out the side of a house...I'd rather just cut off the pipe). An EXPOSE statement or function inside the procedure is also too wordy. Passing a reference is succinct. My own vote is to take Occam's razor to EXPOSE and do away with it. It is just about the only design in REXX that I think was poor (everything else is almost too good to believe!). Steve Bacher Responds: < Actually, "interpret" solves all the problems mentioned. INTERPRET can't do a call by reference for any REXX variable inside of a subroutine. But, beyond this, the REXX language just does not have a mechanism currently to support a call by reference to a STEM. And what about my examples that actually made calls by reference to an arbitrary node in a stem? You just can't do any of this with INTERPRET. The other issue is that INTERPRET makes for *ugly* code. Before it became illegal under SAA to use INTERPRET before the EXPOSE statement I had a friend who actually built a general-purpose sort routine that took as its argument a string that contained a STEM to EXPOSE. Every line of the sort involved using an INTERPRET on the variable that contained this string, and it was the most unreadable piece of code I have ever seen. INTERPRET has legitimate uses. Making up for a lack of call by reference is not one of them. < The return value could be captured as the variable "result". If < you want to retain the syntax of function calling, you need to < have a specialized function for this. And how do I return a structure from a function invocation except by changing the language? My suggestion was to allow calls like: *ReturnedStem. = test() ... test:procedure ... return &SomeStemIWantToReturn. Regarding specialized functions: how do I pass a stem by reference and point to an arbitrary location in that stem when I make a function call? I just don't see how adding any number of functions to the language is going to make up for an issue that has to do with its basic syntax and semantics. So, I think there are a few issues that need to be worked out here, but I'm more convinced now than ever that REXX needs a call by reference that supports both STEMS and portions of STEMS. A facility to have a subroutine return a STEM and some sort of function pointer capability (again, pointer does NOT mean a machine address in this context!) would both be nice, but neither is essential. To contrast, call by reference is essential if REXX is ever going to join the big leagues with C. Thanks, Will
Will@cup.portal.com (Will E Estes) (02/03/90)
In my last posting I say: < I dare anyone to write in REXX a general purpose binary sort < routine that acts on *any* REXX array. Without some changes to < the *language* it can't be done, and I think that should cause < some serious concern to anyone who wants to use REXX as more < than a shell language. I should clarify this "dare", because I just had a nightmare vision about the kind of code that someone is going to send flying at us over the net because of assumptions I leave out of my original statement: (1) I dare anyone to write in REXX a general purpose binary sort routine that acts on *any* REXX array and uses the PROCEDURE keyword on the subroutine. (2) I dare anyone to write in REXX a general purpose binary sort routine that acts on *any* REXX array without the PROCEDURE keyword on the subroutine that doesn't look uglier than Bill the Cat when he wakes up in the morning. The routine for (1) can't be written. And of course using the PROCEDURE keyword is a must for anyone who wants to write structured code. If you don't use the PROCEDURE keyword at all, then you can use INTERPRET liberally throughout the subroutine to do just about anything. But this is a totally unacceptable solution for any number of reasons: 1) the code looks like hell; 2) it is not efficient; 3) it is not supported in the compiler; 4) it requires you to not use the PROCEDURE keyword which exposes all of the caller's environment, and this is hack programming at its worst. Enough said, Will (sun!portal!cup.portal.com!Will)
wagner@pucc.Princeton.EDU (John Wagner) (02/06/90)
In article <26534@cup.portal.com>, Will@cup.portal.com (Will E Estes) writes: > (1) I dare anyone to write in REXX a general purpose binary sort > routine that acts on *any* REXX array and uses the PROCEDURE > keyword on the subroutine. > > (2) I dare anyone to write in REXX a general purpose binary sort > routine that acts on *any* REXX array without the PROCEDURE > keyword on the subroutine that doesn't look uglier than Bill the > Cat when he wakes up in the morning. > > The routine for (1) can't be written. And of course using the > PROCEDURE keyword is a must for anyone who wants to write > structured code. Will, This is simply not true. You may not like how the code looks, but that is different than saying it cannot be done. Remember that the SAA restriction on using "INTERPRET 'name: procedure expose' var" is an IBM restriction that is not part of the language. Don't use the IBM manuals for REXX when you are trying to understand what the language is supposed to be. The only source for that information is Colishaw's book "The REXX Language, A Practical Approach to Programming". > If you don't use the PROCEDURE keyword at all, then you can use > INTERPRET liberally throughout the subroutine to do just about > anything. But this is a totally unacceptable solution for any > number of reasons: 1) the code looks like hell; 2) it is not > efficient; 3) it is not supported in the compiler; 4) it requires > you to not use the PROCEDURE keyword which exposes all of the > caller's environment, and this is hack programming at its worst. I don't know what environment you are using REXX in, but I would guess that it is not VM/CMS since you seem to be missing the "feel" of it. This comes through in the way you state your dare. You have assumed that the correct answer is the ability to write all code in REXX. Colishaw never meant for that to be the case. REXX is a blend of high level code with system dependent function packages. You cannot separate the two. The appropriate response to your dare is that two forms come to mind. The first is: call sort 'Stem_to_sort.' , 'Stem.' < , 'Ascending' > < , 'Descending' > This places the sorted values found in 'Stem_to_sort.' into the stem 'Stem.' with 'Stem.0' containing the number of values. The third parameter just specifies the sort order. It uses the standard REXX technique of only making the first character significant so you could code 'DownDamnIt' it you wanted. The default would be ascending. This procedure would sort any value starting with 'Stem_to_sort.' so you might want to add another parameter to specify valid tail types (Any, Numeric, Character, etc.). It could also be used to sort some portion of a stem's values by specifying a partial tail, as in call sort 'Unsorted.Array.' , 'Sorted.array.' , 'D' If what you want to do is sort words in a string you use SortedString = sortwords(string <, 'Ascending' > ) <, 'Descending' > ) This one can be done using a REXX procedure, but is quicker in machine code. Function packages are meant to do exactly what their name implies, provide function not found in the base REXX language. They are meant as the way to make REXX extensible. You might want to take a look at a REXX function package available from Berthold Pasch (BITNET: PASCH@DHDIBM1 VNET: PASCH at GYSVMHD1). The package is known as XVAR (eXtended VARiable support) and is for REXX programs in CMS. It allows you to access copies of the variables in a callers routine (both R/O and R/W). Using this package it is possible
Will@cup.portal.com (Will E Estes) (02/08/90)
Thanks for the feedback. You touch on several different points, and I'll try to cover each of them. I am re-arranging the order of your points. < Remember that the SAA restriction on using "INTERPRET 'name: < procedure expose' var" is an IBM restriction that is not part of < the language. Don't use the IBM manuals for REXX when you are < trying to understand what the language is supposed to be. The < only source for that information is Colishaw's book "The REXX < Language, A Practical Approach to Programming". This is fine if you use Amiga REXX. However, for the rest of us who live in the IBM world, your statement is wrong. Legally, since Mike was working for IBM on an IBM product when he wrote REXX, IBM, and not Mike, controls the language definition. Practically speaking, in 1993, when I and 20 million other people are using IBM REXX under OS/2, VM/CMS, and MVS, we will be using a version of the language that does not allow you to use the INTERPRET keyword before the PROCEDURE keyword in a subroutine. In fact, IBM is still modifying the language definition, and as far as I'm concerned SAA REXX is REXX. Finally, Cowlishaw's book just came out in 1990 with a second edition. I would be willing to bet good money that Mike's book now conforms to SAA REXX and not to his own original definition. < Will, This is simply not true. You may not like how the code < looks, but that is different than saying it cannot be done. I think you are misunderstanding what I said. I said: (1) you can't write the routine *IN THE REXX LANGUAGE* *WITH THE PROCEDURE* keyword in place. By REXX *I* mean SAA REXX. You can't write this routine in SAA REXX. And to appeal to Cowlishaw's original definition is to really squirrel the issue. But if you insist on hanging onto this thread, then I suppose I can just change the claim below in (2) to not reference the PROCEDURE keyword. Try to see the big picture here. I'm not trying to challenge your ability to write code. I can write the routines you refer to, as can you. My point is that REXX can't do call by reference (or anything that approximates it), and it suffers as a language because of that. I also said: (2) you can't write the routine IN THE REXX LANGUAGE WITHOUT THE PROCEDURE keyword unless you are willing to put up with very ugly code. This is not, by my reading, an assertion that the routine cannot be written. Rather, it is an assertion that the code *can* be written and it will look like hell. And it does. Moreover, the resulting code is inefficient, not compilable, and it is bad technique from a structured programming perspective. I think it is fair that we be able to debate each of those assertions if you like, but please do not hold me to saying that the claim I make in (2) above is that a routine cannot be written. That is not what it says. < I don't know what environment you are using REXX in, but I < would guess that it is not VM/CMS since you seem to be missing < the "feel" of it. This comes through in the way you state your < dare. You have assumed that the correct answer is the ability < to write all code in REXX. Colishaw never meant for that to be < the case. REXX is a blend of high level code with system < dependent function packages. You cannot separate the two. Well, I didn't assume that the best way to write a sort routine for REXX is to write it in REXX; rather, I used the sort as an arbitrary example of how REXX cannot do call by reference. Nevertheless, your concern is valid. I'm well aware about function packages, and by now SAS' C compiler has so many excellent REXX hooks that you could probably even use that. My objective in posting my note, however, was to rhetorically ask if the REXX language itself couldn't be improved through an ability to do call by reference. I am convinced it can be. PRACTICALLY speaking, when I was doing VM/CMS consulting few of my clients had a C compiler, and when you have two weeks to write thousands of lines of REXX you really don't want to hassle writing assembler code unless you know it inside and out. My last client not only forbid me from writing assembler, but he didn't even allow me to upload routines from Bitnet because of a fear about viruses. It's very easy for us to sit in glass houses and anytime we don't find something in REXX just flippantly say that we could always code it in assembler. In the real world, however, only a few of us get such opportunities. REXX is a great prototyping language, and you defeat that purpose in the language if you insist that we resort to assembly code every time we run into a call by reference problem. < Function packages are meant to do exactly what their name < implies, provide function not found in the base REXX < language. They are meant as the way to make REXX extensible. To my way of thinking there are two good reasons to write a function package: 1) you need to make something more efficient; and 2) you need to do something that is very OS-dependent that is just not reasonable to do in REXX. The excellent IUCV routines from University of Maine are an example of the latter. It is disappointing, though, when we have to rely on function packages to make up for deficiencies that are rooted in the syntax and semantics of the language itself. Writing a routine in assembler because I can't do call by reference in REXX should not be accepted as "the REXX way of doing things." It should be taken as evidence that maybe REXX by itself does not do enough and could do better. To say that this is not the way Mike wanted us to do things is to my way of thinking simply Argument Ad Hominem. Since Mike isn't here to give us his reasoning himself, I don't see why we can't go through the reasoning behind his design decisions ourselves. Heck, this board is supposed to contribute to our understanding of the language, isn't it? Let me be very clear that I am crazy about REXX. It is one of the most elegant languages I have ever used. It's one of the better technologies to come out of IBM, in my opinion. I just think it could be better. I can be convinced that I'm wrong, though. < The appropriate response to your dare is that two forms come to < mind. The first is: < < call sort 'Stem_to_sort.' , 'Stem.' < , 'Ascending' > < < , 'Descending' > < If by this you are referring to an assembler routine, I think I covered that already. If by this you are referring to a REXX routine, then pretty much falls under the spectre of (2) above, doesn't it? It uses INTERPRET liberally throughout, and it falls victim to the four problems I posted in my original note. So I don't see this routine as a disclaimer of anything that I said originally. You are right that the routine can be written if one does not use the PROCEDURE keyword and if one uses INTERPRET. But I think it is proof of my point and not a response to it. And the issue over whether we are talking SAA REXX or Mike's original REXX is not really very important relative the concern I'm trying to raise. < You might want to take a look at a REXX function package < available from Berthold Pasch (BITNET: PASCH@DHDIBM1 VNET: < PASCH at GYSVMHD1). The package is known as XVAR (eXtended < VARiable support) and is for REXX programs in CMS. It allows < you to access copies of the variables in a callers routine (both < R/O and R/W). Sounds good. Thanks for the info. Will (sun!portal!cup.portal.com!Will)
wagner@pucc.Princeton.EDU (John Wagner) (02/09/90)
Will, A piece of information you may not know: In the pre-VM/SP version of REXX (the IBM internal use only version also available to some groups doing joint research with IBM) included an interface that could have been used to create call by value and call by reference. It was a piece of the EXECCOMM interface that was removed by development when the product was released. You can still do call by value using the VALUE() function. Call by reference would require a handle that it is no longer possible to create in SAA without modifying the interpreter. Since the interpreter is now entirely without source code (and disassembly is explicityly disallowed by the license agreement signed by the site) it is unlikely that an user site will make the effort to implement what you are looking for even if they think it is a good idea. This leaves you with the option of convincing IBM to do it, convincing some third party vendor with an existing implementation to do it, or writing your own interpreter. While the last option might be fun, unless someone is really willing to push it in the IBM world, it is likely to fail irrespective of the quality of the product. I keep wondering why you aren't looking at PL/I. Your goal (given that INTERPRET is not to be used) is effectively making REXX into PL/I. Or as an alternative, libraries of REXX functions that are included into the code by a macro processor style operation (some companies have developed procedures in this direction).
hayes@ultra.com (John Hayes) (02/10/90)
This entire discussion seems to have been conducted under the assumption that REXX is a programming language. As I learned it, while it may technically be called a language, it's primary design function was to provide a better way to write simple interpreted scripts than exec2 (An older interpreted language available on VM/CMS systems for those in the Amiga world...). These scripts were generally installation scripts or otherwise small scripts to be executed only occasionally, not to become a major programming language. REXX scripts (or programs as some people prefer to call them) are very easy to write, thus making it the perfect language for prototyping parts of larger software projects. Initially, REXX was only available as an interpreter. The ease of programming in it has led to the development of the REXX compiler. Upon the initial design of REXX, it was never supposed to be anything but an interpreted language. A similar parallel can be drawn to (gasp!) the BASIC programming language. BASIC was for many of the recent generation, a quick and easy way to learn a lot of bad programming habits. Most of the computers (espicially micro computers) ran a version of interpreted basic (microsoft basic became a defacto standard). As the popularity of BASIC grew (and microcomputer became more powerful) a compiler BASIC evolved into what is now commonly called Business BASIC. And now we have a generation of 'programmers' who know Business BASIC and call themselves software engineers. As I see it, using REXX as anything but a quick prototyping language and for macro definition under XEDIT, we are just bound to waste more cpu cycles by not having those applications written in a true, optimizable language. -- John Wm. Hayes hayes@ultra.com UltraNetwork Technologies (408)922-0100 x204
peter@ficc.uu.net (Peter da Silva) (02/20/90)
In article <1990Feb9.181153.417@ultra.com> hayes@ultra.com (John Hayes) writes: > As I see it, using REXX as anything but a quick prototyping language and > for macro definition under XEDIT, we are just bound to waste more cpu cycles > by not having those applications written in a true, optimizable language. While I agree with the categorisation of REXX as a kindler and gentler BASIC, I don't see that this conclusion holds. Even on large IBM systems CPU cycles are cheaper than programmer cycles, and if it's easier to program in REXX than PL/I why not use it? Consider, for example, the UNIX environment where so much of the system is actually built up out of shell scripts. Consider C news, which uses shell scripts extensively but by virtue of intelligent encapsulation gets something like 20 times the performance of B news where it counts. On the other hand, I'm not sure that a compiled REXX is a good idea, given the ease of adding external commands in either environment. Write your tight inner loops in PL/I and glue them together with easy-to-read, modular, REXX. -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
Will@cup.portal.com (Will E Estes) (02/21/90)
< This entire discussion seems to have been conducted under the assumption that < REXX is a programming language. As I learned it, while it may technically < be called a language, it's primary design function was to provide a better < way to write simple interpreted scripts than exec2 (An older interpreted Right you are. But the implementation far exceeds this initial purpose. Cowlishaw was asked to build a better Volkswagon and he came up with something that looks a little more like a Porsche. It's a question of objectively looking at a product and what it does and how it does it and coming to our own conclusions rather that blindly accepting IBM's pronouncements. < As I see it, using REXX as anything but a quick prototyping language and < for macro definition under XEDIT, we are just bound to waste more cpu cycles < by not having those applications written in a true, optimizable language. First, there are ways to optimize typeless languages so that they would perform quite reasonably in compiled form. Second, even if we accept the premise that REXX is only valuable as an interpretive prototyping language, it is still valid to ask what changes could we make to the language to make it more powerful for just that purpose. A prototyping language is a programmin g language none the less, and there are questions of ease of use, maintainability of code, etc. Third, you have not spent much time in the real world if you really believe that REXX is being used as a prototyping language. On VM/CMS it is used by many companies as a mainstream application development tool. I know of one site that has a REXX system that approaches one million lines of code. I know of many sites with 10,000+ line applications. To argue that this is not an appropriate use of the language is like arguing that people shouldn't drive in the rain because it's dangerous. People are going to drive in the rain anyway because practical concerns make it impossible not to, so car manufacturers improve the basic design of their cars for rainy conditions. Similarly, companies in the real world are using REXX for production applications because of practical concerns (like it's nearly impossible to find qualified C and assembly programmers and it's much harder to maintain the resulting code), so why not accomodate reality by improving REXX? Will (sun!portal!cup.portal.com!Will)
tron1@tronsbox.UUCP (HIM) (02/22/90)
>In article <1990Feb9.181153.417@ultra.com> hayes@ultra.com (John Hayes) >writes: >> As I see it, using REXX as anything but a quick prototyping language and >> for macro definition under XEDIT, we are just bound to waste more cpu cycles >> by not having those applications written in a true, optimizable language. POSSIBLY in those situations where REXX is >JUST< a glamorous way to write batch style scripts that would be true. BUT , REXX (specifically AMIGA REXX) is so much more. In AREXX , 90% of the work in a program is done through messages to C or whatever compiled user programs. Consider the case where on my Amiga , I would write a REXX script that will take the output of uutraf (a UUCP profiler) that comes over a terminal program , and DYNAMICALLY build a graph of that data in a graphics packadge (the wonder of Multi-Tasking) by the process of .. 1) Parsing the incomming data from a message port attached to the terminal program... 2) Sending messages like "DRAW LINE 100,100 200,200" to my paint program. This is >SO< simple and >SO< usefull as an interpreted language (or a compiler for all I care .. but REXX rather than >C<) that the wasted CPU cycles are not a problem. (FYI - the overhead in data structure initializion for IPC on AMiga is such that I wouldnt want to do it for something this simple when the resident REXX module already does it.) >interpreted language. A similar parallel can be drawn to (gasp!) the BASIC >programming language. Wich in it's modern form is a Compiled, structured, completely useful language. (A bit wordy). Languages evolve. >BASIC was for many of the recent generation, a quick and easy way to learn a >lot of bad programming habits. Most of the computers (espicially micro But no longer. Basic has done more during its evolution than many suspect , and REXX does the same thing (on the Amiga) for MULTI-PROCESSING. The ability for AREXX to control multiple INDEPENDANT applications is staggering. Come to think of it , there had better be a UNIX implementation of >A<REXX soon! **************************************************************************** Everything I say is Copr. 1990, except the stuff I stole from someone else and the stuff I don't want responsibility for. Kenneth J. Jamieson: Xanadu Enterprises Inc. "Professional Amiga Software" UUCP: tron1@tronsbox.UUCP BEST PATH ---> uunet!tronsbox!tron1 Sysop, Romantic Encounters BBS - (201)759-8450 / (201)759-8568 ****************************************************************************