Здравствуйте, ecinunice, Вы писали:

E>Сводится ли частичное применение к синтаксическому сахару или есть другие приемущества? Если другие приемущества есть — можно привести пример?

Может мне кто-нибудь объяснить, что такое "синтаксический сахар"? По-моему, это одно из самых идиотических понятий во всем IT.

Синтаксическим сахаром, строго говоря, является ВСЕ, кроме команд ассемблера. Все конструкции всех языков высокого уровня легко и непринужденно укладываются в машинные коды.

Здравствуйте, mrozov, Вы писали:

M>Синтаксическим сахаром, строго говоря, является ВСЕ, кроме команд ассемблера. Все конструкции всех языков высокого уровня легко и непринужденно укладываются в машинные коды.

Вопрос в уровнях абстракции. Уложи в машинные коды

SELECT * FROM Employee

Здравствуйте, deniok, Вы писали:

D>Здравствуйте, mrozov, Вы писали:

M>>Синтаксическим сахаром, строго говоря, является ВСЕ, кроме команд ассемблера. Все конструкции всех языков высокого уровня легко и непринужденно укладываются в машинные коды.

D>Вопрос в уровнях абстракции.
А определение понятию "уровень абстракции" можно?

D>Уложи в машинные коды
D>

D>SELECT * FROM Employee
D>

D>

В машинные коды влом, а в с# — легко.
Select("Emploee", null);

Фигня это все. Иной "синтаксический сахар" экономит куда больше времени, чем все "уровни абстракции" вместе взятые. Совершенно пустая тема.

Здравствуйте, mrozov, Вы писали:

M>В машинные коды влом, а в с# — легко.
M>Select("Emploee", null);

Дело не во влом. В зависимости от техники доступа к данным тут могут быть сильно разные машинные коды. Фактически эта программа никаких конкретных машинных кодов не специфицирует

Здравствуйте, deniok, Вы писали:

D>Здравствуйте, mrozov, Вы писали:

M>>В машинные коды влом, а в с# — легко.
M>>Select("Emploee", null);

D>Дело не во влом. В зависимости от техники доступа к данным тут могут быть сильно разные машинные коды. Фактически эта программа никаких конкретных машинных кодов не специфицирует

А select * from Emploee, значит, сам по себе эдакий удалец, да? Да нифига — к нему интерпритатор нужен. А тут вопрос к имплементации функции Select — которая первым параметром принимает название таблицы и список наименований столбцов. Нету разницы.

Вот возьми язык запросов в c#. Это — синтаксический сахар к просто вызовам методов, принимающих в качестве параметра анонимные функции. А анонимные функции — синтаксический сахар для просто функций. А просто функции — синтаксический сахар к push->call->pop. А call — синаксический сахар к push->jmp, насколько я помню.

Пустая тема.

Здравствуйте, mrozov, Вы писали:

M>Вот возьми язык запросов в c#. Это — синтаксический сахар к просто вызовам методов, принимающих в качестве параметра анонимные функции.

Это не доказывает, что "SELECT" всегда и везде является синтаксическим сахаром. Вот возьмём реляционную БД — "SELECT" является синтаксическим сахаром к чему?

M>А анонимные функции — синтаксический сахар для просто функций.

Чиво?

M> А просто функции — синтаксический сахар к push->call->pop. А call — синаксический сахар к push->jmp, насколько я помню.

И тут Остапа понесло...

Вызов функции в паскале не может быть синтаксическим сахаром к "push->call->pop" потому что на уровне паскаля никакого push и никакого pop не существует.

Здравствуйте, mrozov, Вы писали:
M>Может мне кто-нибудь объяснить, что такое "синтаксический сахар"? По-моему, это одно из самых идиотических понятий во всем IT.
Могу. Синтаксический сахар — это возможность выразить в компактном виде то, что и так есть в языке.
Например, using(...) и foreach() являются чистым сахаром, поскольку для них существует полный аналог в развернутом виде.
А генерики сахаром не являются, т.к. их нельзя превратить в аналогичный не-генерик код.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, mrozov, Вы писали:
M>>Может мне кто-нибудь объяснить, что такое "синтаксический сахар"? По-моему, это одно из самых идиотических понятий во всем IT.
S>Могу. Синтаксический сахар — это возможность выразить в компактном виде то, что и так есть в языке.
Иными словами, в языке, который поддерживает ассемблерные вставки, синтаксическим сахаром является весь язык целиком, правильно?

S>Например, using(...) и foreach() являются чистым сахаром, поскольку для них существует полный аналог в развернутом виде.
S>А генерики сахаром не являются, т.к. их нельзя превратить в аналогичный не-генерик код.

Разве? Это просто сахар для того, чтобы не написать один код несколько раз. Или сахар для того, чтобы не приводить типы.

Здравствуйте, mrozov, Вы писали:

M>Разве? Это просто сахар для того, чтобы не написать один код несколько раз. Или сахар для того, чтобы не приводить типы.

Нет, это не сахар. Это новый уровень абстракции.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, mrozov, Вы писали:

M>>Вот возьми язык запросов в c#. Это — синтаксический сахар к просто вызовам методов, принимающих в качестве параметра анонимные функции.

ANS>Это не доказывает, что "SELECT" всегда и везде является синтаксическим сахаром. Вот возьмём реляционную БД — "SELECT" является синтаксическим сахаром к чему?
К вызову функции с именем Select и списком параметров. См. DLinq.

M>>А анонимные функции — синтаксический сахар для просто функций.
ANS>Чиво?
Таго. Зачем тебе анонимные функции вообще? Напиши НЕ анонимную и используй ее.

M>> А просто функции — синтаксический сахар к push->call->pop. А call — синаксический сахар к push->jmp, насколько я помню.
ANS>И тут Остапа понесло...
Понесло того, который первым ввел понятие "синтаксический сахар". Ну или того, кто придал этому понятию формальное значение, вместо того, чтобы отнестись к нему как к обычному качественному описанию (типа красиво, стильно и т.п.)

ANS>Вызов функции в паскале не может быть синтаксическим сахаром к "push->call->pop" потому что на уровне паскаля никакого push и никакого pop не существует.
Учи албанский! Есть такое понятие — ассемблерная вставка.


Я все это говорю к тому, что в программировании все, что стоит уровнем выше машинных кодов, существует только для удобства и не предоставляет никаких дополнительных возможностей. Это легко доказать — самый навороченный ООП-код на самом навороченном языке в конечном итоге превращается в asm.

Мораль — ничего важнее, чем синтаксический сахар, в программировании нет. А потому и обсуждать эту тему бессмысленно.

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, mrozov, Вы писали:

M>>Разве? Это просто сахар для того, чтобы не написать один код несколько раз. Или сахар для того, чтобы не приводить типы.

N>Нет, это не сахар. Это новый уровень абстракции.

Что такое "уровень абстракции"? Почему ты считаешь, что foreach вместо while или while вместо jmp это не новый уровень абстракции?

Для меня разница тут количественная, но не качественная. И то и другое позволяет мне взглянуть на задачу под другим углом. Что-то дает больше, что-то меньше. Что-то меняет код сильнее, что-то слабее.

Здравствуйте, mrozov, Вы писали:

M>Синтаксическим сахаром, строго говоря, является ВСЕ, кроме команд ассемблера. Все конструкции всех языков высокого уровня легко и непринужденно укладываются в машинные коды.

Ты еще скажи, что машинные коды — это синтаксический сахар для систем уравнений, описывающих напряжения и токи в микропроцессорах, которые в свою очередь являются синтаксическим сахаром для уравнений Максвелла.

Как тогда объяснить тот факт, что человек, не знающий уравнений Максвелла, может писать сложные SQL-запросы?

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, mrozov, Вы писали:

M>>Синтаксическим сахаром, строго говоря, является ВСЕ, кроме команд ассемблера. Все конструкции всех языков высокого уровня легко и непринужденно укладываются в машинные коды.

N>Ты еще скажи, что машинные коды — это синтаксический сахар для систем уравнений, описывающих напряжения и токи в микропроцессорах, которые в свою очередь являются синтаксическим сахаром для уравнений Максвелла.

Которые, возможно, являются синтаксическим сахором для Исключительно Простой Теории Всего

Здравствуйте, mrozov, Вы писали:

M>Здравствуйте, Sinclair, Вы писали:

S>>Здравствуйте, mrozov, Вы писали:
M>>>Может мне кто-нибудь объяснить, что такое "синтаксический сахар"? По-моему, это одно из самых идиотических понятий во всем IT.
S>>Могу. Синтаксический сахар — это возможность выразить в компактном виде то, что и так есть в языке.
M>Иными словами, в языке, который поддерживает ассемблерные вставки, синтаксическим сахаром является весь язык целиком, правильно?
Как правило, нет. Редкий язык позволяет делать ассемблерные вставки настолько органичным образом, чтобы можно было выражать на них целые конструкции языка. Попробуй, к примеру, выразить try/catch на ассемблерной вставке.
M>Разве? Это просто сахар для того, чтобы не написать один код несколько раз. Или сахар для того, чтобы не приводить типы.
В том-то и дело, что результатом работы генерика является не просто "код, который не надо писать много раз". Чистый синтаксический сахар обычно действует локально, и не затрагивает структуру программы.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, mrozov, Вы писали:

M>>Разве? Это просто сахар для того, чтобы не написать один код несколько раз. Или сахар для того, чтобы не приводить типы.
S>В том-то и дело, что результатом работы генерика является не просто "код, который не надо писать много раз". Чистый синтаксический сахар обычно действует локально, и не затрагивает структуру программы.

По-моему тут как раз имеется разница между тактическим и стратегическим дизайном

Автор: Курилка
Дата: 23.11.07

Здравствуйте, Sinclair, Вы писали:

S>А генерики сахаром не являются, т.к. их нельзя превратить в аналогичный не-генерик код.
В принципе, генерики тоже сахар (скажем, на 90%): они могут быть развернуты так, как это сделали в Java — тупая реализация на основе постоянного кастинга, то есть виртуальная машина ничего не знает о генериках, знает только компилятор.

Здравствуйте, mrozov, Вы писали:

ANS>>Это не доказывает, что "SELECT" всегда и везде является синтаксическим сахаром. Вот возьмём реляционную БД — "SELECT" является синтаксическим сахаром к чему?
M>К вызову функции с именем Select и списком параметров. См. DLinq.

Уууу! Откуда в реляционной алгебре Dlinq?

ANS>>Вызов функции в паскале не может быть синтаксическим сахаром к "push->call->pop" потому что на уровне паскаля никакого push и никакого pop не существует.
M>Учи албанский! Есть такое понятие — ассемблерная вставка.

Есть такое понятие — пифагоровы штаны. Это доказывает, что всё в мире это синтаксический сахар?

M>Я все это говорю к тому, что в программировании все, что стоит уровнем выше машинных кодов, существует только для удобства и не предоставляет никаких дополнительных возможностей. Это легко доказать — самый навороченный ООП-код на самом навороченном языке в конечном итоге превращается в asm.

Я паскаль привёл потому, что в оригинальном паскале нет goto. Это значит, что цикл в паскале не может быть синтаксическим сахаром к if+goto. Потому что goto там нет. А во что оно превращается внизу — это особенности реализации.

Здравствуйте, rsn81, Вы писали:
R>В принципе, генерики тоже сахар (скажем, на 90%): они могут быть развернуты так, как это сделали в Java — тупая реализация на основе постоянного кастинга, то есть виртуальная машина ничего не знает о генериках, знает только компилятор.
Ну если бы они были сделаны как в жаве, то были бы сахаром. Но они сделаны по-нормальному, потому сахаром не являются.

Здравствуйте, Sinclair, Вы писали:

S>Ну если бы они были сделаны как в жаве, то были бы сахаром. Но они сделаны по-нормальному, потому сахаром не являются.
Под "они сделаны", так понимаю, вы подразумеваете "в .NET они сделаны" — тогда и надо так говорить, то есть конкретно ".NET Generics", а не обобщением обо всех генериках.

Здравствуйте, Sinclair, Вы писали:

M>>Может мне кто-нибудь объяснить, что такое "синтаксический сахар"? По-моему, это одно из самых идиотических понятий во всем IT.
S>Могу. Синтаксический сахар — это возможность выразить в компактном виде то, что и так есть в языке.
S>Например, using(...) и foreach() являются чистым сахаром, поскольку для них существует полный аналог в развернутом виде.
S>А генерики сахаром не являются, т.к. их нельзя превратить в аналогичный не-генерик код.

Я бы сказал по-другому: синтаксический сахар — это синтаксическая поддержка определенного программного (семантического) решения.

Например,
— int? x вместо Nullable<int> x (подразумевает наличие Nullable, хотя то же самое можно реализовать и собственным классом)
— do a; b; c вместо a >>= \_ -> b >>= \_ -> c (подразумевает использование обозначения >>=)
— foreach, потому что рассчитывает на IEnumerable
— using, это синтаксическая поддержка для IDisposable

