Prototype für Referenz

Hallo,

in Perl kann man für Funktionen Prototypen definieren,
sodass schon beim Kompilieren festgestellt werden kann,
ob eine Funktion mit der richtigen Anzahl an Argumenten
und Typen (Skalar, Array, Hash, Liste) aufgerufen wird.

Gibt es auch eine Prototype, um für eine Funktion als
Argument eine Referenz festzulegen (idealerweise auch
noch den Referenztyp)? Also in der Art, wie auch
"bless" fordert, dass das erste Argument eine Referenz
sein muss?

Natürlich kann ich das auch innerhalb der Funktion mit
"ref" nachprüfen. Aber faul, wie ich als Perl-Programmierer
nun mal bin, wäre es doch schade, diese Arbeit nicht dem
Compiler zu überlassen, wenn das möglich ist.

Also, weiß jemand, ob es das gibt?

Ach ja, ich spreche von Perl 5; von Perl 6 weiß ich, dass
es dort möglich sein wird.

Danke für eure Antworten & LG,

Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Prototype für Referenz

Ferry Bolhar wrote:

> in Perl kann man für Funktionen Prototypen definieren,
> sodass schon beim Kompilieren festgestellt werden kann,
> ob eine Funktion mit der richtigen Anzahl an Argumenten
> und Typen (Skalar, Array, Hash, Liste) aufgerufen wird.
>
> Gibt es auch eine Prototype, um für eine Funktion als
> Argument eine Referenz festzulegen (idealerweise auch
> noch den Referenztyp)? Also in der Art, wie auch
> "bless" fordert, dass das erste Argument eine Referenz
> sein muss?

Dazu müsste Perl zur Compilezeit feststellen, welche
Werte der betreffende Skalar zur Laufzeit annimmt.
Da das nicht möglich ist, kann es IMO so einen Prototyp
nicht geben.

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: Prototype für Referenz

Frank Seitz schrieb:
> Ferry Bolhar wrote:
>
>
>>in Perl kann man für Funktionen Prototypen definieren,
>>sodass schon beim Kompilieren festgestellt werden kann,
>>ob eine Funktion mit der richtigen Anzahl an Argumenten
>>und Typen (Skalar, Array, Hash, Liste) aufgerufen wird.
>>
>>Gibt es auch eine Prototype, um für eine Funktion als
>>Argument eine Referenz festzulegen (idealerweise auch
>>noch den Referenztyp)? Also in der Art, wie auch
>>"bless" fordert, dass das erste Argument eine Referenz
>>sein muss?
>
>
> Dazu müsste Perl zur Compilezeit feststellen, welche
> Werte der betreffende Skalar zur Laufzeit annimmt.
> Da das nicht möglich ist, kann es IMO so einen Prototyp
> nicht geben.

Ergänzend dazu ist noch zu erwähnen, dass Perl 5 Prototypen nicht das
leisten was du von ihnen erwartest, sondern bei falschem Verständnis
ihrer Funktionsweise auch noch die Quelle subtiler Probleme sein können.

Gut beschrieben ist das unter dem Stichwort 'Prototypes' in Kapitel 9
des neuen Buches "Perl Best Pratices" von Damian Conway das als
Probekapitel bei O'Reilly auf der Website zu finden ist:

http://www.oreilly.de/catalog/perlbp/chapter/ch09.pdf

Gruß
Karlheinz

Re: Prototype für Referenz

Frak Seitz:

> Dazu müsste Perl zur Compilezeit feststellen, welche
> Werte der betreffende Skalar zur Laufzeit annimmt.
> Da das nicht möglich ist, kann es IMO so einen Prototyp
> nicht geben.

Wieso? Wenn ich einer Funktion z.B. mit

test([1,2,3]);

eine Arrayreferenz übergebe, sollte ich doch auch
bereits für den Compiler definieren können, dass diese
Funktion nur ein Argument entgegennimmt, das eine
Arrayreferenz sein muss.

Wird stattdessen ein Skalar übergeben, ist klar, dass
erst zur Laufzeit festgestellt werden kann, was darin
enthalten ist. Aber das hindert ja nicht, solche Prüfungen
wie oben gezeigt zu ermöglichen.

Aber es scheint tatsächlich so zu sein, dass das in Perl 5
noch nicht möglich ist.

Dennoch danke für deine Antwort &

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Prototype für Referenz

