Wygląda na to, że w świętych wojnach językowych ludzie nieustannie oczerniają wszelkie cechy, które nie są dla nich szczególnie przydatne, jako „tylko cukier syntaktyczny”. W tych debatach granica między „prawdziwymi cechami” a „cukrem syntaktycznym” zaciera się. Jak myślisz, jaka jest rozsądna i jednoznaczna definicja cukru syntaktycznego, który pozwala uniknąć zdefiniowania go jako jakiejkolwiek funkcji, która według mówcy / pisarza nie jest przydatna?
Odpowiedzi:
Co powiesz na to: „cukier syntaktyczny jest wygodą dla niektórych funkcji, które nie wprowadzają żadnej znaczącej warstwy abstrakcji”.
Weź a->b, co, jak wskazałeś, jest równoważne (*a).b. Czy ta notacja pozwala rozpatrywać kod w jakiś użyteczny, w inny sposób ukryty sposób? Nie, więc to cukier syntaktyczny.
Teraz zastanów się a[i] == *(a + i). Pomyśl o dowolnym programie C, który używa tablic w jakikolwiek istotny sposób. Czy potrafisz sobie wyobrazić próbę zrozumienia tego bez []zapisu? Z tablicami wielowymiarowymi? Rozważanie tablic jako całych jednostek ma sens, a nie odniesienie do początku ciągłego bloku pamięci. Chociaż pomaga wiedzieć, jak działają tablice w C, jeśli planujesz robić z nimi skomplikowane rzeczy, to nieproduktywne jest zawsze myśleć: „Muszę przechowywać dwa bity pamięci 2 * i bajtów po prawej stronie lokalizacja pamięci, do której odnosi się a. ” Istotą tablicy jest zdolność do wyodrębnienia procesu przechowywania sekwencji jako spójnej jednostki. []Notacja ułatwia tę abstrakcję. To nie jest cukier składniowy.
Nie oznacza to, że cukier składniowy jest zawsze złą rzeczą. Podobnie jak wiele aliteracji, stał się epitetem i przeciwstawiał się „prawdziwym cechom”. Ale LISP i Schemat, na przykład, byłyby nieczytelne, gdyby nie letstenografia (i inne).
Operator trójskładnikowy <pred> ? <cnsq> : <alt>jest kolejnym przykładem. Cukier syntaktyczny może pomóc w organizowaniu programów i usuwaniu zbędnego kodu, co może zaoszczędzić na konserwacji w dół linii. Cukier syntaktyczny może być czasem lepszy niż gromadzenie „rzeczywistych funkcji”, jeśli pomaga usunąć bariery składniowe w programowaniu.
Cytując R ^ 5RS , „Języki programowania powinny być zaprojektowane nie przez umieszczanie funkcji na wierzchu funkcji, ale przez usuwanie słabości i ograniczeń, które sprawiają, że dodatkowe funkcje wydają się konieczne”. IMHO, składnia może być uznana za słabość i ograniczenie, a więc pozwolenie programistom na uniknięcie składni może zwiększyć ekspresję języka.
IMHO Nie sądzę, że można mieć definicję cukru syntaktycznego, ponieważ wyrażenie to jest BS i prawdopodobnie będzie używane przez osoby, które mówią o „prawdziwych programistach” używających „prawdziwych narzędzi” w „prawdziwych systemach operacyjnych”
Jego BS, ponieważ pojęcie „prawdziwych cech” lub „cukru syntaktycznego” jest podobne do błędu No true Scotsman . W ten sposób wyrażenia są „doraźnymi próbami zachowania nieuzasadnionego twierdzenia”. Twierdzenie tutaj jest takie, że funkcja tutaj jest trywialna, ponieważ zamiast tego można użyć „prawdziwej funkcji”.
Jej BS bo niektórzy twierdzą, stosowanie cukru należy unikać , ponieważ można napisać błąd, ale należy trzymać się go , ponieważ jej trudniej błędów zapisu. Czy to nie jest niesamowite. Ta sama fraza prowadzi do dokładnie przeciwnych wniosków przy użyciu tej samej logiki.
Jego BS, ponieważ nikt nie powołuje się na badania użyteczności lub badania liczby defektów, aby poprzeć argumenty dotyczące ich czytelności lub konserwacji lub prawdopodobnych wad.
Jego BS, ponieważ ludzie często mylą się lub mylą się co do równoważności. Na przykład to pytanie potwierdza, że łańcuch C # jest cukrem dla tablicy char. Nie są .
Jeśli jednak chcesz powiedzieć, że dwie rzeczy są cukrem, jeśli są semantycznie równoważne, to pomaga iść dalej i zdefiniować to tak, jak chcesz.
Jeśli chcesz kogoś lekceważyć, możesz również użyć wyrażenia.
Oto bardzo rygorystyczna definicja pokrewnego pojęcia: ekspresja , autor:
Matthias Felleisen:
O ekspresyjnej sile programowania języków [Postscript był jedyną wolną formą, jaką mogłem znaleźć.]
Zobacz także ten wpis dotyczący języka Java i zamknięć .
W rzeczywistości coś jest cukrem syntaktycznym, jeśli można go zmienić na postać bez składni, wprowadzając tylko lokalne zmiany. Jeśli na przykład bez formy składniowej trzeba zmienić kilka różnych lokalizacji kodu lub przenieść fragmenty do innych lokalizacji, to nie jest to cukier.
To powiedziawszy, cukier syntaktyczny jest w porządku, gdy jest właściwie stosowany. Myślę, że każdy programista Scheme wolałby istnieć letspecjalną formę niż tworzyć nową anonimową funkcję, a następnie zastosować ją, co zrobiłoby to samo. Celem jest zwiększenie przejrzystości kodu.
Myślę, że termin cukier składniowy wskazuje na alternatywną składnię wyrażającą tę samą podstawową semantykę.
Weźmy na przykład język programowania A, który ma operację, sumktóra może dodać listę liczb całkowitych o dowolnej długości. W tym języku możemy pisać wyrażenia
sum []
sum [3, 4, 5, 1]
sum [2, 7]
których wyniki wynoszą odpowiednio 0, 13 i 9.
Załóżmy teraz, że zdajemy sobie sprawę, że 90% razy używamy sumz dwoma argumentami i dlatego wprowadzamy dla wygody nową notację
2 + 7
który jest po prostu cukier syntaktyczny dla sum [2, 7].
Teraz weź drugi język B, który nie ma żadnej operacji dodawania. Możemy mieć operatorów takich jak <, =co pozwala nam porównywać liczby, ale nie ma możliwości dodawania liczb. W wersji 2 języka B wprowadzamy nową operację dodawania ze składnią
2 + 7
co dodaje liczby jak zwykle.
W kontekście języka A +notacja jest cukrem syntaktycznym (jest to alternatywna, uproszczona i ad hoc notacja, której można użyć zamiast sum [...]notacji). Podobnie, jak wskazano w odpowiedzi Hoa Long Tam, w C notacja p->fieldjest cukrem syntaktycznym (*p).field.
W kontekście języka B +notacja nie jest cukrem składniowym (jest to jedyna poprawna składnia używana do operacji sumowania). Podobnie, gdyby C mógł uzyskać dostęp do elementów strukturalnych tylko za pomocą wskaźników i gdyby nie miał notacji (*p).field, notacja p->fieldnie byłaby cukrem syntaktycznym.
Moim zdaniem istnieją pewne nieporozumienia dotyczące cukru syntaktycznego, które można prześledzić w zamieszaniu dotyczącym semantyki języka programowania. Rozumowanie wygląda następująco:
Powyższa linia rozumowania prowadzi do ogólnych stwierdzeń, takich jak: „cukier syntaktyczny nie może być właściwie zdefiniowany”, jest to „kwestia gustu” lub „każda cecha języka programowania jest przecież tylko cukrem syntaktycznym”.
Myślę, że głównym problemem w powyższym argumencie jest to, że semantyka dotyczy nie tylko tego, co może być obliczone przez program, ale także tego, w jaki sposób jest on obliczany , tj. Jakie prymitywne konstrukcje są używane i jak są łączone.
Na przykład obiekty nie są cukrem syntaktycznym dla podstawowych konfiguracji bitów i transformacji bitów, są konstrukcją, która pozwala modelować dane i operacje oraz opisywać obliczenia. Obliczanie za pomocą obiektów, metod, wywołań metod nie jest tym samym, co obliczanie za pomocą bajtów, rejestrów procesora, adresów pamięci (nawet jeśli dwa obliczenia mają ten sam wynik, a nawet jeśli drugie obliczenie jest używane do implementacji pierwszego).
Uczyniłem ten opis nieco długim, ale myślę, że jest to ważny aspekt, którego nie widziałem w innych odpowiedziach.
Konkluzja: cukier składniowy jest alternatywną (być może wygodniejszą) składnią dla konstruktu, który jest już w języku i ma już dobrze zdefiniowaną składnię i semantykę. Nowa składnia (cukier składniowy) różni się od istniejącej, ale ma tę samą semantykę . Jeśli wprowadzisz nowy konstrukt w języku i nową składnię, nie będziesz miał cukru syntaktycznego.
cukier syntaktyczny to funkcja, która nie rozszerza samej ekspresji języka, dlatego jest zbędna, a czasem stanowi nadużycie notacji, ale jednocześnie upraszcza życie pisarza i daje czytelnikowi więcej wglądu.
Aby odpowiedzieć na moje pytanie, cechą jest cukier składniowy wtedy i tylko wtedy, gdy uwzględniono go przede wszystkim w celu poprawy estetyki i czytelności i można go w prosty sposób przetłumaczyć w przybliżeniu jeden na jeden w wersji bez cukru. (Przez z grubsza jeden do jednego mam na myśli trywialne rzeczy modulo, takie jak kolejność operacji przemiennych, nazwy zmiennych i białe znaki).
Każda funkcja, która może być pozbawiona cukru tylko przy znacznej ilości dyscypliny programisty, nie jest cukrem syntaktycznym. Jako podzbiór tego, każda funkcja zwiększająca bezpieczeństwo typu nie jest cukrem syntaktycznym, ponieważ ręczne wymuszanie bezpieczeństwa typu za pomocą dyscypliny programisty jest wysoce nietrywialne. Na przykład system obiektowy C ++ to coś więcej niż cukier syntaktyczny na wierzchu polimorfizmu obsadzonego wskaźnikiem C.
Każda funkcja, która wymagałaby znacznego powielenia kodu lub poważnego przeprojektowania, jeśli zostanie usunięta, nie jest cukrem składniowym, ponieważ żadna z nich nie jest trywialnym przedsięwzięciem. Na przykład szablony to nie tylko cukier składniowy, ponieważ uzyskanie równoważnej funkcjonalności bez nich wymagałoby ton klonowania i modyfikacji.
Przykład rzeczy, które są cukrem syntaktycznym:
a[i] zamiast *(a + i)
a -> b zamiast (*a).b
foreach składnia zamiast ręcznego wpisywania składni iteratora.
Całe przeciążenie operatora to czysty cukier składniowy.
Czy to brzmi jak uczciwa i dość jednoznaczna definicja?
„Cukier syntaktyczny” nie jest terminem ściśle zdefiniowanym. W zależności od tego, kogo zapytasz, najprawdopodobniej otrzymasz jedną z następujących definicji:
Nie jestem pewien co do dziedzin informatyki, ale w dziedzinie logiki istnieją koncepcje konserwatywności i możliwości eliminacji definicji [ 1 ], które wydają się być w tym samym duchu.
Stosując korespondencję Curry-Howarda, można by wymyślić równoległą koncepcję dotyczącą „cukru syntaktycznego”.