OpenEuphoria

Re: The Py feeling & Euphoria Compiler Feature Questions.

• Posted by David Cuny <dcuny at LANSET.COM> Oct 27, 2000
• 724 views

Ralf wrote:

> I think that with a few smart optimizations,  Py's
> speed can be pulled at the level of Euphoria's speed.
> Especially by introducing a lazy execution model, but
> perhaps I'm wrong. Maybe I'll take a look myself.

Give me some hints. What do you mean by 'lazy execution model'? I don't
think you'll see anything close to Euphoria's speed, if for no other reason
than all the data is stored in sequences.

By all means, have a look at the code - that's what it's there for.

> No, it was more or less a question about internals.

Read the source, it should answer the question.

> Which leads me to another question. If I have got
> it right, an imported include file assigned to a
> namespace, works like an object where the routines
> are methods ?

It used to be that way, but I changed the model to something much simpler.
Each def and var keep track of the *file* they were originally imported
from, and a copy of the name, type, and index in the def or var table is
then stored in the namespace.

> But we can also assign a routine to a variable, how does
> this work ? Is it a distinguishable datatype ?

Yes, Py distinguishes between defs and vars. So Py knows when you write:

   ? blue (red)

that 'blue' is a variable, so it compiles an CallSelf opcode, in callUser or
callBuiltin. pyBuildCall does the dirty work. See also pyFindName to see how
Py decodes names.

>>> 7) Are you going to offer a run time py exector
>>> that we can link to in our own Euphoria programs ?
>>
>> It's low on the priority list, but I'll keep it in
>> mind. I'll be adding an 'eval' routine that you
>> could use as a hook.
>
> Well, it doesn't seem to require an enormous effort and
> it would add the option of interpreted Py code to the Py
> language as well.

At least the ability to evaluate expressions. It would basically just be a
trimmed down version of parseCommandLine that's in PY.EXE.

>>> 9) Are you going to rewrite Ox as an Ox file ?
>>
>> No. Works fine as it is. Why redo it? 
>
>
> I don't know, maybe its my questionable faith. It would
> be an interesting situation I suppose, to have Ox written
> in Py and Py written in Ox. Feels almost as dangerous as
> DNA-modification 

Conceptually, it's a neat idea. Practically, not enough fun to actually try.

> Maybe Jiri could update his library to allow
> clean and fast input/output of his association
> lists. It seems more obvious to make these updates
> in that library, than in Py, since you would be
> hacking with the datatype.

Well, the syntactic sugar is my doing, not Jiri's. And besides, he's already
rewritten the a-list library to intelligently switch between using find and
binary searches.

> Anyway, thanks for Ox, but could you document certain
> behaviour a little more?

Could you be more specific?

> And does Ox allow for real time rule creation?

No, it's all static.

> That we add a rule, during the parsing procces?

No, and you can't activate/deactivate them, either. But there are some hacks
i can add to Ox if you really need to do dynamic stuff like that. Just do a
forward reference to the parser routine, and then write stuff like this:

   Command = 'return'
           {: if mode = InFunction then
                 return { ReturnValue, parse("Expr") }
              elsif mode = InProcedure then
                 return { Return }
              else
                 oxParseError( "return must be inside procedure or
function", {} }
              end if :}

-- David Cuny

> Cheers,
>
> Ralf N.
> nieuwen at xs4all.nl