Karlheinz Weindl:

> Ergänzend dazu ist noch zu erwähnen, dass Perl 5 Prototypen nicht das
> leisten was du von ihnen erwartest, sondern bei falschem Verständnis
> ihrer Funktionsweise auch noch die Quelle subtiler Probleme sein können.

Ja, aber es gibt trotzdem Fälle, wo sie sinnvoll sind bzw. wo man
auf sie nicht verzichten kann. Wie willst du dem Compiler sonst
klarmachen, dass bei einer Funktion mit einer map-ähnlichen Syntax

myfunc {...} @array;

das {...} keine Hashreferenz, sondern ein Code-Block
sein soll?

> Gut beschrieben ist das unter dem Stichwort 'Prototypes' in Kapitel 9
> des neuen Buches "Perl Best Pratices" von Damian Conway das als
> Probekapitel bei O'Reilly auf der Website zu finden ist:
>
> http://www.oreilly.de/catalog/perlbp/chapter/ch09.pdf

Ich teile Damian's Meinung hier nicht ganz - das von ihm gezeigte
Beispiel ist doch relativ exotisch. Ich verwende Prototypen sehr
gerne, besonders wenn es sich um Benutzschnittstellen handelt.
Der Benutzer kennt den Code, den er aufruft, nicht im Detail,
sondern er weiß, mit wievielen Argumenten er eine Funktion
aufrufen muss. Tut er das nicht, bekommt er dieselbe, vertraute
Meldung, wie er sie auch bei Perl's Builtins bekommen würde.
Und das funktioniert, ohne dass ich dafür eine Zeile Code hätte
schreiben müssen. Was ist also daran auszusetzen?

Es ist aber gut und hilfreich, dass Damian die Problematiken,
die sich aus der Verwendung von Prototypen ergeben können,
aufzeigt. Ich gestehe, dass mir die bisher auch noch nicht in
vollem Umfang bewusst waren.

Dass Prototyping seine Berechtigung hat, ist auch aus der
Tatsache zu erkennen, dass es in Perl 6 weiterhin - und dort
wesentlich erweitert - existieren wird.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Prototype für Referenz

Ferry Bolhar wrote:
> Frak Seitz:
>>
>>Dazu müsste Perl zur Compilezeit feststellen, welche
>>Werte der betreffende Skalar zur Laufzeit annimmt.
>>Da das nicht möglich ist, kann es IMO so einen Prototyp
>>nicht geben.
>
> Wieso? Wenn ich einer Funktion z.B. mit
>
> test([1,2,3]);
>
> eine Arrayreferenz übergebe, sollte ich doch auch
> bereits für den Compiler definieren können, dass diese
> Funktion nur ein Argument entgegennimmt, das eine
> Arrayreferenz sein muss.
>
> Wird stattdessen ein Skalar übergeben, ist klar, dass
> erst zur Laufzeit festgestellt werden kann, was darin
> enthalten ist. Aber das hindert ja nicht, solche Prüfungen
> wie oben gezeigt zu ermöglichen.

Dann sollte Deiner Meinung nach manchmal geprüft
werden und manchmal nicht?
Das ist doch halbgar.

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: Prototype für Referenz

Ferry Bolhar schrieb:

> Karlheinz Weindl:
>
>
>>Ergänzend dazu ist noch zu erwähnen, dass Perl 5 Prototypen nicht das
>>leisten was du von ihnen erwartest, sondern bei falschem Verständnis
>>ihrer Funktionsweise auch noch die Quelle subtiler Probleme sein können.
>
>
> Ja, aber es gibt trotzdem Fälle, wo sie sinnvoll sind bzw. wo man
> auf sie nicht verzichten kann. Wie willst du dem Compiler sonst
> klarmachen, dass bei einer Funktion mit einer map-ähnlichen Syntax
>
> myfunc {...} @array;
>
> das {...} keine Hashreferenz, sondern ein Code-Block
> sein soll?

Deine Fragestellung müßte hier eigentlich lauten:
"Wie willst du dem Compiler denn überhaupt klarmachen diese Syntax
überhaupt zu akzeptieren ohne Prototypen zu verwenden?"

Dies, nämlich das Erstellen von eigenen Funktionen die sich wie
eingebaute Funktionen verhalten, ist meinem Verständnis nach auch der
einzige Zweck der Perl 5 Prototypen und nicht etwa eine wie auch immer
geartete Signaturprüfung, wie sie in strikten OO-Sprachen der Fall ist.

