2014-04-02 36 views
12
function A: Boolean; 
function B: Boolean; 

I (przypadkowo) napisał:Dlaczego wyrażenie boolowskie (z efektami ubocznymi) nie jest wystarczające jako instrukcja?

A or B; 

Zamiast tego:

if not A then 
    B; 

Kompilator odrzuca pierwszą formę, jestem ciekawy, dlaczego?

Z oceną zwarcia oboje zrobiliby to samo, czyż nie?

Wyjaśnienie: Zastanawiam się, dlaczego ten język nie został zaprojektowany, aby umożliwić wyrażenie mojej wypowiedzi jako oświadczenie.

+0

Właściwie cieszę się, że nie jest to dozwolone, ponieważ nie jest ono w ogóle czytelne. Ale ciekawe pytanie. – jpfollenius

+1

Ponieważ Delphi nie jest jeszcze fraktalem PHP. –

Odpowiedz

5

Po prostu, ponieważ kompilator oczekuje wartości statement, a podane wyrażenie nie jest instrukcją.

Skonsultuj się z documentation, a znajdziesz listę prawidłowych wyciągów. Twoje wyrażenie nie może znaleźć się na tej liście.

Zapytałeś w komentarzach (teraz usunięto), dlaczego projektanci języków, którzy nie zdecydowali się na takie wyrażenie, liczą się jako oświadczenie. Ale to pytanie implikuje cel, w którym być może nie było. Jest całkiem prawdopodobne, że projektanci nie zdecydowali się tego nie robić. Raczej nigdy nie rozważają zrobienia tego w pierwszej kolejności. Języki są zazwyczaj zaprojektowane w celu rozwiązania konkretnych problemów. Jest całkowicie prawdopodobne, że projektanci po prostu nigdy nie uważali traktowania takich wyrażeń za wypowiedzi.

5

Pierwsza forma jest wyrażeniem, które ma wartość Boolean, a nie instrukcją.

9

Pierwszy to wyrażenie. Wyrażenia są oceniane. Wyrażenia nie mają widocznych efektów ubocznych (jak odczyt lub zapis zmiennej). Oba operandy wyrażenia są funkcjami, które mogą mieć efekty uboczne, ale aby uzyskać efekty uboczne, należy wykonać instrukcję.

Drugim jest oświadczenie. Porównuje wynik wyrażenia i na podstawie oceny wywołuje inną funkcję.

Częścią mylącą jest to, że w tym przypadku Delphi pozwala nam zignorować wynik funkcji i wykonać ją jako funkcję. Więc oczekujesz tego samego dla A or B. Ale to nie jest dozwolone. Co jest świetne, ponieważ zachowanie jest niejednoznaczne. Na przykład, jeśli masz włączoną leniwą ocenę. A A ocenia się jako prawda, czy B nazywa się tak lub nie.

+2

Warto podkreślić, że można tak samo skonstruować poprawne stwierdzenie, że będzie również niejednoznacznie wykonywać 'B' w zależności od leniwej oceny. 'if (A lub B) następnie ...' itd. –

+0

"Wyrażenia nie mają widocznych efektów ubocznych (jak odczyt lub zapis zmiennej)." Zapisanie zmiennej * jest * widocznym efektem ubocznym! Nie wspominając o tym, że wywołania funkcji są również wyrażeniami, które mogą oczywiście mieć skutki uboczne. – munificent

2

W sercu Delphi to Pascal. Język Pascal został zaprojektowany przez Nicklausa Wirtha i opublikowany w 1968 roku. Mój egzemplarz podręcznika użytkownika i raportu pochodzi z 1978 roku. Został zaprojektowany z myślą o dwóch celachach, jako język nauczania i jako taki, który był łatwy do wdrożenia na dowolnej maszynie. . W tym był spektakularnie udany.

Wirth doskonale znał inne języki tego czasu (w tym Fortran, Cobol, a zwłaszcza Algol) i dokonał szeregu ostrożnych wyborów, mając na uwadze konkretne cele. W szczególności ostrożnie oddzielił pojęcie "działań" od "wartości". "Działania" w języku Pascal są instrukcjami w języku, w tym wywołaniem procedury. "Wartości" obejmują wywołania funkcji. W tym i kilku innych aspektach język jest dość podobny do Algola.

Składnia deklarowania i używania akcji i wartości jest uważnie przechowywana osobno.Język i biblioteki dostarczone z nim nie generalnie mają "skutki uboczne" jako takie. Procedury, w których rzeczy i wyrażenia obliczają wartości. Na przykład "odczyt" jest procedurą, a nie funkcją, ponieważ pobiera wartość i przesuwa się przez plik, ale funkcja "eof" jest funkcją.

Mascalowa wersja Pascala została stworzona przez firmę Borland w połowie lat osiemdziesiątych ubiegłego stulecia i kolejno przekształcana w Turbo Pascal dla Windows, a następnie Delphi. Język bardzo się zmienił i nie wszystko jest tak czyste, jak to zaprojektował Wirth. To jedna z funkcji, która przetrwała.

Nawiasem mówiąc, Pascal nie miał oceny zwarcia. Miał pamięć sterty i zestawy, ale żadnych obiektów. Przybyli później.