Projektowanie składni - po co używać nawiasów, gdy nie są przekazywane żadne argumenty?

W wielu językach function_name(arg1, arg2, ...)do wywołania funkcji służy składnia . Kiedy chcemy wywołać funkcję bez żadnych argumentów, musimy to zrobić function_name().

Dziwne wydaje mi się, że kompilator lub interpreter skryptów wymagałby ()skutecznego wykrycia go jako wywołania funkcji. Jeśli wiadomo, że zmienna jest wywoływalna, dlaczego nie function_name;wystarczy?

Z drugiej strony w niektórych językach możemy zrobić: function_name 'test';a nawet function_name 'first' 'second';wywołać funkcję lub polecenie.

Myślę, że nawiasy byłyby lepsze, gdyby były potrzebne tylko do określenia kolejności priorytetów, a w innych miejscach byłyby opcjonalne. Na przykład wykonywanie if expression == true function_name;powinno być tak samo ważne jak if (expression == true) function_name();.

Moim zdaniem najbardziej irytujące jest to, że 'SOME_STRING'.toLowerCase()funkcja prototypowa wyraźnie nie potrzebuje żadnych argumentów. Dlaczego projektanci zdecydowali się na prostsze 'SOME_STRING'.lower?

Oświadczenie: Nie zrozum mnie źle, uwielbiam składnię podobną do C! ;) Po prostu pytam, czy mogłoby być lepiej. Czy wymaganie ()ma jakieś zalety wydajnościowe, czy też ułatwia zrozumienie kodu? Jestem naprawdę ciekawy, jaki jest dokładnie powód.

W przypadku języków korzystających z funkcji pierwszej klasy dość często składnia odwoływania się do funkcji jest następująca:

a = object.functionName

podczas gdy akt wywołania tej funkcji to:

b = object.functionName()

aw powyższym przykładzie byłoby odwołanie do powyższej funkcji (i można ją wywołać wykonując a()), podczas gdy bzawierałoby wartość zwracaną funkcji.

Podczas gdy niektóre języki mogą wykonywać wywołania funkcji bez nawiasów, może być mylące, czy wywołują funkcję, czy po prostu odnoszą się do funkcji.

Rzeczywiście, Scala pozwala na to, chociaż obowiązuje konwencja: jeśli metoda ma skutki uboczne, i tak należy użyć nawiasów.

Jako autor kompilatora uważam, że gwarantowana obecność nawiasów jest całkiem wygodna; Zawsze wiedziałbym, że jest to wywołanie metody, i nie musiałbym budować rozwidlenia dla nieparzystego przypadku.

Jako programista i czytnik kodów obecność nawiasów nie pozostawia wątpliwości, że jest to wywołanie metody, mimo że nie są przekazywane żadne parametry.

Przekazywanie parametrów nie jest jedyną cechą charakterystyczną wywołania metody. Dlaczego miałbym traktować metodę bez parametrów inaczej niż metodę, która ma parametry?

To właściwie subtelny przypadek wyboru składni. Będę mówić w językach funkcjonalnych, które są oparte na typowym rachunku lambda.

We wspomnianych językach każda funkcja ma dokładnie jeden argument . To, co często nazywamy „wieloma argumentami”, jest w rzeczywistości pojedynczym parametrem typu produktu. Na przykład funkcja, która porównuje dwie liczby całkowite:

leq : int * int -> bool
leq (a, b) = a <= b

bierze jedną parę liczb całkowitych. Nawiasy nie oznaczają parametrów funkcji; służą do dopasowania argumentu do wzorca . Aby cię przekonać, że to naprawdę jeden argument, zamiast tego możemy użyć funkcji projekcyjnych zamiast dopasowywania wzorca do zdekonstruowania pary:

leq some_pair = some_pair.1 <= some_pair.2

Tak więc nawiasy są wygodą, która pozwala nam dopasować wzór i zaoszczędzić trochę pisania. Nie są wymagane.

Co z funkcją, która rzekomo nie ma argumentów? Taka funkcja faktycznie ma domenę Unit. Pojedynczy element Unitjest zwykle zapisywany jako (), dlatego pojawiają się nawiasy.

say_hi : Unit -> string
say_hi a = "Hi buddy!"

