Re: New keywords: ifdef, elsifdef, end ifdef
D. Newhall wrote:
>
> 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.
>
> }}}
<eucode>
> -- 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
> </eucode>
{{{
>
> 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,
Unless I am not understanding, your construct seems to miss the entire point of
the exercise. In the version proposed by Jeremy, you end up modifying the code
which is sent to the compiler. If the code isn't there, it doesn't run. If it
doesn't run, it doesn't slow down the execution. Further, it provides for
various levels of conditional compiles effortlessly.
For example, someone might have a Trial version and a regular version of their
program. With Jeremy's construct, the Trial version is compiled without the
regular version's code (in places where the code is different, of course),
thereby absolutely ensuring that no reverse engineering of any sort can discover
things intended to be undiscovered by the programmer.
With your construct, all you have done is allowed the program to run its various
tests with the knowledge the they will succeed or fail based on reference to an
outside configuration file. But the tests themselves must interrogate the
resulting variables in order to decide what to do.
I admit that it has been over 30 years since I dabbled in LISP (and the current
incarnation probably has little resemblance to what I struggled with at
university), but I think you are looking at this a bit differently than the way
it is intended to be viewed.
Mike
|
Not Categorized, Please Help
|
|