Это называется синтаксическим сахаром как раз потому, что он поддерживает лишь один конкретный IDisposable, а для реализации освобождения ресурса на собственном механизме синтаксической поддержки уже нет.

Тогда частичное применение из соседней ветки по этому критерию сахаром не является, а является просто фичей синтаксиса языка.

Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, Sinclair, Вы писали:

S>>Ну если бы они были сделаны как в жаве, то были бы сахаром. Но они сделаны по-нормальному, потому сахаром не являются.
R>Под "они сделаны", так понимаю, вы подразумеваете "в .NET они сделаны" — тогда и надо так говорить, то есть конкретно ".NET Generics", а не обобщением обо всех генериках.

Скорее можно говорить, что в Java генерики какие-то недоделанные, т.к. не захотелось Sun-у ломать совместимость с предыдущими версиями JVM. А, например, в Eiffel генерики вовсе не являются тупыми кастами.

Здравствуйте, nikov, Вы писали:

N>Как тогда объяснить тот факт, что человек, не знающий уравнений Максвелла, может писать сложные SQL-запросы?

Так, что синтаксический сахар — это самое важное изобретение в программировании. Которое по-другому также называется абстракцией.

Это вообще — очень простой вопрос. Очевидно, что мнемонические коды для машинных команд есть не более, чем синтаксический сахар. Тем не менее, в мнемокодах програмировать несравненно легче.

Ты мне другое объясни — хорошо, путь формальное определение понятию "синтаксический сахар" вдруг найдется. Я в это не верю, но могу и ошибиться. Однако какое имеет значение — является ли та или иная конструкция этим самым сахаром или нет? Значение имеет — удобна ли она. Т.е. вопрос в том — что это дает программисту, а не то, как это квалифицируется.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, mrozov, Вы писали:

M>>Здравствуйте, Sinclair, Вы писали:

S>>>Здравствуйте, mrozov, Вы писали:
M>>>>Может мне кто-нибудь объяснить, что такое "синтаксический сахар"? По-моему, это одно из самых идиотических понятий во всем IT.
S>>>Могу. Синтаксический сахар — это возможность выразить в компактном виде то, что и так есть в языке.
M>>Иными словами, в языке, который поддерживает ассемблерные вставки, синтаксическим сахаром является весь язык целиком, правильно?
S>Как правило, нет. Редкий язык позволяет делать ассемблерные вставки настолько органичным образом, чтобы можно было выражать на них целые конструкции языка. Попробуй, к примеру, выразить try/catch на ассемблерной вставке.

Это сложно, но вполне возможно. Я бы предпочел увидеть формальное определение, в котором не было бы дыр, через которых я мог бы протащить верблюда.

M>>Разве? Это просто сахар для того, чтобы не написать один код несколько раз. Или сахар для того, чтобы не приводить типы.
S>В том-то и дело, что результатом работы генерика является не просто "код, который не надо писать много раз". Чистый синтаксический сахар обычно действует локально, и не затрагивает структуру программы.

Ну вот и получается, что сахар — это несущественное улучшение. Т.е. все сводится к полезности.
Например — c# и ключевое слово var. Многие его характеризуют, как синтаксический сахар. А между тем, оно избавляет от необходимости определять целый дополнительный класс. И где тут отличие от дженериков?

Брось, комрад. За этим термином не скрывается никакой высшей истины. Это просто эмоциональная оценка, как правило — достаточно личная.

Здравствуйте, mrozov, Вы писали:

M>Т.е. вопрос в том — что это дает программисту, а не то, как это квалифицируется.

Если отталкиваться от того, что плотность ошибок на 1000 строк кода величина практически постоянная и не зависит от языка программирования, то сокрашение количества строк кода ведет к уменьшению общего количества ошибок в программе. Т.е. хочешь делать меньше ошибок -- пиши меньше кода. Синтаксический сахар позволяет писать меньше кода.

В качестве примера синтаксического сахара приводится поддержка ООП в C++.

Object-oriented programming
The C programming language is fully capable of object-oriented programming using its facilities of function pointers, type casting, and structures. However, languages such as C++ make object-oriented programming more convenient by introducing syntax specific to this coding style. Moreover, the specialized syntax works to emphasize the object-oriented approach to new programmers. Features of the C# (C Sharp) programming language, such as properties and interfaces, similarly do not enable new functionality but instead make specific programming practices more prominent and more natural.

А вы мне про шаблоны...

И, кстати, чуть ниже дано определение обратного понятия:

Syntactic salt
The metaphor has been extended by coining the term syntactic salt, a feature designed to make it harder to write bad code. Specifically, syntactic salt is a hoop the programmer must jump through just to prove that he knows what's going on, rather than to express a program action. Some programmers consider required type declarations to be syntactic salt. A requirement to write "end if", "end while", "end do", etc. to terminate the last block controlled by a control construct (as opposed to just "end" or even simpler syntax using braces "}") is widely considered syntactic salt.

Во-во.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, mrozov, Вы писали:

M>>Т.е. вопрос в том — что это дает программисту, а не то, как это квалифицируется.

E>Если отталкиваться от того, что плотность ошибок на 1000 строк кода величина практически постоянная и не зависит от языка программирования, то сокрашение количества строк кода ведет к уменьшению общего количества ошибок в программе.

Категорически не могу согласиться. Были когда-то чемпионаты по написанию программ в одну строчку. Тут не в объеме кода дело, а в выразительной мощности скорее.

E>Т.е. хочешь делать меньше ошибок -- пиши меньше кода. Синтаксический сахар позволяет писать меньше кода.
Но ведь не только сахар позволяет это сделать, верно? Это определение подходит только в том случае, если принять мою максиму о том, что синтаксическим сахаром является все, кроме машинных кодов (и даже некоторые из них). Как ты (вероятно) догадываешься, сам я в нее не верю.

M>В качестве примера синтаксического сахара приводится поддержка ООП в C++.
M>

Object-oriented programming
The C programming language is fully capable of object-oriented programming using its facilities of function pointers, type casting, and structures. However, languages such as C++ make object-oriented programming more convenient by introducing syntax specific to this coding style.

А я не согласен с цитатой. 3 кита ООП — это наследование, полиморфизм и инкапсуляция. Если первые 2 концепции реализуются в С (хоть и с лишней писаниной в случае полиморфизма), то инкапсулящия насколько я понимаю полноценно в C не реализуется. Это именно то что нельзя назвать синтаксическим сахаром — базовая концепция, которую должен поддерживать компилятор.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, mrozov, Вы писали:

ANS>>>Это не доказывает, что "SELECT" всегда и везде является синтаксическим сахаром. Вот возьмём реляционную БД — "SELECT" является синтаксическим сахаром к чему?
M>>К вызову функции с именем Select и списком параметров. См. DLinq.

ANS>Уууу! Откуда в реляционной алгебре Dlinq?

Комрад, давай я попробую медленно и еще раз, может ты вдруг поймешь. Ты откажись на минуточку от концепции, что я дурак, я этим делом уже второй десяток лет занимаюсь, как-никак, кое-какие мозги у меня есть.

В DLinq-е есть возможность описать сложные sql-запросы посредством цепочки вызовов методов. Это доказывает, что SQL не предоставляет никаких принципиально новых возможностей по сравнению с процедурным языком программирования. Он просто сокращает и упрощает запись той же логики. А это, в свою очередь, и является основной частью определения того, что такое "синтаксический сахар". Так понятней?

В свою очередь функции являются элементарной надстройкой над asm-ом. Очень удобной, очень полезной. Очень сокращающей код и уменьшающей число ошибок. И все же — предельно простой и не дающей никаких принципиально новых преимуществ.

Это я все к тому, что любая идея, доведенная до своего логического завершения, превращается в абсурд. Поэтому и придавать много значения выяснению вопроса "а вот эта фича — это сахар или нет?" нет никакого смысла. Все относительно.

Здравствуйте, mrozov, Вы писали:

M>>>Т.е. вопрос в том — что это дает программисту, а не то, как это квалифицируется.

E>>Если отталкиваться от того, что плотность ошибок на 1000 строк кода величина практически постоянная и не зависит от языка программирования, то сокрашение количества строк кода ведет к уменьшению общего количества ошибок в программе.

M>Категорически не могу согласиться. Были когда-то чемпионаты по написанию программ в одну строчку. Тут не в объеме кода дело, а в выразительной мощности скорее.

Довести до маразма можно все, что угодно.
Но вот исследования по плотности ошибок проводил, кажется, Ericsson. И еще о чем-то похожем говорят ДеМарко и Листер в "Peopleware"

E>>Т.е. хочешь делать меньше ошибок -- пиши меньше кода. Синтаксический сахар позволяет писать меньше кода.

M>Но ведь не только сахар позволяет это сделать, верно?

Верно. Но сахар позволяет это делать.

M>Это определение подходит только в том случае, если принять мою максиму о том, что синтаксическим сахаром является все, кроме машинных кодов (и даже некоторые из них). Как ты (вероятно) догадываешься, сам я в нее не верю.

Тогда к чему это все?

Здравствуйте, Left2, Вы писали:

M>>В качестве примера синтаксического сахара приводится поддержка ООП в C++.
M>>
L>

L>Object-oriented programming
L>The C programming language is fully capable of object-oriented programming using its facilities of function pointers, type casting, and structures. However, languages such as C++ make object-oriented programming more convenient by introducing syntax specific to this coding style.

L>А я не согласен с цитатой. 3 кита ООП — это наследование, полиморфизм и инкапсуляция. Если первые 2 концепции реализуются в С (хоть и с лишней писаниной в случае полиморфизма), то инкапсулящия насколько я понимаю полноценно в C не реализуется. Это именно то что нельзя назвать синтаксическим сахаром — базовая концепция, которую должен поддерживать компилятор.

Там чуть выше, кстати, указано, что большинство конструкций, которые можно было бы назвать сахаром, тем не менее явно поддерживаются компилятором.
Кроме того, поддержать инкапсуляцию можно и иначе — называть методы по паттерну InternalMethodName, например. В конце концов, c# позволяет вызвать закрытый метод через reflection, если очень уж хочется.

Я уже не говорю о том, что если реализация наследования через переопределение указателей на функции доказывает, что виртуальные методы — это синтаксический сахар, то в этом понятии абсолютно точно нет никакого смысла.

Я эту цитату привел исключительно для того, чтобы продемонстрировать, что этот термин вовсе не является формальным и well-known понятием. То, что для одного — сахар, для другого — важнейшая абстракция.

Здравствуйте, eao197, Вы писали:
E>Тогда к чему это все?

Комрад ткнул в фичу языка немерле, показал эквивалентный код, который эту фичу не использует и спросил — доказывает ли это, что данная фича — не более, чем сахар.

Я выступил с мыслью, что это не имеет никакого значения, важна исключительно степень ее полезности. В свойственной мне манере, разумеется.

Другие комрады, в свойственной им манере, начали нервно ставить мне минусы и уверять, что они прекрасно понимают, что такое синтаксический сахар и чем он отличается от просто возможностей языка. Но я что-то сомневаюсь. Имею я право посомневаться?

Кроме того, друг Евгений, мне щас абсолютно нефиг делать и настроение у меня откровенно нерабочее. Закончу строчить и начну писать заявление на отпуск. Хочу на море.

Здравствуйте, nikov, Вы писали:

N>Как тогда объяснить тот факт, что человек, не знающий уравнений Максвелла, может писать сложные SQL-запросы?

Видимо сахар с травой.

Если серьезно, то "сахар" понятие расплывчатое. Многие вещи можно выразить через другие. Скажем циклы через рекурсию или один вид цикла через другой.

Здравствуйте, mrozov, Вы писали:

M>Другие комрады, в свойственной им манере, начали нервно ставить мне минусы и уверять, что они прекрасно понимают, что такое синтаксический сахар и чем он отличается от просто возможностей языка. Но я что-то сомневаюсь. Имею я право посомневаться?

Безусловно имеешь.
Имхо, оценка "синтаксического сахара" (как и "синтаксического оверхеда") очень субъективна.

M>Кроме того, друг Евгений, мне щас абсолютно нефиг делать и настроение у меня откровенно нерабочее. Закончу строчить и начну писать заявление на отпуск. Хочу на море.

Понимаю тебя. Надеюсь, что заявление тебе подпишут

Здравствуйте, mrozov, Вы писали:

M>>>К вызову функции с именем Select и списком параметров. См. DLinq.

ANS>>Уууу! Откуда в реляционной алгебре Dlinq?

M>В DLinq-е есть возможность описать сложные sql-запросы посредством цепочки вызовов методов. Это доказывает, что SQL не предоставляет никаких принципиально новых возможностей по сравнению с процедурным языком программирования.

DLinq может быть синтаксическим сахаром в C# сколько угодно. Но C# не имеет никакого отношения к SQL.

