Re: Ideas for next Eu

new topic     » goto parent     » topic index » view thread      » older message » newer message

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
> >
>

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu