>>У вас два DSeL. Как они стыкуются? >Как стек. Один на другом. Нижний о верхнем ничего не знает.
О!
А параллельной композиции быть не может? Типа, "вот здесь играем, а здесь рыбу заворачиваем". Клиент-сервер, такого рода. Нельзя такого сделать?
>Задача должна быть описана на самом верхнем уровне, самым высокоуровневым DSL, непосредственно описывающим саму задачу в ее терминах. Этот DSL должен компилироваться в нижележащий DSL, работающий, например, с абстракциями доступных программных средств, и так далее. И вот когда мы изменяем спецификацию задачи, на верхнем уровне, изменения автоматически распространяются на нижележащие слои, без непосредственной работы с ними. Верификация происходит на всех уровнях слоях DSL, естественно. Если DSL не принимает какую-либо "форму", он кричит нам об ошибке, при компиляции.
Ну, представьте себе, что у вас изменилась спецификация входов и выходов одной из компонент, но общая структура (спецификация верхнего уровня, просто налаживающая отношения между компонентами) осталась прежней. Кто и где у вас будет ругаться?
>Это не может полностью защитить от ошибок в логике, но в отличие от типизации, это уменьшит шанс возникновения логических ошибок, за счет сужения сущностей, с которыми мы работаем, за счет максимальной специализации кода под задачу.
А.
С GADT (generalized algebraic data types) вы знакомы? Как с их помощью построить типобезопасный интерпретатор знаете?
Доступно ли у вас аналог type erasure? Гарантирован ли он? Можете ли вы привести пример гарантии непустого списка на входе в функцию head?
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2011-11-02 01:00 pm (UTC)>Как стек. Один на другом. Нижний о верхнем ничего не знает.
О!
А параллельной композиции быть не может? Типа, "вот здесь играем, а здесь рыбу заворачиваем". Клиент-сервер, такого рода. Нельзя такого сделать?
>Задача должна быть описана на самом верхнем уровне, самым высокоуровневым DSL, непосредственно описывающим саму задачу в ее терминах. Этот DSL должен компилироваться в нижележащий DSL, работающий, например, с абстракциями доступных программных средств, и так далее. И вот когда мы изменяем спецификацию задачи, на верхнем уровне, изменения автоматически распространяются на нижележащие слои, без непосредственной работы с ними. Верификация происходит на всех уровнях слоях DSL, естественно. Если DSL не принимает какую-либо "форму", он кричит нам об ошибке, при компиляции.
Ну, представьте себе, что у вас изменилась спецификация входов и выходов одной из компонент, но общая структура (спецификация верхнего уровня, просто налаживающая отношения между компонентами) осталась прежней. Кто и где у вас будет ругаться?
>Это не может полностью защитить от ошибок в логике, но в отличие от типизации, это уменьшит шанс возникновения логических ошибок, за счет сужения сущностей, с которыми мы работаем, за счет максимальной специализации кода под задачу.
А.
С GADT (generalized algebraic data types) вы знакомы? Как с их помощью построить типобезопасный интерпретатор знаете?
Доступно ли у вас аналог type erasure? Гарантирован ли он? Можете ли вы привести пример гарантии непустого списка на входе в функцию head?