|
RE: PD Euphoria IL Save and Load
|
Matt Lewis
|
Dec 08, 2004 04:16 PST
|
Pete Lomax wrote:
| |
On Tue, 7 Dec 2004 17:16:33 +0000, Matt Lewis
<matthewwa-@yahoo.com> wrote:
| | Pete Lomax wrote:
| | I should warn you that performance is abysmal:
ex sieve.ex 2950
exw sieve.ex 2345
sieve.exe 1049 ( as compiled by posetf)
ex eu.ex sieve 95.8
eu.exe sieve 28.5
|
Actually, I'd say that performance is pretty good (it's a lot faster
than eu.ex running natively.
|
You might have misread those figures. Most ways you slice it, RDS is
between two and a half and three times faster than Postef. Only time
will tell if I can narrow that gap or maybe even better RDS, though
it is fair to say I am concentrating on getting things working
first.
Postef can produce a back end for RDS IL, but it's still much slower
than the interpreted RDS back end. The only gain currently available
is a compiled Posetf program vs. the interpreted RDS backend.
As you appear to have modified the RDS front end rather than the
Posetf front end, I think you might be expecting a gain which won't
materialise, at least for a fair while yet.
|
I see. Still, the fact that it works is a good first step.
| | I might be able to make a faster backend for RDS IL (or something
not wholly dissimilar to it), but that's a major departure from what
I'm currently doing. As it happens I am actually considering doing
just that, but I haven't written anything yet, codewise or
designwise.
| | I can't wait to try out posetf with my new front end.
|
No promises, sorry. RL has kicked posetf into touch for a few weeks.
|
That's OK. When I say "can't wait" I really mean that I'm excited,
but, as usual, probably too busy to do everything that I "can't
wait" to do.
| | I'm not a huge fan of OO but I'll try and make sure Posetf has the
basic necessities in terms of the symbol table, at least.
|
I'm not either, but I think it would make certain things a lot
easier, like wxEuphoria, where I'm dealing with a ton of compiled
C++ that I'm interfacing with.
| | | | --Routine Decoration
----------------------------------------------
All routines in a class get decorated so that proper polymorphism
can take place. An '@' will be appended to the routine name,
followed by the datatypes of the parameters (o: object, a: atom, i:
integer, s: sequence, cClassName: instance of some class).
|
What about (old-style) user defined types?
|
Yep, you can do that, however, for these purposes they're currently
treated as an object. I suppose that could change. Part of my
reasoning was that I can't (at compile time) easily tell what
datatype a UDT is supposed to be, so I've just treated them as
objects.
| | Also, won't you need a class prefix, since several classes may
define a method with the same name?
|
A prefix isn't needed, because the class name automatically becomes
part of the decoration. So if you have 2 classes, foo and bar,
and they both have a method named Foo(), then in the symbol
table you'd really have:
Foo@foo@
Foo@bar@
The user never sees these decorated names, though.
| | | | have a 'this' parameter of the class' type automatically added. It won't
show in the source, but can be used (like in C++).
The routine signatures will be used to allow for a type of
polymorphism based on the arguments supplied.
|
Not polymorphism, but one of the things I'm attempting to do with
Posetf is this:
procedure x(integer a, b=2, c=3)
which indicates x can be called with 1, 2, or 3 parameters. You >
can't call it with zero parameters because a does not have a
default.
x(1) will behave identically to x(1,2,3), as b and c are defaulted
in the obvious manner. Not sure if that kind of handling would be of
any interest to you. As I said, not polymorphism, but related, a
bit.
|
I thought about this, but part of my goal is to be able to emit
RDS compatible IL code, and adding default arguments really
complicates things once polymorphism is present, so I decided against
it, since I can still pass a sequence, and have the routine itself
manage the optional stuff.
| | | |
--Scope
-----------------------------------------------
Class methods declared as global will be Public methods (callable
from anywhere), while normal class methods will be Private, and
callable only from class methods.
|
Are you assuming it must be "global class", with these global
functions and procedures in it? It seems to me that if you have a
local class, then any public methods should only be callable within
that source file, ie their scope matches that of the class
definition, and for that reason I would favour "public" and
"private" keywords..
|
I think I got a bit too fancy for my own good here. I think I'm
going to scratch the whole concept (for now, at least) of private
and public methods.
| | | |
--Inheritance
-----------------------------------------------
Classes can inherit from one super class (which can in turn inherit
from other classes). Methods from super classes will be called if
the method isn't overridden.
|
What syntax is used to specify inheritance?
|
You would use the superclass as the datatype for the class:
class foo( object f )
...
end class
class bar( foo b )
...
end class
| | | | --Construction / Destruction
-------------------------------------------------
There is no real concept of this, although you could define a class
with constructors that do something (allocate memory, or fill a
|
I will agree that in a ref counted/garbage collected Eu environment,
they (destructors in particular) probably aren't needed.
|
Yes, I plan to have them as explicit methods in my code, since
they're so important when you're messing around with C++ objects,
but it seemed like the issue should be addressed.
Matt Lewis
|
|
 |
|
