1. Re: Euphoria 2.5 Will Break Existing Code
Hello Al,
----------
> From: Al Getz <Xaxo at aol.com>
> Subject: RE: Euphoria 2.5 Will Break Existing Code
>
> Igor Kachan wrote:
> >
> > Hello Al,
> >
> > Let us see 2.5 released, if it will break
> > or it will not break only knows God ...
> >
> > But for now your files:
> > allyoop.e
> > compile.exw
> > formulas.e
> > formulas.txt
> > have no any reason to be broken.
> >
> > Only demo1.exw may be devided on two parts,
> > as Juergen suggested.
> >
> > This demo has about 100 lines of code,
> > pure second part may have about 10 lines
> > from those 100.
> >
> > Plus some correction in readme for 2.5.
> >
> > You can also at least to update your package
> > and include interpreter 2.4 into this package.
> > It may forever work perfectly as currently
> > designed.
>
> So i guess God told you it will be broken in 2.5 then?
No, I can not ask God to tell me what will be,
and He never tells me what will be.
So, I say "may", not "will".
Then, "Existing Code" is too abstract concept for me.
Concrete example is *your demo1.exw program from
the allyoop.zip package*.
Then, I try to find a replacement for the old and
undocumented by Robert Craig additional feature
you used for your demo1.exw program.
I just do not know other programs used this
additional feature. This feature becomes something
like to unfinished item for the functional equality
of interpreter, translator and binder.
As far I know, for now, no one asked Rob for the
pure functional equality of interpreter, translator
and binder.
But differences were mentioned more than once.
For my own work I have found that simple replacement,
suggested by Juergen, and my own replacement, based
on Juergen's, which is not complicated too.
And you wrote: "Euphoria 2.5 Will Break Existing Code".
> > Just IMHO, sorry.
> > > Robert Craig wrote:
> > > -------------------------------------------------------
> > > >In the next release, with the clearer separation between
> > > >front-end and back-end, the interpreter will also
> > > >process the include (and all other source)
> > > >before it executes any code.
> > > >It will be simpler this way. I don't think a lot of
> > > >people are actually using the above "dynamic" include
> > > >technique, although it has been discussed on this list
> > > >from time to time.
> > > --------------------------------------------------------
> > >
> > > That breaks code, as in my AllyOOP program...
> > >
> > > Excerpt from AllyOOP readme:
> > >
> > > Basic discription:
> > > AllyOOP compiles formulas typed into an ordinary text file
> > > into function calls using 'Eval(i,x)' and stores them in an
> > > include file. The include file can then be included in the
> > > program, or this can be done on the fly by calling AllyOOP()
> > > and then including 'Formulas.e'. One demo for creating
> > > a dynamic include is enclosed with this package.
> > >
> > > Al
>
> If 2.5 cant handle dynamic includes because it will try to
> process EVERY include file before it executes ANY code then
> how can it write a new include file before it runs it?
Just divide your program onto 2, 3 and more modules,
it is not too big problem, this division, I think.
Few key strokes in ed editor.
> Thus, 2.5 will break any code written that uses a dynamic
> include in this manner, which AllyOOP does.
What *any* code?
My own private code I have corrected; you have now the
functional replacement for that additional feature;
Judith, asked for that feature in the concrete example
of her code, has now two possible ways to make plugins
as include files in 2.5 and just now, and a lot of
possible ways useing dlls suggested by Derek, Matt and Rob.
> Any questions?
One question. What another *concrete* known
program *may* require *concrete* corrections?
Let us see please.
> Al
Regards,
Igor Kachan
kinz at peterlink.ru