Was auch immer in Bezug darauf stattfindet halte ich (bislang) für
ziemlich uninteressant, da dies laut Dokumentation bei jeder Art von
Referenzierung der sub (sei es als \& oder Methode) sowieso hinfällig
ist. Oder hab' ich das falsch gelesen?

Gruß
Karlheinz

Re: Prototype für Referenz

Frank Seitz:

> Dann sollte Deiner Meinung nach manchmal geprüft
> werden und manchmal nicht?
> Das ist doch halbgar.

Naja, ich denke, besser "halbgar" als gar nicht...

Die Built-ins können ja auch erst zur Laufzeit prüfen,
ob in Variablen übergebene Werte gültig sind oder
nicht -

bless $a;

kann erst zur Laufzeit feststellen, ob in $a eine Referenz
steht. Und bei einem

$x = $y / $z;

wirst du auch erst zur Laufzeit feststellen können,
ob der Nenner > 0 ist...

Manches geht eben nur zur Laufzeit. Aber das heißt ja
nicht, das man etwas, was man bereits beim Compilieren
prüfen könnte, nicht auch prüfen soll bzw. Mechanismen
zum Prüfen bereitstellen kann.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Prototype für Referenz

Karlheinz Weindl:

> Was auch immer in Bezug darauf stattfindet halte ich (bislang) für
> ziemlich uninteressant, da dies laut Dokumentation bei jeder Art von
> Referenzierung der sub (sei es als \& oder Methode) sowieso hinfällig
> ist. Oder hab' ich das falsch gelesen?

Es ist sogar hinfällig, wenn man nur &sub sagt. Bei einem \& (dh., beim
Aufrufen einer Codereferenz) ist es klarerweise auch hinfällig, weil da der
Compiler ja nicht wissen kann, welche sub über die Referenz angesprochen
werden wird.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Prototype fürReferenz

On 2006-11-20 08:27, Frank Seitz wrote:
> Ferry Bolhar wrote:
>> Frak Seitz:
>>>Dazu müsste Perl zur Compilezeit feststellen, welche
>>>Werte der betreffende Skalar zur Laufzeit annimmt.
>>>Da das nicht möglich ist, kann es IMO so einen Prototyp
>>>nicht geben.
>>
>> Wieso? Wenn ich einer Funktion z.B. mit
>>
>> test([1,2,3]);
>>
>> eine Arrayreferenz übergebe, sollte ich doch auch
>> bereits für den Compiler definieren können, dass diese
>> Funktion nur ein Argument entgegennimmt, das eine
>> Arrayreferenz sein muss.
>>
>> Wird stattdessen ein Skalar übergeben, ist klar, dass
>> erst zur Laufzeit festgestellt werden kann, was darin
>> enthalten ist. Aber das hindert ja nicht, solche Prüfungen
>> wie oben gezeigt zu ermöglichen.
>
> Dann sollte Deiner Meinung nach manchmal geprüft
> werden und manchmal nicht?

Das ist im Compilerbau nicht unüblich. Ein ziemlich triviales Beispiel
ist die Compile-Time-Überprüfung des *printf-Formatparameters durch den
gcc. Ist es eine String-Konstante, wird sie zur Compile-Time überprüft.
Ist es ein Ausdruck, produziert der Compiler Code der von einem
korrekten Formatparameter ausgeht - ist der nicht korrekt, knallt es zur
Laufzeit (oder auch nicht).

Ist halt die Frage, ob sich das auszahlt. Früher enthielten viele
C-Programme hartkodierte Format-Strings, da konnte diese relativ
einfache Überprüfung etliche triviale Fehler finden. Heute verwenden
viele Programme gettext oder ähnliches, da hat der Compiler keine Chance
mehr.

Ebenfalls möglich sind Datenfluss-Analysen. Wenn man z.B. Code wie den
folgenden hat:

sub foo {
return [1, 2, 3];
}

sub bar {
my ($n) = @_;

my $r;
if ($n > 0) {
$r = foo();
} elsif ($ n == 0) {
$r = [ 42 ];
} else {
return 23;
}

test($r);
}

Dann kann der Compiler feststellen, dass $r im Aufruf test($r) nur ein
Arrayref sein kann.

