Добавить методы в О7/13

[vlad]

А все расширизмы выльются в одну опцию компилятора, или в несколько (ну по крайней мере как задумывается )?

Одна опция. Пока нет причин делать тонкий тюнинг фич.

[valexey_u]

Очень советую посмотреть как это все сделано в двух языках:
1) Go
2) Modula-3
3) Haskell

Ибо смотреть только со стороны Симула->С++->Java как-то однобоко :-)

[vlad]

Причем не стоит забывать и о внеязыковых методах решения проблемы.

Не помню рассказывал я или нет... В какой-то момент я пробовал писать на макроассемблере. Соответственно, там были макросы. И можно было писать:
do_something1();
do_something2();
...

Была видимость, что это почти ЯВУ. Главное макросы нужные написать. Проблема была в том, что это была только видимость Потому что все интересное (во всех смыслах) было внутри макросов. И оно было по-прежнему на ассемблере.

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

[vlad]

Очень советую посмотреть как это все сделано в двух языках:
1) Go
2) Modula-3
3) Haskell

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

[valexey_u]

Причем не стоит забывать и о внеязыковых методах решения проблемы.

Не помню рассказывал я или нет... В какой-то момент я пробовал писать на макроассемблере. Соответственно, там были макросы. И можно было писать:
do_something1();
do_something2();
...

Была видимость, что это почти ЯВУ. Главное макросы нужные написать. Проблема была в том, что это была только видимость Потому что все интересное (во всех смыслах) было внутри макросов. И оно было по-прежнему на ассемблере.

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

Аналогия не катит - если бы я предлагал писать макросы для IDE на каждый чих - то было бы засчитано, а так нет :-)

Нужно выявить что именно неудобно и почему и подумать как это дело закткнуть. См. ту же Модулу - там язык не оторван от инструментария и спокойно продолжается в системе сборки например. К слову дженерики там частично реализованы именно в системе сборки. И это чертовски удобно! Очень хорошо когда система сборки знает что-то про язык.

[vlad]

Нужно выявить что именно неудобно и почему и подумать как это дело закткнуть. См. ту же Модулу - там язык не оторван от инструментария и спокойно продолжается в системе сборки например. К слову дженерики там частично реализованы именно в системе сборки. И это чертовски удобно! Очень хорошо когда система сборки знает что-то про язык.

Допустим. Есть конкретная проблема. Я предложил расширить язык. Как это сделать без расширения языка (посредством системы сборки или не знаю чего еще) я не могу придумать (в отличие от дженериков). У тебя есть идеи?

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

[valexey_u]

Нужно выявить что именно неудобно и почему и подумать как это дело закткнуть. См. ту же Модулу - там язык не оторван от инструментария и спокойно продолжается в системе сборки например. К слову дженерики там частично реализованы именно в системе сборки. И это чертовски удобно! Очень хорошо когда система сборки знает что-то про язык.

Допустим. Есть конкретная проблема. Я предложил расширить язык. Как это сделать без расширения языка (посредством системы сборки или не знаю чего еще) я не могу придумать (в отличие от дженериков). У тебя есть идеи?

Это тот Type.js переписать шоле?

[vlad]

Ибо смотреть только со стороны Симула->С++->Java как-то однобоко :-)

Глянул модулу по диагонали. Ну не нравится мне смешивание данных (полей объекта) и контракта (методов).
Кроме того, из общих соображений: хочется иметь максимально чистую декларативную часть. Интерфейсы, как отдельная сущность, ее обеспечивают.

[vlad]

Это тот Type.js переписать шоле?

Да.

[vlad]

Это тот Type.js переписать шоле?

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

[valexey_u]

Это тот Type.js переписать шоле?

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

Я правильно понимаю что тебе нужна некая дополнительная гибкость? Можешь рассказать для чего именно и какая именно гибкость нужна конкретно вот в компиляторе? Ну, то есть под какого рода изменчивость код нужно приспособить, и зачем.

[vlad]

Я правильно понимаю что тебе нужна некая дополнительная гибкость?

Да. Мне нужно много реализаций одного и того же абстрактного интерфейса. Т.к., в обероне Вирт под абстрактным интерфейсом и сокрытием реализации подразумевает интерфейс модуля, то его подход не масштабируется на мой случай.

Можешь рассказать для чего именно и какая именно гибкость нужна конкретно вот в компиляторе? Ну, то есть под какого рода изменчивость код нужно приспособить, и зачем.

Есть сущность, отвечающая за представления Типа в компилтяторе. У типа есть описание (description), который разный для разных классов типов (чтоб не написать типов типов). Этот description замечательно ложится в ООП на метод расширяемого Type. Внезапно оказывается, что в обероне методов нет...
Вот ссылка на код еще раз (конкретнее некуда): https://github.com/vladfolts/oberonjs/blob/master/src/type.js

[vlad]

[Geniepro]

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

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

[valexey_u]

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

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

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