Здравствуйте, PC_2, Вы писали:
UBA>>Ты хотя бы ОО анализ и проектирование с примерами ... читал?
UBA>>
UBA>>Инкапсуляция служит для того, чтобы изолировать интерфейс объекта, отражающий его внешнее поведение, от внутренней реализации объекта
PC_>читай свою книжку по ООП молча, PC_>здесь дяди настолько стары что уже забыли что такое ООП и занялись революционными идеями.
Я считаю уместное замечание в контексте того что инкапсуляция важна не только для безопасности. Там написана правда. Не вся правда, но часть ее. Инкапсуляция относится не только к объектам, и не только к данным, а еще и к коду, который не нужно ломать.
Я лично считаю что инкапсуляция — это прежде всего способ сохранения конечностей себе и окружающим (не дать отстрелить что-либо по недоразумению), и уже потом одно из средств обеспечения безопаности.
Недавно боролся с косяком в C++. Столкнулся с переопределенным общеупотрябимым оператором && в заголовочном файле без ограничения на используемые типы (шаблонный), после чего ломался практически любой код, включающий этот заголовок и использующий этот оператор &&.
В C++ это как раз и есть аналог разъема под японский карбюратор для жигулей. Завел — работает, а далеко ли уедешь — неизвестно.
Здравствуйте, PC_2, Вы писали:
AV>>В прототипировании нет ничего плохого. Но это не имеет никакого отношения к ситуации когда тебе говорят, что у тебя это работает так-то и так (причем верно говорят), а ты обвиняешь их в непонимании
PC_>Влад, меня просто слегка достает что люди видят проблемы там где их нет.
Тут возможны две ситуации. Вариант первый, что ты прав, а твои оппоненты нет. Это означает, что ты не смог донести свои идеи до других. А учитывая, что здесь отметились достаточно головастые товарищи, стоит задуматься как ты планируешь продвигать свой язык. Вариант второй, что проблемы все таки есть.
PC_>Я как разработчик и архитектор сам знаю где там проблемы и догадки меня мало интересуют.
Как раз в этом случае ты отрицал наличие проблемы. И так уже не один раз. В результате закрадываются нехорошие подозрения.
PC_>Особенно учитывая что в среднем 1 из 10 их в точку.
Вообще-то по моим ощущениям скорее 1 из 10 не в точку.
PC_>На то сообщение я ответил что это решаемо и решаемо довольно просто, но сейчас PC_>никто не будет этим заниматься. Работе программ это не мешает.
В случае квадратичной сложности ты даже не намекнул на возможное решение.
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, samius, Вы писали:
S>>Ты думаешь что японский карбюратор лучше согласуется с русской системой питания? Я полагаю что японский карбюратор сдохнет после второй/десятой заправки, если не поставить перед ним японский фильтр и японский насос.
PC_>В том то и дело, чтобы улучшить да и применить Жигули, нужно кучу всяки разных интерфейсов "под себя". PC_>А их нет, как ты говоришь ошибка дизайнеров. Ну не продумали это дяти, не продумали. Сюда монетку можно запихнуть, PC_>а сюда нельзя. И все забито заклепками ( инкапсулировано )
Зато в таком виде она сертифицирована для езды по общественной дорожной сети и обслуживается (в какой-то мере) по гарантии. Если поставишь таки японский карб, то любая ответственность за поломки (пусть даже коробки передач) будет свалена на хозяина. И это правильно. Плохо для владельцев, но правильно для инженеров.
PC_>>>А так это жигули и если клиенту нужно машина побыстрее и побезопасней, то лепить с молотком там подушки безопасности PC_>>>и новый двигатель не имеет смысла. Проще выбросить жигули. И это проблема. PC_>>>Жигули это не конструктор, это галимый конечный автомат выполняющий одну единственную программу "Езжу как жигули". PC_>>>и больше ничего.
Многих не останавливает то что жигули не конструктор. Но давай посмотрим в этом отношении на Тойоту. В Тойоту не лезет карб от Волги или Вейрона... Но это уже смущает гораздо меньшее кол-во людей.
Т.е. в плане полиморфизма Тойота и жигули очень похожи, но это качественно разные машины.
PC_>>>Вот так и все ООП
S>>Про ООП ты начал. Я его не навяливал. Просто в рамках дискуссии об полиморфизме и инкапсуляции ты почему-то вспомнил об ООП. Видимо всплыли шаблоны из не очень качественных книжек. Эти понятия существуют и вне ООП.
PC_>Про что ты общаешся ? PC_>Я тебе на пальцах обьясняю проблемы ООП, почему от него хочу отказаться в РС и чем заменить.
Дык а в чем проблемы-то?
Давай выберем любую машину из существующих (а не жигули) и оценим ее с точки зрения инкапсуляции и полиморфизма. Проблемы с заменой агрегатов мы найдем у любой, но причем тут ООП?
Здравствуйте, PC_2, Вы писали:
PC_>Влад, меня просто слегка достает что люди видят проблемы там где их нет. PC_>Я как разработчик и архитектор сам знаю где там проблемы и догадки меня мало интересуют. PC_>Особенно учитывая что в среднем 1 из 10 их в точку. На то сообщение я ответил что это решаемо и решаемо довольно просто, но сейчас PC_>никто не будет этим заниматься. Работе программ это не мешает.
Пока не убедил
S>Я считаю уместное замечание в контексте того что инкапсуляция важна не только для безопасности. Там написана правда. Не вся правда, но часть ее. Инкапсуляция относится не только к объектам, и не только к данным, а еще и к коду, который не нужно ломать.
Так в том то и суть. Что идеологи ООП недоглядели реальное устроство мира.
И докрутили костыль, в виде жесткого ограничивания данных за оболочкой класса.
Но реально то не так.
Во-первых данные могут мигрировать от класса к классу.
Во-вторых есть централизация прав в государстве. Прав классов на какието данные
Они выписаны в специальных контрактах и эти права динамически.
Это более интеллектуальная и гибкая система, которая отображена в управлении государством
и вообще сколь угодно сложном и живом организме
S>Недавно боролся с косяком в C++. Столкнулся с переопределенным общеупотрябимым оператором && в заголовочном файле без ограничения на используемые типы (шаблонный), после чего ломался практически любой код, включающий этот заголовок и использующий этот оператор &&.
Можна выстрелить, а можно и не выстрелить
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Я предлагаю вместо головастости взять ряд архитектурных задач на себя, проект Опен Сорц.
Тогда очевидно "будете хорошо секти тему" что там и как по архитектуре.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Кстате да, для хитросделаных грушоедов. PC_>В РС появилась наконец библиотечная функция сортировки, меня убедили в необходимости по аналогии с Перлом, PC_>а синтаксис во
PC_>
PC_>SR a
PC_>
PC_>3 символа,
Это образец понятности? А то я, например, ничего не понял. Что значит "SR", что значит "a"?
S>Зато в таком виде она сертифицирована для езды по общественной дорожной сети и обслуживается (в какой-то мере) по гарантии. Если поставишь таки японский карб, то любая ответственность за поломки (пусть даже коробки передач) будет свалена на хозяина. И это правильно. Плохо для владельцев, но правильно для инженеров.
с этим никто не спорит. Молоток сертифицирован для забивания гвоздей и для колки орехов решительно не подходит.
Функция сортировки сертифицирована для сравнения строк по алфавиту, отсортировать по цветам радуги решительно не сертифицирована,
нужно написать такойже свой велосипед и заменить буквально одну строчку
S>Многих не останавливает то что жигули не конструктор. Но давай посмотрим в этом отношении на Тойоту. В Тойоту не лезет карб от Волги или Вейрона... Но это уже смущает гораздо меньшее кол-во людей. S>Т.е. в плане полиморфизма Тойота и жигули очень похожи, но это качественно разные машины.
Так это не дает плюс системе.
Отсудствие унификации ведет к постоянному "дубляжу кода".
Тоесть когда тебе нужно разработать новое авто, все нужно перепроектировать и перетестировать, повесить новый шильдик.
S>Давай выберем любую машину из существующих (а не жигули) и оценим ее с точки зрения инкапсуляции и полиморфизма. Проблемы с заменой агрегатов мы найдем у любой, но причем тут ООП?
при том, что ООП копия неживого автомата.
А не "живой" системы
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
PC_>Я предлагаю вместо головастости взять ряд архитектурных задач на себя, проект Опен Сорц.
Видишь ли в чем проблема. Может я бы и взялся. Но для этого мне надо понять зачем мне это нужно. Пока что я не вижу никакой ценности данного языка. Даже позволю себе несколько более жесткое заявление. Считаю именно эту работу (а не весь Open Source) бессмысленной тратой времени. И еще вижу кучу достаточно плотно расположенных граблей.
Здравствуйте, ambel-vlad, Вы писали:
AV>Это образец понятности? А то я, например, ничего не понял. Что значит "SR", что значит "a"?
это вообще стеб над перлом был.
Потому что глупо было както несколько страниц сравнивать вызов библиотечной функции в перле
и не вызов а сам алгоритм сортировки в РС, пришлось обломать перл в его же стиле
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, ambel-vlad, Вы писали:
AV>Здравствуйте, PC_2, Вы писали:
PC_>>Я предлагаю вместо головастости взять ряд архитектурных задач на себя, проект Опен Сорц.
AV>Видишь ли в чем проблема. Может я бы и взялся. Но для этого мне надо понять зачем мне это нужно. Пока что я не вижу никакой ценности данного языка. Даже позволю себе несколько более жесткое заявление. Считаю именно эту работу (а не весь Open Source) бессмысленной тратой времени. И еще вижу кучу достаточно плотно расположенных граблей.
тогда просто не мешай другим.
Потому что в этом языке ты самая главная грабля и на тебя больше времени уходит
чем на кодинг
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
S>>Я считаю уместное замечание в контексте того что инкапсуляция важна не только для безопасности. Там написана правда. Не вся правда, но часть ее. Инкапсуляция относится не только к объектам, и не только к данным, а еще и к коду, который не нужно ломать.
PC_>Так в том то и суть. Что идеологи ООП недоглядели реальное устроство мира.
Идеологи ООП не претендовали на то что они повторили устройство мира. ООП — это подход к моделированию. Довольно простой, что бы завоевать популярность. Но на точность он не претендовал.
PC_>И докрутили костыль, в виде жесткого ограничивания данных за оболочкой класса.
Нет. Они использовали понятие инкапсуляции. Но оказалось все так, что часть понятия инкапсуляции, использованной в ООП, стала одним из китов ООП, а потом ее стали принимать за догму. PC_>Но реально то не так. PC_>Во-первых данные могут мигрировать от класса к классу.
Это еще один подход к моделированию вселенной. Превосходство его над ООП еще не оценено...
PC_>Во-вторых есть централизация прав в государстве. Прав классов на какието данные PC_>Они выписаны в специальных контрактах и эти права динамически. PC_>Это более интеллектуальная и гибкая система, которая отображена в управлении государством PC_>и вообще сколь угодно сложном и живом организме
Система прав обеспечивает лишь один из аспектов инкапсуляции — нельзя делать это с этими данными. Но не обеспечивает сокрытия реализации, которое может работать на будущую совместимость версий, например.
S>>Недавно боролся с косяком в C++. Столкнулся с переопределенным общеупотрябимым оператором && в заголовочном файле без ограничения на используемые типы (шаблонный), после чего ломался практически любой код, включающий этот заголовок и использующий этот оператор &&.
PC_>Можна выстрелить, а можно и не выстрелить
ну как не выстрелить, если нужно позарез заюзать stl::vector, а он собака этот оператор использует в своих исходниках...
Здравствуйте, samius, Вы писали:
E>>(1..5;('a'..'z').R)\+ E>>Читается так: пять независимо взятых случайных букв объединить путём конкатенации. Что тут сложного? S>Вопросов слишком много о таком выражении.
Ну я же перд этим всё подробно описал и рассказал.
Я думаю, что PC_2 немного погорячился, и для RS логичнее по .R возвращать случайный элемент массива/позицию переборщика.
То есть ('a'..'z').R -- это скаляр, а не переборщик.
S>Я уже писал что не хватает управляющих конструкций (хотя бы LC), комбинаторов, рекурсии.
Про это все в курсе. Сейчас, фактически, обсуждаются, комбинаторы...
S>Но если функций не будет вообще, то и комбинаторы будет комбинировать нечем
Я думаю, что функции нужны. Хотя что именно будет тут функцией -- вопрос тонкий.
Но я вот не понимаю. Если есть идеи, как записывать всякие операции над генераторами непосредственно.
Я вот хочу поиграться с генераторами не точек гиперкубов, и всяких прочих геометрических фигур, а с чем-то более хитрым. Скажем с генератором путей в графе, с алгоритмом А* и т. д...
S>Для меня нет никакого интереса писать самому, если есть библиотечное решение. Более того, если я что-то раз написал, с вероятностью 90% я это смогу реюзнуть. Я пишу относительно обобщенный код.
Это очень ценное замечание, но оно не о том.
E>>Мы же язык хотим придумать, а не библиотеку? S>Язык, не позволяющий создавать библиотеки — не нужен. Если мне сейчас скажут что в РС не будет библиотек — единственная цель с которой я тут останусь — доставать ТС-а.
И это не о том.
Во-первых, само по себе это утверждение не совсем верно. Например, язык регулярных выражений не позволяет создавать библиотеки, но, тем не менее, кому-то нужен.
Во-вторых, если у тебя есть идеи про функции, можешь их предложить. А если ты говоришь о функциях, как в С#, например, то их всегда можно вставить... Что тут обсуждать-то?
S>Это отображение последовательности случайных чисел в символы. считай что это map (не контейнер из stl, а глагол "отображать"). Просто в Linq-е решили поглумиться и сделали SQL подобное название для функции "отобразить". Очень неудачно. Но могу заверить, что прямая аналогия этому методу в F#, Haskell, OCaml и т.п. язках — это map.
А map зачем? А -1?
Я понимаю, почему так в линке получилось, но я согласен с ТС, что неудачно это всё написано. Много лишнего. Не факт, что это плохо, но не понятно, чем плохо попытаться избавиться от излишеств-то?
S>Нет, не согласен. Сложение генераторов отождествляется с операцией concat (последовательное склеивание последовательностей). На C++ у тебя написан zip. Не согласен с выбором символа для операции.
А в RS нет никакого сложения генераторов. Вернее есть оператор, который добавляет в переборщик/массив ещё один элнмент, или несколько. Это запятая.
!x = (1, 2, 5)
x ,= 7
даёт 1, 2, 5, 7
Что будет, если сделать так: (x, x). Насколько я понимаю, этот вопрос пока не проработан.
E>>>>Тогда ПОЛНОЕ описание будет таким: E>>>>!m=1..5 E>>>>('a'..'z')#m/m/+ S>Плохо то, что это решение размещений с повторениями, а нам нужно без них.
Почему без них? Вроде с повторениями хотели.
Можно подумать, как без повторений сделать. Есть очевидный путь. Описать предикат "в строке нет повторов" и профильтровать генератор.
Но это неэффективно, зато просто.
Но я думаю, что если подумать над тензороподобными записями, то получится и без повторений записать. Только я сейчас не готов проанализировать что есть и чего не хватает для этого.
Но лично мне кажется, что надо смотреть по другим задачам. Путям на графах, КС-грамматиках и т. д.
S>Для размещений с повторами — да нужны N вложенных циклов, которые удалось записать складыванием переборщиков. Это правильно. S>Но только повторов быть не должно по условию. S>Можно конечно отфильтровать результат — но это не спортивный ход.
Ну да. Я выше уже написал.
S>Eval дает хорошие возможности по комбинированию вычислений. Но я считаю что прежде всего нужно озадачиться управляющими конструкциями и вывести язык на уровень хотя бы теоретической возможности решения всех задач, в том числе итеративных с окончанием итераций по условию (про разные возможности записи итераций я писал выше). Это надо сделать, а потом закинуть если не интересно развивать в этом направлении. Но пока этого нет — язык скуден до безобразия. Это во-первых.
Ну и что, что скуден? Если у тебя есть идеи по управлению -- давай делись!
S>Во-вторых — будь у тебя средство комбинирования счетчиков как ты привел выше (для задачи размещений с повторениями), стал бы ты использовать Eval для решения этой задачи?
Да не надо о eval думать! Понятно, что на eval можно сделать то, что в лиспе называют сложной рекурсией (это когда функция формирует код следующей и вызывает его, и так далее). Но не понятно зачем этим заниматься не на лиспе. Во всяком случае про сложную рекурсию более или менее всё понтяно. А про тензоры-переборщики -- пока что нет...
S>Так вот, во многих языках с богатыми возможностями композиции кода Eval просто не нужен. А может я просто не умею его готовить. Да и не люблю, честно говоря, в рантайме генерить код без серьезной необходимости.
Предлагаю забить на eval!
Я, кстати, думаю, что "когда всё станет хорошо", в RS будет много встроенных операций над переборщиками. Но поиграться не мешает пока...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, PC_2, Вы писали:
PC_>Здравствуйте, ambel-vlad, Вы писали:
PC_>Я предлагаю вместо головастости взять ряд архитектурных задач на себя, проект Опен Сорц. PC_>Тогда очевидно "будете хорошо секти тему" что там и как по архитектуре.
Брать на себя не договорившись с главным идеологом? Чтобы потом весело провести время в разруливании последствий?
Не, ты попал. Теперь у тебя есть комитет, почти как у Бьёрна Пока не согласуешь — не выпустишь стандарт.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, PC_2, Вы писали:
S>Это еще один подход к моделированию вселенной. Превосходство его над ООП еще не оценено...
та собственно уже почти оценено. На sql модератор хотел квадрат от прямоугольника пронаследовать и тогда я понял
идеальное христоматийное применение. Например фигура могла бы мигрировать от класса Квадрат к классу Прямоугольник
на основе свойства "все стороны равны". А ООП эту простейшую проблему решает реально криво, хоть и тоже пытается
взять ее за христоматийный пример ООП.
S>Система прав обеспечивает лишь один из аспектов инкапсуляции — нельзя делать это с этими данными. Но не обеспечивает сокрытия реализации, которое может работать на будущую совместимость версий, например.
Не нужно реализацию скрывать. Пускай живет себе открыто.
S>>>Недавно боролся с косяком в C++. Столкнулся с переопределенным общеупотрябимым оператором && в заголовочном файле без ограничения на используемые типы (шаблонный), после чего ломался практически любой код, включающий этот заголовок и использующий этот оператор &&. S>ну как не выстрелить, если нужно позарез заюзать stl::vector, а он собака этот оператор использует в своих исходниках...
для тебя просто не очевиден другой аспект проблемы. То что в тупую переопределили оператор, это конечно глупо.
Но в системах более хорошей абстракции, можно было бы определить, что каждая строка такогото шаблона переводится по шаблону.
И что ? Получили бы тривиальную локализацию любой сложной системы на любой разговорный язык.
Или например добавили особое логирование ошибок в каждой строчке где встречается такая комбинация переменных.
И вместо тотального решета трай кетч, получили бы чистинький код.
Короче применений здесь именно практичных очень много.
Система ведет себя очень гибко.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, samius, Вы писали:
E>Я думаю, что PC_2 немного погорячился, и для RS логичнее по .R возвращать случайный элемент массива/позицию переборщика. E>То есть ('a'..'z').R -- это скаляр, а не переборщик.
Я понял
S>>Я уже писал что не хватает управляющих конструкций (хотя бы LC), комбинаторов, рекурсии. E>Про это все в курсе. Сейчас, фактически, обсуждаются, комбинаторы...
Нами с тобой. Автору-то до них дела нет
S>>Но если функций не будет вообще, то и комбинаторы будет комбинировать нечем E>Я думаю, что функции нужны. Хотя что именно будет тут функцией -- вопрос тонкий. E>Но я вот не понимаю. Если есть идеи, как записывать всякие операции над генераторами непосредственно. E>Я вот хочу поиграться с генераторами не точек гиперкубов, и всяких прочих геометрических фигур, а с чем-то более хитрым. Скажем с генератором путей в графе, с алгоритмом А* и т. д...
Пути в графе это примерно то же самое, что и пути в гиперкубе. Берется алгоритм поиска путей в графе (их много, но возьмем любой конкретный, возвращающий множество путей, а не один) и пишется в форме генератора.
IEnumerable<Path> ShortestPathes<V,E>(IEnumerable<E>, V sourceVertex);
Т.е. получать пути мы уже можем.
Можем так же маппировать пути в строки (map, Select), можем брать первые 5 путей (Take), можем фильтровать (Where(p => p.Length < 3)), склеивать пути (Concat, SelectMany)...
А что за алгоритм A* ?
E>>>Мы же язык хотим придумать, а не библиотеку? S>>Язык, не позволяющий создавать библиотеки — не нужен. Если мне сейчас скажут что в РС не будет библиотек — единственная цель с которой я тут останусь — доставать ТС-а. E>И это не о том. E>Во-первых, само по себе это утверждение не совсем верно. Например, язык регулярных выражений не позволяет создавать библиотеки, но, тем не менее, кому-то нужен.
Согласен. Я имел в виду язык общего назначения, а не DSL.
E>Во-вторых, если у тебя есть идеи про функции, можешь их предложить. А если ты говоришь о функциях, как в С#, например, то их всегда можно вставить... Что тут обсуждать-то?
До сих пор обсуждалась возможность вставки функций вообще. И последнюю неделю ТС был против любых функций/грушек вообще. И только сейчас он заговорил о полиморфных функциях.
S>>Это отображение последовательности случайных чисел в символы. считай что это map (не контейнер из stl, а глагол "отображать"). Просто в Linq-е решили поглумиться и сделали SQL подобное название для функции "отобразить". Очень неудачно. Но могу заверить, что прямая аналогия этому методу в F#, Haskell, OCaml и т.п. язках — это map. E>А map зачем? А -1?
map — это отображение последовательности 1..10 в последовательность квадратов. -1 — не помню что бы там был -1. (^2) — это сечение функции возведения в степень.
E>Я понимаю, почему так в линке получилось, но я согласен с ТС, что неудачно это всё написано. Много лишнего. Не факт, что это плохо, но не понятно, чем плохо попытаться избавиться от излишеств-то?
Лишний синтаксис — согласен. Семантики лишней там нет.
S>>Нет, не согласен. Сложение генераторов отождествляется с операцией concat (последовательное склеивание последовательностей). На C++ у тебя написан zip. Не согласен с выбором символа для операции.
E>А в RS нет никакого сложения генераторов. Вернее есть оператор, который добавляет в переборщик/массив ещё один элнмент, или несколько. Это запятая. E>!x = (1, 2, 5) E>x ,= 7 E>даёт 1, 2, 5, 7
Это добавит лишних итераций к тому же циклу, а не вложенные. E>Что будет, если сделать так: (x, x). Насколько я понимаю, этот вопрос пока не проработан.
Угу
E>>>>>Тогда ПОЛНОЕ описание будет таким: E>>>>>!m=1..5 E>>>>>('a'..'z')#m/m/+ S>>Плохо то, что это решение размещений с повторениями, а нам нужно без них. E>Почему без них? Вроде с повторениями хотели.
Речь шла об уникальности символов в пароле. В какой это было форме конкретно — я уже не помню. А найти уже не просто.
E>Можно подумать, как без повторений сделать. Есть очевидный путь. Описать предикат "в строке нет повторов" и профильтровать генератор. E>Но это неэффективно, зато просто.
неинтересно
E>Но я думаю, что если подумать над тензороподобными записями, то получится и без повторений записать. Только я сейчас не готов проанализировать что есть и чего не хватает для этого. E>Но лично мне кажется, что надо смотреть по другим задачам. Путям на графах, КС-грамматиках и т. д.
КС-грамматики? Чему это поможет?
S>>Eval дает хорошие возможности по комбинированию вычислений. Но я считаю что прежде всего нужно озадачиться управляющими конструкциями и вывести язык на уровень хотя бы теоретической возможности решения всех задач, в том числе итеративных с окончанием итераций по условию (про разные возможности записи итераций я писал выше). Это надо сделать, а потом закинуть если не интересно развивать в этом направлении. Но пока этого нет — язык скуден до безобразия. Это во-первых. E>Ну и что, что скуден? Если у тебя есть идеи по управлению -- давай делись!
Я уже устал делиться идеей посмотреть как это сделано в функциональных языках. Комбинаторы генераторов позволят много чем управлять, если будут средства к написанию своих генераторов и комбинаторов. А без средств мы не сможем сделать генератор путей в графе, если его не втащить в ядро языка.
S>>Во-вторых — будь у тебя средство комбинирования счетчиков как ты привел выше (для задачи размещений с повторениями), стал бы ты использовать Eval для решения этой задачи? E>Да не надо о eval думать! Понятно, что на eval можно сделать то, что в лиспе называют сложной рекурсией (это когда функция формирует код следующей и вызывает его, и так далее). Но не понятно зачем этим заниматься не на лиспе. Во всяком случае про сложную рекурсию более или менее всё понтяно. А про тензоры-переборщики -- пока что нет...
Я плохо и давно учился в шклое. Слово тензор помню, а что в него вкладывается — нет.
S>>Так вот, во многих языках с богатыми возможностями композиции кода Eval просто не нужен. А может я просто не умею его готовить. Да и не люблю, честно говоря, в рантайме генерить код без серьезной необходимости. E>Предлагаю забить на eval!
Поддерживаю
E>Я, кстати, думаю, что "когда всё станет хорошо", в RS будет много встроенных операций над переборщиками. Но поиграться не мешает пока...
Основных комбинируюих операций над генераторами не очень много. 10-20 можно наскрести. Но проблема в том, что эти же комбинаторные операции могут работать не только с генераторами, а и с другими сущностями. См. monad / computation expressions. C# немного умеет работать с первой вещью, F# и Nemerle с обоими.
Если не рассмотреть эти возможности с самого начала, то велик риск нагородить костылей, мешающих прикрутить нечто в последствии.
Это прежде всего к тому, что операции над перебощиками не должны быть встроены в ядро. Язык должен быть заточен на удобное использование таких операций — это да. Т.е. сахарок. Но сами операции в ядро — это ограничение гибкости.
