es (instead of
faking them with subs -- if we have appropriate ways of locking &
synchronizing thread data) would be really necessary.
- Branden
At 11:34 AM 25/04/2001 -0400, Dan Sugalski wrote:
>At 11:01 AM 4/25/2001 -0300, Branden wrote:
>>2) Anyway, even resizing vtables we would need some more indirection to
>>determine in which position of the vtable is which operator.
>
>No. Each operator goes in a fixed positi
would work as
expected.
OTOH, vtables that need to use split memory areas or that make reference to
external objects, could have customized SERIALIZE and DESERIALIZE methods
to handle their complexities and details.
- Branden
At 04:12 PM 25/04/2001 +0200, Bart Lateur wrote:
>On Wed, 25 Apr 2001 11:01:07 -0300, Branden wrote:
> >If the idea is supporting arbitrary add-on operators...
>
>I think I second that. I would think of a fixed table for the built-in
>ones, and a linked list for the add-ons.
search à la
AutoLoader, or even define the operator based on the Unicode number of the
symbol theta, or anything like that.
In any of the two ways (resizing or catch all), the operator can be
transparently used in the language, so the choice of which one to use
actually doesn't impact the language, AFAICT.
- Branden
k the language (the syntax) is becoming so much different
than Perl 5, that I think we would need another name for the language as
well... :-(
>Personally, I'm up for calling the interpreter "Parrot" unless someone has
>an objection...
Agreed.
- Branden
cached. Anyway, this should
probably be handled by the interpreter, by putting some tags on the code
where the substr operation is being used.
Another problem I see is for when the code traverses the string from the
end backwards. But I think some encodings don't even su
here would probably be other cases in which I need a balance of
speed and compact storage, and I'll probably go into the trouble of
implemented a variable-width indexed string approach, but if the language
doesn't support strings through a well defined API, I would never have how
to do that!
I'm coming up with a proposal that would build a vtable-based API for
dealing with strings in an efficient way, without loosing generality. I
think I'll have it ready by next week, then I post it here.
- Branden
rees, and such things on strings) and having an abstract API to deal with
them transparently, like Hong suggested.
- Branden
Damien Neil wrote:
> On Thu, Feb 15, 2001 at 08:07:39AM -0300, Branden wrote:
> > I think you just said all about why we shouldn't bother giving objects
> > deterministic finalization, and I agree with you. If we explicitly want
to
> > free resources (files, data
Tim Bunce wrote:
> On Thu, Feb 15, 2001 at 08:21:03AM -0300, Branden wrote:
> > And don't forget that if we stick with refcounting, we should try to
find a
> > way to break circular references, too.
>
> As a part of that the weak reference concept, bolted recently into p
r is more expensive than refcounting. I guess we have
to make a decision between deterministic finalization and not using
refcounting as GC, because both together sure don't exist.
And don't forget that if we stick with refcounting, we should try to find a
way to break circular references, too.
- Branden
citly call close.
Otherwise, it will be called when DESTROY is eventually called.
- Branden
etermine that $fh has no active
> > references at the end of the block
>
> No, it can't, but it can certainly put a *test* for not having references
> there.
>
How can it do it without using ref-counts or spawning a full GC round?
- Branden
filehandles out of
scope don't get destroyed) could probably use it to guarantee the resource
(open file, not memory) has been freed.
I hope I could explain it well. Anyone has questions about it?
- Branden
handles ASAP. OTOH, if you're writing an
application that only opens one file and does a lot of processing over it,
you simply wouldn't care and let it be freed whenever the GC collects its
memory.
> At 10:12 AM 2/14/2001 -0300, Branden wrote:
> >If resource exhaustion is the proble
the thing when there's none more...
- Branden
the
data explicitly. That would require more complexity on the implementation
and optimizers that can find this kind of situation on the source code. That
means:
1) I avoid it, if I can; or
2) I'll go for it, if it's a big win.
- Branden
Alan Burlison wrote:
> Branden wrote:
> > Any suggestions?
> Yes, but none of them polite.
> You might do well to study the way perl5 handles these issues.
Perl 5 basically clones on every assignment. As it uses refcounting, it
knows it doesn't need to clone a string if its
Buddha Buck wrote:
> At 01:45 PM 02-12-2001 -0300, Branden wrote:
> >Am I too wrong here?
>
> It's... complicated...
>
Agreed.
> Here's an example of where things could go wrong:
>
> sub foo {
> my $destroyme1 = new SomeClass;
> my
ns) and allows
more optimized code, since the code can go through a real expensive
optimizator once and be stored to be used by the interpreter many times
(this could be done for distributing the production version of the program).
- Branden
a refcount-GC, while other objects that don't need that
could use a copy-GC. I really don't know if this is really feasible, it's
only an idea now. I also note that objects that are associated to resources
aren't typically the ones that get shared much in Perl, so using refcount
for them wouldn't be very expensive...
Am I too wrong here?
- Branden
elieve 8-bit ASCII will always be an option, for who doesn't care
> >about extended characters and want the best of both worlds on speed and
> >memory usage.
>
> 8-bit characters in general, yep. (ASCII is really 7-bit) ASCII, EBCDIC,
or
> raw byte buffers.
>
That includes Latin-1, Latin-etc. (I believe they're 10 or 12), which are
the same as the ISO-8859-1, ISO-8859-(etc).
- Branden
le `destroy' that doesn't need to be
called if the buffer was reused... Or split `destroy' in two, one that would
get called always and the other only when the value is cleaned by the GC...
Any suggestions?
Thanks,
- Branden
out the language at a whole. Do you
want we to make Perl K ?
Please be specific about what you liked in it, describe it for us, and tell
us why you liked it. And I think data structures and PDL related stuff was
already discussed in -language-data.
- Branden
XML-based simple object access protocol,
or something like that) will mostly become the `recommended' way to do it.
Do you have interesting points about K we're missing?
- Branden
what
is the document you think we should read? Any reason in particular we should
read it? Any comments about it?
- Branden
.htm#Why do K applications run so fast
http://www.kx.com/developers_faq_k.htm#If K is so concise and productive,
how readable is it
http://www.kx.com/developers_faq_k.htm#How about K and code reusability such
as is talked about in OO
- Branden
Hi.
This was posted on -language about packaging scripts/modules in a kind of a
zip file, for easy automated installing. This issue was brought up:
Branden wrote:
> Nicholas Clark wrote:
> > on perl 5 different configure options generate different binaries.
>
> Can this be stand
ry!", or "This string isn't too
big, so I should convert it to bloated UTF-32 at once!", or even "use less
'memory';".
And I believe 8-bit ASCII will always be an option, for who doesn't care
about extended characters and want the best of both worlds on speed and
memory usage.
- Branden
f @a is a tied array? This matrix thing is actually getting
very confusing to me... I think all these proposed additions to the language
should be carefully examined for possible mis-interpretations like these.
- Branden
Dan Sugalski wrote:
> At 01:35 PM 2/7/2001 -0200, Branden wrote:
> >2. Making the implementation of `tie' and `overload' more efficient
('cause
> >it's very slow in Perl 5).
>
> No, not at all. This isn't really a consideration as such. (The vtable
&
) FETCH function
> from the relevant module, then just passes control on to the add() vtable
> method associated with the PMC returned by FETCH, passing through the
> original args.
>
Tying is clear to me. I only see a problem with overloading on assignment,
that clearly cannot co-exist with tie, as I explained above.
- Branden
Branden wrote:
>
> Well, if it's not tie/overload, I didn't really understand why a vtable
> would have to be attached to a variable. I'd really like to see an example
> of variables whose vtables would have set_* and get_* different one from
> another, and anot
des (in a sense that one opcode calls various methods
of a (potentially) tied/overloaded variable/value).
The example of `my @a :int' really shows your point. I was actually thinking
current Perl5 syntax as a target, and I really wouldn't know how to deal
with this... (but sure I'll think about it!)
- Branden
he C++ overloading of ++, that uses a dummy parameter to
tell if it's a pre or a post increment. So bad...)
- Branden
s it can be reused, I'm not sure it's worth using an array to
save 2 pushes into the stack...
- Branden
need for a separation between
store/fetch and add/subtract/mul/... . I've been tried to figure it out how
your proposal would fit this situation, but I couldn't find a way...
I actually don't know if my assumptions are wrong, and tying and overloading
would not be handled by set_*/get_* and add/subtract/mul/..., but I actually
can't see another way.
What do you think about it?
- Branden
all the vtable for the generic way of doing it.
I _think_ this would be a great speed up if the program doesn't use much
magic, but perhaps the overhead would be too big and make tying slower than
in Perl 5... something to consider tough.
- Branden
Dan Sugalski wrote:
> At 05:41 PM 2/6/2001 -0200, Branden wrote:
> > > >I actually don't see a reason why the vtable entries should be the
> >opcodes.
> > > >Is there?
> > >
> > > Speed.
> > >
> >
> >Actually, I don&#
y;
bless $a;
return $b;
}
I think the problem is not with the overloading magic, but with the code
snippet...
- Branden
Sorry, I promess it's the last reply for today! Please don't rant on me!
Dan Sugalski wrote:
> At 04:23 PM 2/6/2001 -0200, Branden wrote:
> >Dan Sugalski wrote:
> > > Don't forget we have an opcode machine here--we are *not* emitting C
code
> > > to
Simon Cozens wrote:
> On Tue, Feb 06, 2001 at 05:01:38PM -0200, Branden wrote:
> > How is a list currently (Perl5) implemented?
>
> It's a bunch of SVs sitting on the stack, followed by a mark.
>
Where can I find how Perl5's stack works (specially about parameter pas
ng constants requires
> doing some evil things...)
>
Indeed I can attach it, but it gets away as soon as I try to store it in a
variable, so it's useless, in this sense. And the kind of magic I was
wanting to attach to a string was the overloading kind, so that I can have a
string "foo" stored in a variable $x and overload its + operation so that it
concatenates (I know this example sucks, but you get the idea).
- Branden
bles, and I'm not sure I want to
> go there) It'll likely just return true or false. I'll rethink it.
>
Will Perl 6 still be based on a stack, to pass a list of parameters and
return a list of results to the subs? Or is there any other approach
discussed for it? Is it still undefined? Will it work the same as in Perl 5
or will it take changes? Too soon to talk about it?
- Branden
eference to the object...
> package main;
> my ($bar, $baz);
> $bar = bar::->new();
> $baz = baz::->new();
>
> print "bar $bar\n";
> print "baz $baz\n";
Try printing $$bar, it will work...
- Branden
Dan Sugalski wrote:
> At 02:32 PM 2/6/2001 -0200, Branden wrote:
> >I noticed I couldn't get it to work. The thing is that $x = ... makes a
> >sv_setsv, what copies the value of the other SV (ST(0) in this case), but
> >not its magic, and other stuff. Here is the di
Dan Sugalski wrote:
> At 01:50 PM 2/6/2001 -0200, Branden wrote:
> >In the approach using the vtables I propose, it would be:
> >
> >
> > // get the PMC's that correspond to each variable...
> > HVAR *foo = get_hvar("foo");
> > SVAR *baz
original magical
thing. But from that day I actually saw that SV is a variable, definitely
*not* a value.
- Branden
in Perl 5, with its sv_setsv function. Of course, SV* can be
used for _perl_variables_, scratchpads, references, ... . But as in all
these cases it has the property of being able to change its value, it's a
variable.
The name->PMC translation really has nothing to do with this subject. It's a
thing with the compiler...
- Branden
and hashes are actually collections of values, so as a scalar
is a `holder' for a value. Store and fetch methods should be in the variable
side, and operations on the value side.
Sorry if I can't make myself well understood...
- Branden
Simon Cozens wrote:
> On Tue, Feb 06, 2001 at 11:30:12AM -0200, Branden wrote:
> > I actually have some more on it, but I'm saving it for the next
postings.
> > I'll wait for your opinions first. I really hope to see critics about
this.
>
> I don't understand w
Simon Cozens wrote:
> > > =item logical_or
> > > =item logical_and
> > > =item logical_not
> >
> > Er, why not just use get_bool?
>
> Overloading.
>
Please see my previous post on the subject. As I pointed there, implementing
|| and && like that breaks short-circuits.
- Branden
ind of) Perl5's current interface of `tie' and `overload', I
think it would be enough high level to be used by both the language and the
extensions. Of course, I could be wrong...
I actually have some more on it, but I'm saving it for the next postings.
I'll wait for your opinions first. I really hope to see critics about this.
I'd really like to read them so please send them in!!!
- Branden
es to the ?: operator.
See $f && close $f; now suppose $f is undef, close $f should not be called.
But if this should be passed to a logical_and function, $f and the value
returned by close $f would be evaluated, and then passed to logical_and. So
close $f would be evaluated, what is wrong...
What should be here is bitwise_*, that are different for strings and ints,
for example.
- Branden
dive into it, but I think it's ok to start with...
Anyway, I see if I'll write something about my ideas, and I send it to the
list later.
Thanks,
- Branden
evel of cognitive complexity. This is good--details are a
pain
> in the butt, and people aren't good at details.
I just expect consistency, e.g. nothing like sv_xyz, SvXYZ, SV_XYZ, SVt_XYZ
and I wonder what else there would be!!! (damn XS!)
- Branden
be overridden to implement another method lookup
algorythm.
Note that a blessed hash would have both DEREF_HASH and DEREF_OBJECT entries
of it's scalar reference working, so that it's possible to do $x->{foo} and
$x->bar (the former would call DEREF_HASH and then FETCH from the hash
vtable, and the latter would call DEREF_OBJECT from $x and then CALL_METHOD
with `bar' and an empty list [the arguments] as parameters.)
- Branden
, ... functions. And nothing more direct to tie a variable
than fill in the function pointers in a (v)table, rather than calling
sv_magic, casting the array to (SV*), setting the entry '~' of the magic
table, lighting some candles, and singing something exoteric.
- Branden
rvalue to the lvalue on aliasing,
right? Then what should happen to the data? Copying how, same reference,
duplicate the value? Perhaps special vtable entry for handling the value
part when aliasing?
- Branden
Edwin, good that we agree. I have some questions for you:
Edwin Steiner wrote:
> Branden wrote:
> > but would certainly make the program die, what could be avoided if SV*,
AV*,
> > HV* and so on are different of each other, and casts are not required
among
> > them, as is
Edwin Steiner wrote:
> Branden wrote:
> [...]
> >
> > I also don't see how it wouldn't bang badly if we get an incorrect PMC.
How
> > would we extract the 5th element of a scalar? And how would we read one
line
> > out of an array? Sum two hashes? I think
t representations of the same thing (useful
for database rows...)
I also don't see how it wouldn't bang badly if we get an incorrect PMC. How
would we extract the 5th element of a scalar? And how would we read one line
out of an array? Sum two hashes? I think having only one vtable for all
would only put a burden on who implements a vtable to croak an error on not
supported types.
- Branden
it will
probably not want a cache.
- Branden
can be taken here too.
I think those results are the ones that matter for making a decision about
which scenario will be used. I guess that choice is for Larry, but we should
give him enough facts about the scenarios so that the choice is made right
and we don't have to redesign because of portability/efficiency problems.
Branden.
great
> data manipulation library only to rewrite it in every subsystem?
>
> -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
>
>
>
I'm sorry I didn't express myself OK..., but we're in violent agreement.
Please read my previous post to the perl6-internals mail-list, entitled
``Modular subsystem design (was Re: Speaking of signals...)''
Your ``pluggable'' idea is just what I was looking for. To me, that's what
perl6 needs to be.
Branden
66 matches
Mail list logo