Aby wywołać tę funkcję, musielibyśmy zastosować ją do wartości typu Unit, która musi być (), więc w końcu piszemy say_hi ().

Tak więc naprawdę nie ma czegoś takiego jak lista argumentów!

Na przykład w języku Javascript użycie nazwy metody bez () zwraca samą funkcję bez jej wykonania. W ten sposób możesz na przykład przekazać funkcję jako argument do innej metody.

W Javie wybrano, że identyfikator, po którym następuje () lub (...), oznacza wywołanie metody, podczas gdy identyfikator bez () odnosi się do zmiennej składowej. Może to poprawić czytelność, ponieważ nie masz wątpliwości, czy masz do czynienia z metodą, czy zmienną składową. W rzeczywistości ta sama nazwa może być używana zarówno dla metody, jak i zmiennej składowej, obie będą dostępne z ich odpowiednią składnią.

Składnia jest zgodna z semantyką, więc zacznijmy od semantyki:

Jakie są sposoby korzystania z funkcji lub metody?

Istnieje wiele sposobów:

• można wywoływać funkcję z argumentami lub bez
• funkcję można traktować jako wartość
• funkcja może być częściowo zastosowana (tworząc zamknięcie przyjmujące co najmniej jeden mniej argumentu i zamykające przekazane argumenty)

Posiadanie podobnej składni do różnych zastosowań jest najlepszym sposobem na stworzenie albo dwuznacznego, albo co najmniej mylącego języka (i mamy ich dość).

W językach C i C-podobnych:

• wywoływanie funkcji odbywa się za pomocą nawiasów w celu dołączenia argumentów (może ich nie być) jak w func()
• traktowanie funkcji jako wartości można wykonać, po prostu używając jej nazwy jak w &func(C tworzenie wskaźnika funkcji)
• w niektórych językach masz krótkie składnie do częściowego zastosowania; Java pozwala someVariable::someMethodna przykład (ograniczony do odbiornika metody, ale nadal przydatny)

Zwróć uwagę, że każde użycie ma inną składnię, co pozwala łatwo je rozróżnić.

W języku z efektami ubocznymi IMO naprawdę pomaga rozróżnić (teoretycznie bez skutków ubocznych) odczyt zmiennej

variable

i wywoływanie funkcji, która może powodować działania niepożądane

launch_nukes()

OTOH, jeśli nie ma efektów ubocznych (innych niż te zakodowane w systemie typów), nie ma sensu nawet rozróżniać między odczytem zmiennej a wywołaniem funkcji bez argumentów.

Żadna z pozostałych odpowiedzi nie próbowała odpowiedzieć na pytanie: ile powinno być nadmiarowości przy projektowaniu języka? Ponieważ nawet jeśli potrafisz zaprojektować język, który x = sqrt yustawi x na pierwiastek kwadratowy z y, nie oznacza to, że koniecznie powinieneś.

W języku bez nadmiarowości każda sekwencja znaków oznacza coś, co oznacza, że ​​jeśli popełnisz jeden błąd, nie otrzymasz komunikatu o błędzie, twój program zrobi coś niewłaściwego, co może być czymś zupełnie innym niż to, co robisz zamierzone i bardzo trudne do debugowania. (Jak każdy, kto pracował z wyrażeniami regularnymi, będzie wiedział). Mała nadmiarowość jest dobra, ponieważ umożliwia wykrycie wielu błędów, a im więcej jest nadmiarowości, tym bardziej prawdopodobne jest, że diagnostyka będzie dokładna. Teraz oczywiście możesz posunąć się za daleko (obecnie nikt z nas nie chce pisać w języku COBOL), ale równowaga jest odpowiednia.

Nadmiarowość pomaga również w czytelności, ponieważ jest więcej wskazówek. Angielski bez redundancji byłby bardzo trudny do odczytania, to samo dotyczy języków programowania.

W większości przypadków są to składniowe wybory gramatyki języka. Przydatne jest, aby gramatyka różnych indywidualnych konstruktów była (względnie) jednoznaczna, gdy zostaną wzięte razem. (Jeśli występują niejasności, jak w niektórych deklaracjach w C ++, muszą istnieć określone reguły rozwiązywania problemów.) Kompilator nie ma możliwości zgadywania; wymagane jest przestrzeganie specyfikacji języka.

