1. The Py feeling & Euphoria Compiler Feature Questions.
An interactive command line interpreter. It almost feels like i've
timewarped back to my old commodore.
No, really interesting approach, esspecially when a number of debug features
and a number of special routines are added.
But David, a few questions and remarks remain.
1) First of all, are you planning of doing anything on the optimization
part ?
2) I love the OO approach, and the Else clause for all kinds of non-ending
loops. (brilliant)
3) Is overloading of routines legal, and if so or if so not, how does it
deal with this ? Esspecially when dealing with routine-id-variables.
4) Are you going to introduce labelled exits, and labelled statement
blocks. (also great for error messages) ?
5) If not, could I convince you to at least add the option to jump out of a
number of statement blocks ? (i.e. exit (3) jumps out of the last three
started statement blocks)
6) Now you have a full working OO model, are you planning to redo Win32lib ?
7) Are you going to offer a run time py exector that we can link to in our
own Euphoria programs ?
8) Are you going to rewrite Ox in Py ?
9) Are you going to rewrite Ox as an Ox file ?
10) How do the sequence operators and the print () and get () work with the
association-lists ?
And the last few question goes out to Robert Craig:
10) Robert, what do you think about David's new features ? Esspecially the
little gizmo's such as the Else clause for while and for loops, the for-in
loop, the associations lists, the multiple assigns (like: value, get_status
= get (1) ). All of these would create code, which is easier to read,
maintain and debug.
11) Will the Euphoria compiler allow you to include C code, directly into
your Euphoria code ?
12) Could the compiler be written so that the global routines are exportable
? (to create DLL's, VBX'en, VXD's etc.) Or at least offer routines to set up
exportable routines ? For example, to create Winamp plugins for trippy
visualisation, or to create Photoshop filters, etc.
Thanks in advance, and success. (to you both, btw)
Ralf N.
nieuwen@
nieuwen at xs4all.nl
2. Re: The Py feeling & Euphoria Compiler Feature Questions.
- Posted by David Cuny <dcuny at LANSET.COM>
Oct 26, 2000
-
Last edited Oct 27, 2000
Ralf wrote:
> 1) First of all, are you planning of doing anything on
> the optimization part ?
Until the code stabilizes, I'm not going to do much in terms of
optimizations. The speed at this point is actually suprisingly good. But
yes, it's on the "to do" list.
> 2) I love the OO approach, and the Else clause for all
> kinds of non-ending loops. (brilliant)
Thanks, but I can't take credit for any of it. The OOP comes right out of
JavaScript, and the Else clause is from Python.
> 3) Is overloading of routines legal, and if so or if so
> not, how does it deal with this ? Especially when
> dealing with routine-id-variables.
In the last release, you could redefine defs. In the new version, I've
removed that capability. Could you give me some example of what you want to
do?
> 4) Are you going to introduce labelled exits, and
> labelled statement blocks?
The current implementation method makes that difficult, or I'd do it.
> 5) If not, could I convince you to at least add the option
> to jump out of a number of statement blocks?
I've got an interesting idea that I'll probably steal from ABC that *should*
take care of those sorts of problems.
> 6) Now you have a full working OO model, are you planning
> to redo Win32lib?
No, that's a major job with dubious benefits, and I'd rather work on
wrapping GTK+ (in Euphoria) than rehashing Win32Lib. I'm pretty curious to
see what Derek has done to restucture the code...
But I will hack it so you can run Win32Lib from Py.
> 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.
You *can* run pi.ex to create a wrapper for existing Euphoria libraries, so
going the other way is trivial.
> 8) Are you going to rewrite Ox in Py ?
No. Work fine as it is. Why redo it?
> 9) Are you going to rewrite Ox as an Ox file ?
No. Works fine as it is. Why redo it?
> 10) How do the sequence operators and the
> print () and get () work with the association-lists ?
Good idea. All the i/o routines need to be fixed, probably next week at
earliest.
Thanks for the feedback!
-- David Cuny
3. Re: The Py feeling & Euphoria Compiler Feature Questions.
> > 1) First of all, are you planning of doing anything on
> > the optimization part ?
>
> Until the code stabilizes, I'm not going to do much in terms of
> optimizations. The speed at this point is actually suprisingly good. > But
yes, it's on the "to do" list.
I think that with a few smart optimizations, Py's speed can be pulled at
the level of Euphoria's speed. Esspecially by introducing a lazy execution
model, but perhaps I'm wrong. Maybe i'll take a look myself.
> > 3) Is overloading of routines legal, and if so or if so
> > not, how does it deal with this ? Especially when
> > dealing with routine-id-variables.
>
> In the last release, you could redefine defs. In the new version, I've
> removed that capability. Could you give me some example of what you want
to
> do?
No, it was more or less a question about internals. I'm not sure what I want
to do. I'm trying to see what reach Py has. What is possible with it, and
what isn't. Overloading is an obvious gray area.
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 ?
But we can also assign a routine to a variable, how does this work ? Is it a
distinguishable datatype ?
red = routine_id ("my_red_func")
? red
blue = red
? blue
? blue (red)
Does this work ? How ?
> > 4) Are you going to introduce labelled exits, and
> > labelled statement blocks?
>
> The current implementation method makes that difficult, or I'd do it.
Are you referring to the parser or to py ?
> > 5) If not, could I convince you to at least add the option
> > to jump out of a number of statement blocks?
>
> I've got an interesting idea that I'll probably steal from ABC that
> *should* take care of those sorts of problems.
Well, we'll just have to wait and see, I guess.
> But I will hack it so you can run Win32Lib from Py.
Perhaps, it is wise to have Win32lib run at Euphoria's speed rather than
Py's speed.
> > 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.
> You *can* run pi.ex to create a wrapper for existing Euphoria
> libraries, so going the other way is trivial.
Yes, I read about this in your documentation, how does it work ? Why not
allow real-time wraps of Euphoria files by Py ? (using a different parser
file!)
> > 8) Are you going to rewrite Ox in Py ?
>
> No. Work fine as it is. Why redo it?
> > 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
> > 10) How do the sequence operators and the
> > print () and get () work with the association-lists ?
>
> Good idea. All the i/o routines need to be fixed, probably next
> week at earliest.
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.
Anyway, thanks for Ox, but could you document certain behaviour a little
more ? And does Ox allow for real time rule creation ? That we add a rule,
during the parsing procces ?
Cheers,
Ralf N.
nieuwen at xs4all.nl
4. Re: The Py feeling & Euphoria Compiler Feature Questions.
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
5. Re: The Py feeling & Euphoria Compiler Feature Questions.
Ralf writes:
> 10) Robert, what do you think about David's new features ?
I intend to look at Py after I finish the translator.
> 11) Will the Euphoria compiler allow you to include C code,
> directly into your Euphoria code ?
At the moment, you would have to do this manually.
For instance you might create your own .c file,
and add it to a modified emake.bat. You could add calls
to functions in your .c, from a .c that the translator generates.
You might need to know a bit about the (current) internal
representation of Euphoria objects. Eventually this will be
supported in a better way.
> 12) Could the compiler be written so that the global routines
> are exportable ? (to create DLL's, VBX'en, VXD's etc.)
Again, you can hack this together by your self today, but
better support will come eventually.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com