1. Those of us who are C'ly challenged :>
- Posted by Jeffrey Caldwell <kirran at AMERITECH.NET>
Jul 15, 1998
-
Last edited Jul 16, 1998
I was just wondering if anyone has ever seen a program that could
reduce a c source into something readable by C-challenged people
like me :>
I was looking over muds and ended up getting the gcc compiler to
try to learn c...(finally)... but I ended up at a Euphoria page
and for the third time looked at Euphoria again :> Three times
the charm... I actually got a program to run. (ok ok... Euphoria
is easy... compared to other languages ;)
The point being... C is just plain icky :>
BUT... everyone writes in C... and if I wanna see how someone
else does something.. I need to know C too.. or else find a
better alternative.
(hah... if I were a dreamer I'd make a wish for a C to Euphoria
converter ;) ;)
If anyone has some suggestions, I'd love to hear them.
'nother thing, anyone got any ideas for simple beginner's projects?
I did a (ohmygawdit'ssocompletelymessedup) version of a ponglike
game (I figured what game would be more simple than a clone of the
*first* game? :)
Thanks :>
2. Re: Those of us who are C'ly challenged :>
- Posted by David Cuny <dcuny at LANSET.COM>
Jul 15, 1998
-
Last edited Jul 16, 1998
Jeffrey wondered about learning C.
Yes, C *is* icky. But it's not that hard to read. Like any other language,
it's best to learn the language in the natural idiom rather than work with
crutches of seeing it as if it were a different language (C to Euphoria
translator, for example).
I'm just re-learning C for a Euphoria-related project. It's actually a
pretty simple language - it's the pointers that add the complexity, as well
as give you the cool features. I'm using "The C Programming Language", by
Kernighan and Ritchie (the "K&R" book). In my mind, it's still the best text
out there. You probably want to supplement the difficult topic (pointers,
natch) with readings from other places. There are a number of good tutorials
available on the web.
Ironically, Euphoria did a pretty good jub of training me to get into the C
"frame of mind". Back when I used BASIC, I balked at having to use printf()
and their like. Now, they are second nature. Just be sure to look up the
parameters and return values of all the C functions - unlike Euphoria's
sprintf, for example, 'C's does *not* return a pointer to a string. There
were a number of gotchas like that.
I spent a couple days with the training wheels on, playing with a C
interpreter called Quincy (QNC) available at the Dr. Dobb's site. I'd
recommend it - except for lacking color coding, it's a very good training
platform. I eventually move on the the gcc and spent a week or so gnashing
my teeth over errors like:
"The error occurs somewhere before the ;"
Probably the most unhelpful error message I can think of. Getting to know a
language is, unfortunately, also the process of learning to decode error
messages like the one above (which usually mean there is a missing
parenthesis, or something similar).
If you want a good project, try writing a tool for virtual string arrays.
You'll use most of the useful features in C, get a good handle on pointers,
and when you're done you'll have a very useful tool.
-- David Cuny
3. Re: Those of us who are C'ly challenged :>
>I was just wondering if anyone has ever seen a program that could
>reduce a c source into something readable by C-challenged people
>like me :>
C is reabable, and in its basic, nothing more than ASM with a extensive
macros.
Loops, functions, etc. it is all precizely clear what code it produces, and
arrays, are nothing more than a calculation..
It therefor gives you a lot of control. You can have C-code and ASM interact
so nicely.
The problem is some dude once called it a high-end-language. And all do, it
contains high-end-elements you can still translate C-code literally to ASM.
Every where where { } stand is made into an asm-block.
It is thus great for fast, low-level problems, but you have to translate a
whole algorithm-idea-thingie in your head to almost precize directions for
the proccesor. And because the high-end-elements are still so fixed, you end
up using all kinds of hacks of non-clean programming.
That is why they added the two plus signs. Not even such a bad idea... an
ASM-macro preproccesor totally out of control. And well, prolly due to those
nice plus signs, is the reason why a normal windows program is at least a
couple of megs big, and goes extremely slow in comparison. Still, everybody
uses C. Well I think C++ is completely useless. There are much
higher-languages that you can use to have a bit of order in your program
that are fast and clean at that kind of thing, which could contain C-code.
For example, Inline ASM can help, Inline C would be great. Just see it as
inlining the latest ASM-version with all cool macro-scripting and stuff and
just forget about those double plus signs.
>I was looking over muds and ended up getting the gcc compiler to
>try to learn c...(finally)... but I ended up at a Euphoria page
>and for the third time looked at Euphoria again :> Three times
>the charm... I actually got a program to run. (ok ok... Euphoria
>is easy... compared to other languages ;)
Euphoria talks in our language, not in the proccesor's language, that is the
difference between a high-level-language and a low-level.
>(hah... if I were a dreamer I'd make a wish for a C to Euphoria
>converter ;) ;)
Well, actually, it wouldnt be that hard to convert C to working EUphoria
code, but I would suppose you want it to be transformd to Euphoria-style
code.
Still, it would be great to test a c-program. It is works translated to
Euphoria, then there could be no memory leaks, etc.
>'nother thing, anyone got any ideas for simple beginner's projects?
>I did a (ohmygawdit'ssocompletelymessedup) version of a ponglike
>game (I figured what game would be more simple than a clone of the
>*first* game? :)
I did something like that 
.. I named it 'clone'. But it was one big
hack, very ugly code actually.
Well, we haven't even seen a PacMan, have we ?
And with all the grahpics libraries out there...
Or master-mind game to try one of the GUI's.. ?
(or does this already exist ?)
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
4. Re: Those of us who are C'ly challenged :>
I've NEVER found Euphoria to be easier than C! I just haven't. The reason is
that Euphoria wasn't designed to be structured (at least, I think so). C
gets the job done. Euphoria is more of a gaming language than anything.
Now, have you ever heard Doom being made in Euphoria? I wouldn't think so. C
seems to me to be more powerful that Euphoria, but I like Euphoria's easy to
use strategy.
- Nate Brooman
[nateb at log.on.ca]
-----Original Message-----
From: Jeffrey Caldwell <kirran at AMERITECH.NET>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: July 16, 1998 12:08 AM
Subject: Those of us who are C'ly challenged :>
>I was just wondering if anyone has ever seen a program that could
>reduce a c source into something readable by C-challenged people
>like me :>
>
>I was looking over muds and ended up getting the gcc compiler to
>try to learn c...(finally)... but I ended up at a Euphoria page
>and for the third time looked at Euphoria again :> Three times
>the charm... I actually got a program to run. (ok ok... Euphoria
>is easy... compared to other languages ;)
>
>The point being... C is just plain icky :>
>
>BUT... everyone writes in C... and if I wanna see how someone
>else does something.. I need to know C too.. or else find a
>better alternative.
>
>(hah... if I were a dreamer I'd make a wish for a C to Euphoria
>converter ;) ;)
>
>If anyone has some suggestions, I'd love to hear them.
>
>'nother thing, anyone got any ideas for simple beginner's projects?
>I did a (ohmygawdit'ssocompletelymessedup) version of a ponglike
>game (I figured what game would be more simple than a clone of the
>*first* game? :)
>
>Thanks :>
>
5. Re: Those of us who are C'ly challenged :>
Nate Brooman wrote:
> I've NEVER found Euphoria to be easier than C!
I, on the other hand, find it infinitely easier than C - primarily for
the same reason many find Java superior as well:
- No pointers
- Strings
- Automatic garbage collection
> ... Euphoria wasn't designed to be structured
By any definition I can think of, Euphoria is a *highly* structured
language.
> Euphoria is more of a gaming language than anything.
I disagree. I think that the "gaming" feature shows off just how fast
Euphoria can be. One of the reasons you see so much gaming stuff written
is the nature of the platform: DOS coders tend to write games.
I suspect that the main reason you don't see as much Win32 code is
because the library support is rather weak. As better tools become
available, I think you'll see more non-game applications being
developed.
-- David Cuny
6. Re: Those of us who are C'ly challenged :>
Well, one reason Euphoria/Win32 is so weakly developed is because Eu32
f***ks up the screen.
One main reason why I think that C is better then Eu is that you can declare
stuff below the initial procedure. I.E.:
int main()
{
printf("Hello\n");
goaway();
}
goaway()
{
printf("\nGo away now!\n");
}
and it's bound to work. But I get errors in Eu by typing:
procedure hello()
clear_screen()
puts(1,"Hello!\n")
goaway()
end procedure
procedure goaway()
puts(1,"\nGo away now!\n")
end procedure
You know why it does this David? I can structurize Eu, but not like the
previous example (why is this Rob?)
- Nate Brooman
[nateb at log.on.ca]
-----Original Message-----
From: Cuny, David <David.Cuny at DSS.CA.GOV>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: July 16, 1998 2:51 PM
Subject: Re: Those of us who are C'ly challenged :>
>Nate Brooman wrote:
>
>> I've NEVER found Euphoria to be easier than C!
>
>I, on the other hand, find it infinitely easier than C - primarily for
>the same reason many find Java superior as well:
>
> - No pointers
> - Strings
> - Automatic garbage collection
>
>> ... Euphoria wasn't designed to be structured
>
>By any definition I can think of, Euphoria is a *highly* structured
>language.
>
>> Euphoria is more of a gaming language than anything.
>
>I disagree. I think that the "gaming" feature shows off just how fast
>Euphoria can be. One of the reasons you see so much gaming stuff written
>is the nature of the platform: DOS coders tend to write games.
>
>I suspect that the main reason you don't see as much Win32 code is
>because the library support is rather weak. As better tools become
>available, I think you'll see more non-game applications being
>developed.
>
>-- David Cuny
>
7. Re: Those of us who are C'ly challenged :>
Nate Brooman wrote:
>
> Well, one reason Euphoria/Win32 is so weakly developed is because Eu32
> f***ks up the screen.
>
> One main reason why I think that C is better then Eu is that you can declare
> stuff below the initial procedure. I.E.:
>
> int main()
> {
> printf("Hello\n");
> goaway();
> }
>
> goaway()
> {
> printf("\nGo away now!\n");
> }
>
> and it's bound to work. But I get errors in Eu by typing:
>
> procedure hello()
>
> clear_screen()
> puts(1,"Hello!\n")
> goaway()
> end procedure
>
> procedure goaway()
>
> puts(1,"\nGo away now!\n")
>
> end procedure
>
> You know why it does this David? I can structurize Eu, but not like the
> previous example (why is this Rob?)
>
> - Nate Brooman
> [nateb at log.on.ca]
>
Defining functions before they are called is one of the things that
separates structured langueges from unstructured - like BASIC.
Your example is called "forward declaration" and is generally
discouraged as sloppy
programming. It's normally reserved for use when there is no
alternative, or when
your CS grades are too high.
Irv
8. Re: Those of us who are C'ly challenged :>
Nate wondered:
> One main reason why I think that C is better then Eu is that you can
> declare stuff below the initial procedure. I.E.:
Actually, your example will NOT work in ANSI C. The compiler will
complain that "goaway" is an unknown function, just like Euphoria does.
For the code to compiler, you need to define prototype for your function
first:
void goaway(void); /* prototype */
int main() {
printf("Hello\n");
goaway();
}
void goaway() {
printf("\nGo away now!\n");
}
It might work automagically if your compiler supports automatic
prototype generation, but that's not standard ANSI C.
If you had re-written your code in the manner that Euphoria requires, it
would work just fine in C, without the need for a prototype:
void goaway() {
printf("\nGo away now!\n");
}
int main() {
printf("Hello\n");
goaway();
}
That's because C and Euphoria are both one-pass compilers. You can't
reference anything until it's been defined. C lets you get around that
by setting up prototypes, but those are prone to error. I prefer to lay
my C code out similar to Euphoria code.
On those rare occasions that you really *do* need to call a function
before it is defined, you can use routine_id and call_routine to
accomplish the same thing that C prototypes do.
-- David Cuny
9. Re: Those of us who are C'ly challenged :>
>Actually, your example will NOT work in ANSI C. The compiler will
>complain that "goaway" is an unknown function, just like Euphoria does.
>For the code to compiler, you need to define prototype for your function
>first:
I thought the same, but made a simple example code (like the one in
discussion) and compiled perfectly under Turbo C v2.0 (is it ANSI C?), but
on Turbo C++ 3.0 it complained and required the function prototype (or
rearregment of the code).
Regards,
Daniel Berstein
daber at pair.com
10. Re: Those of us who are C'ly challenged :>
-----Original Message-----
De: Nate Brooman <nateb at LOG.ON.CA>
Para: EUPHORIA at cwisserver1.mcs.muohio.edu
<EUPHORIA at cwisserver1.mcs.muohio.edu>
Fecha: Jueves 16 de Julio de 1998 05:39 PM
Asunto: Re: Those of us who are C'ly challenged :>
>Well, one reason Euphoria/Win32 is so weakly developed is because Eu32
>f***ks up the screen.
I have never had this problem.
>One main reason why I think that C is better then Eu is that you can
declare
>stuff below the initial procedure. I.E.:
>
>int main()
>{
>printf("Hello\n");
>goaway();
>}
>
>goaway()
>{
>printf("\nGo away now!\n");
>}
>
>and it's bound to work. But I get errors in Eu by typing:
>
>procedure hello()
>
> clear_screen()
> puts(1,"Hello!\n")
> goaway()
>end procedure
>
>procedure goaway()
>
> puts(1,"\nGo away now!\n")
>
>end procedure
If you try to compile your C code on a C++ compiler it will complain. Plain
C compilers seems to not need a explicit foward declaration (C++ does need
prototypes for foward calling). I find absolutly more structered to have all
function references be firstly declared. You must agree that Pascal is a
very structured language, and it doesn't support foward calling unless you
explicitly use the "foward" reserved word (at least with Borland's
implementation). If you want an un-structurized language example search for
BASIC (ugghh!!!).
If you read the Euphoria reference manual one of the first things said about
function/procedures is that htey cannot call undeclared (not in scope)
functions/procedures. This oblies you to have your code very well
structured, thinking twice before inserting functions: think (program flow),
then code.
Regards,
Daniel Berstein
daber at pair.com
11. Re: Those of us who are C'ly challenged :>
>One main reason why I think that C is better then Eu is that you can
declare
>stuff below the initial procedure. I.E.:
And this man thinks he knows what makes a language structured ?
If C is so very structured why the need for the OO to make C++
Have you ever used the switch statement ? Or wondered if there are
enough }'s ?
And since when is freedom of ordening (what you like so much about C)
considered structured.. and why do all C programs have such a fixed
indentation ? Why, is this structured language otherwise confusing to read ?
C is structured from a processor's view, not from an algorithm
point-of-view..
It is structured is such way it can easily be translated to ASM.
Euphoria is much more structured and consistent..
Take a 'for' statement:
end_var = 10
for index = 1 to end_var do
endvar = 1
end for
In Euphoria it will still go to 10 as it should..
In C however it will cycle through it only ONE time..
Can you image if it was a function call, or some other very expensive call ?
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
12. Re: Those of us who are C'ly challenged :>
- Posted by Nate Brooman <nateb at LOG.ON.CA>
Jul 16, 1998
-
Last edited Jul 17, 1998
Listen, I code my way, you guys code your way.
-----Original Message-----
From: Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: July 16, 1998 8:28 PM
Subject: Re: Those of us who are C'ly challenged :>
>>One main reason why I think that C is better then Eu is that you can
>declare
>>stuff below the initial procedure. I.E.:
>
>And this man thinks he knows what makes a language structured ?
>If C is so very structured why the need for the OO to make C++
>Have you ever used the switch statement ? Or wondered if there are
>enough }'s ?
>And since when is freedom of ordening (what you like so much about C)
>considered structured.. and why do all C programs have such a fixed
>indentation ? Why, is this structured language otherwise confusing to read
?
>C is structured from a processor's view, not from an algorithm
>point-of-view..
>It is structured is such way it can easily be translated to ASM.
>Euphoria is much more structured and consistent..
>
>Take a 'for' statement:
>end_var = 10
>for index = 1 to end_var do
> endvar = 1
>end for
>
>In Euphoria it will still go to 10 as it should..
>In C however it will cycle through it only ONE time..
>Can you image if it was a function call, or some other very expensive call
?
>
>Ralf Nieuwenhuijsen
>nieuwen at xs4all.nl
>
13. Re: Those of us who are C'ly challenged :>
>Listen, I code my way, you guys code your way.
Didnt want to offend you, sorry.
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
14. Re: Those of us who are C'ly challenged :>
Oh, that's allright Ralf. It's just that I was always told to code 1 step at
a time. For example, in QBasic, if I want to code a program, I structurize
it:
' A Program
DECLARE SUB MainMenu ()
DECLARE SUB QuitScreen()
etc...
and in Euphoria, I have to do this:
-- A Program
include get.e
object menuselect
etc...
procedure QuitScreen ()
etc...
end procedure
procedure MainMenu ()
etc...
end procedure
MainMenu ()
Is this how to do it guys? I would have thought that Euphoria read all of
the code first, then ran the program.
- Nate Brooman
[nateb at log.on.ca]
-----Original Message-----
From: Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: July 17, 1998 1:27 PM
Subject: Re: Those of us who are C'ly challenged :>
>>Listen, I code my way, you guys code your way.
>
>
>Didnt want to offend you, sorry.
>
>Ralf Nieuwenhuijsen
>nieuwen at xs4all.nl
>
15. Re: Those of us who are C'ly challenged :>
Nate wondered:
> I would have thought that Euphoria read all of the code
> first, then ran the program.
Reading tha manual carefully can really save you a lot of grief. For
example, section 2.6 explains how Euphoria handles converting source
code.
Think of it this way: as Euphoria reads the file, it "compiles" that
code into an internal representation. As soon as the end of an un-nested
statement is reached, the code that was built is executed. For example,
as soon as Euphoria realizes it has reached the end of the statement:
? 1 + 2
it executes the code that was just created. Note that the EOL (end of
line) marker does *not* mark the end of a statement in Euphoria; you
could have just as easily written:
? 1 -- comments are ignored
+ 2
and it would run the same. If there are *nested* statements, Euphoria
waits until the end of the top-most statement is reached before
executing it. For example:
for i = 1 to 10
for j = i to 10
? {i,j}
end for
end for
doesn't execute until the second "end for" is reached. Some statements
have no visible execution behavior, such as:
procedure foo()
puts( 1, "foo!" )
end procedure
Code has been generated, but the "procedure" statement essentially tells
Euphoria to store "foo"'s code for later execution, instead of running
it immediately. Statements like:
integer x, y
also have no "visible" action - their execution does magical stuff in
the interpreter, out of our view.
-- David Cuny
16. Re: Those of us who are C'ly challenged :>
From: Nate Brooman
>It's just that I was always told to code 1 step at
>a time. For example, in QBasic, if I want to code a program, I structurize
>it:
[code snipped]
Precisely. One step at a time. The only real difference in what
you're
describing is that QBasic requires you to declare the routines first, then
comes the main program, then the routines' actual code; whereas in
Euphoria, the routines come first, then the main program, with no
declarations necessary. (except when bypassing that rule with
routine_id() )
QB source looks like:
<Declarations of routines which follow program>
<Main Program>
<Routines declared before program>
EU source looks like:
<Routines>
<Main Program>
Qbasic won't let you use undeclared routines either. (Technically, that is,
actually it generates the declarations for you if you forget them, but in
my experience it often gets the declarations wrong.)
Benefits to Euphoria's 'stricter' structure are:
1. You (or the interpreter) can read code straight through, start to
finish,
and never come across something that hasn't been defined yet. The
interpreter doesn't need to try to 'guess' what something will be, so it's
more efficient.
2. You have more freedom to mix things up. All your routines don't have
to come first or last, you can put main-level code before, between, or after
routines, so long as everything which that bit of code uses already exists.
3. It discourages sloppy programming by encouraging you to know
what the steps will be, and exactly what they will do, before you start
writing the main program, rather than writing a program and then hacking
parts of it off into routines.
4. It's a good deal easier to work with and better looking once you get
used to it. (which won't take long)
17. Re: Those of us who are C'ly challenged :>
I've noticed that QBasic games (especially M/K Productions games) are
acually fast and fun! Euphoria, given the right time, will practically
replace QBasic (if it hasen't already 
. Go take a look at M/K's games at:
http://members.aol.com/mkwebsite/
Boy! I NEVER would have thought QBasic had great fast games! Look at their
Fury, which has yet to be overcome in the QB world.
- Nate Brooman
[nateb at log.on.ca]
-----Original Message-----
From: Falkon <Falkn13 at IBM.NET>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: July 18, 1998 2:59 AM
Subject: Re: Those of us who are C'ly challenged :>
>From: Nate Brooman
>>It's just that I was always told to code 1 step at
>>a time. For example, in QBasic, if I want to code a program, I structurize
>>it:
>[code snipped]
>
> Precisely. One step at a time. The only real difference in what
>you're
>describing is that QBasic requires you to declare the routines first, then
>comes the main program, then the routines' actual code; whereas in
>Euphoria, the routines come first, then the main program, with no
>declarations necessary. (except when bypassing that rule with
>routine_id() )
>
>QB source looks like:
><Declarations of routines which follow program>
><Main Program>
><Routines declared before program>
>
>EU source looks like:
><Routines>
><Main Program>
>
>Qbasic won't let you use undeclared routines either. (Technically, that
is,
>actually it generates the declarations for you if you forget them, but in
>my experience it often gets the declarations wrong.)
>
>
>Benefits to Euphoria's 'stricter' structure are:
>1. You (or the interpreter) can read code straight through, start to
>finish,
>and never come across something that hasn't been defined yet. The
>interpreter doesn't need to try to 'guess' what something will be, so it's
>more efficient.
>
>2. You have more freedom to mix things up. All your routines don't have
>to come first or last, you can put main-level code before, between, or
after
>routines, so long as everything which that bit of code uses already exists.
>
>3. It discourages sloppy programming by encouraging you to know
>what the steps will be, and exactly what they will do, before you start
>writing the main program, rather than writing a program and then hacking
>parts of it off into routines.
>
>4. It's a good deal easier to work with and better looking once you get
>used to it. (which won't take long)
>
