about these language issues. Please,
don't flame on me because of this. It's only my opinion, and I think
many people think different than this (actually, my opinion is all based
on this fact). I also don't expect it to be accepted or agreed by all, I
only wanted to share my thoughts about it, so that maybe someone can see
the subject on a different, new point of view.
- Branden
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
ou cause a whole bunch of JAPH's to relearn lots. And
> > then, these people might be prompted to say "Hey, if I have to relearn
> > all this, let me check out some alternatives."
>
>Well they certainly won't run to Java.
>They might look at Pythong -- but there they'll find syntactic
>peculiarities that make Perl6 look like Ada.
s/Perl6/Perl5/;s/Ada/Befunge/;$_.=' ;-)';
- Branden
ne-liners know the value of $ugly.$and.$nasty.$things.
Anyway, any behaviour that would break my script if I add/remove whitespace
of is nasty.
- Branden
"Let's not fix what isn't broken."
e it is pretty good the way it is!
>This is something to watch out for, not something that should decide
>Perl 6's design for paranoia's sake. I know that I am not the only one
>that loves Perl first and foremost for its syntax.
I am another one that loves Perl first and foremost for its syntax.
>Change too much and
>you're bound to drive some people away. Especially if these changes are
>inconsistent with other languages.
IMO, consistence with other languages doesn't matter.
>My conclusion: I say we do ". and +" or neither.
My conclusion: Let's not fix what is not broken.
- Branden
eat things Perl
doesn't... But when I saw it's Java-like syntax, I thought: Forget about
it! Perl syntax rules!
The bottom line is: please don't change the syntax, unless it's
unavoidable. It will cost many time of reading code until finding bugs
because of operators that used to work and don't work anymore...
- 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
is
around `my's variables, what also increases readability.
Think about it, the change isn't really big. The only differences are the
necessary parenthesis on usage of `my' in the middle of a list of arguments
and the fact of `my $a, $b, $c;' DWIMs, what is a big win, IMHO. Beginners
would know they can use `my' the same way they use every function in Perl,
what also makes Perl a little easier to use. (Note I didn't say `every
*other* function', I *know* `my' isn't one.)
- Branden
AAD. Is there any?
I hope I can calm things a bit here, since I'm sure we'll never agree on
what's better, this is too much a matter of taste, and we shouldn't discuss
taste.
- Branden
ey both get lists (agreed, different lists, `my' needs a list of
variables) and they both should behave the same when lists are given to
them.
>
> This would upset the entire structure of perl's usefulness.
>
You're completely right. Messing with `,' and `=' is a bad idea.
> --
> John Porter
>
> You can't keep Perl6 Perl5.
>
>
- Branden
they're different (one is compile-time, other runtime, and much more
differences). But both (potentailly) receive a list of arguments. With
`print' (or any other function) I don't need parenthesis if I don't want to
put them (and I almost always don't want them). Why with `my' I do need
them? Why don't these behave the same?
- Branden
7;'. Please just think about it and tell me
in which cases `` 'my' having higher precedence than comma is signficantly
more useful than if it had a lower precedence'', instead of just saying
``Let's all just acknowledge that fact''. I really can't find one way in
which the current behaviour is more `useful'!
- Branden
ocal($,),my($c)) = @_;
What is it, anyway? A joke? (There's Perl poetry, why can't be there Perl
jokes?) Who writes this kind of code anyway?
- Branden
roduct,
I think that's why we discuss it here.
> - you don't make any of these decisions arbitrarily.
That's why we argue about it. It's not about changing something just for the
fun of it. We must see where it's better, where it's not, if we would pay
the price for changing it, if it's worth it. I'm not proposing it because I
like changes, but I also don't the not DWIMness of some things of Perl.
- Branden
I said:
> Anyway, I don't see why `local' (and `our' and `my') should bind more
> strongly than , and = . They are list operators, they should behave the
same
> as those.
>
Actually, they *look like* list operators, they should behave like those.
> - Branden
>
>
Bryan C. Warnock wrote:
> On Friday 16 February 2001 07:36, Branden wrote:
> > But it surely isn't
> > consistent with the rest of the language.
>
> It's consistent with "our" and "local", which are really the only other
> things in the langua
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
k like a function, so it isn't.
>
> Ah, more pointless changes with perl5.
>
If this makes `my' DWIM, I think it's not pointless...
- Branden
hould result in $c==3, which is the
expected.
Both ways are possible though.
- Branden
f
(my $a, $b, $c) = @_;
or even
my($a, $b, $c) = @_; ## current syntax keeps working.
- Branden
ged. Its way of working is already in
our subconscients. Changing it would be probably bad. But it surely isn't
consistent with the rest of the language.
- Branden
<[EMAIL PROTECTED]> wrote:
> On Thu, Feb 15, 2001 at 10:04:51AM -0300, Branden wrote:
> > Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
> > little too much not-orthogonal? Why don't we require `eval { do FILE }'
to
&
John Porter wrote:
> Branden wrote:
> >
> > Well, I checked the archives, and I found that the discussion begun in
> > http:[EMAIL PROTECTED]/msg01441.html
>
> That thread was rather tame; even so, I believe the end result,
> if one can be deduced, is that
y don't think making one of this things
default would be good, because it would make one-liners and small quick and
dirty scripts some harder to write. For longer scripts and modules (that
already are many lines long), writing one or two more lines isn't expensive
at all...
- 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
;s AAAD for sure!
I never said `our' should affect the variables inside the block! I said this
was the *main* problem in the discussion of RFC 64! Having `our' (or
anything) outside the scope change the scope of things is a very bad idea.
It's clear it ends with all the purpose of it.
>
> I have to disagree with you.
>
Read it again, and see if it has problems or not. Note again, I'm not asking
you to use it, or even like it. I'm only asking if it has the ``far more
serious problems than it purports to solve'' you said it has.
- Branden
Jonathan Scott Duff wrote:
> On Thu, Feb 15, 2001 at 01:40:53PM -0300, Branden wrote:
> > I propose the introduction of two new keywords (just like `my' and
`our')
> > for specifying a different scope: `global' and `outer'. `global' would
be
> > use
I only
think it would probably be useful for some of us, and that only adding a new
`scope' pragma wouldn't hurt anybody, while possibly helping some. And it
wouldn't be much work to do either, since mostly everything that can be done
with it can be almost directly translated in something that can be done
without it (but hey, let's put the burden on translate it to the compiler,
since it's what it does anyway!).
Sorry again to bother you with this issue again, but I actually think it's
worth trying it.
- Branden
odule, MyModule::OtherModule, etc. and mainly when `use
MyModule' creates namespace OtherNamespace (that has nothing to do with the
name `MyModule'). How will Perl know what's the version of the module
associated with OtherNamespace ??? What if several modules put things in a
common namespace ?
- Branden
Perl 5, it would be written `defined($x) ? $x : "N/A"', but this has the
problem that $x is evaluated twice, so it doesn't work if instead of $x we
have a function call (or even if $x is tied...).
- Branden
; form. do FILE behaves just like eval() (except it reads its data from a
> source file), while do BLOCK doesn't. Neither.
>
Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
little too much not-orthogonal? Why don't we require `eval { do FILE }' to
have the behaviour of not dying and setting $@ ?
- Branden
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
David Mitchell wrote:
> James Mastros <[EMAIL PROTECTED]> wrote:
> > [snip about DESTORY predictablity not being neccessary]
> > You're probably right about that, Branden. Quite nice, but not
neccessary.
> Hmm, I'd have to say that predictability is very, *very
ames Mastros
> --
> "All I really want is somebody to curl up with and pretend the world is a
> safe place."
> AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
>
- Branden
licitly destroy an object, for
better (and sooner) resource disposal. The programmer wouldn't have to do it
(and wouldn't do it most the time), but if he knows he uses many resources
and he would like to be nice, he *could* do it (not meaning he would have to
do it either...).
- Branden
James Mastros wrote:
> On Wed, Feb 14, 2001 at 10:12:36AM -0300, Branden wrote:
> > Also, I think it would be valid for the programmer to explicitly say ``I
> > would like to DESTROY this object now'',
> I'd think that an extension to delete is in order here. Bas
st to deal with this is set a flag if
the object was already DESTROYed. Then if any other tries to use it, it
raises an exception (dies) with a message about ``This object was already
DESTROYed.''. This flag could be used also to signal to the GC system that
the object already got its DESTROY method called, and it shouldn't be called
again. Just an idea, but...
- Branden
loyment of Perl itself and Perl programs & modules.
- Branden
ot;bar";
}
I die with "foo" or "bar" ? Why is this the right behaviour? Any sample code
that shows why this should be done this way and not the other?
Thanks,
- Branden
igned for Perl 6. And I think this
discussion goes along with the one about `par', since these directory
structures exist mainly for installing extensions on them...
- Branden
The problem
> of having Perl but not pun.
Won't be a problem with Perl 6.
> That's simple enough, par can build an
> archive with a minimalist version of pun with the par attached as
> __DATA__ or something.
>
See my solution above.
- Branden
bly help me with this, if that's OK with you. Could
you
> > send me some text/URLs saying how it works so that I can figure out one
way
> > to do it and include it in the PDD.
>
> Oh, I'm the last person to ask about crypto. I don't even know how to
> use pgp. I just peeked into a jar and saw how they did it.
Are there already modules that handle this (RSA/IDEA/...) ? Perhaps we'll
also want them to share the same interface so that we can do it flexible as
well... For this one I don't know if we could support different key formats
or if we should standardize on one...
- Branden
the thing when there's none more...
- Branden
If not, where should we be discussing
it?
>
> [EMAIL PROTECTED] anyone?
>
If someone cares to create this list? It should probably be
[EMAIL PROTECTED], because I believe the main focus is on shipping it with
Perl 6, althought I think we'll probably have a preliminary version on Perl
5.
- Branden
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
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
[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).
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
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
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
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
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
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
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
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
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
| Yes |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
+--+-+-+-+
- Branden
ctually 10 times it
needs to be? (if it were even _possible_ to pack all the data without
fragmentation problems)
- 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
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
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
.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
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
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
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
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
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
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
ead about it in
the web. I guess their file format is a disguised .tar.gz, right?
- 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
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
t zip?
Is it ported to all platforms Perl currently runs on? Is there a Perl module
for handling zips?
- 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
-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
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
-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
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
1 - 100 of 156 matches
Mail list logo
