Damian Conway wrote:
> # As Branden proposes:
>
> package From_STDIN;
>
> sub new { bless $_[1], $_[0] }
>
> sub MORE_DATA { $_[0]->getn($_[1]) }
> sub ON_FAIL { $_[0]->pushback($_[1]) }
>
> use overload "=~" => 1;
>
> pack
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
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.
ssing. What is more, I
> believe that the changes above can remove most of the
> significant bottlenecks for the problems we have in text-
> processing of today. At least I know a lot of problems which
> would have feasible solutions given these changes.
>
> And I need not repeat that a handful of small extensions to
> the expressive power of the regular expression engine could
> radically extend the domain of its applicability. ;-)
>
That's exactly the kind of thing we can do by exposing regexp engine's guts.
Tags in the string we can implement by using lists, just as lisp would do
it. If we have SVs that actually independ from the implementation, we can
create a ``tagged-string'', that's seen as a string by the script but
internally implemented as a list. And, if we have access to the regexp
engine's guts, we can implement matches and substitutions against those
magic tagged strings.
The other thing about copy-on-write would be piece of cake, using the same
magic SVs for implementing strings that are substrings of other strings.
Branden.
27;s worth it. And now is for sure the time to think on this
kind of thing. After the implementation is done, if it's there, it's there,
otherwise, it will probably never be!
Thanks a lot.
Branden
one, but I list it down here for
completion:
: sub abc_handler {
: do_pre_handler(@_); # pre part
: my $result = $_->(@_);
: do_post_handler($result);
: return $result;
: }
: push_handler(\&abc, \&abc_handler);
Well, what you think of it? Does it have disadvantages I'm not aware of?
Branden
only on the behaviour
the superclass attaches to the same method!
I think I didn't make myself clear with my approach, I may eventually
rephrase it...
Thanks, Branden.
Garrett Goebel wrote:
> From: Branden [mailto:[EMAIL PROTECTED]]
> >
> > I was reading RFC 271 and thinking about this pre/post
> > handler thing. Why instead of having 2 subs, one for
> > pre and other for post condition, and having to deal
> > with things a
perl5, what's
problematic with perl5 is the actual syntax of having to mix references,
typeglobs, and the tied function for every method call!)
Thanks a lot, Branden.
ts he goes about it. I actually didn't read
it, but I guess he means he prefers Java to C++. This
point I disagree. Of course, C++ has no GC, which is a
good thing, but you can always fake it with Refcounts,
which is much more efficient, and easily feasable with
C++. And at least they didn't chop from you templates
and operator overloading, which could do Java a usable
thing. At least I could then have a list of integers,
instead of the verbose code above!
- Branden
have threads, you have to say
explicitly if you want anythinig to be shared. And if you explicitly
share something, then you should care the locks by yourself.
At least, that's my opinion.
- Branden
point continues, int(time()) solves p52p6 problem!),
RFC 73, on making all built-ins return objects, which would do the
stringifying thing or even allow with and without fractions in one
object, and RFC 48, on changing localtime() and gmtime(), 'cause
maybe time() will go with them too!
- Branden
that
are present only in *non-local* variables, and take care of holding
some locks for every operation that is made against that variable.
This way shared data structures get protected.
- Branden
robably the hardest type to spot,
hardest to reproduce kind of things that lead to bugs. I think the less
magic we put into locks, the more we enforce programmers to be conscient
about race conditions in multi-threading.
- Branden
r borked. Please investigate.";
: # in a logfile, the clarity argument is even more valuable...
Well, at least that's what I think about time. This change wouldn't break
compatibility, and changing the way we think about this function is a
healthy thing for our programmer mind
nd that clock
will probably have sub-second precision.
- Branden
ary measurement is
> absurd. It might makes sense to have some other functions giving units
> since some point in the past next to time() though.
More than one function to do the same thing is A Bad Thing, IMO. It only
causes confusion.
If a change of mind when writing new software is too much a burden, then,
I say it again, we should stick with perl5! As Jarkko always quotes:
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
If old code and old-code thinking are the only thing that prevents us to
change time() or move it out of CORE, then I believe we should do it yes!
- Branden
oing this, like AUTOLOAD is for modules, would
be a good thing. Whenever an inexistent sub is called and it cannot be found
in existing packages and by package's AUTOLOAD's, this special sub is called
and it can auto-load packages that provide such functionality. Then there
would be a generic way to do such things.
- Branden
it will
probably not want a cache.
- Branden
a bad thing.
I share your thought. But I proposed a new name for people that think that
``this would confuse UNIX users, that relate Perl's time with UNIX C's
time''.
Having the same name and modifying the semantics is more appropriate, IMO.
- Branden
esult value slot in the stack, or anything
like that, leaving the same `return' interface to the user.
- Branden
esult value slot in the stack, or anything
like that, leaving the same `return' interface to the user.
- Branden
g/modules/Bar';
use Baz URL => 'ftp://my.local.domain/pub/share/perl-modules/Baz', VERSION
=> 2.0;
This way, Perl could automatically fetch and install modules (supposing
module install is not so hard as now, involving makefiles, and such...). And
this could also be used to identify interfaces. That's only an idea, but I
think it can lead to good things.
- Branden
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
Piers Cawley wrote:
>"Branden" <[EMAIL PROTECTED]> writes:
>> Of course, C++ has no GC, which is a good thing, but you can always
>> fake it with Refcounts, which is much more efficient, and easily
>> feasable with C++.
>
>Err... current research sho
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
w your first proposal would save keystrokes, by replacing
`return $x;' with `MyReallyLongishAndBloodyIdiotSubName = $x; last
MyReallyLongishAndBloodyIdiotSubName; # must type this to get out of the
sub'. Anyway, I always recommend to learn to type fast, it ain't hard (just
kidding... ;-)
- 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
to handle the case in which the module is not found,
tipically to create stubs to the subs/classes the module would provide...
> * What happens when the requested version isn't found?
same as above.
If that's a common desire, I volunteer to help writing the beast. Can even
start it on Perl 5, and then convert it with p52p6. This way everyone can
see it and make critics before shipping it with Perl 6.
- Branden
> left as an exercise for the reader. :)
Well, try that on strict 'subs'...
- Branden
e nifty tool from Internet for a
quick job, I don't want to go in the complexities of MakeMaker, Makefiles,
not to mention compilers, which I don't have access on Win32 (yeah, I have
Cygwin, but I never compiled Perl with it...). I think easy
access/downloading/building of external modules is a must to make Perl more
popular.
- 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
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
, ... 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
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
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
) is. It's
rather explicit, and is very clear about what is done. Using a (\@)
prototype on DirectBubbleSort would be ok too, since its name says right
what it does and everybody likes some vanilla syntax. But making it
@SomeList = DirectBubbleSort is the most error-prone thing I see! Nobody
will get it right on first use...
- Branden
.
> > Eh, I don't think that bad memory, or a bad variable naming scheme
> > justifies this new feature.
> A new feature doesn't need that much justification. And nobody is
> advocating getting rid of "return".
Yes it does. Otherwise, we get even more bloated than now!
- 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
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
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
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
original magical
thing. But from that day I actually saw that SV is a variable, definitely
*not* a value.
- 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
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
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
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
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
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
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
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
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
y;
bless $a;
return $b;
}
I think the problem is not with the overloading magic, but with the code
snippet...
- 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
&
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
) 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
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&#
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
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
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
s it can be reused, I'm not sure it's worth using an array to
save 2 pushes into the stack...
- Branden
he C++ overloading of ++, that uses a dummy parameter to
tell if it's a pre or a post increment. So bad...)
- Branden
-loading of the same modules from Internet, if they are pretty
obfuscated or are in byte-code form. Only a sandbox or something like that
can assure security in either case.
- Branden
Michael G Schwern wrote:
> On Thu, Feb 08, 2001 at 12:07:18PM -0200, Branden wrote:
> > The issue is actually not auto-downloading modules and their
prerequisites,
> > but actually packaging several scripts and modules in one file, so as
Java's
> > jar do. I think sup
-scoped variables by default:
use scope 'subs';
sub make_incrementer {
$n = shift;
$increment = sub {
$x = shift;
parent_sub's $x;
return $x + $n;
};
return $increment;
}
Comments?
- Branden
applications would be actually distributed on the
`.noarch' kind of par archive, to contrast the `.src' kind.
Did I miss something here? Is it just me, or you also think this
(deploy/install) is essential for a language be used by `layman-users', and
not only JAPHs.
- Branden
I'm writing a PDD on the subject, as suggested by Dan, and I intend to post
it by tomorrow. In the lack of a better list, I think we stick
with -language. If someone can suggest a better one, please do it.
- Branden
t zip?
Is it ported to all platforms Perl currently runs on? Is there a Perl module
for handling zips?
- Branden
7;t solve the problem for scripts/programs).
Anyone of ActiveState there? Can't we adapt PPM so that it handles what's
needed? Or is it too different from what we want? Does it use zip or
tar/gzip or other?
- Branden
ead about it in
the web. I guess their file format is a disguised .tar.gz, right?
- Branden
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
n the PDD. Anyone has a suggestion on something to add?
Other important issue I don't know yet: Is there an Archive::Zip module for
Perl? How cross-platform is it? Can we bundle it with Perl (licensing
issues)? Is it stable? Will it give us the support we need (access to
individual files in the archive, and the ability to `fake' them as real
files through tied filehandles)?
- Branden
n";
print $c;# also prints nothing
--
*c = \$b;
*b = \$a;
$a = "foo\n";
print $c;# also prints nothing
I guess that demonstrates that aliasing is a wild beast and using it for
more than two variables is probably a good way to get in trouble...
- Branden
would just pass the bytes
through. This is what should probably be used for zip. If you mean the
uncompress-on-the-fly thing I think it would be handled like source filters
are today. In Perl 5.7 you can even have a source filter that decompresses a
.gzipped script and runs it, by using a source filter. I believe zip could
be handled by this also in 5.7. Perl 6 will certainly improve this area very
much.
- 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
what
is the document you think we should read? Any reason in particular we should
read it? Any comments about it?
- 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
.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
correct spell and grammar would be very
appreciated.
- Branden
(cut here) ---
PDD: `par' -- The Perl Achive
1. Introduction
`par' stands by `Perl Archive'. It's a way to provide deploy and
installation of Perl programs/scripts
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
so of p5p where
> Alan's trying to plug a batch of perl memory leaks to see how well the
> refcount scheme seems to be working now...
Yeah, I know that... But I actually think this is because Perl 5's
implementation of refcounting is quite messy, specially when weakrefs are in
the game.
- Branden
n really doubt... Breakfasting? ;-)
> I agree with Branden that the inheritance semantics is screwy.
> I think DesignByContract contract enforcement is best done with
> a parameter typing system of some kind (as in C++). Proper
> objects don't get into invalid states (unless you
ctually 10 times it
needs to be? (if it were even _possible_ to pack all the data without
fragmentation problems)
- Branden
| Yes |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
+--+-+-+-+
- Branden
of the same thing only to satisfy users that use
different formats').
I think we should go for `standard' rather than `flexible' on this one.
Of course we still can change the file format, if someone isn't happy about
zip. That's the advantage of discussing it before making it: it's not here
for we to regret about it...
- 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
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
he user could
request an archive in a determined format) an utility to convert a package
from one format to another. Otherwise, developer's life would be harder...
- Branden
John Porter wrote:
> Branden wrote:
> >
> > For example, with tgz it would be complex to deal
> > with running without extracting,
>
> What? tar -z not good enough for you?
>
The problem is that we cannot access individual files inside the archive
without decompr
all .tar.gz.
>
I actually don't believe the modules already on CPAN will work directly,
since they'll probably have to go through p52p6 translation. And I don't see
any problem in supporting the old approach to installing modules, since it's
mainly manual and requires almost no support from the programs.
- Branden
you need to do a "is it an object with a
> DESTROY" check at block boundaries.
>
Only because the type is static, I don't think they wouldn't be references.
my $foo = new Baz();
{
my Baz $bar = $foo;
};
# DESTROY should be called on the object ref'd by $bar ?
# It's still ref'd on $foo !!!
- Branden
define the
Archive::* implementations for Perl6, possibly stating that we'd like them
to have the same interface, so that we can use one or another with the same
code.
- Branden
Jarkko Hietaniemi wrote:
> On Mon, Feb 12, 2001 at 12:36:53PM -0300, Branden wrote:
> > The problem is that we cannot access individual files inside the archive
> > without decompressing the whole archive, what is possible with .tar (not
>
> I do not see a huge problem in de
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
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
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
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
another features, and make benchmarks
with all proposed formats. And probably `p52p6' can be used to translate it
to Perl 6 and include it in Perl 6 distribution, cutting much work (and
time) when Perl 6 is ready.
- Branden
[EMAIL PROTECTED] wrote:
> On Fri, Feb 09, 2001 at 06:17:34PM -0200, Branden wrote:
> > I put together a comparison table between par and rpm/jar.
>
> You forgot deb, which I'd *much* rather deal with than rpm (if only
> because I can point apt and dselect at CPAN).
1 - 100 of 156 matches
Mail list logo