Oder so. In Perl ist das nämlich nicht so einfach. Es könnte ja jemand
zwischen dem Zeitpunkt da sub foo und sub bar compiliert wurden und dem,
an dem bar dann tatsächlich aufgerufen wird, ein anderes foo erzeugen,
das statt dessen ein Hashref zurückliefert.

Eine globale Analyse, die sowas ausschließt, wäre vermutlich irrsinnig
aufwendig, sowas will man nicht bei jedem Start eines Perl-Scripts
machen. Bei Sprachen, die compilierte Files erzeugen, ist es ein
geringeres Problem, wenn ein Compilerlauf 5 Stunden dauert :-).

hp


--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: Prototype für Referenz

Ferry Bolhar wrote:
> Frank Seitz:
>>
>>Dann sollte Deiner Meinung nach manchmal geprüft
>>werden und manchmal nicht?
>>Das ist doch halbgar.
>
> Naja, ich denke, besser "halbgar" als gar nicht...

Das sehe ich ganz anders: Entweder ein Konzept funktioniert
oder nicht. Halbgare Konzepte sollte man nicht einführen.

> Die Built-ins können ja auch erst zur Laufzeit prüfen,
> ob in Variablen übergebene Werte gültig sind oder
> nicht -
>
> bless $a;
>
> kann erst zur Laufzeit feststellen, ob in $a eine Referenz
> steht. Und bei einem
>
> $x = $y / $z;
>
> wirst du auch erst zur Laufzeit feststellen können,
> ob der Nenner > 0 ist...
>
> Manches geht eben nur zur Laufzeit. Aber das heißt ja
> nicht, das man etwas, was man bereits beim Compilieren
> prüfen könnte, nicht auch prüfen soll bzw. Mechanismen
> zum Prüfen bereitstellen kann.

Ich habe nichts gegen Laufzeitprüfungen.
Nur Prototypes machen nunmal keine Laufzeitprüfungen.
Dass ein kleiner Teil der Konstrukte (Literale auf
Argumentpostionen) zur Compilezeit geprüft
werden könnte, ist doch kein Argument. De facto
wäre die Sache unbrauchbar und würde die Perl-Prototypes
noch diffuser machen.

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: Prototype für Referenz

Peter J. Holzer wrote:
> On 2006-11-20 08:27, Frank Seitz wrote:
>>
>>Dann sollte Deiner Meinung nach manchmal geprüft
>>werden und manchmal nicht?
>
> Das ist im Compilerbau nicht unüblich. Ein ziemlich triviales Beispiel
> ist die Compile-Time-Überprüfung des *printf-Formatparameters durch den
> gcc. Ist es eine String-Konstante, wird sie zur Compile-Time überprüft.
> Ist es ein Ausdruck, produziert der Compiler Code der von einem
> korrekten Formatparameter ausgeht - ist der nicht korrekt, knallt es zur
> Laufzeit (oder auch nicht).

Das ist etwas anderes.
Solche printf-Prüfungen macht Perl auch (zur Laufzeit), entweder
um den betreffenden Parameter zu konvertieren oder ihn
(ggf. mit Warnung) zurückzuweisen.

Ein paralleles Beispiel wäre eine C Funktionsdeklaration, die
der Compiler ganz oder teilweise ignoriert. Sowas kommt
in C (und vermutlich den meisten streng typisierten Sprachen)
meines Wissens nicht vor.

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: Prototype für Referenz

Frank Seitz:

>> Das ist im Compilerbau nicht unüblich. Ein ziemlich triviales Beispiel
>> ist die Compile-Time-Überprüfung des *printf-Formatparameters durch den
>> gcc. Ist es eine String-Konstante, wird sie zur Compile-Time überprüft.
>> Ist es ein Ausdruck, produziert der Compiler Code der von einem
>> korrekten Formatparameter ausgeht - ist der nicht korrekt, knallt es zur
>> Laufzeit (oder auch nicht).
>
> Das ist etwas anderes.

Wieso?

Du hast doch selbst geschrieben:

> Das sehe ich ganz anders: Entweder ein Konzept funktioniert
> oder nicht. Halbgare Konzepte sollte man nicht einführen.

Und jetzt passt es doch?

Manche Dinge können nur zur Laufzeit geprüft werden, andere
bereits beim Compilieren. Und daher macht es Sinn, die Möglich-
keit hierfür vorzusehen.