Visual Basic w różnych formach rozróżnia procedury, które nie zwracają wartości, i funkcje.

Procedury muszą być wywoływane jako instrukcja i nie wymagają parens, tylko argumenty oddzielone przecinkami, jeśli występują. Funkcje muszą być wywoływane jako część wyrażenia i wymagają parens.

Jest to względnie niepotrzebne rozróżnienie, które sprawia, że ​​ręczne refaktoryzacja między tymi dwiema formami jest bardziej bolesne niż musi być.

(Z drugiej strony Visual Basic używa tych samych parens ()o referencje tablicy jak dla wywołań funkcji, więc odniesienia array wyglądać funkcja nazywa. A to ułatwia ręczne refaktoryzacji tablicy do wywołania funkcji! Tak, możemy rozważać inne języki użyć []„s dla odwołań do tablicy, ale dygresję ...)

W językach C i C ++ dostęp do zawartości zmiennych jest uzyskiwany automatycznie przy użyciu ich nazw, a jeśli chcesz odwoływać się do samej zmiennej zamiast jej zawartości, zastosuj &operator jednoargumentowy .

Ten rodzaj mechanizmu można również zastosować do nazw funkcji. Surowa nazwa funkcji mogłaby oznaczać wywołanie funkcji, podczas gdy &do określenia funkcji (samej) jako danych użyto by jednego operatora. Osobiście podoba mi się pomysł dostępu do pozbawionych argumentów funkcji ubocznych bez efektów o takiej samej składni jak zmienne.

Jest to całkowicie prawdopodobne (podobnie jak inne wybory składniowe).

Spójność i czytelność.

Gdybym dowiedział się, że pan wywołać funkcję Xtak: X(arg1, arg2, ...), a potem oczekiwać, że działają w ten sam sposób przez nie argumenty X().

Teraz uczę się, że możesz zdefiniować zmienną jako jakiś symbol i używać jej w następujący sposób:

a = 5
b = a
...

Co ja bym pomyślał, kiedy to znajdę?

c = X

Twoje domysły są równie dobre jak moje. W normalnych okolicznościach Xjest to zmienna. Ale gdybyśmy podążyli twoją ścieżką, mogłaby to również być funkcja! Czy muszę pamiętać, czy który symbol odwzorowuje na którą grupę (zmienne / funkcje)?

Możemy nałożyć sztuczne ograniczenia, np. „Funkcje zaczynają się od dużej litery. Zmienne zaczynają się od małej litery”, ale jest to niepotrzebne i komplikuje sprawy, chociaż czasami może pomóc niektórym celom projektowym.

Uwaga 1: Inne odpowiedzi całkowicie ignorują jeszcze jedną rzecz: język może pozwalać na używanie tej samej nazwy zarówno dla funkcji, jak i zmiennej, i rozróżnianie według kontekstu. Zobacz Common Lispjako przykład. Funkcja xi zmienne xwspółistnieją doskonale.

Side-Note 2: zaakceptowane odpowiedź pokazuje nam składnię: object.functionname. Po pierwsze, nie jest uniwersalny dla języków z pierwszorzędnymi funkcjami. Po drugie, jako programista traktowałbym to jako dodatkową informację: functionnamenależy do object. To, czy objectjest obiektem, klasą czy przestrzenią nazw, nie ma większego znaczenia, ale mówi mi, że gdzieś należy . Oznacza to, że musisz albo dodać sztuczną składnię object.dla każdej funkcji globalnej, albo utworzyć ją, objectby zawierała wszystkie funkcje globalne.

W obu przypadkach tracisz możliwość posiadania oddzielnych przestrzeni nazw dla funkcji i zmiennych.

Aby dodać do innych odpowiedzi, weź przykład C:

void *func_factory(void)
{
        return 0;
}

void *(*ff)(void);

void example()
{
        ff = func_factory;
        ff = func_factory();
}

Gdyby operator wywołania był opcjonalny, nie byłoby sposobu na odróżnienie przypisania funkcji od wywołania funkcji.

Jest to tym bardziej problematyczne w językach, w których nie ma systemu typów, np. JavaScript, gdzie wnioskowania o typie nie można użyć do ustalenia, co jest, a co nie jest funkcją.