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 let
stenografia (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.
Oto bardzo rygorystyczna definicja pokrewnego pojęcia: ekspresja , autor:
Matthias Felleisen:
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ć
let
specjalną formę niż tworzyć nową anonimową funkcję, a następnie zastosować ją, co zrobiłoby to samo. Celem jest zwiększenie przejrzystości kodu.źródło
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ę,
sum
która może dodać listę liczb całkowitych o dowolnej długości. W tym języku możemy pisać wyrażeniaktórych wyniki wynoszą odpowiednio 0, 13 i 9.
Załóżmy teraz, że zdajemy sobie sprawę, że 90% razy używamy
sum
z dwoma argumentami i dlatego wprowadzamy dla wygody nową notację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ą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ć zamiastsum [...]
notacji). Podobnie, jak wskazano w odpowiedzi Hoa Long Tam, w C notacjap->field
jest 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
, notacjap->field
nie 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.
źródło
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.
źródło
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?
źródło
„Cukier syntaktyczny” nie jest terminem ściśle zdefiniowanym. W zależności od tego, kogo zapytasz, najprawdopodobniej otrzymasz jedną z następujących definicji:
źródło
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”.
źródło