>синтаксические расширения типа макросов и EDSL служат для той же цели, что и типы - для раннего обнаружения ошибок. "Наглядность" - это быстрое понимание структуры кода и обнаружение неисправностей.
Кроме того макросы позволяют снизить цикломатическую сложность кода, путем заталкивая бойлерплейта, неизбежно возницающего из-за несоответствия между сущностями предметной области и сущностями языка программирования обзщего назначения, в реализацию макроса.
>Только типы 1) могут быть сущностями первого класса
В случае с макросистемой: код - сущность первого класса, а макросы - нет В случае с системой типов: тип - сущность первого класса, а сама система типов - нет. Или существуют способы передавать систему и параметризовывать ею код?
На мой взгляд, ситуация идентичная, хотя я встречал утверждения, что макросы могут задавать систему типов, но я не понимаю, как это может работает.
>2) много мощнее макросов.
Я уже писал, что считаю типы ортоганальными макросам, потому не ясно на основании каких каких критериев можно сделать подобный вывод.
>До изобретения do-нотации использовали >>=, >> и return. И сейчас используют. И теряют совсем немного (и часто выигрывают).
do-нотация - это лишь пример синтаксического сахара, которого в Haskell в большом достатке. Или list comprehensions тоже не используются? При этом в Haskell они есть, но через типы их сделать нельзя.
>Предметные области могут быть параметризованы. Предметная область "язык программирования" может быть параметризована предметной областью компилятор и предметной областью интерпретатор.
Это не параметризация предментной области, а просто различные реализации. Это было бы очень неприятно, если бы в случае с компилятором у нас был бы один язык, а с интерпретатором - другой. Не смотря на то, что в Haskell сделано именно так: ghci забрасывать пользователя прямиков внутрь IO-монады, после чего пользователь наслаждается всеми прелестями do-нотации, полезность которой вы отрицаете, я считаю это плохой практикой. При этом проблемы с реализаций различного поведения на макросах быть не должно. В одном случае сайд-эффекты будут применятся по ходу процесса разбора и типизации, а в другом - после.
>А можно использовать только систему типов. См. зависимые типы данных.
Simon Peyton-Jones и компания решили, что для монад и списков нужен сахар, как и во многих других местах. Если бы системы типов было бы достаточно, сахар бы не множился. Сама реальность языка Haskell опровергает это вашей утверждение. В этом констексте, интересно было бы узнать, что именно натолкнуло разработчиков Скалы на запиливание макросов в язык.
no subject
Кроме того макросы позволяют снизить цикломатическую сложность кода, путем заталкивая бойлерплейта, неизбежно возницающего из-за несоответствия между сущностями предметной области и сущностями языка программирования обзщего назначения, в реализацию макроса.
>Только типы 1) могут быть сущностями первого класса
В случае с макросистемой: код - сущность первого класса, а макросы - нет
В случае с системой типов: тип - сущность первого класса, а сама система типов - нет.
Или существуют способы передавать систему и параметризовывать ею код?
На мой взгляд, ситуация идентичная, хотя я встречал утверждения, что макросы могут задавать систему типов, но я не понимаю, как это может работает.
>2) много мощнее макросов.
Я уже писал, что считаю типы ортоганальными макросам, потому не ясно на основании каких каких критериев можно сделать подобный вывод.
>До изобретения do-нотации использовали >>=, >> и return. И сейчас используют. И теряют совсем немного (и часто выигрывают).
do-нотация - это лишь пример синтаксического сахара, которого в Haskell в большом достатке. Или list comprehensions тоже не используются? При этом в Haskell они есть, но через типы их сделать нельзя.
>Предметные области могут быть параметризованы. Предметная область "язык программирования" может быть параметризована предметной областью компилятор и предметной областью интерпретатор.
Это не параметризация предментной области, а просто различные реализации. Это было бы очень неприятно, если бы в случае с компилятором у нас был бы один язык, а с интерпретатором - другой. Не смотря на то, что в Haskell сделано именно так: ghci забрасывать пользователя прямиков внутрь IO-монады, после чего пользователь наслаждается всеми прелестями do-нотации, полезность которой вы отрицаете, я считаю это плохой практикой. При этом проблемы с реализаций различного поведения на макросах быть не должно. В одном случае сайд-эффекты будут применятся по ходу процесса разбора и типизации, а в другом - после.
>А можно использовать только систему типов. См. зависимые типы данных.
Simon Peyton-Jones и компания решили, что для монад и списков нужен сахар, как и во многих других местах. Если бы системы типов было бы достаточно, сахар бы не множился. Сама реальность языка Haskell опровергает это вашей утверждение. В этом констексте, интересно было бы узнать, что именно натолкнуло разработчиков Скалы на запиливание макросов в язык.