Re: Ideas for next Eu
- Posted by "Lucius L. Hilley III" <lhilley at CDC.NET> Nov 06, 1999
- 714 views
It sounds as if you are doing something of this nature. function this1(sequence xy) return xy+1 end procedure function this2(sequence xy) xy = this1(xy) do_other_things() end function function this3(xy) xy = this2(xy) end function In this case I would probably do the following. sequence xy procedure this1() xy += 1 end procedure procedure this2() this1() do_other_things() end procedure procedure this3() this2() end procedure Notice that xy is still local yet it is available to all the routines that are declared after it. This works as long as all of the routines are in the same file. If you wish to span include files you would be force to use global. Such as: global sequence xy include this1.e include this2.e procedure this3() this2() end procedure xy is then available to everything after the global sequence xy statement. Lucius L. Hilley III lhilley at cdc.net lucius at ComputerCafeUSA.com +----------+--------------+--------------+----------+ | Hollow | ICQ: 9638898 | AIM: LLHIII | Computer | | Horse +--------------+--------------+ Cafe' | | Software | http://www.cdc.net/~lhilley | USA | +----------+-------+---------------------+----------+ | http://www.ComputerCafeUSA.com | +--------------------------------+ ----- Original Message ----- From: simulat <simulat at INTERGATE.BC.CA> To: <EUPHORIA at LISTSERV.MUOHIO.EDU> Sent: Saturday, November 06, 1999 2:44 AM Subject: Re: Ideas for next Eu > ---------------------- Information from the mail header ----------------------- > Sender: Euphoria Programming for MS-DOS <EUPHORIA at LISTSERV.MUOHIO.EDU> > Poster: simulat <simulat at INTERGATE.BC.CA> > Subject: Re: Ideas for next Eu > -------------------------------------------------------------------------- ----- > > Hi > The programs I write are pretty self-contained; that is, there's no > interaction with the user. In that context, it's kind of a nuisance to not > be able to modify global variables from inside functions. Here's an example. > > I have a sequence called "tiles" that holds a bunch of bitmaps. The bitmaps > are manipulated by placing tiles[x] onto the screen and then drawing on the > screen then saving the screen to tiles[x] again. Sometimes, the functions > that accesses tiles are deeply buried within strings of other functions. I > end up having to pass tiles through a bunch of functions that don't use it, > just to make it available for one that does (but that might not even be > called), and then I have to pass the modified value back up the chain. I > think this is less than elegant, maybe even ugly. It's certainly a hassle. > It would be a lot easier if there was just a way to modify the global > variable. > > OK - I admit it - I learned to program on something called "Level 1 BASIC". > All the variables were global. Variable names could be up to 2 characters > long. I found that if I needed a variable to be local that it was easy to > do, but that it was rarely necessary. It didn't take long for me to > appreciate the benefits of structured programming and I found it easy to > implement in that completely unstructured environment. > > I understand that when programs are written by large teams, and when > software is used by many people at once, extreme efforts must be taken to > protect data integrity. But that's not what I'm doing. I write programs that > make pictures. It's no big deal if it crashes - it's not like it's > controlling an airplane or anything. I find that the subtle logic bug is > rare, but that the crashes caused by the safety features of structured > programming (like not letting functions modify global variables) are a > constant hassle. > > I like Euphoria. It works just perfectly for the kind of programming that I > do. One of it's benefits is that it has very little programming overhead. > Personally, I think that "beauty" would be found by making the language > looser and more flexible. There are lots of languages around that are rigid. > > Bye > Martin > > > > > > >From: Brian K. Broker <bkb at CNW.COM> > > On Fri, 5 Nov 1999, Darth Maul wrote: > > > > > You know how in Q(uirk)Basic, all values are passed to FUNCTIONs/SUBs by > > > reference? Maybe you should add a 'byref' keyword so that variables are > pas- > > > sed by reference. This would make porting progs from QB to Eu a little > > > easier. > > > > Ick! IMHO it is a poor practice to have variables passed to a sub or > > function be globally changed by that sub or function. Besides, you > > can already easily accomplish that same effect by declaring your > > variables outside of your subs/functions (then you don't even need to > > pass them). There is more than one way to get around your porting problem > > than to introduce that ugliness into Euphoria. But again, that's just my > > opinion. > > > > Can you provide a better reason for this inclusion (besides making it > > easier to port poorly written QB progs)? > > > > -- Brian > > >