In Perl _gibt_ es nunmal die Möglichkeit des Prototyping, auch
wenn die Intention für dessen Einführung möglicherweise nicht
dieselbe war wie z.B. in C. Aber ich kann definieren, dass eine
Funktion nur mit genau zwei Argumenten aufgerufen werden
darf und dass das erste z.B. ein skalarer Wert und das zweite
eine Array-Variable (die dann als Referenz übergeben wird)
sein muss. Daher wäre es - auch wenn es offensichtlich in Perl
5 nicht vorgesehen ist - nichts verkehrtes, diese Möglichkeiten
auf die Prüfung von Referenzen (und vielleicht sogar auf
Referenztypen) auszuweiten. Dass dies nicht immer in allen
Fällen möglich sein wird, steht auf einem anderen Blatt.

Im Übrigen ist obige Argumentation für mich nicht nachvoll-
ziehbar (und scheinbar auch für die Perl-Entwickler nicht),
denn Perl 6 wird ein solches Prototyping unterstützen.

> Dass ein kleiner Teil der Konstrukte (Literale auf
> Argumentpostionen) zur Compilezeit geprüft
> werden könnte, ist doch kein Argument.

Für die Perl-Entwickler scheinbar doch..

> De facto wäre die Sache unbrauchbar und würde die
> Perl-Prototypes noch diffuser machen.

Vielleicht ist das sogar beabsichtigt... ;-))

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Prototype für Referenz

Ferry Bolhar wrote:
> Frank Seitz:
>>
>>>Das ist im Compilerbau nicht unüblich. Ein ziemlich triviales Beispiel
>>>ist die Compile-Time-Überprüfung des *printf-Formatparameters durch den
>>>gcc. Ist es eine String-Konstante, wird sie zur Compile-Time überprüft.
>>>Ist es ein Ausdruck, produziert der Compiler Code der von einem
>>>korrekten Formatparameter ausgeht - ist der nicht korrekt, knallt es zur
>>>Laufzeit (oder auch nicht).
>>
>>Das ist etwas anderes.
>
> Wieso?
>
> Du hast doch selbst geschrieben:
>
>>Das sehe ich ganz anders: Entweder ein Konzept funktioniert
>>oder nicht. Halbgare Konzepte sollte man nicht einführen.
>
> Und jetzt passt es doch?

Ferry, Du kopierst mehrere Postings von mir zusammen, streichst
Erläuterungen raus, stellst einen neuen Sinnzusammenhang
her (den ich ehrlich nicht verstehe) und fragst einfach "Wieso?"
und "Und jetzt passt es doch?".
Das ist kein besonders guter Stil und ist mir auch zu mühsam.

Ich habe die Begründung, warum das, was Du Dir bei
den Perl5 Prototypes wünscht, meiner Meinung nach unter dem
gegebenen Randbedingungen (reine Compiletime-Behandlung)
grundsätzlich nicht geht bzw. wegen starker Beschränkungen
(nur bei Literalen anwendbar) kein sinnvolles Konzept
darstellt, bereits komplett kundgetan.
Ich könnte mich nur wiederholen.

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: Prototype für Referenz

Frank Seitz:

> Ferry, Du kopierst mehrere Postings von mir zusammen, streichst
> Erläuterungen raus, stellst einen neuen Sinnzusammenhang
> her (den ich ehrlich nicht verstehe) und fragst einfach "Wieso?"
> und "Und jetzt passt es doch?".
> Das ist kein besonders guter Stil und ist mir auch zu mühsam.

Sorry, ich hatte es nicht so gemeint. Ich hatte nur das Gefühl,
dass der Umstand, dass beim Prototyping Compilerprüfungen
nicht möglich sind, wenn an die jeweilige Funktion Skalare
und keine Literale übergeben werden, für dich ein Problem ist
und den Sinn des Prototyping an sich in Frage stellt, während
es bei dem von Peter gezeigten Beispiel mit "printf" für dich
OK ist, dass eben manche Prüfungen erst zur Laufzeit ablaufen
können. Und das kam mir irgendwie unkonsequent vor.

> Ich habe die Begründung, warum das, was Du Dir bei
> den Perl5 Prototypes wünscht, meiner Meinung nach unter dem
> gegebenen Randbedingungen (reine Compiletime-Behandlung)
> grundsätzlich nicht geht bzw. wegen starker Beschränkungen
> (nur bei Literalen anwendbar) kein sinnvolles Konzept
> darstellt, bereits komplett kundgetan.

Ich habe dich durchaus verstanden. Ich verstehe nur nicht,
wieso es bei "printf" für dich sehr wohl sinnvoll ist, dass bereits
durch den Compiler eine Prüfung des Formatstrings erfolgt,
wenn dieser als Literal vorliegt, und beim Prototyping eben nicht.
Die printf-Prüfung ist letztlich genauso "halbgar" wie die durch
Prototyping durchgeführten Prüfungen, die eben manchmal
bereits durch den Compiler durchgeführt werden können und
ein anderes erst zur Laufzeit (bzw. gar nicht).

Und wie ich bereits ausgeführt habe (darauf bist du nicht
eingegangen), ist die von mir angedachte Erweiterung von
Prototyping in Perl 6 ja realisiert worden, so weltfremd und
"kein sinnvolles Konzept" (wie du denkst) dürfte sie also
doch nicht sein.

Nochmals sorry, ich wollte dir keinesfalls zu nahe treten.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Prototype fürReferenz

On 2006-11-22 09:12, Ferry Bolhar wrote:
> Frank Seitz:
>> Ferry, Du kopierst mehrere Postings von mir zusammen, streichst
>> Erläuterungen raus, stellst einen neuen Sinnzusammenhang
>> her (den ich ehrlich nicht verstehe) und fragst einfach "Wieso?"
>> und "Und jetzt passt es doch?".
>> Das ist kein besonders guter Stil und ist mir auch zu mühsam.
>
> Sorry, ich hatte es nicht so gemeint. Ich hatte nur das Gefühl,
> dass der Umstand, dass beim Prototyping Compilerprüfungen
> nicht möglich sind, wenn an die jeweilige Funktion Skalare
> und keine Literale übergeben werden, für dich ein Problem ist
> und den Sinn des Prototyping an sich in Frage stellt, während
> es bei dem von Peter gezeigten Beispiel mit "printf" für dich
> OK ist, dass eben manche Prüfungen erst zur Laufzeit ablaufen
> können. Und das kam mir irgendwie unkonsequent vor.

Es gibt einen prinzipiellen Unterschied: Prototypes in Perl ändern den
Kontext der aufrufenden Funktion:

#!/usr/bin/perl
use warnings;
use strict;

sub fx {
return 42;
}

sub f0() {
return 42;
}

sub f1($) {
return 42;
}

my $x;

$x = fx + 23;
print "$x\n";

$x = f0 + 23;
print "$x\n";

$x = f1 + 23;
print "$x\n";

gibt aus:

42
65
42

(wobei mich das erste 42 etwas überrascht - ich hätte da ein "no
bareword sub allowed with strict ..." o.ä. erwartet)

Im Fall von printf wird der Kontext nicht geändert - der Compiler hat
nur zusätzliche Information, die es ihm erlaubt, eine Warnung
auszugeben, wenn der Programmierer mit hoher Wahrscheinlichkeit einen
Fehler gemacht hat - er produziert aber den gleichen Code.

Ebenso bei den anderen Beispielen, die ich genannt habe - dort wo das
verwendet wird, dient es entweder dazu Warnungen auszugeben oder
besseren Code zu generieren (speziell C-Compiler können deutlich
besseren Code generieren, wenn sie z.B. nachweisen können, dass zwei
Pointer nicht auf das gleiche Objekt zeigen können).

hp


--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: Prototype für Referenz

Ferry Bolhar wrote:

> Ich habe dich durchaus verstanden. Ich verstehe nur nicht,
> wieso es bei "printf" für dich sehr wohl sinnvoll ist, dass bereits
> durch den Compiler eine Prüfung des Formatstrings erfolgt,
> wenn dieser als Literal vorliegt, und beim Prototyping eben nicht.
> Die printf-Prüfung ist letztlich genauso "halbgar" wie die durch
> Prototyping durchgeführten Prüfungen, die eben manchmal
> bereits durch den Compiler durchgeführt werden können und
> ein anderes erst zur Laufzeit (bzw. gar nicht).

Prototypes und Formatstrings sind etwas völlig anderes.
Prototypes drücken Constraints aus, von denen
man erwartet, dass der Compiler/Interpreter ihre Einhaltung
konsequent prüft bzw. forciert. printf-Formatstrings sind etwas
Beliebiges, nichtmal Teil der Syntax der Sprache.
Inwieweit da etwas geprüft wird und auf welchem
Weg, ist vollkommen freigestellt.

> Und wie ich bereits ausgeführt habe (darauf bist du nicht
> eingegangen), ist die von mir angedachte Erweiterung von
> Prototyping in Perl 6 ja realisiert worden, so weltfremd und
> "kein sinnvolles Konzept" (wie du denkst) dürfte sie also
> doch nicht sein.

Kann sein, weiß ich nicht. Das geht dann nur, wenn
in Perl6 Prototype-Vereinbarungen auch zur Laufzeit
herangezogen und die aktuellen Parameter gegen diese
geprüft werden. Das ist auch völlig in Ordnung.
Nur das Perl5-Konzept sieht nunmal anders aus, was
Implikationen hat, u.a. die, dass das, was Du haben
möchtest, nicht geht, was Du ungern akzeptieren willst.

> Nochmals sorry, ich wollte dir keinesfalls zu nahe treten.

Du bist mir nicht zu nahe getreten.
Du hast nur wild zitiert und wiedermal ein beachtliches
Beharrungsvermögen gegen ansich (meiner Meinung nach)
klare Argumente.

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: Prototype für Referenz

Peter J. Holzer wrote:

> Es gibt einen prinzipiellen Unterschied: Prototypes in Perl ändern den
> Kontext der aufrufenden Funktion:

Vorsicht: der Begriff "Kontext eines Funktionsaufrufs" ist bei
Perl schon anderweitig belegt und bezieht sich auf den
Returnwert, nicht die Argumente.

> 42
> 65
> 42
>
> (wobei mich das erste 42 etwas überrascht - ich hätte da ein "no
> bareword sub allowed with strict ..." o.ä. erwartet)

Wenn Du das möchtest, musst Du die Subroutine-Definition
nur nach unten ziehen.

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: Prototype für Referenz

Frank Seitz:

> Prototypes und Formatstrings sind etwas völlig anderes.
> Prototypes drücken Constraints aus, von denen
> man erwartet, dass der Compiler/Interpreter ihre Einhaltung
> konsequent prüft bzw. forciert. printf-Formatstrings sind etwas
> Beliebiges, nichtmal Teil der Syntax der Sprache.
> Inwieweit da etwas geprüft wird und auf welchem
> Weg, ist vollkommen freigestellt.

OK.

> Nur das Perl5-Konzept sieht nunmal anders aus, was
> Implikationen hat, u.a.

Das war's ja eigentlich, was ich wissen wollte.

> die, dass das, was Du haben
> möchtest, nicht geht, was Du ungern akzeptieren willst.

Nein, gar nicht. Nur hat mich deine Formulierung von "halbgaren
Sachen" etwas gestört. Ich bin auch jetzt noch der Ansicht, dass
erweitertes Prototyping nichts "Halbgares" ist, auch wenn es in
Perl5 noch nicht implementiert wurde, sondern erst in Perl6.

> Du bist mir nicht zu nahe getreten.
> Du hast nur wild zitiert und wiedermal ein beachtliches
> Beharrungsvermögen gegen ansich (meiner Meinung nach)
> klare Argumente.

"Wiedermal"?

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Prototype für Referenz

Ferry Bolhar wrote:

> Nein, gar nicht. Nur hat mich deine Formulierung von "halbgaren
> Sachen" etwas gestört. Ich bin auch jetzt noch der Ansicht, dass
> erweitertes Prototyping nichts "Halbgares" ist, auch wenn es in
> Perl5 noch nicht implementiert wurde, sondern erst in Perl6.

Missverständnis: Das "halbgar" bezog sich auf Deinen Vorschlag,
im Falle von Perl5 (= Prototype-Prüfungen nur zur Compile-Time),
lediglich Literale zu checken und alles andere unkontrolliert
passieren zu lassen.

>>Du bist mir nicht zu nahe getreten.
>>Du hast nur wild zitiert und wiedermal ein beachtliches
>>Beharrungsvermögen gegen ansich (meiner Meinung nach)
>>klare Argumente.
>
> "Wiedermal"?

Ja :) YMMV.

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