Frage zu @_
am 22.05.2006 19:13:14 von Ferry Bolhar
Hallo liebe Perler,
die Doku (perlsub) behauptet gleich ziemlich am Anfang:
"Any arguments passed in show up in the array @_ . Therefore, if you called
a function with two arguments, those would be stored in $_[0] and $_[1] .
The array @_ is a local array, but its elements are aliases for the actual
scalar parameters. In particular, if an element $_[0] is updated, the
corresponding argument is updated (or an error occurs if it is not
updatable)."
Nun probiere ich:
@arr = (1,2,3);
func(@arr);
print @arr;
sub func {
@_ = (7,8,9);
}
Wenn ich den Text richtig verstehe, müssten doch durch das Überschreiben von
@_ die Elemente von @arr nach dem Aufruf von
func(@arr) die Werte 7, 8 und 9 enthalten. Tun sie aber nicht (wäre mir auch
neu). Ich kenne ein solches Verhalten (Aliasing) eigentlich
nur von foreach() und map().
Was ist jetzt falsch, die Doku, meine Überlegung oder mein Testskript?
Schöne Grüße aus Wien,
Ferry
--
Ing. Ferry Bolhar
Municipality of Vienna, Department 14
A-1010 Vienna / AUSTRIA
E-mail: bol@adv.magwien.gv.at
Re: Frage zu @_
am 22.05.2006 19:33:26 von Frank Seitz
Ferry Bolhar wrote:
> Nun probiere ich:
>
> @arr = (1,2,3);
>
> func(@arr);
>
> print @arr;
>
> sub func {
> @_ = (7,8,9);
> }
>
> Wenn ich den Text richtig verstehe, müssten doch durch das Überschreiben von
> @_ die Elemente von @arr nach dem Aufruf von
> func(@arr) die Werte 7, 8 und 9 enthalten. Tun sie aber nicht (wäre mir auch
> neu). Ich kenne ein solches Verhalten (Aliasing) eigentlich
> nur von foreach() und map().
>
> Was ist jetzt falsch, die Doku, meine Überlegung oder mein Testskript?
Deine Vorstellung ist falsch.
Die aktuelle Parameterliste @_ ist eine Subroutine-lokale Struktur,
die existiert außerhalb nicht. Lediglich die einzelnen Elemente
($_[0], $_[1], ...) kannst Du "by reference" manipulieren, die
in Deinem Beispiel den einzelnen Arrayelementen entsprechen.
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Re: Frage zu @_
am 22.05.2006 19:39:59 von Mirco Wahab
Hallo Ferry
> Nun probiere ich:
>
> @arr = (1,2,3);
>
> func(@arr);
>
> print @arr;
>
> sub func {
> @_ = (7,8,9);
> } ...
> Was ist jetzt falsch, die Doku, meine Überlegung oder mein Testskript?
Die Überlegung ist falsch. Ich denke, Frank hat es
auch nicht exakt auf den Punkt gebracht, daher jetzt
mein Wink mit dem Zaunpfahl:
use strict;
my @arr = (1,2,3);
func (\@arr);
print @arr;
sub func {
my ($ar) = @_;
@{$ar} = (7,8,9);
}
Was Du gemacht hast, ist - die Kopie
der Elemente des Arrays auf dem Stack
abzulagern, diese werden dann aliasiert.
Um das Array selbst zu erhalten, musst
Du es auch übergeben ;-)
'pass by value' vs. 'pass by reference'
Viele Grüße
Mirco
Re: Frage zu @_
am 22.05.2006 19:44:22 von Daniel Fischer
Ferry Bolhar!
> Nun probiere ich:
>
> @arr = (1,2,3);
>
> func(@arr);
>
> print @arr;
>
> sub func {
> @_ = (7,8,9);
($_[0],$_[1],$_[2]) = (7,8,9);
> }
>
> Wenn ich den Text richtig verstehe, müssten doch durch das Überschreiben von
Gruß
Daniel
Re: Frage zu @_
am 22.05.2006 19:59:15 von Mirco Wahab
Hi Daniel
>>sub func {
>> @_ = (7,8,9);
>
>
> ($_[0],$_[1],$_[2]) = (7,8,9);
@_[0..2]= (7,8,9);
>
>>}
Viele Grüße
Mirco
Re: Frage zu @_
am 22.05.2006 20:53:12 von Andreas Seltenreich
Mirco Wahab schrob:
> Hi Daniel
>>>sub func {
>>> @_ = (7,8,9);
>>
>>
>> ($_[0],$_[1],$_[2]) = (7,8,9);
>
> @_[0..2]= (7,8,9);
@_[0..2] = 7..9;
SCNR,
Andreas
Re: Frage zu @_
am 22.05.2006 23:56:39 von Mirco Wahab
Hi Andreas
>>>($_[0],$_[1],$_[2]) = (7,8,9);
>>
>> @_[0..2]= (7,8,9);
>
>
> @_[0..2] = 7..9;
>
.... wird das ein Wettbewerb?
sub func {
${\pop}=$_ for 9,8,7;
}
oder
sub func {
${\shift}=$_ for 7..9;
}
:-Ö
Viele Grüße
M.
Re: Frage zu @_
am 23.05.2006 01:22:11 von Andreas Seltenreich
Mirco Wahab schrob:
>>>>($_[0],$_[1],$_[2]) = (7,8,9);
>>>
>>> @_[0..2]= (7,8,9);
>>
>>
>> @_[0..2] = 7..9;
>>
>
> ... wird das ein Wettbewerb?
Hehe, der letzte Perlgolf-Thread ist in der Tat schon lange her...
> sub func {
> ${\pop}=$_ for 9,8,7;
> }
>
> oder
>
> sub func {
> ${\shift}=$_ for 7..9;
> }
Interessant, aber leider nicht kurz genug :-).
Gruß
Andreas
Re: Frage zu @_
am 23.05.2006 09:33:23 von Ferry Bolhar
Frank Seitz:
> Die aktuelle Parameterliste @_ ist eine Subroutine-lokale Struktur,
> die existiert außerhalb nicht. Lediglich die einzelnen Elemente
> ($_[0], $_[1], ...) kannst Du "by reference" manipulieren, die
> in Deinem Beispiel den einzelnen Arrayelementen entsprechen.
Na gut, spreche ich eben ein Element einzeln an:
@arr = (1,2,3);
func(@arr);
print @arr;
sub func {
@_ = (7,8);
$_[2] = 9;
}
Ich erhalte dennoch als Ausgabe "123".
Außerdem kann ich deine Erklärung nicht nachvollziehen: wenn
ich @_ eine Liste zuweise, dann weise ich ja den einzelnen
Skalaren des Arrays Werte zu dh., die Anweisung
@_ = (7,8,9); ist equivalent zu
($_[0],$_[1],$_[2]) = (7,8,9);
Wo sollte da also ein Unterschied sein?
Innerhalb der sub haben $_[0], $_[1] usw. ja auch die neuen Werte,
nur nach dem Verlassen nicht mehr. Ganz verstehe ich es also nicht.
LG, Ferry
--
Ing. Ferry Bolhar
Municipality of Vienna, Department 14
A-1010 Vienna / AUSTRIA
E-mail: bol@adv.magwien.gv.at
Re: Frage zu @_
am 23.05.2006 10:05:37 von Mirco Wahab
Hallo Ferry
> @_ = (7,8,9); ist equivalent zu
>
> ($_[0],$_[1],$_[2]) = (7,8,9);
>
> Wo sollte da also ein Unterschied sein?
>
> Innerhalb der sub haben $_[0], $_[1] usw. ja auch die neuen Werte,
> nur nach dem Verlassen nicht mehr. Ganz verstehe ich es also nicht.
Das Kochbuch drückt sich hier genauer aus:
(http://www.unix.org.ua/orelly/perl/cookbook/ch10_02.htm)
All incoming parameters appear as separate scalar
values in the special array @_ , which is
automatically _local_ to each function.
...
The *scalars* in @_ are implicit aliases for the ones
passed in, not copies. That means changing the
_elements_ of @_ in a subroutine changes the values
in the subroutine's caller.
***********************************
This is a holdover from before Perl
had proper references.
************************************
(emphasis added by me)
Es ist also tatsächlich nicht ganz 'user friendly' ;-)
Warum nimmst Du nicht:
function(\array);
oder sowas?
Viele Grüße
Mirco
Re: Frage zu @_
am 23.05.2006 10:40:59 von Frank Seitz
Ferry Bolhar wrote:
> Frank Seitz:
>>
>>Die aktuelle Parameterliste @_ ist eine Subroutine-lokale Struktur,
>>die existiert außerhalb nicht. Lediglich die einzelnen Elemente
>>($_[0], $_[1], ...) kannst Du "by reference" manipulieren, die
>>in Deinem Beispiel den einzelnen Arrayelementen entsprechen.
>
> Na gut, spreche ich eben ein Element einzeln an:
>
> @arr = (1,2,3);
>
> func(@arr);
>
> print @arr;
>
> sub func {
> @_ = (7,8);
Was soll das? Damit initialisierst Du @_ neu.
Anschließend hat @_ nichts mehr mit den aktuellen
Parametern der Subroutine zu tun.
> $_[2] = 9;
> }
>
> Ich erhalte dennoch als Ausgabe "123".
Mach's mal so, dann siehst Du den Effekt:
sub func {
$_[2] = 9;
}
> Außerdem kann ich deine Erklärung nicht nachvollziehen: wenn
> ich @_ eine Liste zuweise, dann weise ich ja den einzelnen
> Skalaren des Arrays Werte zu dh., die Anweisung
>
> @_ = (7,8,9); ist equivalent zu
>
> ($_[0],$_[1],$_[2]) = (7,8,9);
>
> Wo sollte da also ein Unterschied sein?
Im ersten Fall initialisierst Du das Array @_ als Ganzes.
Im zweiten Fall manipulierst Du einzelne Elemente des Array.
Die Elemente von @_ haben die Besonderheit, dass sie
Aliase für die aktuellen Parameter sind. Wenn Du die
manipulierst, manipuliest Du das Original beim Aufrufer
(Call by Reference Semantik).
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Re: Frage zu @_
am 23.05.2006 15:56:04 von f.ballandt
> Mach's mal so, dann siehst Du den Effekt:
>
> sub func {
> $_[2] = 9;
> }
>
buh, das ist ja bösartig!
ich gebe zu, manchmal tue ich so was, jedoch ohne! nach dem sub-aufruf
etwas davon merken zu wollen. Wie kann ich mich denn davor schützen, daß
eine (ggfs. nicht von mir stammende) sub so was tut? Muß ich jede sub
mit Kopien aufrufen, damit mit meinen Variablen nichts passiert?
Frank
Re: Frage zu @_
am 23.05.2006 17:15:14 von Frank Seitz
f.ballandt wrote:
>>Mach's mal so, dann siehst Du den Effekt:
>>
>>sub func {
>> $_[2] = 9;
>>}
>
> buh, das ist ja bösartig!
> ich gebe zu, manchmal tue ich so was, jedoch ohne! nach dem sub-aufruf
> etwas davon merken zu wollen. Wie kann ich mich denn davor schützen, daß
> eine (ggfs. nicht von mir stammende) sub so was tut?
In der Subroutine nicht mit $_[$i] arbeiten und falls doch,
dann nur lesend.
> Muß ich jede sub
> mit Kopien aufrufen, damit mit meinen Variablen nichts passiert?
Das machst Du nicht vorm Aufruf, sondern in der Subroutine.
Z.B. so:
sub f
{
my $arg = shift;
# alle Änderungen an $arg sind lokal
...
}
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Re: Frage zu @_
am 24.05.2006 10:09:42 von f.ballandt
Guten Morgen,
> Das machst Du nicht vorm Aufruf, sondern in der Subroutine.
> Z.B. so:
>
> sub f
> {
> my $arg = shift;
> # alle Änderungen an $arg sind lokal
> ...
> }
Ja, das ist klar. Die Frage war etwas anders rum. Wenn ich subs nutze,
die ich nicht näher kenne und nicht sicher bin, ob sie mit
> $_[$i] arbeiten
, muß ich diese mit Kopien meiner später noch gebrauchten Variablen
aufrufen?!
my$x=3;
sub_unbekannt($x);
print "$x (sollte immer noch 3 sein)\n";
$x=3;
sub_unbekannt(my$temp=$x);
print "$x (ist immer noch 3)\n";
Ist das nun ein Bug oder ein Feature????
sächsische Grüße
Frank
Re: Frage zu @_
am 24.05.2006 10:32:10 von Peter Ehrenberg
"f.ballandt" writes:
> [...] Wenn ich subs nutze, die ich nicht näher kenne [...]
Wenn du nicht den Quellcode liest, dann doch zumindest die Doku. Und
da sollte drinstehen, wenn Argumente manipuliert werden.
Perl ist nix für paranoide.
Peter
--
Natürlich bin ich paranoid. Aber bin ich paranoid genug?
-unbekannt-
Re: Frage zu @_
am 24.05.2006 10:41:46 von Daniel Fischer
Andreas Seltenreich!
> Mirco Wahab schrob:
>
>>> ($_[0],$_[1],$_[2]) = (7,8,9);
>>
>> @_[0..2]= (7,8,9);
>
> @_[0..2] = 7..9;
Okay, da hab ich ein paar Dinge nicht bedacht... jetzt weiß ich
wenigstens, warum ich perl mag und warum mir die anderen dcl*-Gruppen
manchmal langweilig vorkommen. ;)
Gruß
Daniel
Re: Frage zu @_
am 25.05.2006 22:54:48 von hjp-usenet2
f.ballandt wrote:
[perl verwendet call by reference]
> Ist das nun ein Bug oder ein Feature????
Feature. D.h., es war so geplant und ist so dokumentiert. Das ist nicht
versehentlich passiert. Ob das gut so ist oder "broken by design",
darüber kann man streiten.
hp
--
_ | Peter J. Holzer | Man könnte sich [die Diskussion] auch
|_|_) | Sysadmin WSR/LUGA | sparen, wenn man sie sich einfach sparen
| | | hjp@hjp.at | würde.
__/ | http://www.hjp.at/ | -- Ralph Angenendt in dang 2006-04-15
Re: Frage zu @_
am 29.05.2006 10:39:19 von Daniel Fischer
Peter J. Holzer!
> Feature. D.h., es war so geplant und ist so dokumentiert. Das ist nicht
> versehentlich passiert. Ob das gut so ist oder "broken by design",
> darüber kann man streiten.
Perl ist eben die einzige esoterische Programmiersprache, die es in den
mainstream geschafft hat :)
Gruß
Daniel
Re: Frage zu @_
am 29.05.2006 10:53:12 von Mirco Wahab
Thus spoke Daniel Fischer (on 2006-05-29 10:39):
> Peter J. Holzer!
>> Feature. D.h., es war so geplant und ist so dokumentiert. Das ist nicht
>> versehentlich passiert. Ob das gut so ist oder "broken by design",
>> darüber kann man streiten.
>
> Perl ist eben die einzige esoterische Programmiersprache, die es in den
> mainstream geschafft hat :)
Perl ist 'compressed unix culture' (hat
das Larry mal gesagt?) und in meinen Augen
eher gar nicht esoterisch sondern 'praktikabel'
und mit einem gewissen 'ad hoc'-Charme versehen.
Was für mich eher esoterisch aussieht, ist Python
(da verdrehn sich immer die Augen ;-), obwohl
es sich inzwischen natürlich zu einem guten
und brauchbaren Werkzeug gemausert hat.
Aber ich sehe immer FORTRAN, wenn ich Python sehe ;-)
Und auf die Idee mit den *unsichtbaren* Klammern
muss man erstmal kommen. *Sichtbare* halte ich
für einfacher zu überblicken ;-)
BTW. die OP-Frage nach $_[n] berührt
die kompatibilität zu Perl4, wo es noch
keine expliziten Referenzen (\$ etc.) gab.
Viele Grüße
Mirco
Re: Frage zu @_
am 29.05.2006 13:00:40 von Daniel Fischer
Mirco Wahab!
> Perl ist 'compressed unix culture' (hat das Larry mal gesagt?) und in
> meinen Augen eher gar nicht esoterisch sondern 'praktikabel' und mit
> einem gewissen 'ad hoc'-Charme versehen.
Ich find's auch praktikabel. Ich mag perl wirklich. Es enthält nur einige
Features, die ich eher einer esoterischen Sprache zuordnen würde, z.B.
Filter::Simple, Code-Referenzen in @INC, AUTOLOAD,...
Und Acme::Brainfuck existiert...
> Und auf die Idee mit den *unsichtbaren* Klammern muss man erstmal
> kommen. *Sichtbare* halte ich für einfacher zu überblicken ;-)
Hast Du mal versucht, Programmieren zu unterrichten? Bei einem Anfänger
sieht man meiner Erfahrung nach oft genug die sichtbaren Klammern *nicht*,
weil *nichts* eingerückt wird. Bei Python geht das schonmal nicht, da
sieht man die unsichtbaren Klammern durchaus besser als im C eines
Programmierneulings. :)
Gruß
Daniel
Re: Frage zu @_
am 29.05.2006 17:33:00 von Frank Seitz
Daniel Fischer wrote:
> Perl ist eben die einzige esoterische Programmiersprache, die es in den
> mainstream geschafft hat :)
Esoterisch? Larry Wall ist tiefgläubiger Christ, so weit ich weiß.
Was mich an Perl am meisten fasziniert ist, dass man selbst
nach Jahren noch grundlegende Dinge dazulernt und die Sprache
wegen ihres Facettenreichtums nie langweilig wird.
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Re: Frage zu @_
am 29.05.2006 18:37:17 von Ferry Bolhar
Frank Seitz:
> Was mich an Perl am meisten fasziniert ist, dass man selbst
> nach Jahren noch grundlegende Dinge dazulernt und die Sprache
> wegen ihres Facettenreichtums nie langweilig wird.
Ganz genau, Frank. Und so sage ich: wartet mal ab, was dann
alles in Perl6 los sein wird (so wir's erleben werden)!
LG, Ferry
--
Ing. Ferry Bolhar
Municipality of Vienna, Department 14
A-1010 Vienna / AUSTRIA
E-mail: bol@adv.magwien.gv.at
Re: Frage zu @_
am 30.05.2006 11:27:20 von Daniel Fischer
Ferry Bolhar!
> Frank Seitz:
>
>> Was mich an Perl am meisten fasziniert ist, dass man selbst
>> nach Jahren noch grundlegende Dinge dazulernt und die Sprache
>> wegen ihres Facettenreichtums nie langweilig wird.
>
> Ganz genau, Frank.
Dem schließe ich mich an.
> Und so sage ich: wartet mal ab, was dann
> alles in Perl6 los sein wird (so wir's erleben werden)!
Das ist ja häppchenweise schon vorher zu lesen, es gibt ja schon eine
prototypische Implementation von dem, was von perl6 bisher bekannt ist.
Siehe dazu: http://pugscode.org/
Gruß
Daniel
Re: Frage zu @_
am 30.05.2006 12:23:09 von Mirco Wahab
Thus spoke Daniel Fischer (on 2006-05-30 11:27):
> Ferry Bolhar!
>> Frank Seitz:
>>> Was mich an Perl am meisten fasziniert ist, dass man selbst
>>> nach Jahren noch grundlegende Dinge dazulernt und die Sprache
>>> wegen ihres Facettenreichtums nie langweilig wird.
>> Ganz genau, Frank.
> Dem schließe ich mich an.
>> Und so sage ich: wartet mal ab, was dann
>> alles in Perl6 los sein wird (so wir's erleben werden)!
>
> Das ist ja häppchenweise schon vorher zu lesen, es gibt ja schon eine
> prototypische Implementation von dem, was von perl6 bisher bekannt ist.
Was uns direkt zur nächsten Frage bringt:
- Ist die Fertigstellung von perl6 überhaupt *möglich* ?
Oder wird perl6 eine Designstudie bleiben,
die schritweise in Perl5 eingeht und end-
lich unter der neuen Flagge a.d.h.o.c. *
(aka perl7) realisiert, welche dann denn Code
in jeglicher bekannter Programmiersprache
akzeptiert?
* [ad]vanced [h]andling [o]f [c]ode
Wer weiss?
Viele Grüße
Mirco
Re: Frage zu @_
am 30.05.2006 13:41:41 von Frank Seitz
Mirco Wahab wrote:
> Thus spoke Daniel Fischer (on 2006-05-30 11:27):
>>>Frank Seitz:
>>>
>>>>Was mich an Perl am meisten fasziniert ist, dass man selbst
>>>>nach Jahren noch grundlegende Dinge dazulernt und die Sprache
>>>>wegen ihres Facettenreichtums nie langweilig wird.
>>>
>>>Ganz genau, Frank.
>>
>>Dem schließe ich mich an.
>>
>>>Und so sage ich: wartet mal ab, was dann
>>>alles in Perl6 los sein wird (so wir's erleben werden)!
>>
>>Das ist ja häppchenweise schon vorher zu lesen, es gibt ja schon eine
>>prototypische Implementation von dem, was von perl6 bisher bekannt ist.
>
> Was uns direkt zur nächsten Frage bringt:
>
> - Ist die Fertigstellung von perl6 überhaupt *möglich* ?
>
> Oder wird perl6 eine Designstudie bleiben,
> die schritweise in Perl5 eingeht und end-
> lich unter der neuen Flagge a.d.h.o.c. *
> (aka perl7) realisiert, welche dann denn Code
> in jeglicher bekannter Programmiersprache
> akzeptiert?
>
> * [ad]vanced [h]andling [o]f [c]ode
>
> Wer weiss?
Ähm, setzt Du da jetzt die Sprache Perl6 mit der virtuellen Maschine
Parrot, die den Code ausführen soll, gleich?
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Re: Frage zu @_
am 30.05.2006 14:21:01 von Mirco Wahab
Thus spoke Frank Seitz (on 2006-05-30 13:41):
> Mirco Wahab wrote:
>> Oder wird perl6 eine Designstudie bleiben,
>> die schritweise in Perl5 eingeht und end-
>> lich unter der neuen Flagge a.d.h.o.c. *
>> (aka perl7) realisiert, welche dann denn Code
>> in jeglicher bekannter Programmiersprache
>> akzeptiert?
>>
>> * [ad]vanced [h]andling [o]f [c]ode
>>
>> Wer weiss?
>
> Ähm, setzt Du da jetzt die Sprache Perl6 mit der virtuellen Maschine
> Parrot, die den Code ausführen soll, gleich?
Nee nee, ich dachte an die Aufnahme aller
Inline::* in den Core und eine Auto-Detection/
Framing/Translation bei Skriptstart.
Wozu dann noch irgendwas Anderes benutzen ;-)
$> perl6 gaussian.f77
$> perl6 gvrcomplicated.py
Parrot ist ja auf dem richtigen Weg.
Viele Grüße
Mirco
Re: Frage zu @_
am 31.05.2006 08:44:29 von Ferry Bolhar
Mirco Wahab:
> - Ist die Fertigstellung von perl6 überhaupt *möglich* ?
>
> Oder wird perl6 eine Designstudie bleiben, die schritweise in
> Perl5 eingeht und endlich unter der neuen Flagge a.d.h.o.c. *
> (aka perl7) realisiert
Es spricht einiges dafür, dass es so ablaufen wird bzw. läuft es ja
teilweise bereits so ab. Wie mir gesagt wurde, wird 5.10 einiges
an 6er-Features enthalten, ohne Parrot eben, aber welchen "nor-
malen" Perl-Programmierer interessiert das? Er freut sich über
neue Features; wie sie implementiert wurden, ist da eher zweit-
rangig.
> welche dann denn Code in jeglicher bekannter Programmier-
> sprache akzeptiert?
Die Frage ist, ob man das überhaupt braucht. Ich hatte da unlängst
erst bei uns im Haus eine Diskussion darüber. Was zB. sollte die
Entwickler von Python dazu bringen, es so umzuschreiben, dass es
Parrot verwendet? Ich - anstelle der Entwickler von Python - würde
mir das gut überlegen! Die Wahrscheinlichkeit, dass danach einige
Python-Programme nicht mehr, oder fehlerhaft, oder langsamer
laufen werden, und damit letztlich eine verminderte Akzeptanz der
Sprache, ist schließlich nicht ganz von der Hand zu weisen. Und
das würde ich als Entwickler wahrscheinlich nicht riskieren wollen.
Wenn in Perl 5 alle (für den Programmierer wesentlichen!) 6er-
Features übernommen werden und von anderen Sprachenent-
wicklern kein Interesse an Parrot besteht, würde Parrot dann
nur noch um seiner selbst Willen weiterentwicklet werden. Und
ich denke, das würde den Aufwand nicht mehr rechtfertigen,
und somit wäre das Parrot dann gestorben.
Und daher ist die grundsätzliche Frage, ob es in Perl 5 Features
geben wird, die nur durch Parrot abgedeckt werden können.
Falls nicht, wird es früher oder später entsprechende Erweiterungen
auch für Perl 5 geben, sei es im Core oder durch Module, je länger
die Entwicklung von Perl 6 noch dauert. Sollte dann eines Tages
doch noch eine 6er-Version das Licht der Welt erblicken, wird sie
kaum Neues bieten, dafür wird XS-Code nicht mehr unterstützt
oder müsste zumindest komplett umgeschrieben werden. Und für
ein solches Perl sehe ich eigentlich wenig Zukunftsperspektiven.
Soviel mein Senf dazu, schöne Grüße aus Wien,
Ferry
--
Ing. Ferry Bolhar
Municipality of Vienna, Department 14
A-1010 Vienna / AUSTRIA
E-mail: bol@adv.magwien.gv.at