M>Он просто сокращает и упрощает запись той же логики. А это, в свою очередь, и является основной частью определения того, что такое "синтаксический сахар". Так понятней?

Еще раз. Есть оператор SQL "SELECT". Через какой оператор SQL можно выразить этот "SELECT"? Если его можно можно выразить через некий SQL-оператор, то "SELECT" это синтаксический сахар в SQL. Всё. При этом некая фича может быть синтаксическим сахаром в одном языке и быть базовым функционалом в другом.

То, что SQL сервер можно написать на "С" не делает SQL синтаксическим сахаром к операторам С, Паскаля или любого другого языка.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Еще раз. Есть оператор SQL "SELECT". Через какой оператор SQL можно выразить этот "SELECT"? Если его можно можно выразить через некий SQL-оператор, то "SELECT" это синтаксический сахар в SQL. Всё. При этом некая фича может быть синтаксическим сахаром в одном языке и быть базовым функционалом в другом.

Очень хорошо. Правильно ли я понимаю, что в любом языке, поддерживающим ассемблерные вставки, синтаксическим сахаром является весь язык целиком? Если нет — то почему. Спасибо.

Здравствуйте, eao197, Вы писали:

E>Понимаю тебя. Надеюсь, что заявление тебе подпишут

Я еду фоткать рыбок! Ну или еще чего-нибудь придумаю.
Как говаривала одна моя знакомая — ура-ура.

M>Кроме того, поддержать инкапсуляцию можно и иначе — называть методы по паттерну InternalMethodName, например. В конце концов, c# позволяет вызвать закрытый метод через reflection, если очень уж хочется.
называть методы по паттерну InternalMethodName — это перекладывать на программиста работу компилятора. Ну а насчёт вызова через рефлекшн — так и в C++ #define private public никто не отменял. Инкапсуляция спасает от неосознанного (случайного) использования приватных методов, перед хакерской атакой она бессильна.

M>Я эту цитату привел исключительно для того, чтобы продемонстрировать, что этот термин вовсе не является формальным и well-known понятием. То, что для одного — сахар, для другого — важнейшая абстракция.
Все понятия такого рода допускают некую вольность трактовки, тут никто не спорит. Тем не менее эта вольность не обесценивает эти понятия до уровня бесполезных.

Здравствуйте, mrozov, Вы писали:

M>Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>Еще раз. Есть оператор SQL "SELECT". Через какой оператор SQL можно выразить этот "SELECT"? Если его можно можно выразить через некий SQL-оператор, то "SELECT" это синтаксический сахар в SQL. Всё. При этом некая фича может быть синтаксическим сахаром в одном языке и быть базовым функционалом в другом.

M>Очень хорошо. Правильно ли я понимаю, что в любом языке, поддерживающим ассемблерные вставки, синтаксическим сахаром является весь язык целиком? Если нет — то почему. Спасибо.

Скорее возможность ассемблерной вставки является синтаксическим сахаром, т.к. в таких языках (как правило) ничто не мешает заслать в байтовый массив машинные коды и выполнить их

Здравствуйте, mrozov, Вы писали:

M>Очень хорошо. Правильно ли я понимаю, что в любом языке, поддерживающим ассемблерные вставки, синтаксическим сахаром является весь язык целиком? Если нет — то почему. Спасибо.

Не правильно. Хотя бы потому, что в общем случае в конструкциях языка ничего не говорится об ассемблере. Например, программа на "С" выполняется на абстрактной "С"-машине, а не на конкретной x86 или PPC. А вставка на ассемблере взаимодействует с программой на "С" только случайно Конкретный пример: VW ST. Но это не делает St синтаксическим сахаром к ассемблеру. Кстати, одни и те же конструкции языка могут, в конечном итоге, транслироваться в разные ассемблерные комманды. Расстворимый какой-то сахарок получается.

А вот SQLJ это скорее синтаксический сахар к жабе, потому как он не имеет прямого отношения к SQL и сознательно прикручен поверх жабы

Здравствуйте, mrozov, Вы писали:


M>Может мне кто-нибудь объяснить, что такое "синтаксический сахар"? По-моему, это одно из самых идиотических понятий во всем IT.

Самое идиотическое понятие во всем IT — само понятие IT. А "синтаксический сахар" существовал задолго до IT.

Б№@, люди, ну вы даете!
Мне стоило 3-4 поста из всего треда прочитать, как у меня уже первые признаки диабета появились!
Сахар — сахар — сахар!

Здравствуйте, mrozov, Вы писали:

M>Комрад, давай я попробую медленно и еще раз, может ты вдруг поймешь. Ты откажись на минуточку от концепции, что я дурак, я этим делом уже второй десяток лет занимаюсь, как-никак, кое-какие мозги у меня есть.

Похоже не только мозги, но и ещё какая-то каша в голове.

M>В DLinq-е есть возможность описать сложные sql-запросы посредством цепочки вызовов методов. Это доказывает, что SQL не предоставляет никаких принципиально новых возможностей по сравнению с процедурным языком программирования. Он просто сокращает и упрощает запись той же логики. А это, в свою очередь, и является основной частью определения того, что такое "синтаксический сахар". Так понятней?

Правильно.

M>В свою очередь функции являются элементарной надстройкой над asm-ом.

Абсолютно неверно. Например, C# не только не является надстройкой над MSIL, но даже не имеет никакого понятия что это такое.

Здравствуйте, mrozov, Вы писали:

M>Очень хорошо. Правильно ли я понимаю, что в любом языке, поддерживающим ассемблерные вставки, синтаксическим сахаром является весь язык целиком? Если нет — то почему. Спасибо.

Потому что встроенный ассемблер и язык в который он встроен — это два разных человека. Встроенный ассемблер как правило сильно покоцан и не дотягивает до полноценного языка.

Здравствуйте, mrozov, Вы писали:

M>Ну вот и получается, что сахар — это несущественное улучшение. Т.е. все сводится к полезности.

И что в этом плохого?

M>Например — c# и ключевое слово var. Многие его характеризуют, как синтаксический сахар. А между тем, оно избавляет от необходимости определять целый дополнительный класс. И где тут отличие от дженериков?

Никаких целых дополнительных классов var не определяет. Если ты об анонимных типах, то этим занимается ключевое слово new. Кстати, var не является синтаксическим сахаром хотя бы по той причине, что с его помощью можно определять конструкции, которые нельзя выразить другими средствами языка.

M>Брось, комрад. За этим термином не скрывается никакой высшей истины. Это просто эмоциональная оценка, как правило — достаточно личная.

Этот термин имеет прямое отношение к компиляторостроению и обозначает класс конструкций языка, которые можно заменить другими языковыми средствами того же самого языка. Заметь, не ассемблера, а именно того же самого языка. Понятное дело в этом нет ничего мифического.

Здравствуйте, VladD2, Вы писали:

VD>Если серьезно, то "сахар" понятие расплывчатое. Многие вещи можно выразить через другие. Скажем циклы через рекурсию или один вид цикла через другой.

Не думаю, что всё так просто. Результат может быть не эквивалентным.

Здравствуйте, Кодёнок, Вы писали:

Кё>— int? x вместо Nullable<int> x (подразумевает наличие Nullable, хотя то же самое можно реализовать и собственным классом)

Нельзя

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Sinclair, Вы писали:

M>>>Может мне кто-нибудь объяснить, что такое "синтаксический сахар"? По-моему, это одно из самых идиотических понятий во всем IT.
S>>Могу. Синтаксический сахар — это возможность выразить в компактном виде то, что и так есть в языке.
S>>Например, using(...) и foreach() являются чистым сахаром, поскольку для них существует полный аналог в развернутом виде.
S>>А генерики сахаром не являются, т.к. их нельзя превратить в аналогичный не-генерик код.

Кё>Я бы сказал по-другому: синтаксический сахар — это синтаксическая поддержка определенного программного (семантического) решения.

Кё>Например,
Кё>— int? x вместо Nullable<int> x (подразумевает наличие Nullable, хотя то же самое можно реализовать и собственным классом)
Дело не в реализации. int? — это 100% синтаксический сахар, точно такой же, как и сам int по отношению к System.Int32.
Кё>— do a; b; c вместо a >>= \_ -> b >>= \_ -> c (подразумевает использование обозначения >>=)
Кё>- foreach, потому что рассчитывает на IEnumerable
Неа. С форичем всё еще хуже. Он не рассчитывает ни на какие IEnumerable. Он ведет себя так, как будто компилятор раскрывает "макрос" в соответствующий код, а потом уже его компилирует его. Так что это — сахар на 150%.
Кё>- using, это синтаксическая поддержка для IDisposable
Кё>Это называется синтаксическим сахаром как раз потому, что он поддерживает лишь один конкретный IDisposable, а для реализации освобождения ресурса на собственном механизме синтаксической поддержки уже нет.

M>Что такое "уровень абстракции"? Почему ты считаешь, что foreach вместо while или while вместо jmp это не новый уровень абстракции?

не хочу огорчать, но foreach во многих языках действительно находится на другом уровне абстракции чем for и while

Здравствуйте, Left2, Вы писали:

L>А я не согласен с цитатой. 3 кита ООП — это наследование, полиморфизм и инкапсуляция. Если первые 2 концепции реализуются в С (хоть и с лишней писаниной в случае полиморфизма), то инкапсулящия насколько я понимаю полноценно в C не реализуется.

Инкапсуляция с успехом достигается на С с помощью опережающих деклараций и интерфейстных фукнций. #include позволяет включать в файлы описание публичного интерфейса, а реализация скрывается в бинарной форме. Именно так обеспечивается инкапсуляция в ОС вроде Виндовс или Линукс (имеющих С-АПИ).

L>Это именно то что нельзя назвать синтаксическим сахаром — базовая концепция, которую должен поддерживать компилятор.

Как не смешно это звучит, но ООП действительно при некоторой натяжке можно назвать синтаксическим сахаром, а флуды о сахаре являются филосовскими (не имеющими практической пользы).

Что же касается С++, то его первый компилятор CFront был препроцессором в С. Так что функционально языки эквивалентны.

mrozov же говорит верно. Если быть принципиальным, то почти все абстракции являются сахаром для чего-то и наоборот почти весь сахар — это фичи нужные людям. Любые языки полные по Тьюригу теоритически позволяют написать любую программу. Вопрос только в том каков уровень абстракций языка, какие полдходы (парадигмы) можно в нем применять и какова (в результате) будет сложность написания программы на данном языке.

Вот взять упертых фанатиков С++ которые доказывают, что в паттерн-матичнге нет ничего интересного так как его видители в некоторой упрощенной форме можно эмулриовать.

M>Это я все к тому, что любая идея, доведенная до своего логического завершения, превращается в абсурд. Поэтому и придавать много значения выяснению вопроса "а вот эта фича — это сахар или нет?" нет никакого смысла. Все относительно.

вот это — правильная мысль

можно кастрюлю назвать сковородкой-с-высокими краями, но ведь зачем-то называют кастрюлю кастрюлей.

и люди, которые часто пользуются посудой, через какое-то время, безошибочно начинают различать кастрюли и сковородки. без чёткого определения, прошу заметить! и с первого взгляда, зачастую

вот так же и с "синтаксическим сахаром".

Здравствуйте, IT, Вы писали:

IT>Не думаю, что всё так просто. Результат может быть не эквивалентным.

Это уже детали. Факт в том, что сахар слишком неопределенное понятие. В трепологических целях его конечно использовать можно, но делать какие-то выводы на базе того что что-то является сахаро, а что-то нет я бы не стал.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, mrozov, Вы писали:

M>>Очень хорошо. Правильно ли я понимаю, что в любом языке, поддерживающим ассемблерные вставки, синтаксическим сахаром является весь язык целиком? Если нет — то почему. Спасибо.

ANS>Не правильно. Хотя бы потому, что в общем случае в конструкциях языка ничего не говорится об ассемблере.
Ну причем тут это? Говорится-не говорится. Ну а если документацию подправить, тогда что?
В языке возможность есть? Есть. Выразить через нее все остальное можно? Можно.

Определение, которое бы однозначно сортировало фичи языка на сахар и не сахар можно?

Другой занятный вопрос. Допустим, в языке есть две конструкции для организации цикла — for и while.
Каждая может быть легко выражена через другую. Внимание — вопрос — которая из них сахар?

А дело-то в том, что твое формальное определение неформальной вещи неизбежно будет лишено логики. Потому что на самом деле и то и другое есть синтаксический сахар над cmp->jne А то, что в языке возможности напрямую использовать эту конструкцию нет — это детали имплементации.

Здравствуйте, mrozov, Вы писали:

M>В языке возможность есть? Есть. Выразить через нее все остальное можно? Можно.

Перечислите пожалуйста поимённо те инструкции ассемблера через которые выражается цикл for в "C".

Здравствуйте, IT, Вы писали:

IT>Абсолютно неверно. Например, C# не только не является надстройкой над MSIL, но даже не имеет никакого понятия что это такое.
А твой стол не имеет ни малейшего понятия о том, что он стол, а не табуретка. Это все — пустая демагогия.
По факту с#, как и все языки высокого уровня, является оберткой над машинными кодами.

В очередной раз прошу.
Определение того, что есть "синтаксический сахар" — в студию. Определение из википедии, к примеру, совершенно безумно и никак не соотносится с тем, о чем мне тут вещают господа теоретики и ты в том числе.

Затем, когда я это определение получу (хотя я уже и в этом начал сомневаться), я задам следующий вопрос — какой в этом понятии практический смысл вообще, и какой в нем смысл для тех, кто не пишет компиляторы, в частности. Собственно в этом-то и вопрос — и ни в чем ином.

Здравствуйте, mrozov, Вы писали:

M> какой в этом понятии практический смысл вообще, и какой в нем смысл для тех, кто не пишет компиляторы, в частности. Собственно в этом-то и вопрос — и ни в чем ином.

У хост-платформы есть возможности и ограничения. Фразу "синтаксический сахар" говорят, когда фича не привносит дополнительных возможностей и подлежат всем известным ограничениям платформы.

Например, если известно, что using это сахар для finaly+dispose, то можно предположить, что а) можно забыть использовать using и не получить ошибку компиляции; б) можно вызвать dispose 2 раза (раз самому, раз в using и получить ObjectDisposedException); в) можно не правильно реализовать метод dispose; г) вероятно может вылететь исключение, когда объект уже создан, но еще не присвоен временной переменной и dispose не будет вызван; д) можно отгрести проблемы с временем жизни и владением (например, в общем случае нельзя передавать объект в другой тред).

Здравствуйте, VladD2, Вы писали:

VD>Это уже детали. Факт в том, что сахар слишком неопределенное понятие. В трепологических целях его конечно использовать можно, но делать какие-то выводы на базе того что что-то является сахаро, а что-то нет я бы не стал.

По-моему, ты всё слишком драматизируешь. Ничего сложного и неопределённого в этом понятии нет. По крайней мере для меня. Если какую-либо конструкцию можно эквивалентно выразить другими языковыми средствами, то это сахар. Если нельзя, то нет. Честно говоря, я вообще не понимаю о чём этот топик

Здравствуйте, mrozov, Вы писали:

IT>>Абсолютно неверно. Например, C# не только не является надстройкой над MSIL, но даже не имеет никакого понятия что это такое.
M>А твой стол не имеет ни малейшего понятия о том, что он стол, а не табуретка. Это все — пустая демагогия.

Демагогия — это твоё следующее утверждение:

M>По факту с#, как и все языки высокого уровня, является оберткой над машинными кодами.

Только что ты нам песни пел о встроенном ассемблере, а теперь вдруг перешёл на машинные коды и обёртки. Сравниваем тёплое с мягким?

M>В очередной раз прошу.
M>Определение того, что есть "синтаксический сахар" — в студию. Определение из википедии, к примеру, совершенно безумно и никак не соотносится с тем, о чем мне тут вещают господа теоретики и ты в том числе.

Определение тебе уже тут десять раз приводили. Попробую ещё раз.

Языковые конструкции, которые эквивалентно выражаются другими средствами того же самого языка, называются синтаксическим сахаром.

Обрати внимание на выделенное и подумай над ним.

M>Затем, когда я это определение получу (хотя я уже и в этом начал сомневаться), я задам следующий вопрос — какой в этом понятии практический смысл вообще, и какой в нем смысл для тех, кто не пишет компиляторы, в частности. Собственно в этом-то и вопрос — и ни в чем ином.

У меня складывается впечатление, что ты и сам отлично всё понимаешь, просто раз уж встрял в спор, то надо идти до конца.

Здравствуйте, mrozov, Вы писали:

M>Другой занятный вопрос. Допустим, в языке есть две конструкции для организации цикла — for и while.
M>Каждая может быть легко выражена через другую. Внимание — вопрос — которая из них сахар?

А ты сам попробуй подумать

M>Может мне кто-нибудь объяснить, что такое "синтаксический сахар"? По-моему, это одно из самых идиотических понятий во всем IT.

Синтаксис, имеющий нулевое value, и существующий только потому, что создателю языка пришло в голову "а вот можно и так".

M>Синтаксическим сахаром, строго говоря, является ВСЕ, кроме команд ассемблера. Все конструкции всех языков высокого уровня легко и непринужденно укладываются в машинные коды.

Некоторый синтаксис имеет value, некоторый — нет.

__>не хочу огорчать, но foreach во многих языках действительно находится на другом уровне абстракции чем for и while

Виртуальные методы в Си++ — это другой уровень абстракции, да. Как и конструкторы и деструкторы.

А вот operator+ — нет. "Сахар".

Здравствуйте, VladD2, Вы писали:

VD>Факт в том, что сахар слишком неопределенное понятие.

На самом деле все очень просто. Если вызывает рак точки с зяпятой — зачит сахар.

Здравствуйте, IT, Вы писали:

IT>По-моему, ты всё слишком драматизируешь. Ничего сложного и неопределённого в этом понятии нет. По крайней мере для меня.

В нем нет одного. Определения. Это не термин — это балшит. Кроме флэйма он ничего полезного не дает.

IT> Если какую-либо конструкцию можно эквивалентно выразить другими языковыми средствами, то это сахар.

ОК. С++ по твоему определению — это сахар к С, так как все что есть в С++ можно выразить средствами С. В прочем, на компьютере вообще мало что нельзя выразить его средствами. Так что все кроме доступа к портам процессора является сахором к С.

IT> Если нельзя, то нет. Честно говоря, я вообще не понимаю о чём этот топик

Ну, раз не понимашь, то ничего не поделаешь.
Нет у этого термина четкого определения. В определение сахара включется вкусовщина и другие недетерминированные факторы. В итоге договориться о том, что что-то явлется сахором для людей с разным мировозрением крайне сложно.

В общем, в лес не детерминированные понятия. Понятие "фича" мне больше нравится.

Здравствуйте, Трурль, Вы писали:

VD>>Факт в том, что сахар слишком неопределенное понятие.

Т>На самом деле все очень просто. Если вызывает рак точки с зяпятой — зачит сахар.

Можно подробнее про раков?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Трурль, Вы писали:

VD>>>Факт в том, что сахар слишком неопределенное понятие.

Т>>На самом деле все очень просто. Если вызывает рак точки с зяпятой — зачит сахар.

VD>Можно подробнее про раков?

Syntactic sugar causes cancer of the semi-colons
Alan J. Perlis, Epigrams on Programming

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, IT, Вы писали:

IT>>По-моему, ты всё слишком драматизируешь. Ничего сложного и неопределённого в этом понятии нет. По крайней мере для меня.

VD>В нем нет одного. Определения. Это не термин — это балшит. Кроме флэйма он ничего полезного не дает.

IT>> Если какую-либо конструкцию можно эквивалентно выразить другими языковыми средствами, то это сахар.

VD>ОК. С++ по твоему определению — это сахар к С, так как все что есть в С++ можно выразить средствами С. В прочем, на компьютере вообще мало что нельзя выразить его средствами. Так что все кроме доступа к портам процессора является сахором к С.

Ты вовлекаешь в рассмотрение некий компьютер, тем самым погружаясь в дебри исполнения программы, то есть семантики. А сахар-то синтаксический. То есть разрешение вопроса о "сахарности" должно искаться на уровне синтаксиса языка. При таком подходе термин становится банальным: если короткая языковая конструкция A синтаксически эквивалентна более длинной конструкции B, то A — это сахар для B.

В синтаксисе Хаскелла выделяют небольшой language core, и в стандарте описана трансляция большинства конструкций (sections, []-list notation, list comprehension, etc) в это ядро. То есть понятие сахара столь же формально определено, сколь хорошо формализован сам синтаксис конкретного языка.

Здравствуйте, VladD2, Вы писали:

IT>> Если какую-либо конструкцию можно эквивалентно выразить другими языковыми средствами, то это сахар.

VD>ОК. С++ по твоему определению — это сахар к С, так как все что есть в С++ можно выразить средствами С.

Это разные языки. Говорить о каком-то сахаре тут вообще бессмысленно.

VD>Нет у этого термина четкого определения. В определение сахара включется вкусовщина и другие недетерминированные факторы.

Ну да, вкусовщина и глуповщина.

Здравствуйте, mrozov, Вы писали:

M>Очень хорошо. Правильно ли я понимаю, что в любом языке, поддерживающим ассемблерные вставки, синтаксическим сахаром является весь язык целиком? Если нет — то почему. Спасибо.

Ну чего вот ты уперся рогом в землю? Сам же ведь все понимаешь. А если действительно не понимаешь, то я уж не знаю что и думать. Язык высокого уровня не является синтаксическим сахаром над ассемблером, period. Надо объяснять почему? На всякий случай, специально для тех кто в особо глухом танке — на языке высокого уровня можно написать программу, которую можно странслировать в любой ассемблер, в том числе — и это особенно важно — еще не существующий в природе.

MS> на языке высокого уровня можно написать программу, которую можно странслировать в любой ассемблер, в том числе — и это особенно важно — еще не существующий в природе.

да не в этом дело.

программу на языке "А" можно транслировать в программу на языке "Б" для любого А и Б.

вот и всё.

доказывается элементарно: напишем на языке "Б" интерпретатор/компилятор языка "А" — и всего делов
хотя, очевидно, для большинства случаев есть более простые способы.

кстати, программа на языке "Б" не обязана ни синтаксически, ни семантически, ни алгоритмически походить на свой аналог на "А".

для эквивалентности, достаточно чтобы внешняя реакция на любой сигнал была одинаковой.

Здравствуйте, _pk_sly, Вы писали:

MS>> на языке высокого уровня можно написать программу, которую можно странслировать в любой ассемблер, в том числе — и это особенно важно — еще не существующий в природе.

__>да не в этом дело.
__>программу на языке "А" можно транслировать в программу на языке "Б" для любого А и Б.
__>вот и всё.

Ну да, конечно. Вот есть у нас 10 разных программ, написанных на 10 разных ассемблерах. Сколько нам потребуется трансляторов для полной кросс-платформенности? Ответ: N*N = 10*10 = 100. А теперь возьмем те же 10 программ на языке высокого уровня. Все, что для них надо — это 10 кодогенераторов. Это и называется новым уровнем абстракции. И дело здесь не просто в количестве, а в переходе из категории O(N*N) в категорию O(N). И хватит об этом.

Здравствуйте, Sinclair, Вы писали:

Запоздало и, возможно, не совсем по существу дела, но познавательно (из какого-то блога):

foreach (int i in c) { Console.WriteLine(i); }

In addition to the obvious branching opcodes, this can also emit try/finally, a call to IDisposable, unboxing opcodes.

If C is an T[], then the compiler emits an efficient for(int i = 0; i < c.Length; i++) loop. Sweet.
IF C implements the method protocol for IEnumerable but doesn't actually implement the interfaces, then the compiler emits the calls directly.
If C is IEnumerable<T>, then then compiler calls the proper methods on the interface. It will also setup a Try/Finally to ensure that IDisposable.Dispose is called on the IEnumerator<T> object.
If C is IEnumerable (the non-generic version), it's similar to IEnumerable<T>. But since IEnumerator doesn't derive from IDisposable, the compiler must also check if the enumerator implements IDisposable.

Т.е. если это и сахар, то не идеально чистый

Здравствуйте, IT, Вы писали:

M>>Другой занятный вопрос. Допустим, в языке есть две конструкции для организации цикла — for и while.
M>>Каждая может быть легко выражена через другую. Внимание — вопрос — которая из них сахар?

IT>А ты сам попробуй подумать

А ты не сваливай сложну работу на других .

Здравствуйте, McSeem2, Вы писали:

MS>Ну чего вот ты уперся рогом в землю? Сам же ведь все понимаешь. А если действительно не понимаешь, то я уж не знаю что и думать. Язык высокого уровня не является синтаксическим сахаром над ассемблером, period. Надо объяснять почему? На всякий случай, специально для тех кто в особо глухом танке — на языке высокого уровня можно написать программу, которую можно странслировать в любой ассемблер, в том числе — и это особенно важно — еще не существующий в природе.

Ну, что ты уперся рогом в свой танк? Специально для тех кто буравит рогами танки еще раз опишу проблему — основной вопрос заключается в том, что термин "синтаксический сахар" не определен как следует и стало быть его применение ни к чему путному не привдет. Им конечно можно пользваться, но это требует от собеседника/читателя снисходительногого отношения к применению термина и отсуствие желания упереться рогом. Ни то споры вроде является ли LINQ сахаром или фичей станут вечными.

Андестенд?

Здравствуйте, mrozov, Вы писали:

M>А твой стол не имеет ни малейшего понятия о том, что он стол, а не табуретка. Это все — пустая демагогия.
M>По факту с#, как и все языки высокого уровня, является оберткой над машинными кодами.

Скажем так. Это взгляд имеющий право на существование. Как имеются еще пара сотен взглядов которые так же разумны в некотором контексте. Вот и сахар в некотором контексте является разумной абстракций. Мы смотрим на фичу как на некий шорткат для некого паттерна и называем это паттерном, но проблема в том, что та же конструкций в других условиях (или при другой точке зрения) может не быть реализована по средствам синтаксического сокращения.

Здравствуйте, IT, Вы писали:

IT>Определение тебе уже тут десять раз приводили. Попробую ещё раз.

IT>Языковые конструкции, которые эквивалентно выражаются другими средствами того же самого языка, называются синтаксическим сахаром.

Замечательно. Теперь давай подумаем над таким простым фактом. Практически все что угодно можно выразить в терминах условия и следующего за ним безусловного перехода на метку. Таким образом минимальный язык в котором нет сахара может состоять из конструкции if (без else) и goto. Все что угодно. В том числе сложныешие вещи вроде LINQ выражаются через них. Стало быть в C# (согласно твоему определению) все кроме иф и готу является сахаром. Но это же смешно. Стало быть твое определение не полно. Ну, или сам термин сахар является чем-то не определенным.

Здравствуйте, VladD2, Вы писали:

IT>>Языковые конструкции, которые эквивалентно выражаются другими средствами того же самого языка, называются синтаксическим сахаром.

VD>Замечательно. Теперь давай подумаем над таким простым фактом. Практически все что угодно можно выразить в терминах условия и следующего за ним безусловного перехода на метку. Таким образом минимальный язык в котором нет сахара может состоять из конструкции if (без else) и goto. Все что угодно. В том числе сложныешие вещи вроде LINQ выражаются через них. Стало быть в C# (согласно твоему определению) все кроме иф и готу является сахаром. Но это же смешно.

Вот именно! В C# более 90 ключевых слов. Через if/goto можно выразить максимум три. Это ты называешь всё?

Здравствуйте, IT, Вы писали:

IT>Вот именно! В C# более 90 ключевых слов. Через if/goto можно выразить максимум три. Это ты называешь всё?

Через if/goto, ну, еще присвоение нужно не забыть конечно, можно выразить все. Это полный по Тьюрингу набор конструкций. От того собственно все ассемблеры из них и состоят в осноном.

Собственно тут как-то в Декларативном программировании проходил язык в котром база как раз и состояли из этих трех вещей. Далее в языке был реализовано декларативное объявление конструкций и уже через это дело и базовые операторы был раскручен не хилый язык мало чем уступающий Немерлу (ну, разве что сырая реализация). Да и сам Немерле в базе это match, =, def и вызов. Остальное практически все на макросах.

ЗЫ

Бессмысленное это занятие... сравнивать субективные мнения о неопределенном понятии.
Лучше найти более нужное занятие.

Здравствуйте, VladD2, Вы писали:

IT>>Вот именно! В C# более 90 ключевых слов. Через if/goto можно выразить максимум три. Это ты называешь всё?

VD>Через if/goto, ну, еще присвоение нужно не забыть конечно, можно выразить все. Это полный по Тьюрингу набор конструкций. От того собственно все ассемблеры из них и состоят в осноном.

Причём тут ассемблеры? Мы говорим о конкретном языке, в котором, например, switch не выразишь эквивалентно через if/goto, по той простой причине, что switch генерирует принципиально другой код.

VD>Бессмысленное это занятие... сравнивать субективные мнения о неопределенном понятии.

Это оно для тебя неопределённое, т.к. ты почему-то говоришь не о конкретном языке, а о машинах Тьюринга и ассемблерах. Не надо туда ходить и всё сразу станет определённо и ясно как божий день.

Здравствуйте, IT, Вы писали:

VD>>Через if/goto, ну, еще присвоение нужно не забыть конечно, можно выразить все. Это полный по Тьюрингу набор конструкций. От того собственно все ассемблеры из них и состоят в осноном.

IT>Причём тут ассемблеры?

Притом, что ассемблеры являются надстройкой над маш.кодами которые в свою очередь являются набором базовых вычислительных примитивов плюс ряд оптимизаций. Исходя из твоего определения без проблем можно считать, что ассемблеры сахар для маш кодов (они же "эквивалентно выражаются другими средствами"). В вот тот же это самый язык или уже другой вопрос филосовский.

IT> Мы говорим о конкретном языке, в котором, например, switch не выразишь эквивалентно через if/goto, по той простой причине, что switch генерирует принципиально другой код.

Через if, goto и присвоение можно выразить все. В том числе и свитч. Просто работы будет сильно больше. Так ее выполняет компилятор, автоматически, а так прийдется ее каждый раз проделывать вручную. Это тоже самое, что скажем использование foreach, но в случае ручной реализации foreach-а работы будет больше.

Скажу больше, goto легко заменят даже вызовы методов. В первых ассемблерах инструкций вроде call/ret не было. Ее эмулировали с помощью goto. Причем это позволяло сильно упростить реализацию, так как не надо было заботиться о ковенциях вызова. Они были паттернами.

Так что реально под сахаром люди понимают некие языковые абстракции кажующеся им по каким-то причинам незначительными. Вот только критерий незначительности определяется разными людьми по разному. От того термир практически не приминим в спорах, так как то что для одного "сахарок" для другого основа мировозрения.

VD>>Бессмысленное это занятие... сравнивать субективные мнения о неопределенном понятии.

IT>Это оно для тебя неопределённое,

А этого уже достоточно. Если термин понимается по разному разными людьми, то он никуда не годен и его лучше не использовать.

IT> т.к. ты почему-то говоришь не о конкретном языке, а о машинах Тьюринга и ассемблерах. Не надо туда ходить и всё сразу станет определённо и ясно как божий день.

А говорю о том, что видил и прошел на своей шкуре. Кода я в статье использовал термин "синтаксический сахар", то сразу же получил кучу разношерстных мнений гиперболизированных в разные стороны. Пытаясь говорить с "критиками" я понял, что не согласны они в общем-то не с тем, что я пишу, а с теми выводами которые оплучаются. Ну, любят одни С++ больше жизни. И любые слова принижающие значимость этого старичка для них выглядят как личное оскоробление. Аргументов у них нет. Вот и начинаются докапывания до слов и терминалогические игры. И термин сахар, почему-то, сразу и неприменно становится объектом атаки. Разговор сразу превращается в софистику. Ну, а раз так, то что вообще использовать термин которые кроме как для образования флэйма ни на что друго не пригоден. Если я скажу, что foreach — это новая синтаксическая конструкция, а не сахар, то никто от этого не пострадает. И спорить будет не с чем.

Здравствуйте, _pk_sly, Вы писали:

__>можно кастрюлю назвать сковородкой-с-высокими краями, но ведь зачем-то называют кастрюлю кастрюлей.

Сковорода и кострюля отличаются, главным образом, своим предназначением. Одна предназначена для жарки, а другая для варения. Отсюда и свойства. Одна из толстого метала, обычно с длинной ручкой и невысокими краями, а другая с высокими краями и более тонкими стенками. Если сделать сковороду с высокими стенками, или кастрюлю с низкими, то вряд ли кто-то сможет угадать на вид, что это такое.

И вообще, аналогии для доказательств не катят.

Здравствуйте, IT, Вы писали:

M>>Ну вот и получается, что сахар — это несущественное улучшение. Т.е. все сводится к полезности.

IT>И что в этом плохого?

Плохо, то, что существенность есть субъективный критерий. Для одного, скажем, foreach, не существенно, а для другого — существенно. Вот кое-кто, не будем показывать пальцем считает сахаром LINQ, а другие — нет.

M>>Например — c# и ключевое слово var. Многие его характеризуют, как синтаксический сахар. А между тем, оно избавляет от необходимости определять целый дополнительный класс. И где тут отличие от дженериков?

IT>Никаких целых дополнительных классов var не определяет. Если ты об анонимных типах, то этим занимается ключевое слово new.

И тем неменее без var небыло бы даже возможности использовать анонимные типы. Получается, без сахара невозможна фундаметальная фича. В прочем, вопрос являются ли анонимные типы фичей или сахара тоже открытый. Это зависит от субъективного мнения. И хрен когда все прийдут к одному мнению.

IT> Кстати, var не является синтаксическим сахаром хотя бы по той причине, что с его помощью можно определять конструкции, которые нельзя выразить другими средствами языка.

Согласен. Вот только это не мешает многим называть var сахаром.

Сообственно об этом вам Морозов и пытается расскзать, а вы его высмеивать пытаетесь. Это тот случай когда большинство гнет свою линию не смотря не ее несостоятельность.

M>>Брось, комрад. За этим термином не скрывается никакой высшей истины. Это просто эмоциональная оценка, как правило — достаточно личная.

IT>Этот термин имеет прямое отношение к компиляторостроению и обозначает класс конструкций языка, которые можно заменить другими языковыми средствами того же самого языка. Заметь, не ассемблера, а именно того же самого языка. Понятное дело в этом нет ничего мифического.

Ничего он не обозначает. Ты не найдешь такой термин ни в одной серьезной статье по компиляторостороению. Научный мир старается не оперировать недетерминированными понятиями.

Здравствуйте, Sinclair, Вы писали:

S>Дело не в реализации. int? — это 100% синтаксический сахар, точно такой же, как и сам int по отношению к System.Int32.

Для подобного "сахара" есть четко детерминированное поняите type alias. В том же C# ты можешь подобную фигню и сам замутить:

using myint = System.Int32;

но к сожалению только на один файл.
А в других языках есть встроенные средства для их определения.

Более того, по

Кё>>— do a; b; c вместо a >>= \_ -> b >>= \_ -> c (подразумевает использование обозначения >>=)
Кё>>- foreach, потому что рассчитывает на IEnumerable
S>Неа. С форичем всё еще хуже. Он не рассчитывает ни на какие IEnumerable. Он ведет себя так, как будто компилятор раскрывает "макрос" в соответствующий код, а потом уже его компилирует его. Так что это — сахар на 150%.

А for по-твоему не сахар? Его тоже в терминах while нефига делать выразить. В прочем как и наоборот.

VD>Сковорода и кострюля отличаются, главным образом, своим предназначением. Одна предназначена для жарки, а другая для варения. Отсюда и свойства. Одна из толстого метала, обычно с длинной ручкой и невысокими краями, а другая с высокими краями и более тонкими стенками. Если сделать сковороду с высокими стенками, или кастрюлю с низкими, то вряд ли кто-то сможет угадать на вид, что это такое.
VD>И вообще, аналогии для доказательств не катят.

Воот!

"Сахарные" оппоненты тут начали бы рассуждать, а на столько ли толсто дно у этой конкретной сковороды, можно ли в кастрюле жарить и является ли тушение в сковородке разновидностью варки в кастрюле. И вообще, всё это — "синтаксический сахар" для ложки. А ложка — синтаксический сахар для вилки... и т.д.

Но по сути, всё это является пустым трёпом. Есть, конечно, некоторые "средние" варианты, но я более чем уверен что средний человек (а тем более, повар!) безошибочно различит 99% сковородок и кастрюль.

Что не так с аналогией? Она даже слишком хорошо подходит: все (по крайней мере, "повара") знают что такое "сахар"; приходит человек, который, в общем-то, в теме и начинает жонглировать словами, доказывая что через нечёткое определение всё можно назвать любым словом


А дело в чём — в том, что термины придумывают не для создания умного вида, а для того, чтобы они (термины) отделяли одни явления от других. Они помогают описать существующие вещи, предсказать или придумать новые. Люди, которые в данном споре понимают значение слова "сахар", используют это слово в парсерах, компиляторах и т.д. При чём, используют успешно! И не важно что, возможно, они не могут дать математически чёткого определения этому. Главное — что оно помогает, оно работает.

А вот "сахарные оппоненты" об этом сахаре только слышали, но пользы из этого никогда не извлекали. Вот и пытаются доказать что раз это не понадобилось им, значит это не нужно вообще — чертовски знакомо!

При нечётких определениях "нафилософствовать" и доказать можно вообще всё что угодно. Это простые тролли.

Здравствуйте, VladD2, Вы писали:

V> Мы смотрим на фичу как на некий шорткат для некого паттерна и называем это паттерном, но проблема в том, что та же конструкций в других условиях (или при другой точке зрения) может не быть реализована по средствам синтаксического сокращения.

Видишь ли, какая штука. Есть такое понятие, как "хорошо" и "плохо". Эти понятия невозможно формально определить. Они очень индивидуальны и отличаются для каждого индивидуума. Но они все равно полезны. Люди стремятся к хорошему и избегают плохого — в их понимании. Поэтому понятие "хорошо" имеет ценность.

Понятие "синтаксический сахар" никакой ценности не имеет.

Оно не имеет ценности при использовании фичи языка — потому что тут играют роль факторы удобства написания кода и скорости его работы (ну и некоторые другие). Что угодно — переносимость, наглядность и т.п. может иметь значение, но сахарность критерием не является.

Оно не имеет ценности при создании языка — по той же причине, собственно. Мне тут пытаются впаривать, что это понятие используется компиляторописателями — так вот, у меня для вас новость — конечно же НЕ используется. Используются совсем другие, имеющие куда более формальное определение. Исключения (наверное) бывают, но к счастью большинство из нас никогда не столкнется с продуктом работы таких "специалистов".

Т.е. это определение, не подходящее на роль класификатора в силу своей приблизительности и не подходящее на роль оценки, так как эта оценка сама по себе лишена смысла.

Речь об этом и только об этом.

Здравствуйте, IT, Вы писали:

IT>По-моему, ты всё слишком драматизируешь. Ничего сложного и неопределённого в этом понятии нет. По крайней мере для меня. Если какую-либо конструкцию можно эквивалентно выразить другими языковыми средствами, то это сахар. Если нельзя, то нет. Честно говоря, я вообще не понимаю о чём этот топик

Мне кажется, кроме выразимости у сахара должно быть ещё какое то качество. Конструкции языка редко образуют достаточный и необходимый базис. Обычно базис бывает не полный, а переполненный.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, mrozov, Вы писали:

M>>Другой занятный вопрос. Допустим, в языке есть две конструкции для организации цикла — for и while.
M>>Каждая может быть легко выражена через другую. Внимание — вопрос — которая из них сахар?

IT>А ты сам попробуй подумать

Я нашел ошибку в твоем определении. Я ее вскрыл и показал тебе. Что-нибудь еще, кроме смайликов и обвинений в демагогии или глупости продемонстрировать можешь?

Или может лучше сразу меня забанить за споры с модераторами?

Комрад — ну неужеди так сложно признать, что я, в сущности, прав? Тем более, что это даже не моя точка зрения, я ее честно спер из куда более авторитетного источника.

Здравствуйте, VladD2, Вы писали:

VD>>>Через if/goto, ну, еще присвоение нужно не забыть конечно, можно выразить все. Это полный по Тьюрингу набор конструкций. От того собственно все ассемблеры из них и состоят в осноном.

IT>>Причём тут ассемблеры?

VD>Притом, что ассемблеры являются надстройкой над маш.кодами которые в свою очередь являются набором базовых вычислительных примитивов плюс ряд оптимизаций. Исходя из твоего определения без проблем можно считать, что ассемблеры сахар для маш кодов (они же "эквивалентно выражаются другими средствами").

Ты плохо читал моё определение, если вообще читал. Я подчеркнул, что речь должна идти об одном и том же языке. Вы же с автором топика почему-то всё время скатываетесь на Тьюринга, ассемблер, железо и молекулы. Не надо этого делать. Попробуй оставаться в рамках одного языка и проблема сразу исчезнет.

VD> В вот тот же это самый язык или уже другой вопрос филосовский.

Это как раз самый главный момент.

IT>> Мы говорим о конкретном языке, в котором, например, switch не выразишь эквивалентно через if/goto, по той простой причине, что switch генерирует принципиально другой код.

VD>Через if, goto и присвоение можно выразить все. В том числе и свитч. Просто работы будет сильно больше.

Вырази. Возми и вырази, только не языком, а средсвами C#. Напиши код без switch, который сгенерирует тоже самое что и switch. А потом, если до тебя всё же не дойдёт, мы продолжим обсуждение.

VD>Так ее выполняет компилятор, автоматически, а так прийдется ее каждый раз проделывать вручную. Это тоже самое, что скажем использование foreach, но в случае ручной реализации foreach-а работы будет больше.

Это не тоже самое. Это принципиально невозможно.

VD>Скажу больше, goto легко заменят даже вызовы методов. В первых ассемблерах инструкций вроде call/ret не было.

Не надо про ассемблеры. Давай о C#. Сделай мне, пожалуйста, на C# эквивалентный вызов метода средствами goto.

VD>Так что реально под сахаром люди понимают некие языковые абстракции кажующеся им по каким-то причинам незначительными.

Люди под сахаром понимают прежде всего абстракции одного и того же языка, а не ассемблеры и молекулы.

IT>>Это оно для тебя неопределённое,

VD>А этого уже достоточно. Если термин понимается по разному разными людьми, то он никуда не годен и его лучше не использовать.

Это в случае, если он понимается по разному. В данном случае он просто кем-то НЕ понимается.

Здравствуйте, mrozov, Вы писали:

M>>>Другой занятный вопрос. Допустим, в языке есть две конструкции для организации цикла — for и while.
M>>>Каждая может быть легко выражена через другую. Внимание — вопрос — которая из них сахар?

IT>>А ты сам попробуй подумать

M>Я нашел ошибку в твоем определении. Я ее вскрыл и показал тебе. Что-нибудь еще, кроме смайликов и обвинений в демагогии или глупости продемонстрировать можешь?

Если в определении найдена ошибка (что не есть факт), то его всегда можно подправить. Главное не это, главное — понимание сути. Что касается твоего твоего вопроса, на который ты сам же откался отвечать, то по моему мнению while более низкоуровневая конструкция, но это не важно. Влад вообще утверждает, что обе конструкции можно выразить через if/goto

M>Или может лучше сразу меня забанить за споры с модераторами?

А это тут причём? Это уже точно смахивает на демагогию.

M>Комрад — ну неужеди так сложно признать, что я, в сущности, прав? Тем более, что это даже не моя точка зрения, я ее честно спер из куда более авторитетного источника.

Видишь ли в чём дело. Называние источника авторитетным для меня уже давно не является критерием авторитетности. Я готов выслушать любые резонные мнения и суждения, а выводы об авторитетности я уж сделаю как-нибудь сам.

M>Я нашел ошибку в твоем определении. Я ее вскрыл и показал тебе.

вот в этом — суть твоего разговора.

"определите мне, пожалуйста математически точно понятие "лопата", а я вам всем докажу что вы неправы".

все себе представляют лопату, но точными определениями никто не занимается. даже в толковых словарях найдёшь только примерное описание.

поспорим что не определишь (по крайней мере с первого раза) _математически точно_ "лопату"? я найду изъян.

ну так чем ты здесь занимаешься тогда?

Здравствуйте, VladD2, Вы писали:

VD>Собственно тут как-то в Декларативном программировании проходил язык в котром база как раз и состояли из этих трех вещей. Далее в языке был реализовано декларативное объявление конструкций и уже через это дело и базовые операторы был раскручен не хилый язык мало чем уступающий Немерлу (ну, разве что сырая реализация). Да и сам Немерле в базе это match, =, def и вызов. Остальное практически все на макросах.

А не подскажешь дополнительной информации?
Ну, например, как давно, или примерное название. А то так не найду, а посмотреть хочется.

Здравствуйте, VoidEx, Вы писали:

VD>>Собственно тут как-то в Декларативном программировании проходил язык в котром база как раз и состояли из этих трех вещей. Далее в языке был реализовано декларативное объявление конструкций и уже через это дело и базовые операторы был раскручен не хилый язык мало чем уступающий Немерлу (ну, разве что сырая реализация). Да и сам Немерле в базе это match, =, def и вызов. Остальное практически все на макросах.

VE>А не подскажешь дополнительной информации?
VE>Ну, например, как давно, или примерное название. А то так не найду, а посмотреть хочется.

Не помню. Помню только что Гапертон по нему проходился. И помню, что там мощьный постоитель парсеров использовался.

Думаю, если задать вопрос на том форуме, то ссылочку подкинут.

Здравствуйте, VladD2, Вы писали:

VD>Не помню. Помню только что Гапертон по нему проходился. И помню, что там мощьный постоитель парсеров использовался.

VD>Думаю, если задать вопрос на том форуме, то ссылочку подкинут.

Спасибо, попробую.

Здравствуйте, VladD2, Вы писали:

VD>А for по-твоему не сахар? Его тоже в терминах while нефига делать выразить. В прочем как и наоборот.
Согласен. Правда, сахар for ничуть не слаще, чем сахар while. Вот using значительно слаще по отношению к try/finally:dispose.
Вообще, можно ввести цельную систему специй. Тут где-то уже соль упоминали Вот и получается, что for/while — это кетчуп/майонез.
int? — это такой типа ванилин, а вот using — нормальная глюкоза.

Здравствуйте, IT, Вы писали:

IT>Ты плохо читал моё определение, если вообще читал. Я подчеркнул, что речь должна идти об одном и том же языке. Вы же с автором топика почему-то всё время скатываетесь на Тьюринга, ассемблер, железо и молекулы.

Я хорошо читал. Потому и говорил не об cmp, mov и т.п., а о goto, if и присвоении. Эта база есть почти в любом языке и ее достаточно для эмуляции любых фич. Если бы это было не так, то на первых Васиках нельзя было бы программировать.

Исходя из твоего определения все кроме этих инструкций можно считать сахаром.

Дело тут не в моих докапываниях, а в том, что ты сам не можешь дать точного определения данному термину.

На самом деле, в это определение нужно добавить еще одну фаруз. Что-то вроде: "Вносящее несущественные изменения в язык.". Но такое определение само по себе очень сильно зависит от IMHO-в.

VD>> В вот тот же это самый язык или уже другой вопрос филосовский.

IT>Это как раз самый главный момент.

Он опять же не детерминирован. Скажем если взять базовый Немерле (без единого макроса), то это будет сильно другой язык. Но с некоторой натяжкой все макросы есть ни что иное как синтаксический сахар.

VD>>Через if, goto и присвоение можно выразить все. В том числе и свитч. Просто работы будет сильно больше.

IT>Вырази. Возми и вырази, только не языком, а средсвами C#.

А что есть какие-то проблемы? Я когда-то писал на дремучем Васике. Тем набор инструкций был шире только на инструкции "go sub <номер строки>" и exit sub, но до этого Васики и их не имели.

IT> Напиши код без switch, который сгенерирует тоже самое что и switch.

Поясни, плиз, что мне помешает это сделать? Ну, кроме объемов и запутаности получаемого кода? switch-и строются по двум принципам: на базе вложенных ифоф и на базе таблиц переходов. Обе концепции переписываются на if+goto+присоение. Машинный код будет полностью идетниченый. Не говоря уже о семантике.

IT> А потом, если до тебя всё же не дойдёт, мы продолжим обсуждение.

Пожалуй я не буду его продолжать. Не охота доказывать базовые вещи и боростья с какими-то домыслами.

VD>>Так ее выполняет компилятор, автоматически, а так прийдется ее каждый раз проделывать вручную. Это тоже самое, что скажем использование foreach, но в случае ручной реализации foreach-а работы будет больше.

IT>Это не тоже самое.

Что не тоже самое?

IT>Это принципиально невозможно.

Что невозможно?

IT>Это в случае, если он понимается по разному. В данном случае он просто кем-то НЕ понимается.

И ты конечно уверен, что понимашь все хорошо и лучше все?

Здравствуйте, _pk_sly, Вы писали:

__>Но по сути, всё это является пустым трёпом. Есть, конечно, некоторые "средние" варианты, но я более чем уверен что средний человек (а тем более, повар!) безошибочно различит 99% сковородок и кастрюль.

Он еще выделит такие вещи как: казан для плова, котелок для похода, горшок для тушения, ковш для варки и т.п. И все это он сделал бы по внешнему виду.

__>Что не так с аналогией?

То что нет никаких освнований полагать, что верность утверждений в этой аналогии хоть как-то сочетается с верностью утверждений в другой области.

__> Она даже слишком хорошо подходит: все (по крайней мере, "повара") знают что такое "сахар"; приходит человек, который, в общем-то, в теме и начинает жонглировать словами, доказывая что через нечёткое определение всё можно назвать любым словом

У сахар есть формула и вид ристалической решотки. Так что жанглеру можно быстро указать на то, что он занимается софистикой. А вот в синтаксическом сахаре все зависит от оценки человека. Это эмоциональная оценка, а не факт.

__>А дело в чём — в том, что термины придумывают не для создания умного вида, а для того, чтобы они (термины) отделяли одни явления от других. Они помогают описать существующие вещи, предсказать или придумать новые. Люди, которые в данном споре понимают значение слова "сахар", используют это слово в парсерах, компиляторах и т.д. При чём, используют успешно! И не важно что, возможно, они не могут дать математически чёткого определения этому. Главное — что оно помогает, оно работает.

Я не видел, чтобы серьзные компиляторщики бросались пдобными словами. Обычно речь идет о фичах. У компиляторщиков как раз все прсото. Им просто нет нужды делить что-то на фичи и сахар.

__>А вот "сахарные оппоненты" об этом сахаре только слышали, но пользы из этого никогда не извлекали. Вот и пытаются доказать что раз это не понадобилось им, значит это не нужно вообще — чертовски знакомо!

Это переверание чужих слов. Лично я полностью уверен, что термин "синтаксический сахар" понимается разными людьми по разному. Причем он постоянно приводит к спорам. И споры эти в общем-то не очем. Ведь, как говорится, хоть горшком назови, только в печь не ставь.

