Re: Another EU 2.5 suggestion...
- Posted by Isaac Raway <isaac-topica at blueapples.org> Jan 26, 2004
- 491 views
Matt Lewis wrote: > > >--- Isaac Raway <isaac-topica at blueapples.org> wrote: >=20=20 > >>aku saya wrote: >> >>=20=20=20=20 >> >>>After reading many posts about the eval() function, I want to post my >>>opinion, that eval() will not be suitable for euphoria, because >>>euphoria can be translated and compiled, not just interpreted. Eval() >>>needs interpreter. So I think there will never be an eval() function >>>in euphoria. >>>=20 >>> >>>=20=20=20=20=20=20 >>> >>I disagree entirely. The facility that eval() provides would be easy to= =20 >>implement. Simply create a function euParse() which returns the IL code= =20 >>for a string of Euphoria source, and a function euRun() which executes= =20 >>this IL. You could then provide a function eval(sequence source) that=20 >>just does return euRun(euParse(source)). Easy. >> >>Also, it is not quite true that Euphoria can be compiled. It is simply= =20 >>translated to the aforementioned IL, and then executed, so providing=20 >>these three functions should be as simple as wrapping their Euphoria=20 >>(for the parser in 2.5) and C counterparts. >> >>=20=20=20=20 >> > >As others have noted, Euphoria *can* be compiled (using the Euphoria runti= me >library). In order to have the eval() functionality, though, you'd probab= ly >need an additional library to do the parsing, as well as a thin interprete= r >that could call the run time libarary. > >Matt Lewis > > >=20=20 > No, it cannot be compiled. An approximately equivalent C source file can be generated, which is=20 then compiled. This is very different from an actual compiler, as it=20 introduces another layer in the process with it's own questions. Such a=20 question was cited in another response to this thread, where Aku assumed= =20 that the translator should discard variable names. I don't know that it=20 does this now, as I don=92t use it, but it certainly is not a requirement= =20 that it does. The facility I described (euParse(), euRun() and eval()) should execute=20 just fine in a translated program. If not, then the translator would be=20 changing the semantics of the program to the point that little else=20 should be expected to execute properly either. Even if would not work in a translated program, this should not be of=20 concern to a new version of the language. The translator will just have=20 to "grow up", so to speak, and support the new feature. >__________________________________ >Do you Yahoo!? >=20=20 > No. I most certainly do not Yahoo.