Re: Suggested Changes to 4gl

In article <1992Dec14.215058.24334@netcom.com> pmahler@netcom.com (Paul Mahler) writes: >So far the only responses I have received have been suggestions >for changes to the input array statement. Is everyone really >this satisfied with 4gl? Is there nothing else we can >complain about? 1) inadequate INPUT ARRAY 2) no dynamic memory allocation (eg dynamically sized arrays) 3) no pointer variables, or "call by reference" 4) strange syntax restrictions, eg "DISPLAY some_function()" is illegal 5) mismatch between semantics of some 4GL and SQL language constructs eg: in the following code fragment: DEFINE x RECORD LIKE y.* (1) SELECT * (2) INTO x.* (1) FROM y the ``*'' in (1) are expanded to the list of columns at compile time, while the ``*'' in (2) is expanded at run time. 6) Cursor and window names cannot be constructed dynamically (nor is there any other method of having multiple instances of the same window or cursor open simultaneously). [Aside: it would also be nice to be able to pass window or cursor references as arguments to functions] Therefore certain recursive algorithms become difficult. Consider how you would implement this pseudocode for a simple tree walk... # start with: call walk_tree(rootnode, 1, 1) function walk_tree(startnode, row, col) open window <windowname> at row,col foreach cursor <fetch_children> into child_node display child_node do-some-interactive-work call walk_tree(child_node, row+1, col+1) end foreach close window <windowname> end function Well, those are the ones that bug me. Who was it who said "Informix 4GL isn't a `4G' and is hardly an `L'"? Harsh, but fair. I must say that I like the Online engine, but really sometimes I wish we were developing apps in C instead of 4GL. -- Hugh Grierson Fujitsu/ICL New Zealand - Software Development Centre hugh@nezsdc.icl.co.nz Speaking for myself only. See figure 1. Quote of the decade: "We're not just talking about unpopulated areas of the Southern Hemisphere anymore" [Pres. Bush, on the Ozone hole]