Re: New keywords: ifdef, elsifdef, end ifdef
Jeremy Cowgar wrote:
>
> Ok, in SVN revision 452, there are 2 new keywords. ifdef and elsifdef. The
> ifdef
> is combined with an existing keyword, end, to make a complete set of
> conditional
> compilation keywords.
>
> A quick rundown:
>
> 1. Setting defines can be done in 2 ways:
> 1a..... with define=debug
> ....... this can be given multiple times to define more than one item
> 1b..... exu/ecu, ex/exw/exwc/ecw -D debug
> ....... -D parameter can be given multiple times to define more than one item
>
> 2. Clearing defines can be done with without:
> 1a..... without define=debug
> ....... this turns off the debug define.
>
> 3. Predefined "defines"
> 2a..... Current operating system (WIN32, DOS32, LINUX, FREEBSD)
> 2b..... Current Euphoria version (EU400)
>
> 4. ifdef/elsifdef/end ifdef work on static defines. You cannot execute dynamic
> code in your ifdef/elseifdef.
>
(snip examples)
>
> All three of the above are dynamic. i.e. it depends on code to be executing,
> thus those are decisions that can take place only in the interpreter, not at
> parse time. If you need the above, then you use the normal if/elsif/else/end
> if statements.
>
> This is in SVN right now for anyone who wishes to test it, play with it. There
> is a unit test added for it: tests/t_condcmp.e ... 672 tests now and counting!
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
Now, granted I've just dropped in after not even looking at Euphoria for a year
or so, but the above looks really ugly to me. To me, it looks like some
bastardized version of C macros.
I considered Euphoria to be one of cleanest "scripting languages" around.
Granted, it has its occasional rough edges which you quickly got used to
(remember when '$' first appeared?) but overall the design of the language and
the library is really, really clean. The 'ifdef' and 'elsifdef' statements seem
much less clean than the rest of the language. Also, what about such constructs
like a 'ifnotdef' or an 'elsedef'? These would also be needed as well and they
are even uglier.
This is just me, however, and there are worse designs than what's been proposed.
Moreover, what I would want in a language is probably not what you would want in
one. I think compile-time coding is a terribly important thing (it is actually
one of the things that might make me come back to Euphoria) but I would want just
that, compile-time coding, not just simple conditional including.
(Odd Lisp-influenced tangent follows)
In case you don't see what I mean I'll give you an example. (The syntax used was
the one from a preprocessor I wrote for my own use a while ago. It just called
the Euphoria interpreter after parsing. Everything after a '#' is done at compile
time. I'm not saying this syntax is better necessarily (although, I do partially
prefer it), I'm just illustrating what would I think would be the "right thing"
to do in this case.) This code (which is based on code I actually used in a
project) opens a file and puts all the variable/value pairs from each line inside
the code itself.
-- Program code
#sequence filenm, line, var_val
#integer fn
#filenm = "consts.conf"
#fn = open(filenm, "r")
#line = gets(fn)
#while sequence(line) do
# var_val = split(line, '\t')
-- This "puts the statement in the code"
-- (it just puts a string into a buffer)
# statement("sequence " & var_val[1])
# statement(var_val[1] & " = " & var_val[2])
# end while
-- Program code
This code was used to allow a user to embed constants and variables in the
program so they could use them later on in the code because later on there was
some code that allowed the user to specify any include files they wrote to etend
the program. I use the Common Lisp equivalent of these constructs every time I
code.
An alternative syntax could be to stick the compile-time code into a block of
some sort, such as:
-- Assuming we defined the above code in a procedure...
compile_time -- This could instead be 'macro' or anything really
read_consts()
end compile_time
There is of course the argument that supporting this would make the interpreter
more complex and perhaps slower is a very valid argument that needs to be
considered. There is not, I feel, an argument that such constructs would not be
used. It obviously would be used for everything 'ifdef' is intended for plus it
could be used for more advanced stuff which some people need (I wrote a
preprocessor program so I could this type of programming). Heck, you might even
get some Lispers migrate to Euphoria.
I don't expect this to ever be supported, I'm just illustrating what I think the
"ideal" thing to support would be. Regardless, I still feel that the 'ifdef'and
'elseifdef' constructs need to be revised for the sake of the language's clarity.
I still have a deep (if not currently utilized) love for the language and
recommend Euphoria to beginning programmers so I'd hate to have something which
seems so counter-intuitive to the language's goals included in it.
- Derek
|
Not Categorized, Please Help
|
|