__>При нечётких определениях "нафилософствовать" и доказать можно вообще всё что угодно. Это простые тролли.

Дык тот-то и оно. 90% данного (и не только) форуима будут тролить и изворачиваться лиш бы не принять неприятные им вещи.
Менять свое мнение при обоснованных возражениях умеют очень не многие. Большинство или упирается рогом в очевидных ситуациях, или соглашаются с любой чущью ведя себя как флюгер на верту.

Здравствуйте, Sinclair, Вы писали:

VD>>А for по-твоему не сахар? Его тоже в терминах while нефига делать выразить. В прочем как и наоборот.
S>Согласен. Правда, сахар for ничуть не слаще, чем сахар while.

А... точно. Чтобы жанглирование терминами было по красивше, а софистика по гуще, нада еще обсудить вопрос сладости сахара .

S> Вот using значительно слаще по отношению к try/finally:dispose.

О, да. Особенно если сравнивать с директивой using открывающую пространство имен.

S>Вообще, можно ввести цельную систему специй. Тут где-то уже соль упоминали Вот и получается, что for/while — это кетчуп/майонез.

S>int? — это такой типа ванилин, а вот using — нормальная глюкоза.

Ага, а LINQ — это глютаминат натрия .

Здравствуйте, _pk_sly, Вы писали:

__>все себе представляют лопату, но точными определениями никто не занимается. даже в толковых словарях найдёшь только примерное описание.

Не надо песен. У лопат даже спецификации есть. И что-это такое тоже совершенно ясно. Просто это широкий класс.

__>поспорим что не определишь (по крайней мере с первого раза) _математически точно_ "лопату"? я найду изъян.

Лопата определяется логически точно. Просто термин настолько очевидный и распространненный, что таких точных определений на практике не требуется.

А вот обсуждаемый термин отнюдь не очевиден и не имеет точного определения. В его определении имеется недетерминизм. Он основан на вкусах конкретных личностей.

__>ну так чем ты здесь занимаешься тогда?

Пытается обяснить довольно примитивные вещи, которые массы как всегда недоганяют. Попробуй поиспользовать этот "термин" при отстаивании своего мнения и сразу увидишь, что его каждый использует как хочет.

Здравствуйте, VladD2, Вы писали:
__>>все себе представляют лопату, но точными определениями никто не занимается. даже в толковых словарях найдёшь только примерное описание.
VD>Не надо песен. У лопат даже спецификации есть. И что-это такое тоже совершенно ясно. Просто это широкий класс.
__>>поспорим что не определишь (по крайней мере с первого раза) _математически точно_ "лопату"? я найду изъян.
VD>Лопата определяется логически точно. Просто термин настолько очевидный и распространненный, что таких точных определений на практике не требуется.

термин — очевидный и распространненный. но ненаучный. не математический и (если угодно) не логический.
именно поэтому я готов поспорить что далеко не каждый простой человек сможет дать на 100% точное его определение.
более того, готов поспорить, что для выведения точного определения, даже непростым людям пришлось БЫ (если бы они стали заниматься этой глупостью) потратить далеко не одну неделю, попутно уточняя спецификации попутных терминов.

любое слёту данное определение будет либо не необходимым либо недостаточным.

__>> Она даже слишком хорошо подходит: все (по крайней мере, "повара") знают что такое "сахар"; приходит человек, который, в общем-то, в теме и начинает жонглировать словами, доказывая что через нечёткое определение всё можно назвать любым словом

VD>У сахар есть формула и вид ристалической решотки. Так что жанглеру можно быстро указать на то, что он занимается софистикой. А вот в синтаксическом сахаре все зависит от оценки человека. Это эмоциональная оценка, а не факт.

Влад Ты хочешь сказать, что то, что мы кладём в чай, элементарно описывается формулой и кристаллической решёткой?
Это далеко не так.
Ну, это к слову.
Хочу сказать, что при желании можно придраться к любому слову. Потому что это — не математика.

VD>Я не видел, чтобы серьзные компиляторщики бросались пдобными словами. Обычно речь идет о фичах. У компиляторщиков как раз все прсото. Им просто нет нужды делить что-то на фичи и сахар.

А зачем "бросаться"? Просто, в процессе работы, он у себя где-то в уголке может отметить: "это — сахар", "это — соль", например.
Если это кого-то раздражает, вслух можно не говорить

__>>А вот "сахарные оппоненты" об этом сахаре только слышали, но пользы из этого никогда не извлекали. Вот и пытаются доказать что раз это не понадобилось им, значит это не нужно вообще — чертовски знакомо!
VD>Это переверание чужих слов. Лично я полностью уверен, что термин "синтаксический сахар" понимается разными людьми по разному. Причем он постоянно приводит к спорам. И споры эти в общем-то не очем. Ведь, как говорится, хоть горшком назови, только в печь не ставь.

я, в принципе, о том и говорю..
если термин помогает, он имеет право на существование.
даже нечёткий.

вообще, эта беседа мне напоминает объяснение С++-нику о пользе замыканий, о continuations, о list comprehensions и т.д.

Здравствуйте, VladD2, Вы писали:

VD>Я хорошо читал. Потому и говорил не об cmp, mov и т.п., а о goto, if и присвоении. Эта база есть почти в любом языке и ее достаточно для эмуляции любых фич. Если бы это было не так, то на первых Васиках нельзя было бы программировать.

По-моему, тут ты не прав.
Вот это:

struct A { int x, y; };

не выражается через if/else/goto. Зато вот это (псевдокод):

interface X
{
  void foo (int x, int y);
};

элементарно выражается средствами того же языка (пусть это будет Си++):

class X
{
public:
  virtual ~X() = 0 {}
  virtual void foo (int x, int y) = 0;
};

Так что interface в данном случае — синтаксическия сахар, а вот struct — нет. Да, конечно, использование такой структуры можно заменить на обычные переменные, но само объявление структуры — нет. Т.е. сделать синтаксическое преобразование кода

A a; a.x = 45;

В такой:

int a_x; int a_y; a_x = 45;

компилятор может только при знании объявления этой структуры, а не просто так, т.е. это уже не просто синтаксическое преобразование.
Разве нет?

Здравствуйте, _pk_sly, Вы писали:

__>Влад Ты хочешь сказать, что то, что мы кладём в чай...

Откровенно говоря я уже ничего больше сказать не хочу. Все равно слушать нитко не хочет. И уж темболее не хочется обсуждать вопросы чая.

M>Может мне кто-нибудь объяснить, что такое "синтаксический сахар"?

То без чего можно программировать, но трудно пить чай.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, IT, Вы писали:

IT>>Ты плохо читал моё определение, если вообще читал. Я подчеркнул, что речь должна идти об одном и том же языке. Вы же с автором топика почему-то всё время скатываетесь на Тьюринга, ассемблер, железо и молекулы.

VD>Я хорошо читал. Потому и говорил не об cmp, mov и т.п., а о goto, if и присвоении. Эта база есть почти в любом языке и ее достаточно для эмуляции любых фич. Если бы это было не так, то на первых Васиках нельзя было бы программировать.

VD>Исходя из твоего определения все кроме этих инструкций можно считать сахаром.

VD>Дело тут не в моих докапываниях, а в том, что ты сам не можешь дать точного определения данному термину.

VD>На самом деле, в это определение нужно добавить еще одну фаруз. Что-то вроде: "Вносящее несущественные изменения в язык.". Но такое определение само по себе очень сильно зависит от IMHO-в.

Да, пожалуй это уточнение во многом соответствует приближению данного выше определения к установишимся понятиям о "сахаре". Но все-таки это еще не все.
Например, foreach в java вроде бы по общему признанию является сахаром над стандартным циклом for.

foreach (Test test : elements)
{
    foo(test);
}

//или
for (int i=0; i<elements.length(); i++)
{
    foo(elements.get(i));
}

В то же время, например, почему-то никто не считает while сахаром на if и goto. Почему? Только ли потому, что goto в java не существует, хотя и зарезервирован? Мне кажется, нет.

Псеводява:

while (res)
{
    res = foo();
}

//или
label:
res = foo();
if (res)
    goto label;

Почему в первом случае — это сахар, а во втором — нет? Только потому, что foreach вносит менее существенные изменения по сравнению с while? Или тут кроется еще что-то? Например то, что while был еще в древнем С, когда термина "синтаксический сахар" вроде не было, стал, так сказать, необходимым элементом любого языка. А foreach возник в тот момент, когда в мода на всякий "сахар" была в самом разгаре. Т. е. по сути, все тот же субъективизм, о котором говорили. Так что, ИМХО, точного определения таки дать нельзя.

Здравствуйте, lse, Вы писали:

lse>В то же время, например, почему-то никто не считает while сахаром на if и goto. Почему? Только ли потому, что goto в java не существует, хотя и зарезервирован?
lse>Мне кажется, нет.
А мне кажется — да.

lse>Псеводява:
lse>//или
lse>label:
lse>res = foo();
lse>if (res)
lse> goto label;
lse>[/java]
Ну так в этой воображаемой псевдояве while и был бы сахаром. Если бы у бабушки было сами-знаете-что, то она была бы дедушкой. Если бы соль была сладкой, то она была бы сахаром.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, lse, Вы писали:

lse>>В то же время, например, почему-то никто не считает while сахаром на if и goto. Почему? Только ли потому, что goto в java не существует, хотя и зарезервирован?
lse>>Мне кажется, нет.
S>А мне кажется — да.

lse>>Псеводява:
lse>>//или
lse>>label:
lse>>res = foo();
lse>>if (res)
lse>> goto label;
lse>>[/java]
S>Ну так в этой воображаемой псевдояве while и был бы сахаром. Если бы у бабушки было сами-знаете-что, то она была бы дедушкой. Если бы соль была сладкой, то она была бы сахаром.

Может быть. Ну тогда в С++, где goto есть, while будет являться сахаром. while и еще пол-языка. Ты согласен?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, lse, Вы писали:

lse>>В то же время, например, почему-то никто не считает while сахаром на if и goto. Почему? Только ли потому, что goto в java не существует, хотя и зарезервирован?
lse>>Мне кажется, нет.
S>А мне кажется — да.

lse>>Псеводява:
lse>>//или
lse>>label:
lse>>res = foo();
lse>>if (res)
lse>> goto label;
lse>>[/java]
S>Ну так в этой воображаемой псевдояве while и был бы сахаром. Если бы у бабушки было сами-знаете-что, то она была бы дедушкой. Если бы соль была сладкой, то она была бы сахаром.

Можно еще следующим образом усилить определение, дополненное VladD2:

...служащее другой (более удобной) формой записи определенной конструкции языка.

Т. е. while тогда нельзя назвать сахаром, т к он получается путем комбинации различных конструкций, каждая из которых НЕ ПРЕДНАЗНАЧЕНА только лишь для организации циклов. С помощью этих же выражений можно всю программу написать, а не просто организовать цикл. А вот foreach будет являться сахаром, т к по сути, служит другой формой записи конструкции, служащей (в общем) ТОЛЬКО для определения циклов.

Здравствуйте, lse, Вы писали:

lse>С помощью этих же выражений можно всю программу написать
Я уже привел пример, что нет.
Но вот while действительно получается сахаром.

Здравствуйте, lse, Вы писали:
lse>Может быть. Ну тогда в С++, где goto есть, while будет являться сахаром. while и еще пол-языка. Ты согласен?
Нет, не согласен. Покажи мне эти пол-языка. Не надо преувеличивать мощность goto.

Здравствуйте, lse, Вы писали:

lse>Может быть. Ну тогда в С++, где goto есть, while будет являться сахаром. while и еще пол-языка. Ты согласен?

всякие циклы пришли из структурного программирования. Специально доказывалось, что при наличии в языке структурных конструкций можно программировать без goto. И в данном случае наличие goto это низкоуровневая оптимизация, типа ассемблрной вставки. Без goto вполне себе можно жить.

Здравствуйте, VoidEx, Вы писали:

VE>Здравствуйте, lse, Вы писали:

lse>>С помощью этих же выражений можно всю программу написать
VE>Я уже привел пример, что нет.
VE>Но вот while действительно получается сахаром.

как это нет? if, goto, := — полная по Тьюрингу комбинация.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, lse, Вы писали:
lse>>Может быть. Ну тогда в С++, где goto есть, while будет являться сахаром. while и еще пол-языка. Ты согласен?
S>Нет, не согласен. Покажи мне эти пол-языка. Не надо преувеличивать мощность goto.

for, while, do...while, class, struct, определение функции (метода), вызов функции (метода) (с полной поддержкой стека), реализация виртуальных вызовов ...

все это можно реализовать полным по Тьюрингу набором — операторы присваивания (предполагающее, само-собой, наличия переменных), условного ветвления, перехода на метку. И согласно твоему определению, все это является сахаром.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, lse, Вы писали:

