1. 1 pass?
I've been using Euphoria for a whole week now (a whole week? (yes a
whole week!)) and one question has been bugging me. Is there any reason
that Euphoria is a one pass compiler / interpreter. As it makes
programming recursive procedures a pain in the arse.
2. Re: 1 pass?
Ian Andrews wrote:
>
> I've been using Euphoria for a whole week now (a whole week? (yes a
> whole week!)) and one question has been bugging me. Is there any reason
> that Euphoria is a one pass compiler / interpreter. As it makes
> programming recursive procedures a pain in the arse.
Hello, and welcome to the list.
I will leave the "why" question to Rob Craig, but recursion is very
easy in Euphoria. Perhaps you are referring to mutual recursion.
That's also easy. See Einar Mogen's discussion and code in the FAQ
at http://www.mindspring.com/~mountains (click on Euphoria FAQ, then
"answers")
Regards,
Irv
3. Re: 1 pass?
Ian Andrews writes:
> Is there any reason
> that Euphoria is a one pass compiler / interpreter. As it makes
> programming recursive procedures a pain in the arse.
For normal recursion, there is no problem.
A routine can simply call itself, just like in most other
languages.
For "mutual" recursion, where A calls B which directly
or indirectly calls A, you need to use
routine_id(), and either call_func() or call_proc().
e.g.
integer B_id
procedure A()
call_proc(B_id, {})
end procedure
procedure B()
A()
end procedure
B_id = routine_id("B")
The fact that the language works this way
has little to do with the one-pass structure
of the compiler. It would have
been fairly easy to implement calls to routines
that are defined later, provided the call did not actually
take place until the later routine was parsed.
A one-pass compiler can "back-patch", or fill-in
missing information when it becomes available,
either later in the compile, or at run-time.
I didn't feel that making mutual recursion easier to code
was important enough to justify destroying the
"define it before you use it" property of Euphoria.
This property helps readability and maintainability.
It's not there just because Euphoria works in one-pass.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
4. Re: 1 pass?
Robert Craig wrote:
>I didn't feel that making mutual recursion easier to code
>was important enough to justify destroying the
>"define it before you use it" property of Euphoria.
>This property helps readability and maintainability.
>It's not there just because Euphoria works in one-pass.
Rob,
I realize, you feel quite strongly about this "define it before you
use it" thing, you mentioned it already several times. But I urge you
to think about it again, and I hope you will eventually see it has
absolutely nothing to do with readability or maintainability of the
code. In my view, to put it quite bluntly, it is simply a convenience
for the compiler designer and an unnecessary restriction imposed on
the user. In the end it comes down to one's favourite programming
style, 'top-to-bottom', or 'bottom-up', or whatever the labels are. A
lot of programmers, including myself, find it much more natural to
start with the broad picture at the top and gradually refine the
texture, fill in the gaps. And with the speed of modern compilers,
including yours, I do not care where it flags an unresolved reference,
whether it is at beginning, in the middle, or at the very end of the
program. Jiri
5. Re: 1 pass?
Thanks for the reply. I am confused as to how forcing people to
implement mutual recursion via those inelegant routine_id routines helps
with readability and maintainability. I don't have a problem with your
"define it before you use it" principle (I have a degree in computer
science so I can appreciate what you're saying). But I do think there is
a case for making procedure and function names different. They are
conceptually different from variables anyway. A while back I coded a
text generation programming language for the Amiga. I made that two
pass. It took no time at all to zip through the code and pick up the
function names. You could do the same thing with Euphoria. That would be
the humble recommendation of this user.
> -----Original Message-----
> From: Robert Craig [SMTP:rds at EMAIL.MSN.COM]
> Sent: Monday, August 03, 1998 10:22 PM
> To: EUPHORIA at cwisserver1.mcs.MUOHIO.EDU
> Subject: Re: 1 pass?
>
> Ian Andrews writes:
> > Is there any reason
> > that Euphoria is a one pass compiler / interpreter. As it makes
> > programming recursive procedures a pain in the arse.
>
> For normal recursion, there is no problem.
> A routine can simply call itself, just like in most other
> languages.
>
> For "mutual" recursion, where A calls B which directly
> or indirectly calls A, you need to use
> routine_id(), and either call_func() or call_proc().
> e.g.
>
> integer B_id
>
> procedure A()
> call_proc(B_id, {})
> end procedure
>
> procedure B()
> A()
> end procedure
>
> B_id = routine_id("B")
>
> The fact that the language works this way
> has little to do with the one-pass structure
> of the compiler. It would have
> been fairly easy to implement calls to routines
> that are defined later, provided the call did not actually
> take place until the later routine was parsed.
> A one-pass compiler can "back-patch", or fill-in
> missing information when it becomes available,
> either later in the compile, or at run-time.
>
> I didn't feel that making mutual recursion easier to code
> was important enough to justify destroying the
> "define it before you use it" property of Euphoria.
> This property helps readability and maintainability.
> It's not there just because Euphoria works in one-pass.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://members.aol.com/FilesEu/
6. Re: 1 pass?
Hello,
Jiri wrote:
>I realize, you feel quite strongly about this "define it before you
>use it" thing, you mentioned it already several times. But I urge you
>to think about it again, and I hope you will eventually see it has
>absolutely nothing to do with readability or maintainability of the
>code.
I beg to differ, the "define it before you use it" is not least among
the many features of Euphoria that makes it possible for me to program.
This simple consistancy is in my opinion a high priority for
readability. I like to know that my program stopped exactly where an
error occurred instead of sweeping past it only to discover later that
something is wrong. This may sound strange but I don't want my program
to run a line past the spot that I make a mistake. I guess I like order
a lot.
> In my view, to put it quite bluntly, it is simply a convenience
>for the compiler designer and an unnecessary restriction imposed on
>the user.
This is not unnecesary for me, quite the contrary infact.
>In the end it comes down to one's favourite programming
>style, 'top-to-bottom', or 'bottom-up', or whatever the labels are. A
>lot of programmers, including myself, find it much more natural to
>start with the broad picture at the top and gradually refine the
>texture, fill in the gaps.
Actually this is the way that I program in Euphoria, but I suppose I
mean this in a different way than you do. At least I find Euphoria's
structure to be no barrier to me but quite the contrary.
Just my two and a half cents,
Lewis Townsend
.
|\
| \
||\\EWIS
||_\\
|____\RT --I messed up my old sig file
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
7. Re: 1 pass?
>Hello,
No more "Salutations"? ;)
>Jiri wrote:
>
>>I realize, you feel quite strongly about this "define it before you
>>use it" thing, you mentioned it already several times. But I urge you
>>to think about it again, and I hope you will eventually see it has
>>absolutely nothing to do with readability or maintainability of the
>>code.
>
>I beg to differ, the "define it before you use it" is not least among
>the many features of Euphoria that makes it possible for me to
>program. This simple consistancy is in my opinion a high priority for
>readability. I like to know that my program stopped exactly where an
>error occurred instead of sweeping past it only to discover later that
>something is wrong. This may sound strange but I don't want my
>program to run a line past the spot that I make a mistake. I guess I
like
>order a lot.
I agree. I like knowing what can and what can't call each function, what
variables and such can access each other. (Uh oh, this is sounding like
OOP... "oop"s! ;) [Bad pun, had to do it. ;) ])
Besides, if you want to program the main routine(s) first, followed by
the smaller routines then use the UP arrow key.... That's why it's there
for. :) (That's what I do.)
>Just my two and a half cents,
Uh, this would be my quarter of a cent... Hope it's put to good use. :)
>.
>|\
>| \
>||\\EWIS
>||_\\
>|____\RT --I messed up my old sig file
Well, it's a piece of cake to get it back. Ask (I have too much undeleted
mail)... or check the list archives and copy it back.
_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]
8. Re: 1 pass?
- Posted by Irv <irv at ELLIJAY.COM>
Aug 04, 1998
-
Last edited Aug 05, 1998
Lewis Townsend wrote:
>
> Hello,
>
> Jiri wrote:
>
> >I realize, you feel quite strongly about this "define it before you
> >use it" thing, you mentioned it already several times. But I urge you
> >to think about it again, and I hope you will eventually see it has
> >absolutely nothing to do with readability or maintainability of the
> >code.
>
During the past 20 years I have been paid to write code, there have been
a few
occasions to use mutually recursive code. (perhaps 3 or 4)
On the other hand, I cannot count how many times I had to debug, modify,
or update code - often someone elses' code.
So for me, readability and a predictable structure greatly outweigh the
need for
easy recursivity - on the order of a couple million to one.
Anyone who wants to call routines before he writes them should also run
them
before he writes them. That way he will know about any future errors,
and
can avoid writing them in the first place.
(Nostradamus School of Computer Science - 101 - Chap.3, Saving Work)
Regards,
Irv
9. Re: 1 pass?
Lewis Townsend wrote:
>Jiri wrote:
>
>>I realize, you feel quite strongly about this "define it before you
>>use it" thing, you mentioned it already several times. But I urge you
>>to think about it again, and I hope you will eventually see it has
>>absolutely nothing to do with readability or maintainability of the
>>code.
>
>I beg to differ, the "define it before you use it" is not least among
>the many features of Euphoria that makes it possible for me to program.
>This simple consistancy is in my opinion a high priority for
>readability. I like to know that my program stopped exactly where an
>error occurred instead of sweeping past it only to discover later that
>something is wrong. This may sound strange but I don't want my program
>to run a line past the spot that I make a mistake. I guess I like order
>a lot.
Lewis, in your rush to support the status quo (pretty common on this
list) you completely missed the point (as so many others did too,
judging from the response). But you all do not have to worry, your
blunders would be unaffected, because you could get exactly the same
error messages, pinpointing your mistakes, as it's done now, only
perhaps several milliseconds later, when the interpreter/compiler
reaches the end of the source code and it can be sure you again forgot
to declare some of your routines. Enough, no point. Jiri
10. Re: 1 pass?
- Posted by Hawke <mdeland at NWINFO.NET>
Aug 04, 1998
-
Last edited Aug 05, 1998
blahblahsnipsnipblahsnip
jiri,lewis,irv said this and the other about chickens and eggs
coming in tops down (woowoo!) and bottoms up (gulp) programming.
i use both. i write my code in almost pure pseudocode,
but structured pseudocode, in one file. that becomes my
.ex or .exw file... i then, in another file(s), at the same
time, write the proc/func's that the pseudocode calls and
that file(s) becomes my .e or .ew file.
benefit? i get jiri's style (and others) of being able
to define my program (problem solution?) in the way
*i think*, and i get the benefit of others who build up
from small snippits of a solution to bigger and bigger
pieces/building blocks of the final puzzle...
by keeping all my routines in include files, and only having
'main' in my .ex or .exw file, i never worry about what
can call what or when or from whence it comes...
hopefully, this approach i use will benefit those with
problems coding in euphoria, and perhaps end the beating
of this horse?
take care, hope this helps--Hawke'
11. Re: 1 pass?
Hawke wrote in his inimitable way:
>blahblahsnipsnipblahsnip
>jiri,lewis,irv said this and the other about chickens and eggs
>coming in tops down (woowoo!) and bottoms up (gulp) programming.
<lot of wisdom inadvertently snipped out>
>hopefully, this approach i use will benefit those with
>problems coding in euphoria, and perhaps end the beating
>of this horse?
If you structure you code the same way as your messages, I do not
think I want to know. Btw, will we ever know? Jiri
12. Re: 1 pass?
jiri babor wrote:
> If you structure you code the same way as your messages, I do not
> think I want to know.
< pain inflicted >
ouch!
</pain inflicted >
yeah, things have been gnarly around here lately, and
i've been a bit scatterbrained... guess its showing, eh?
>Btw, will we ever know?
if you are referring to the fact that i rarely post code
to the newsgroup (such as answers to problems), it's
because by the time i read my email, someone usually
beat me to the posting of said code. *shrug*
if your referring to the fact that i don't post
code to the main euph page, it's because i generally
send it via email from private requests for some of
the things i've coded (which i did post a notice
here when they were done). i feel the diskspace can
be better served at the main page holding utilities
that people -want-... only a few seemed actually
interested in truecolor coding for example...
lastly, i decided to scrap the last approx. 4 months
of coding i was doing for the game creation system
i was developing... i am still coding it, but it will
be coded in a different environment from what it was
originally coded in.
</update for any1 who wants to know>
enjoy--Hawke'
13. Re: 1 pass?
- Posted by jiri babor <jbabor at PARADISE.NET.NZ>
Aug 05, 1998
-
Last edited Aug 06, 1998
Hawke wrote:
>< pain inflicted >
>ouch!
></pain inflicted >
Sorry, Hawke, you kicked me so I lashed back. I am too old to change. I hope
there is no lasting damage. Good luck with your coding. Jiri
14. Re: 1 pass?
>References to prior publication, please.
Just a wild guess and a half-hearted compliment, Irv, no offence intended.
Jiri
15. Re: 1 pass?
I've been quite busy, and I just read this thread, which I concatonated
into a file.
>>>>>
You are absolutely right. This is not about easy recursivity, this is
about freedom to structure my programs in the best possible, logical
way for *me* to work on them. And I reserve my right to protest when
that freedom is denied on the flimsy pretext that it's good for me.
<<<<<
Yes, you do. You must also remember that it is *his* program, a
programming language for that matter. And although we can protest all we=
want, no one only Bob can make the changes. We have to respect that.
This doesn't mean I disagree with you. Frankly, it took a while for me t=
o
get adjusted to this 1 pass thing, before I realized that I had a
philosophical difference with Euphoria. In my view, this *is* a bottom-u=
p
language (instead I use routine_id, which I never have). For example, in=
a
program I wrote, I had to define all the procedures first, then work my w=
ay
up to the surface, and define procedure start() as my last procedure. Th=
is
is not the way I think.
On the other hand, define-it-before-use is something that I appreciate. =
Do
you not believe it is logical? If I have an error, I can say "oh, the
error happened here. The error happened in previous lines of code". If
our brains had our way, the error would be limited to the whole code. 1
pass lets you know you have a good program until the error.
A solution could be to wait until after the pass that these sorts of erro=
rs
are reported (no previous declaration errors). My brain is stuck right
now, and I can't think of a negative consequence for people who would sti=
ll
write in the original Euphorian style.
--Alan
=
16. Re: 1 pass?
Alan Tu wrote:
>On the other hand, define-it-before-use is something that I
>appreciate. Do you not believe it is logical? If I have an error, I
>can say "oh, the error happened here. The error happened in previous
>lines of code". If our brains had our way, the error would be limited
>to the whole code. 1 pass lets you know you have a good program until
>the error.
You, guys, drive me nuts: everybody's talking, nobody is thinking,
nobody's listening. I'll say it again (for the last time, I promise):
as far as error reporting is concerned, *nothing* would change. You
would get exactly the same message "xyz has not been declared, line
nnn" (or whatever it is) as you get it now, when you forget to declare
your variables or to include your includes or to define your routines.
So if you are foolish enough, you can still believe your program is ok
up to that point 
.
But on the other hand, you would gain the freedom to organize your
program in a way best suited to your way of thinking. Obviously, it
does not matter for short, trivial programs, but it could make a huge
difference for bigger, complex projects. Trust me. Jiri
17. Re: 1 pass?
Hmmm..., why doesn't someone just write a simple editor similar to Mike
Carrolls. But instead of having a tab for each separate file open, have
(user-definable) tabs representing various groups of subroutines for a
single open file ? The labels might be perhaps, say, Main Fileops
Interface Sound
I suppose that the actual file would have to a Eu sequence and some minor
details about opening/closing the file would need resolving etc..But, once
operable such an editor would enable a programmer to code any way they
desired. Some things to keep in mind would probably be that when testing
code the text sequence generated to invoke the EX/EXW executable would need
to be in the "Standard" Eu format, ie: main() at the end and or_all() etc..
at the start. Some rules might be that any routines within each group that
call each other be Std_Eu and any inter-group links do the same - I suppose
that (apart from the "top-level") the order that a pure text file of code
be created (for testing etc..) be as in the above example:
Fileops
Interface
Sound
Main
Now, when someone programs this in Eu, can I please have a copy?
Yours Truly
Michael Palffy
michael at igrin.co.nz
----------
> From: BABOR, JIRI <J.Babor at GNS.CRI.NZ>
> To: EUPHORIA at cwisserver1.mcs.muohio.edu
> Subject: Re: 1 pass?
> Date: Friday, 7 August 1998 11:53
>
> Alan Tu wrote:
>
> >On the other hand, define-it-before-use is something that I
> >appreciate. Do you not believe it is logical? If I have an error, I
> >can say "oh, the error happened here. The error happened in previous
> >lines of code". If our brains had our way, the error would be limited
> >to the whole code. 1 pass lets you know you have a good program until
> >the error.
>
> You, guys, drive me nuts: everybody's talking, nobody is thinking,
> nobody's listening. I'll say it again (for the last time, I promise):
> as far as error reporting is concerned, *nothing* would change. You
> would get exactly the same message "xyz has not been declared, line
> nnn" (or whatever it is) as you get it now, when you forget to declare
> your variables or to include your includes or to define your routines.
> So if you are foolish enough, you can still believe your program is ok
> up to that point .
>
> But on the other hand, you would gain the freedom to organize your
> program in a way best suited to your way of thinking. Obviously, it
> does not matter for short, trivial programs, but it could make a huge
> difference for bigger, complex projects. Trust me. Jiri
18. Re: 1 pass?
Mike wrote:
>Hmmm..., why doesn't someone just write a simple editor similar to Mike
>Carrolls. But instead of having a tab for each separate file open, have
>(user-definable) tabs representing various groups of subroutines for a
>single open file ? The labels might be perhaps, say, Main Fileops
>Interface Sound
As I understand it, the issue is that Euphoria requires that if you have
function A calling function B, function B must be defined before function A.
Putting routines into groups wouldn't really address the problem.
It is possible to write a pre-processor that takes care of all the details
for you. It would be the task of the pre-processor to arrange the routines
so that the proper routines are called first. This is not that terribly
difficult; I had done something like that for eBasic.
The problem comes in when you have a pair of mutually recursive routines,
such as:
procedure x()
y()
end procedure
procedure y()
x()
end procedure
This is trickier to automatically solve. A program can detect mutually
recursive routines, but what can be done about them? Since you are
delegating responsibility to the editor, it would have to choose one of the
routines at random and make it a forward reference:
integer forward_y
procedure x()
call_routine( forward_y, {} )
end procedure
procedure y()
x()
end procedure
forward_y = routine_id( "y" )
But I don't think Jiri wants to run a pre-processor each time he's going to
test his programs.
-- David Cuny
19. Re: 1 pass?
Michael Pallfry,
Your idea looks good, but IMHO it is not necessary to write a seperate
Euphoria program for it. If you want to do it your way, you could write
your program in a subdirectory, and include main.e, interface.e, sound.e
etc. All these include files should then have global routines and
variables. If the program works you could concatenate all those files aga=
in
into your main program. Using ed.ex or Cuny=B4s editor you can have all f=
iles
open at the same time and work alternating with them.
Regards,
Ad Rienks
original message
From: mike <michael at IGRIN.CO.NZ>
Subject: Re: 1 pass?
To: EUPHORIA at cwisserver1.mcs.muohio.edu
Hmmm..., why doesn't someone just write a simple editor similar to Mike
Carrolls. But instead of having a tab for each separate file open, have
(user-definable) tabs representing various groups of subroutines for a
single open file ? The labels might be perhaps, say, Main Fileops
Interface Sound
I suppose that the actual file would have to a Eu sequence and some minor=
details about opening/closing the file would need resolving etc..But, onc=
e
operable such an editor would enable a programmer to code any way they
desired. Some things to keep in mind would probably be that when testing
code the text sequence generated to invoke the EX/EXW executable would ne=
ed
to be in the "Standard" Eu format, ie: main() at the end and or_all() etc=
=2E.
at the start. Some rules might be that any routines within each group tha=
t
call each other be Std_Eu and any inter-group links do the same - I suppo=
se
that (apart from the "top-level") the order that a pure text file of code=
be created (for testing etc..) be as in the above example:
Fileops
Interface
Sound
Main
Now, when someone programs this in Eu, can I please have a copy?
Yours Truly
Michael Palffy
michael at igrin.co.nz
