Здравствуйте, IT, Вы снимали: Здесь.

Классно! Первая презентация, где наглядно видно "чем что лучше Немерле". Спасибо!
Пара вопросов:
1. А в чём делалась презентация? Выглядит клёво, с "зумом" и "подсветкой" получается оч наглядно.
2. Алгебраические типы: всё равно не ясно, что же это такое. Просто несколько классов внутри другого? А в чём бенефит? А просто иерархия — её недостаточно для матчинга (в частности, вот для этого SQL-оптимизатора)?
3. Можно ли "передавать управление" в матчинге? (goto case)

M>2. Алгебраические типы: всё равно не ясно, что же это такое. Просто несколько классов внутри другого? А в чём бенефит? А просто иерархия — её недостаточно для матчинга (в частности, вот для этого SQL-оптимизатора)?

Можно почитать:
— Кратко про алгебраические типы
— Более длинно про алгебраические типы
Размеченные объединения позволяют компактно описывать весьма сложные структуры данные и определяют способ работы с ними через паттер-матчинг. Чтобы увидеть "бефенит", можно попробовать записать дерево (или даже граф) через АТД, а потом переписать в какую-то более императивную форму (список ребер, матрица смежности и тд). Думаю, разница будет очевидна.

M>3. Можно ли "передавать управление" в матчинге? (goto case)
goto никаким образом к паттерп-матчингу не относится. Откуда и куда нудно "передавать управление" ?

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

M>>2. Алгебраические типы: всё равно не ясно, что же это такое.
STD>Можно почитать:
STD>- Кратко про алгебраические типы

Хм... это же бред полный! "Барин, нам бы попроще, как для нормальных!".
По-моему, описанная "математика" — это чисто академическая штуковина, заниматься которой в реальных программах можно только сильно упростив до частных, практических случаев.
Когда IT показывает сопоставление кортежей (типа |(a, _, c) => ....), не думаю, что есть особый смысл влезать в дифференцирование типов — "на пальцах" всё намного нагляднее и главное — ты можешь сам начать это использовать. Просто теория "а теперь мы можем умножить эти типы!" ничего не даёт.
И ещё: мне постоянно мерещится что-то типа си-шных unions — это не оно?


STD>Чтобы увидеть "бефенит", можно попробовать записать дерево (или даже граф) через АТД

Ага. Осталось дело за малым — понять, что такое АТД и только тогда уже "записать дерево". Я не смогу увидеть преимуществ, если я даже не знаю, что и как описывать.

STD>, а потом переписать в какую-то более императивную форму

Да легко! Как раз когда понимаешь, как твои данные сидят в памяти и как ты ими можешь оперировать, задача превращается в тривиальщину. Вот структуры, объединения, указатели — понимаю, а variant — что-то типа union на типах, наверное, но опять же, почему недостаточно классического ООПшного наследования, чтобы всем этим красиво оперировать? Ведь ПМ позволяет "матчить" типы? (и даже объекты)


M>>3. Можно ли "передавать управление" в матчинге? (goto case)
STD>goto никаким образом к паттерп-матчингу не относится. Откуда и куда нудно "передавать управление" ?

Прям даже и не знаю, что сказать...

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

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

M>И ещё: мне постоянно мерещится что-то типа си-шных unions — это не оно?
В статье, которая длинней статье про это есть. Да, используется похожий механизм.

M>...Ведь ПМ позволяет "матчить" типы? (и даже объекты)
В Nemerle паттер-матчинг разбирает объекты, но с помощью выражения when можно уточнить тип.

STD>>goto никаким образом к паттерп-матчингу не относится. Откуда и куда нудно "передавать управление" ?
M>Прям даже и не знаю, что сказать...
Поговаривают, что можно открыть наймспэйс Nemerle.Imperative и случится что-то ужасное, но я таким пока не пользовался. В любом случае, в стетье по вашей ссылке описана одна их самых худших практик, которые только могут быть. Очень надеюсь, что Nemerle такое не позволяет.

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

STD>А вы попробуйте почитать.

