OpenEuphoria

Re: Bind Problems (solved?)...

• Posted by Roderick Jackson <rjackson at CSIWEB.COM> Jun 28, 1999
• 395 views

Irv Mullins wrote:
>On Mon, 28 Jun 1999, you wrote:
>> Robert Craig wrote:
>> >Mike Fowler writes:
>> >[a bunch of suggestions about the bind program]
>> >
>> >Thanks for the suggestions.
>> >In any redesign of bind, I would seriously consider making
>> >it 2-pass, so it could discard any routines, variables or
>> >constants that aren't used.
>>
>> Hmmm. I hate to ask this Rob, but would that be the best way to go?
>> Sure, condensing code is a good thing and all, but couldn't this
>> seriously affect code performance/requirements between bound and unbound
>> code? Even to the extent that the code behaves differently?
><snip>
>
>On the flip side, wouldn't it be nice if bind would discard unused routines
>from the Euphoria run-time as well? Then we could get back to writing 5k Hello
>World programs, instead of 175k.

Well, that might solve half of the problem...

The fact that declared code is being ignored isn't obvious from the
source; you'd need the language's documentation. Noting that commented
code won't be compiled, on the other hand, is fairly clear. Not
recognizing that someone else's code could be ignored complicates the
other problems (keep reading.)

It would simply be a Bad Thing to be forced to put something like

   myconstant = myconstant

or

   dummyvar = myfunction ()

into the source just to make sure that commenting out one small routine
(or even temporarily not making use of the routines in question)
wouldn't result in the exclusion of code. I'd rather be forced to
comment out the code I DIDN'T want in a program than to explicitly
specify "No, I want *this* constant/routine/library to not be ignored."

Yes, I know, including an entire nnnK library just to use a few features
eats into memory and all. But it's logically consistent: if declared, it
exists, as opposed to if used, it exists. That might be hard to determine
with unbound code; it'll kill the few opportunities for dynamic source
code we have (E! and Dynaminc come to mind.) And I don't think programs
using routine_id to choose among several routines, in bound OR unbound
code, will even be possible anymore (object-oriented methods and libraries,
for example.)

I realize my argument against the idea sounds a bit self-serving, but then
again the impact would be somewhat farther reaching than just the few
things I've produced. We're talking about eliminating entire ways of
working in the language here, all for the sake of shrinking (compiled, not
source) code. I would rather see an effort to produce smaller, possibly
more numerous libraries rather than see it all come to that.


Rod Jackson