Re: Another EU 2.5 suggestion...

new topic     » goto parent     » topic index » view thread      » older message » newer message

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.

blink

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu