Θέμα: ΜΕΤΑΒΙΒΑΣΗ ΠΑΡΑΜΕΤΡΩΝ ΣΕ ΥΠΟΠΡΟΓΡΑΜΜΑΤΑ

[evry]

       Η παράγραφος 10.5.3 είναι από φέτος στην ύλη του μαθήματος. Ο τρόπος μεταβίβασης παραμέτρων που έχουν επιλέξει οι συγγραφείς είναι γνωστός στην βιβλιογραφία ως call-by-value-result και συναντάται σε μια έκδοση της algol την ALGOLW.
    Στον τρόπο αυτό δεν υπάρχει διαχωρισμός σε παραμέτρους εισόδου και εξόδου. Είναι όλες και εισόδου και εξόδου. Το τι ρόλο παίζει κάποια εξαρτάται καθαρά από το πως θα τη χρησιμοποιήσει ο μαθητής.
   Το θέμα που θέλω να φέρω προς συζήτηση είναι: Τι θα εμφανίσει το παρακάτω πρόγραμμα;

Κώδικας: [Επιλογή]

ΠΡΟΓΡΑΜΜΑ Πέρασμα_Παραμέτρων
ΜΕΤΑΒΛΗΤΕΣ
  ΑΚΕΡΑΙΕΣ: a, result                             
ΑΡΧΗ
  a <-- 10
  ΚΑΛΕΣΕ ambiguous(a, a, result)
  ΓΡΑΨΕ a, '   ', result
ΤΕΛΟΣ_ΠΡΟΓΡΑΜΜΑΤΟΣ
!-----------------------------------------------------------
ΔΙΑΔΙΚΑΣΙΑ ambiguous(x, y, z)
ΜΕΤΑΒΛΗΤΕΣ
  ΑΚΕΡΑΙΕΣ: x, y, z
ΑΡΧΗ
  x <-- x + y
  y <-- y + x
  z <-- x + y
ΤΕΛΟΣ_ΔΙΑΔΙΚΑΣΙΑΣ
!-----------------------------------------------------------


[alkisg]

Με βάση το σχολικό βιβλίο, νομίζω ότι δεν μπορούμε να απαντήσουμε την ερώτηση! Θα έπρεπε να ξέρουμε και τη σειρά που γίνονται pop οι παράμετροι από τη στοίβα!

Όπως γράφω και στο εγχειρίδιο της ΓΛΩΣΣΑΣ (https://alkisg.mysch.gr/ΓΛΩΣΣΑ/Μεταβίβαση_παραμέτρων/), τα δύο a που περνιούνται παράμετροι είναι διαφορετικές μεταβλητές στη διαδικασία, δηλαδή το x και το y της διαδικασίας δεν αναφέρονται στην ίδια θέση μνήμης!

Επομένως μετά το ΤΕΛΟΣ_ΔΙΑΔΙΚΑΣΙΑΣ εννοούνται εντολές του τύπου

Κώδικας: ΓΛΩΣΣΑ

1. result <- z
2. a <- y
3. a <- x

και επομένως το a θα γίνει είτε x είτε y, ανάλογα με τη σειρά που εκτελούνται οι παραπάνω εντολές (το pop από τη στοίβα δηλαδή).

Δεν υπάρχει μία "στάνταρ" σειρά (π.χ. από αριστερά προς τα δεξιά) με την οποία να γίνονται pop οι παράμετροι από τη στοίβα, και το βιβλίο δεν νομίζω ότι αναφέρει κάτι σχετικό, οπότε γι' αυτό λέω ότι δεν μπορούμε να απαντήσουμε.

Πάντως σε καμία περίπτωση δε θα ήθελα να ήμουν μαθητής και να μου έθεταν τέτοια ερώτηση! Ούτε στο σχολείο ούτε στις πανελλήνιες!

[evry]

Και εγώ έτσι πιστεύω. Αυτό που δεν μπορώ να καταλάβω είναι τι είχαν στο μυαλό τους οι συγγραφείς όταν επέλεγαν αυτό τον τρόπο μεταβίβασης παραμέτρων ο οποίος είναι όχι μόνο αντιεπιστημονικός αλλά και αντιπαιδαγωγικός.
Δεν μπορεί να γίνει κάποια διόρθωση και μια και η γλώσσα είναι ένα  αντίγραφο της Pascal  να υπάρχουν δυο είδη παραμέτρων κατά τιμή και κατά αναφορά (βλέπε var) και να λήξει η υπόθεση;
Υπάρχει κάποια ομάδα που να ασχολείται με την αναβάθμιση της Γλώσσας και τη συγγραφή ενός καινούργιου διδακτικού πακέτου?

Ερώτηση: Στον διερμηνευτή της Γλώσσας έχεις υλοποιήσει την εμβέλεια τον μεταβλητών όπως τη λέει στο βιβλίο? Διότι στη Γλωσσομάθεια την οποία χρησιμοποιώ στο μάθημα  η μεταβίβαση παραμέτρων είναι κατ'αναφορά και μπορείς να χρησιμοποιήσεις κανονικά καθολικές μεταβλήτες στα υποπρογράμματα.

[graeep]

Συμφωνώ με τον alkisg. Εφόσον μιλάμε για πέρασμα παραμέτρων με τιμή, δεν ξέρουμε το αποτέλεσμα μέχρι να πληροφορηθούμε πως γίνεται η ανάκτηση των τιμών των μεταβλητών από τη στοίβα. Εξαρτάται δηλαδή από την υλοποίηση του Διερμηνευτή

Προσοχη: Στη Γλωσσομάθεια το πέρασμα των τιμών των μεταβλητών γίνεται όπως είδα με αναφορά και αυτό έχει ως αποτέλεσμα το πρόγραμμα να εμφανίζει 40 , 80.

Πάντως για να πούμε και του στραβού το δίκιο, δεν νομίζω ότι θα έστεκε να δώσουν τέτοιο θέμα στις εξετάσεις, αφού
1) Αντίκειται σε βασικούς κανόνες προγραμματισμού
2) Υπάρχουν καλύτερες ασκήσεις για να ελέγξουν αν οι μαθητές έχουν αφομοιώσει το πέρασμα μεταβλητών με τιμή.

[alkisg]

Στο Διερμηνευτή, επειδή ο ψευδοκώδικας εκτελείται από τα αντίστοιχα objects που έχω φτιάξει στο Delphi, έχω την ευχέρεια να υλοποιώ τη ΓΛΩΣΣΑ με οποιονδήποτε τρόπο (δε μεταφράζεται δηλαδή εσωτερικά ο ψευδοκώδικας σε Pascal, αλλά εκτελείται απευθείας).

Έτσι την υλοποίηση των διαδικασιών στο Διερμηνευτή την έκανα όπως γράφει το βιβλίο - με αντιγραφή και όχι με αναφορά. Μάλιστα για να παίζουν όλα τα παραδείγματα του σχολικού βιβλίου (π.χ. Πύργοι του Ανόι) επιτρέπονται και παράμετροι με τιμή (οπότε δηλαδή γίνεται copy-in αλλά όχι copy-out).

Το κακό είναι ότι το βιβλίο δεν είναι πάντα σαφές, οπότε τα ασαφή σημεία τα υλοποιώ μετά από συννενόηση με τους συγγραφείς ή μετά από συζητήσεις εδώ στο στέκι... χωρίς να υπάρχει "επίσημη" θέση από κάποιον φορέα...

Υ.Γ. ο Διερμηνευτής στο παραπάνω πρόγραμμα εμφανίζει
20   50
(κάνει push από αριστερά προς τα δεξιά και pop αντίθετα) και δεν επιτρέπει τη χρήση καθολικών μεταβλητών...
Πάντως το αμφιλεγόμενο είναι αν έπρεπε να εμφανίσει
20   50 ή
30   50,
το 40   80 δεν είναι σωστό με βάση το βιβλίο...

[klitos]

Η ερώτηση γίνεται για να απαντηθεί απο τους μαθητές ή για να πούμε τι θα έπρεπε, κατα την γνώμη μας, να ισχύει ?
Νομίζω ότι ειναι περα για πέρα εξω απο το πνεύμα της προετοιμασίας των μαθητών. Δεν ειναι το μόνο σκοτεινό σημείο ...
Σε όλες τις γλώσσες προγραμματισμού υπάρχει και η ... γλώσσα προγραμματισμού για να δούμε πως "τρέχει" ενα πρόγραμμα ... εδώ δεν μπορούμε να το κάνουμε ... αρα δεν μπορεί να υπάρχει καμμία συγκριση ουτε με ALGOL ή καποια άλλη γλώσσα..
Ας αρκεστούμε σε αυτά που αναφέρει το σχολικό  βιβλίο για τα υποπρογράμματα και ειναι νοιμίζω αρκετά παραστατικό το παράδειγμα που αναφέρει στην παράγραφο 10.5.3 για το πέρασμα των τιμών απο τις πραγματικές στις τυπικές παραμέτρους ..

[andreas_p]

Είναι αποδεκτή η παρακάτω κλήση ;

a <-- 10
ΚΑΛΕΣΕ ambiguous(a, a, result)

Γιατί να μην είναι ;

a <-- 10
b<-- a
 ΚΑΛΕΣΕ ambiguous(a, b, result)

[evry]

Φυσικά και είναι. Για ποιο λόγο να μην είναι? Απο τη στιγμή που συμφωνούν οι τύποι και ο αριθμός των τυπικών με τις πραγματικές παραμέτρους είναι σωστή από κάθε άποψη. Αυτό που δεν είναι σωστό είναι ο τρόπος μεταβίβασης παραμέτρων που έχει υιοθετήσει το βιβλίο.
  Σύμφωνα με το βιβλίο ο παρακάτω κώδικας δεν πληρεί το κριτήριο της καθοριστικότητας αφού δεν ξέρεις ποια τιμή θα επιστραφεί στο a. Δηλαδή η ΓΛΩΣΣΑ του βιβλίου παράγει κώδικα ο οποίος παραβιάζει κάποιο αλγοριθμικό κριτήριο το οποίο είναι αδιανόητο για σχολικό βιβλίο και ειδικά πανελλαδικού μαθήματος.

Είναι αποδεκτή η παρακάτω κλήση ;

a <-- 10
ΚΑΛΕΣΕ ambiguous(a, a, result)

Γιατί να μην είναι ;

a <-- 10
b<-- a
 ΚΑΛΕΣΕ ambiguous(a, b, result)

[gpapargi]

Το παράδειγμά σου evry δείχνει όντως κάτι σωστό και ενδιαφέρον, αλλά είναι τραβηγμένο στα άκρα.

Στην πράξη δεν έχει νόημα να βάλεις 2 φορές την ίδια παράμετρο σε υποπρόγραμμα αφού και μια φορά αν τη βάλεις η πληροφορία μπαίνει μέσα. Επίσης και μια φορά να τη βάλεις πάλι η πληροφορία βγαίνει έξω. Δηλαδή πρέπει να θέλεις να δημιουργήσεις πρόβλημα για να τη βάλεις 2 φορές, όπως ακριβώς έκανες εσύ (και σωστά) αφού ήθελες να καταδείξεις αυτό το αδύνατο σημείο της ΓΛΩΣΣΑΣ.

Αν πέσει τέτοιο θέμα στις εξετάσεις θα πέσει αλύπητο ξύλο. :-)

Στο ζήτημα των καθολικών μεταβλητών, οι συγγραφείς  υποθέτω ότι ήθελαν πάση θυσία να τις αποφύγουν για να ωθήσουν το μαθητή στην ανεξαρτησία προγράμματος και υποπρογραμμάτων και άρα στο δομημένο προγραμματισμό. Αν επέτρεπαν καθολικές μεταβλητές είμαι σχεδόν βέβαιος ότι μεγάλη μερίδα μαθητών και καθηγητών θα λέγανε «Ας τα κάνουμε όλα με καθολικές μεταβλητές». Εδώ το κάνουν τώρα (δηλαδή επιλέγουν την κακή λύση που απλώς τρέχει) σε άλλα ζητήματα πολύ πιο ξεκάθαρα. Εκεί θα κωλώνανε;

Το ζήτημα των 2 ειδών παραμέτρων με βρίσκει σύμφωνο. Αλλά θα δυσκόλευε το μάθημα και μάλιστα σε ένα ζήτημα κυρίως υλοποίησης και όχι τόσο αλγοριθμικό. Δηλαδή θα δυσκόλευε σε ένα θέμα που δεν είναι και τόσο πολύ ο κύριος σκοπός του μαθήματος.  Σηκώνει κουβέντα αυτό το θέμα.

[evry]

Από τη στιγμή που θέλεις να εισάγεις τους μαθητές στα υποπρογράμματα είσαι υποχρεωμένος να το κάνεις σωστά. Οπότε θα πρέπει να κάνεις επιλογές που είναι και επιστημονικές αλλά και εκπαιδευτικές. Αυτό πιστεύω ότι είχε ο Wirth στο νου του όταν έκανε την Pascal και επέλεξε τα δυο είδη παραμέτρων.
   Και στο κάτω κάτω λέμε στα παιδιά ότι έχουμε παραμέτρους εισόδου και εξόδου. Καλό θα ήταν να φαινόταν και αυτό στη δήλωση του υποπρογράμματος. Αν θυμάμαι καλά στην Ada γράφεις f(in x, out y, in out z).
Εμείς θα μπορούσαμε να γράψουμε f(ΕΙΣΟΔΟΣ x, ΕΞΟΔΟΣ y) σαν μια πρώτη ιδέα

Υ.Γ. Πράγματι το παράδειγμα ήταν ακραίο :-), αλλά στα ακραία παραδείγματα αναζητάς πάντα τις αδυναμίες των προγραμμάτων.

Το ζήτημα των 2 ειδών παραμέτρων με βρίσκει σύμφωνο. Αλλά θα δυσκόλευε το μάθημα και μάλιστα σε ένα ζήτημα κυρίως υλοποίησης και όχι τόσο αλγοριθμικό. Δηλαδή θα δυσκόλευε σε ένα θέμα που δεν είναι και τόσο πολύ ο κύριος σκοπός του μαθήματος. Σηκώνει κουβέντα αυτό το θέμα.

[gpapargi]

Για να είμαι ειλικρινής δε μου πολυαρέσει ο διαχωρισμός που γίνεται σε πέρασμα παραμέτρων κατά τιμή και κατά αναφορά. Προτιμώ το να λέμε ότι στη μια περίπτωση περνάμε σαν παράμετρο το περιεχόμενο μιας μεταβλητής ενώ στην άλλη περνάμε σαν παράμετρο τη θέση μνήμης της. Έτσι γίνεται κατανοητό γιατί στη μια περίπτωση δε διατηρείται η τιμή εκτός συνάρτησης ενώ στην άλλη διατηρείται. Τέλος πάντων αυτά είναι προσωπικές μου ανησυχίες :- )

Οι 2 τρόποι είναι αναγκαίοι στα υποπρογράμματα. Η μόνη μου επιφύλαξη είναι αν θα γίνουν κατανοητοί. Εδώ πασχίζω να εξηγήσω γιατί θα πρέπει να μετράει η ποιότητα του αλγορίθμου και δεν ξέρω αν και πόσους έχω πείσει.

Το παράδειγμα καλώς ήταν ακραίο. Όταν θέλεις να δείξεις μια αντίφαση βρίσκεις ένα αντιπαράδειγμα. Είναι η μέθοδος της εις άτοπον απαγωγής. Ένα αντιπαράδειγμα είναι αρκετό.