lse>>Может быть. Ну тогда в С++, где goto есть, while будет являться сахаром. while и еще пол-языка. Ты согласен?

ANS>всякие циклы пришли из структурного программирования. Специально доказывалось, что при наличии в языке структурных конструкций можно программировать без goto. И в данном случае наличие goto это низкоуровневая оптимизация, типа ассемблрной вставки. Без goto вполне себе можно жить.

Я не говорю, что без goto нельзя жить. Я хочу сказать, что наличие этого и некоторых других операторов позволяет реализовать эти самые структурные коннструкции. Из чего автоматом из определения Sinclair, данного в начале темы, следует, что они являеются сахаром.

Я не против самого понятия "сахар" Я только против неверного определения этого понятия

Здравствуйте, lse, Вы писали:
lse>for, while, do...while, class, struct, определение функции (метода), вызов функции (метода) (с полной поддержкой стека), реализация виртуальных вызовов ...
Ничего, кроме операторов цикла, через goto реализовать не удастся.
lse>все это можно реализовать полным по Тьюрингу набором — операторы присваивания (предполагающее, само-собой, наличия переменных), условного ветвления, перехода на метку. И согласно твоему определению, все это является сахаром.
Нет. Сахар действует локально — он не приводит к переписыванию всей программы. Никаким goto ты не заменишь стейтмент, в котором определяется struct.

Здравствуйте, lse, Вы писали:
lse>как это нет? if, goto, := — полная по Тьюрингу комбинация.
Сахар не имеет никакого отношения к полноте по Тьюрингу. Мы же говорим о синтаксическом сахаре — когда один синтаксис является альтернативой другому.
А ты говоришь, фактически, о трансляции в другой язык. К примеру, обработка CFront превратит C++ программу в C программу, но это не означает, что весь C++ состоит из сахара, дополнительного к C++. Потому, что нельзя применить CFront к части исходников, и надеяться, что остальная часть станет работать. К примеру, отказ от встроенной в компилятор поддержки VMT потребует переписать все места вызова метода.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, lse, Вы писали:
lse>>как это нет? if, goto, := — полная по Тьюрингу комбинация.
S>Сахар не имеет никакого отношения к полноте по Тьюрингу. Мы же говорим о синтаксическом сахаре — когда один синтаксис является альтернативой другому.
S>А ты говоришь, фактически, о трансляции в другой язык. К примеру, обработка CFront превратит C++ программу в C программу, но это не означает, что весь C++ состоит из сахара, дополнительного к C++. Потому, что нельзя применить CFront к части исходников, и надеяться, что остальная часть станет работать. К примеру, отказ от встроенной в компилятор поддержки VMT потребует переписать все места вызова метода.

Все же я утверждаю, что можно именно заменить конкретные конструкции и писать сходным образом. См. ответ выше по ветке.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, lse, Вы писали:
lse>>for, while, do...while, class, struct, определение функции (метода), вызов функции (метода) (с полной поддержкой стека), реализация виртуальных вызовов ...
S>Ничего, кроме операторов цикла, через goto реализовать не удастся.

Можно.
Вот, например, определение и вызов функции. При каждом новом вызове функцию нужно модифицировать, это не нарушает определения функции.

int ret;
int param1;
int retVal;

// Определение функции
goto function_end;
function_begin:
//тело функции
if (param1==1)
    retVal=1;
else
    retVal=0;
if (ret==0) // Это исключительно из-за того, что без метапрограммир.
    goto ret0;
else if (ret==1)
    goto ret1;
else if (ret==2)
    goto ret2;
...
function_end:

// Вызов функции
ret=0;
int oldParam=param1;
param1=1; // Передаваемый параметр
goto function_begin;
param1=oldParam; // Не забыть восстановить стек!
ret0:

Вот исключения не реализовать, это да.

lse>>все это можно реализовать полным по Тьюрингу набором — операторы присваивания (предполагающее, само-собой, наличия переменных), условного ветвления, перехода на метку. И согласно твоему определению, все это является сахаром.
S>Нет. Сахар действует локально — он не приводит к переписыванию всей программы.

Вот! Уже лучше. Все, что я хочу — это чтобы ты дополнил нужным образом свое же определение. Я, например, не знаю, как это можно сделать, поэтому интересно...
Но прошу заметить, что все, что я привел, не является переписыванием программы. Те же концепции, реализованные напрямую. Вызов функции, например.

S>Никаким goto ты не заменишь стейтмент, в котором определяется struct.

структура заменится списком, элементы списка будут эквивалентны полям структуры. Далее, работаешь со списком, используя адресную арифметику указателей. Можешь, конечно, возразить, что структура полностью определена в compile-time, а список только в runtime.

Здравствуйте, lse, Вы писали:

S>>Никаким goto ты не заменишь стейтмент, в котором определяется struct.

lse>структура заменится списком, элементы списка будут эквивалентны полям структуры.
А ничего, что поля структуры могут иметь разный тип?
А ничего, что элементы списка собственно сами должны быть структурвми?
lse>Далее, работаешь со списком, используя адресную арифметику указателей.
Я же говорю — придется везде, где мы писали A.b писать некую другую хрень. Например, (int)next(next(A))). Нарушилась локальность.
lse>Можешь, конечно, возразить, что структура полностью определена в compile-time, а список только в runtime.
Угу. Вычислительная эквивалентность всем мозг проела. Забудьте про нее. Тезис Черча интересен только в плане проблемы P=NP. Новые языки программирования создаются не для того, чтобы изменить понятие вычислимости, а для того, чтобы сделать тексты более лаконичными.
Возможность обойтись без некоторой конструкции совсем не относится к сахару. Внутри CPU, как известно, ни шаблонов, ни операторов нет. Вопрос во внутренней структуре самого языка: является ли некоторая локальная синтаксическая конструкция эквивалентом другой?
for() в С++ является чистейшим сахаром для while(). А вот частичная специализация не является сахаром для ручного описания всех видов потребных функций.

Здравствуйте, lse, Вы писали:
lse>Все же я утверждаю, что можно именно заменить конкретные конструкции и писать сходным образом. См. ответ выше по ветке.
Ничего сходного в ответе выше по ветке нет.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, lse, Вы писали:

S>>>Никаким goto ты не заменишь стейтмент, в котором определяется struct.

lse>>структура заменится списком, элементы списка будут эквивалентны полям структуры.
S>А ничего, что поля структуры могут иметь разный тип?
S>А ничего, что элементы списка собственно сами должны быть структурвми?

Ни то, ни другое — не проблема. Первое лечится void* и приведением типов при обращении, второе — указателем на вложенный список. Только структура, полученная таким образом, и struct все-таки будут разными. Под struct-объекты память резервируется на этапе компиляции, это достаточно серъезное различие. Так что пример не катит, т к противоречит определению 1; т е struct — таки не сахар.

Здравствуйте, VladD2, Вы писали:

VD>Поясни, плиз, что мне помешает это сделать? Ну, кроме объемов и запутаности получаемого кода? switch-и строются по двум принципам: на базе вложенных ифоф и на базе таблиц переходов. Обе концепции переписываются на if+goto+присоение. Машинный код будет полностью идетниченый. Не говоря уже о семантике.

The switch instruction implements a jump table. The format of the instruction is an unsigned int32 representing the number of targets N, followed by N int32 values specifying jump targets. These targets are represented as offsets (positive or negative) from the beginning of the instruction following this switch instruction.

The switch instruction pops a value off the stack and compares it, as an unsigned integer, to N. If value is less than N, execution is transferred to the target indexed by value, where targets are numbered from 0 (for example, a value of 0 takes the first target, a value of 1 takes the second target, and so on). If the value is greater than or equal to N, execution continues at the next instruction (fall through).

If the target instruction has one or more prefix codes, control can only be transferred to the first of these prefixes.

Control transfers into and out of try, catch, filter, and finally blocks cannot be performed by this instruction. (Such transfers are severely restricted and must use the leave instruction instead).

Здравствуйте, lse, Вы писали:
lse>Ни то, ни другое — не проблема. Первое лечится void* и приведением типов при обращении, второе — указателем на вложенный список.
Вот этого не понял. Кто куда указатель? Обычный список — просто куча структур (data, next). Из скаляра ты список не построишь.
lse>Только структура, полученная таким образом, и struct все-таки будут разными. Под struct-объекты память резервируется на этапе компиляции, это достаточно серъезное различие. Так что пример не катит, т к противоречит определению 1; т е struct — таки не сахар.
Дело даже не в том, как резервируется память. А в том, что к членам такой "псевдоструктуры" нельзя обратиться по имени через точку.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, lse, Вы писали:
lse>>Ни то, ни другое — не проблема. Первое лечится void* и приведением типов при обращении, второе — указателем на вложенный список.
S>Вот этого не понял. Кто куда указатель? Обычный список — просто куча структур (data, next). Из скаляра ты список не построишь.

Тьфу, черт, не список, конечно, а массив. Его-то можно использовать? Все-таки я же не сказал, что весь С++ можно сахаром назвать, а только половину Массив указателей void*.

lse>>Только структура, полученная таким образом, и struct все-таки будут разными. Под struct-объекты память резервируется на этапе компиляции, это достаточно серъезное различие. Так что пример не катит, т к противоречит определению 1; т е struct — таки не сахар.
S>Дело даже не в том, как резервируется память. А в том, что к членам такой "псевдоструктуры" нельзя обратиться по имени через точку.

По имени нельзя — по индексу можно. Ну да ладно, я же уже признал, что со структурой промахнулся.

Здравствуйте, AndrewVK, Вы писали:

AVK>

The switch instruction implements a jump table...

и?

Здравствуйте, Sinclair, Вы писали:

lse>>for, while, do...while, class, struct, определение функции (метода), вызов функции (метода) (с полной поддержкой стека), реализация виртуальных вызовов ...
S>Ничего, кроме операторов цикла, через goto реализовать не удастся.
lse>>все это можно реализовать полным по Тьюрингу набором — операторы присваивания (предполагающее, само-собой, наличия переменных), условного ветвления, перехода на метку. И согласно твоему определению, все это является сахаром.
S>Нет. Сахар действует локально — он не приводит к переписыванию всей программы. Никаким goto ты не заменишь стейтмент, в котором определяется struct.

Рассуждение о struct и пропуск "for, while, do...while" можно считать, что они является сахаром для С, С++ и даже C#?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>всякие циклы пришли из структурного программирования. Специально доказывалось, что при наличии в языке структурных конструкций можно программировать без goto. И в данном случае наличие goto это низкоуровневая оптимизация, типа ассемблрной вставки. Без goto вполне себе можно жить.

Без стркутрного программирования, как в прочем и без циклов, тоже можно жить. Зачем тему то подменять? Тема была не о крутости циклов супротив готу, а о том как определить сахар.

Здравствуйте, Sinclair, Вы писали:

lse>>как это нет? if, goto, := — полная по Тьюрингу комбинация.
S>Сахар не имеет никакого отношения к полноте по Тьюрингу. Мы же говорим о синтаксическом сахаре — когда один синтаксис является альтернативой другому.

Замечательно. Теперь потрудись учесть в своем определении термина "сахар" эту замечательную мысль. Или просто признай, что этот термин слишком сильно зависит от личного восприятия и не может служить базой для точных утверждений.

Если рассуждать логически, то "сахара" может быть два типа.
1. Вводится алиас для уже имеющейся фичи.
2. Вводится новая фунциональность которую раньше приходилось бы варажать реализацией некоторого паттерна (обещепринятого подхода).

О первом и говорить не чего. А второе это уже введение в язык новой идиомы. Те кто не проникся идиомой будут твердить, что это толко сахар. А те кто проникся будут утверждать, что это полезная фича, так как она позвляет поднять уровень абстракции.

Здравствуйте, VladD2, Вы писали:

AVK>>

The switch instruction implements a jump table...

VD>и?

И то, что в некоторых случаях по конструкции switch компилятор C# порождает команду switch, чего ты никакими фокусами с if и goto не добъешься.

Здравствуйте, AndrewVK, Вы писали:

AVK>И то, что в некоторых случаях по конструкции switch компилятор C# порождает команду switch, чего ты никакими фокусами с if и goto не добъешься.

Ну, я сам ее реализую. И что? Функционал тот же. Производительность та же. Только тарах неимоверно больше.

Или это и есть такой критерий сахара. Все что не порождает тот же ИЛ не сахар. А что порождает — сахар? Тогда в том же Шарпе половина конструкций один фиг сахар. Но многие с этим не согласятся.

Здравствуйте, VladD2, Вы писали:

AVK>>И то, что в некоторых случаях по конструкции switch компилятор C# порождает команду switch, чего ты никакими фокусами с if и goto не добъешься.

VD>Ну, я сам ее реализую. И что? Функционал тот же.

Синтаксический сахар это не когда функционал тот же, а когда результат компиляции идентичен. Абсолютно идентичен.

VD>Тогда в том же Шарпе половина конструкций один фиг сахар.

Какие то — безусловно сахар.