Собсно, мой коммент и был рождён прочтением "напальцевой" статьи. И из "2+2" у меня не вытекает "int + int" Это даже не объяснение, а попытка привести аналогии, но без объяснения самой сути.
Пока я только "механически" понимаю, что в вариант можно засунуть типы (только их?). Чем они хороши супротив иерархии — я пока нипонимай.

STD>А позиция "математика — чисто академическая штука" ущербна. Прорывы в индустрии....

Не-не, "бороздить просторы Большого Театра" мы будем потом. Понятно, что куча программ только из науки и состоит (архиваторы, обработка изображений, криптография...), однако, незнание гидрокрекинга нефти не мешает водителю крутить баранку! Тут аналогично: я хочу по методу индукции сначала понять простые и практические составляющие, а потом уже пижонить на форумах "это же АТД!".

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

Это подход далёких от программирования теоретиков. "На бумаге" ты уверенно складываешь бесконечные ряды, а потом садишься за комп и ... пук! "Максимальная точность — 10 разрядов, скорость обработки — 100МГц".
Да и потом, с теории разумно начинать тому, кто и продолжать будет в той же теории. А когда тебе нужно "сваять морду к базе", буквально пятиминутный урок "таблица-ключ-индекс" тебе спокойно позволит делать промышленные системы, не вдаваясь в "десятую нормальную форму" и "теорию множеств".

STD>Поговаривают, что можно открыть наймспэйс Nemerle.Imperative и случится что-то ужасное

Знаю! Откроется ящих пандорры, набигут домики деревяные императивщики и испохабят светлую идею "чистой функциональщины". Хотя как раз приверженцы маргинальных идей пугают больше всего Мыслим мы всё равно императивно. Ладно, бог с ним, с goto, пока важнее понять пределы ПМ.

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

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

M>>>2. Алгебраические типы: всё равно не ясно, что же это такое.
STD>>Можно почитать:
STD>>- Кратко про алгебраические типы

M>Хм... это же бред полный! "Барин, нам бы попроще, как для нормальных!".

Поддерживаю.

M>Да легко! Как раз когда понимаешь, как твои данные сидят в памяти и как ты ими можешь оперировать, задача превращается в тривиальщину. Вот структуры, объединения, указатели — понимаю, а variant — что-то типа union на типах, наверное, но опять же, почему недостаточно классического ООПшного наследования, чтобы всем этим красиво оперировать? Ведь ПМ позволяет "матчить" типы? (и даже объекты)

Поддерживаю.

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

M>1. А в чём делалась презентация? Выглядит клёво, с "зумом" и "подсветкой" получается оч наглядно.

Camtasia Studio. На редкость глючная штуковина.

M>2. Алгебраические типы: всё равно не ясно, что же это такое. Просто несколько классов внутри другого? А в чём бенефит? А просто иерархия — её недостаточно для матчинга (в частности, вот для этого SQL-оптимизатора)?

При задании опции варианта компилятор автоматически ассоциирует поля варианта с параметрами паттерна, что даёт очень компактный синтаксис задания варианта, похожий на вызов конструктора. Я об этом говорю в самом конце. Для обычных типов такую ассоциацию тоже можно задать, если у нас есть плоская одноуровневая иерархия, например, System.Linq.Expressions.

Бенефит плоской иерархии может быть не так очевиден, но наблюдая за тем как я сам последнее время проектирую структуры данных на C#, то могу признаться, что у меня всё время полуаются ADT. Как-то оно проще и понятнее. Могу сравнить это с тем как после перехода на C++ мне приходилось писать на C и в моих функциях на C стал появлятся первый параметр с названием 'this'. Т.е. даже на C я уже проектировал приложения в объектно ориентированном стиле. Так и здесь. Как не проектируй данные, а всё время получается ADT

M>3. Можно ли "передавать управление" в матчинге? (goto case)

Нельзя. Подобные задачи гораздо изящнее решаются с помощью локальных функций.

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

IT>Здесь.

Внезапно оказалось, что я многого не знал про матчинг в Немерле. Спасибо за каст!