1. Re: Implementing structures
Kasey wrote:
>>This sounds like somthing a good preprocessor could do. In fact most =
of the
>>changes people want could probably be done with a
>>preprocessor, which if customizeable, could let them EACH have thier =
own personal
>>flavor of Euphoria without RDS having to add a thousand bells and =
whistles, most of
>>with I for one DON'T want, and thats why I'm using euporia instead of =
visual c++
>>turbo
Pre-processors for Euphoria can be a bit challanging to write, =
especially since Euphoria allows commands to be broken over several =
lines, or places on the same line. For example:
puts
(
1
,
"this is legal"
)
is perfectly legal, as is:
puts( 1, "this is" ) puts( 1, " legal" )
I got around this in my pre-processor by requiring that certain =
constructs be on a single line. Adding an end of line marker (such as =
'_') will also work.
Another issue is included files. For example, let's say that I define a =
structure in a file foo.pp. The pre-processor converts the file to foo.e =
(for example). If I include foo.e in my file, my main program can't use =
the structures defined in foo.e (at least, not as *structures*) because =
there are no structures anymore - they have been converted into Euphoria =
code.
For implementing control structures (case, etc.), a pre-processor is =
fine. But for global structures, it can be problematic.
Besides, who wants to have to write a pre-processor (besides me)? You =
should be able to find an acceptable mechanism in the structure of the =
language to accomplish what you want. If you can't, perhaps the language =
*does* need a new feature.
In the case of structures, I think that Euphoria *can* adequately =
simulate them. But they seem to mesh well with the concept of sequences, =
and there's always the benefit of optimization if it's part of the nativ =
feature set.
>>finaly structure i needed. so rather than ask for changes to the =
language I wrote to
>>short
>>little recursive routines to pre-define the sequence structure however =
I needed (it
>>was a LOT simpler than I thought!) I found it usefull enough I upped =
it to RDS for the
>>contrib page.
I've written a version of the DIM statement myself. It's a good example =
of things that *can* be coded in the language.
>>Please don't take any of this as flames, I really do intend it as a =
contribution to the
>>Euphoria comunity, I like euphoria BECUASE it doesn't have any of the =
b.s.
>>microsoft and other big software companies are trying to tell us we =
gotta have. the
>>old C=3D64's didn't
>>have OOP or OLE or a zillion layers of indirection, yet how many =
thousands of cool
>>programs were written for it that ran just fine (how many times did =
comercial
>>software for the c64 crash the system?????) a way was even found to =
make the
>>FLOPPY drive play
>>music!!
There were a lot of cool programs, but how maintainable were they? In =
many cases, they were examples of what could be coded in spite of the =
many limitations.
Often, mechanisms that seem unnecessary or bulky for small programs can =
be extremely useful for large programs. For example, I'm not especially =
fond of a lot of features in Python - but people developing large =
programs seem to love it, because those features solve real problems for =
them.
I don't envy Robert - it's a tough to decide exactly how much to put in, =
and what to leave out. I agree with most people that one of Euphoria's =
selling points is it *not* being a feature-bloated environment.
-- David Cuny
