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

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

S>>Многих не останавливает то что жигули не конструктор. Но давай посмотрим в этом отношении на Тойоту. В Тойоту не лезет карб от Волги или Вейрона... Но это уже смущает гораздо меньшее кол-во людей.
S>>Т.е. в плане полиморфизма Тойота и жигули очень похожи, но это качественно разные машины.

PC_>Так это не дает плюс системе.
PC_>Отсудствие унификации ведет к постоянному "дубляжу кода".
PC_>Тоесть когда тебе нужно разработать новое авто, все нужно перепроектировать и перетестировать, повесить новый шильдик.
Там есть своя модульность, уверяю. У тех же жигулей шла одна деталь на весь ряд классик + Ока. А другая на весь ряд классик и самар. Но протестировать конечно надо.

S>>Давай выберем любую машину из существующих (а не жигули) и оценим ее с точки зрения инкапсуляции и полиморфизма. Проблемы с заменой агрегатов мы найдем у любой, но причем тут ООП?

PC_>при том, что ООП копия неживого автомата.
Любая программа — неживой автомат. И написанная на РС — тоже. Попробуй поспорь.
PC_>А не "живой" системы
Для того что бы сделать копию живой системы, одним языком не обойдешься.

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

S>Проблема. В текущем дизайне языка в их ленивости смысла нет, т.к. они по природе своей проходят от начала диапозона до конца и не останавливаются посередине. Сделаешь их ленивыми — они все равно не смогут остановиться.

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

Один из путей, возможно правильный -- поручить самим переборщикам осуществлять всякие хитрые операции, вроде поиска, или разбиения на поддиапазоны, скажем... Поиска медианы, двухпутевого слияния, сортировки там или ещё чего. Так, по идее и транслятору будет оптимизировать проще, и писать код легче.

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

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

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

S>>Это еще один подход к моделированию вселенной. Превосходство его над ООП еще не оценено...

PC_>та собственно уже почти оценено. На sql модератор хотел квадрат от прямоугольника пронаследовать и тогда я понял
PC_>идеальное христоматийное применение.
В христоматиях это как раз классический пример нарушения LSP. Открывай иногда христоматии.

PC_>Например фигура могла бы мигрировать от класса Квадрат к классу Прямоугольник
PC_>на основе свойства "все стороны равны". А ООП эту простейшую проблему решает реально криво, хоть и тоже пытается
PC_>взять ее за христоматийный пример ООП.
Ты где учил ООП?

PC_>Не нужно реализацию скрывать. Пускай живет себе открыто.
Пускай. лениво спорить, но я при мнении что скрывать нужно.

S>>ну как не выстрелить, если нужно позарез заюзать stl::vector, а он собака этот оператор использует в своих исходниках...

PC_>для тебя просто не очевиден другой аспект проблемы. То что в тупую переопределили оператор, это конечно глупо.
PC_>Но в системах более хорошей абстракции, можно было бы определить, что каждая строка такогото шаблона переводится по шаблону.
И получили бы обрезание гибкости.
PC_>И что ? Получили бы тривиальную локализацию любой сложной системы на любой разговорный язык.
Моя не понимаит.

PC_>Или например добавили особое логирование ошибок в каждой строчке где встречается такая комбинация переменных.
PC_>И вместо тотального решета трай кетч, получили бы чистинький код.
Ты не понял. Проблема была в том, что бы скомпилировать. До лога там было не достать.

PC_>Короче применений здесь именно практичных очень много.
PC_>Система ведет себя очень гибко.
Недостаточно для решения некоторых задач.

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

KV>А если мы хотим не фильтровать уже готовую последовательность, а применять фильтр в процессе перебора, чтобы не плодить лишние объекты? В моем примере это достигается за счет переноса .Map из конца выражения в его середину.
Так будет неудобно, однако.

Естественным способом это можно сделать, распространяя по дереву перебора состояния некоторого автомата.
Я думаю, что прямее всего уметь строить переьорщик по автомату непосредственно.

KV>Ну, я могу напредполагать наличие в RS сопоставления с образцом, АТД и метапрограммирования... Важно же то, что есть сейчас? А то, что будет, обсудим по факту его появления, я думаю.
Ничего нет, очевидно. PC-2 предложил прикольную нотацию, чем-то похожую на тензоры. Я, например, ещё не наигрался с ней, чтобы понять годится такой подход на что-то или нет. Если ты умнее, то можешь поделиться выводами, только аргументированно. Потому, что на веру я принимать не буду. Я лучше приму к сведению и наиграюсь таки.

У меня, кстати, есть мощное чувство, что я где-то что-то крайне похожее видел.
Вернее я знаю одно место, относительно похожее, но оно проприетарное. Но там это всё вторично, IMHO. А вот где я видел оригинал -- никак не вспомню.
Неужели это таки тензоры и только?

KV>moderator@rsdn.ru
Ой, да уж сам с собой, как-нибудь договорись, да?

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

AV>Не, то что это можно будет сделать я вполне верю. То что будет сделано — не верю. Может быть какой-нибудь один частынй случай. Но не более.

Казалось бы, для всех простых случаев всё просто, для комбинаций где-то просто, а где не просто, там полиморфизм. А где совсем не, там массивы.

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

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

S>>Проблема. В текущем дизайне языка в их ленивости смысла нет, т.к. они по природе своей проходят от начала диапозона до конца и не останавливаются посередине. Сделаешь их ленивыми — они все равно не смогут остановиться.

E>Ну, как бы, даже в текущем дизайне бывают фильтры. Кроме того, я согласен, что стоит иметь и другие способы ограничивать перебор.
Фильтры типа (I>10?I) не ограничивают перебор. Он продолжает выполняться, даже если не нужен уже.
E>Предлагай хорошие.
устал предлагать
У меня такое ощущение, что если я опять скажу "генераторы", то ты опять это не заметишь...

E>Один из путей, возможно правильный -- поручить самим переборщикам осуществлять всякие хитрые операции, вроде поиска, или разбиения на поддиапазоны, скажем... Поиска медианы, двухпутевого слияния, сортировки там или ещё чего. Так, по идее и транслятору будет оптимизировать проще, и писать код легче.
Выглядит будто ты придумал. Но я пытался сказать о том же

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

S>Я верю что ты сможешь написать нерекурсивное решение задачи перебора размещений без повторений. Но не верю, что оно будет хоть столько же компактно, как рекурсивное. Не настаиваю на предъявлении решения. Но если будет — с интересом взгляну.

Ну, зато это интересно. Всё рекурсивное можно записать нерекурсивно. Дальше вопрос в выразительности используемых средств.

Циклами-то можно же записать? Так что можно и нерекурсивно, я думаю.

Самый прямой путь, кстати -- завести ещё один переборщик -- переборщик перестановок. Но это будет чит, хотя и практически ценный.
Но, у нас же может быть сколь угодно умный язык. То есть правило может быть сложнее, чем "буквы не повторяем"...

S>При необходимости напишу и интерпретатор. Была бы грамматика (в любой форме) и спецификация языка. Но думаю что оценить работоспособность я смогу и без интерпретатора. Еще раз, речь о размещениях без повторений. И не хотелось бы видеть решение задачи с повторениями и последующей фильтрацией. Зачета не будет.

При чём тут зачёт? Зачем мне нужны твои оценки?
Если у тебя есть идеи, как можно на тнезороподобных конструкциях написать переьорщик перестановок, например, то давай обсуждать...
Если нет, то ты максимум можешь помочь конструктивной критикой, когда кто-то, что-то таки предложит

S>Есть надежда сбить спесь. Не отвадить от написания языка, нет. Показать что он многого не знает и что без этого ему не стать хорошим специалистом в этой области при таком самомнении и манере вести дискуссии.

Ну воспитывайте, если вам это надо...
Только, если ты хочешь заиметь у него авторитет, тебе надо будет начать предлагать хорошие идеи для RS...
А то так и будете сраться. И тебе, IMHO, страться должно быть более стыдно, чем ТС. Тем более в его топике...

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

E>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>А если мы хотим не фильтровать уже готовую последовательность, а применять фильтр в процессе перебора, чтобы не плодить лишние объекты? В моем примере это достигается за счет переноса .Map из конца выражения в его середину.
E>Так будет неудобно, однако.
Это очень удобно.

E>Естественным способом это можно сделать, распространяя по дереву перебора состояния некоторого автомата.
E>Я думаю, что прямее всего уметь строить переьорщик по автомату непосредственно.
Паттерн 'итератор' чистой воды.

E>Ничего нет, очевидно. PC-2 предложил прикольную нотацию, чем-то похожую на тензоры. Я, например, ещё не наигрался с ней, чтобы понять годится такой подход на что-то или нет. Если ты умнее, то можешь поделиться выводами, только аргументированно. Потому, что на веру я принимать не буду. Я лучше приму к сведению и наиграюсь таки.
Из прикольного что он предложил — неявный забег по нескольким итераторам из блока выражений в том же блоке выражений (спрятал for/foreach). Но получение декартового произведения итераторов — фишка известная и используемая в мэйнстриме и в частности в C#.

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

AV>Тогда ты скорее всего получишь язык для решения одного-двух типов языков.

Ну цель стоит ясная. Написать легко и просто шахматы, потом шашки, потом каллах и т. д...

PC_>>та собственно уже почти оценено. На sql модератор хотел квадрат от прямоугольника пронаследовать и тогда я понял
PC_>>идеальное христоматийное применение.
S>В христоматиях это как раз классический пример нарушения LSP. Открывай иногда христоматии.

Не знаю чего там нарушении, но срачь получился тогда на sql зачетный. Две темы не могли разобраться что от чего наследовать,
оставались много висячих и лишних методов.
Проблема есть и ООП ее не решает, а вот РС с фигурами может наконец разрулить так как надо

PC_>>Например фигура могла бы мигрировать от класса Квадрат к классу Прямоугольник
PC_>>на основе свойства "все стороны равны". А ООП эту простейшую проблему решает реально криво, хоть и тоже пытается
PC_>>взять ее за христоматийный пример ООП.
S>Ты где учил ООП?

У Страуструпа например

PC_>>для тебя просто не очевиден другой аспект проблемы. То что в тупую переопределили оператор, это конечно глупо.
PC_>>Но в системах более хорошей абстракции, можно было бы определить, что каждая строка такогото шаблона переводится по шаблону.
S>И получили бы обрезание гибкости.
PC_>>И что ? Получили бы тривиальную локализацию любой сложной системы на любой разговорный язык.
S>Моя не понимаит.

Локализовать систему — задача простая. А на деле, если разработчики не продумали и весь код не писали с особым извращением, то все

PC_>>Или например добавили особое логирование ошибок в каждой строчке где встречается такая комбинация переменных.
PC_>>И вместо тотального решета трай кетч, получили бы чистинький код.
S>Ты не понял. Проблема была в том, что бы скомпилировать. До лога там было не достать.

Почитай про аспектную парадигму в википедии.

PC_>>Короче применений здесь именно практичных очень много.
PC_>>Система ведет себя очень гибко.
S>Недостаточно для решения некоторых задач.

ну разве что "некоторых"

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

AV>Тебе интересно обсудить именно RS или все таки тензоры и иже с ними? Если второе, то гораздо более продуктивно будет это делать в отдельном топике. И при этом сначала стоит обратить внимание на уже существующие наработки. Те, которые ТС с самого начала назвал говнокодом.
А я вот не знаю ничего такого же выразительного.
Смысла в другой ветке тоже особого не вижу.

AV>Вот только ценность может меняться в связи с особенностями изложения.
Ценность мыслей нет. Доступность -- да.

AV>Лучше это делать в отдельном топике.
Зачем?Хочешь -- заводи.

AV>Как минимум, ничего лучшего пока что не было предложено. Да, теоретически можно и лучшее найти. Вот только как это впишется в обсуждаемый RS. А абсолютная отвязанность от языка ничего полезного не принесет.
Ну мне тоже кажется, что LC тянуть сюда нет нужды.

AV>Да, оно больше деструктивное. Это так ужасно? А насчет "извращения", то как иначе назвать то, что предложил ТС? В теории быть может все это и красиво. Но то, что есть на практике иначе я назвать не могу.
Что именно тебе кажется неприменимым?

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

S>Увы, все нужное вставить нереально. А если разрабатывается язык общего назначения, то что нужно кому-то — даже и предположить сложно.

Что значит "всё нужное"? Есть базис некоторый. Во всяком случае есть вполне известный перечень того, что можно сделать эффективно. И более или менее понятны необходимые операции.

По крайней мере уже то, что так можно написать язык, который будет эффективно считаться и на КУДЕ и на обычном железе -- уже прикольно.

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

S>Нами с тобой. Автору-то до них дела нет
Во-первых, он предложил нам подумать/договориться, а он пока занят.
Во-вторых, какая разница?

S>Пути в графе это примерно то же самое, что и пути в гиперкубе. Берется алгоритм поиска путей в графе (их много, но возьмем любой конкретный, возвращающий множество путей, а не один) и пишется в форме генератора.

Ну вот, положим есть у меня какой-то способ описать генератор путей в графе. Я хочу из обычного сделать А*, например. Как всё это надо устроить?
Я понимаю, что очень похожая задача, но конкретно вот записать пока не могу. И понять, что можно на такой записи делать, а что нет -- тоже.

S>А что за алгоритм A* ?
Ну есть такой. Гуглится. Типа как алгоритм Дейкстры для поиска пути, но целенаправленный. Мы имеем для каждой точки априорную оценку пути до конца. Постепенно строим апостериорные цены путей до точек. На каждом шаге достраиваем продолжения через вершину, в которой сумма апостериорной цены от начала и априорной цены до конца оптимальна.
Елси надо подробнее, то скорее всего в вики есть.

S>До сих пор обсуждалась возможность вставки функций вообще. И последнюю неделю ТС был против любых функций/грушек вообще. И только сейчас он заговорил о полиморфных функциях.
Да нет. Он то же, что и я говорит. Просто непонятно.

-1 -- это в RND

S>Речь шла об уникальности символов в пароле. В какой это было форме конкретно — я уже не помню. А найти уже не просто.
Ну я пока что про задачу с повторениями толькл видел.
И решение ТС с Eval, тоже с повторениями было.

S>КС-грамматики? Чему это поможет?
Ну это более интересный переборщик строк, чем размещение без повторений...

S>Я плохо и давно учился в шклое. Слово тензор помню, а что в него вкладывается — нет.
Забей. Просто выражения RS похожи очень на тензоры.

S>Это прежде всего к тому, что операции над перебощиками не должны быть встроены в ядро. Язык должен быть заточен на удобное использование таких операций — это да. Т.е. сахарок. Но сами операции в ядро — это ограничение гибкости.

Зато эффективность. Но это не важно всё.

В общем надо подумать.

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

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

E>Ну, зато это интересно. Всё рекурсивное можно записать нерекурсивно. Дальше вопрос в выразительности используемых средств.
+1

E>Циклами-то можно же записать? Так что можно и нерекурсивно, я думаю.
Циклами можно. Но сейчас RS умеет только декартово произведение счетчиков. Т.е. вложенные for-ы, которые он отрабатывает от начала и до конца. Дополнительные ветвления есть — условие на вход в итерацию, но больше ничего. На мой взгляд — этого недостаточно для решения размещений без повторений.

E>Самый прямой путь, кстати -- завести ещё один переборщик -- переборщик перестановок. Но это будет чит, хотя и практически ценный.
Переборщик перестановок, переборщик сочетаний, с повторами, без, ой-ой. Язык должен уметь создавать пользовательские переборщики. Иначе он ограничен.

E>Но, у нас же может быть сколь угодно умный язык. То есть правило может быть сложнее, чем "буквы не повторяем"...
Сколь-угодно умный язык превращается в сколь-угодно долгий цикл разработки. И не мертвый язык, но и не рожденный. Не нужен.

S>>При необходимости напишу и интерпретатор. Была бы грамматика (в любой форме) и спецификация языка. Но думаю что оценить работоспособность я смогу и без интерпретатора. Еще раз, речь о размещениях без повторений. И не хотелось бы видеть решение задачи с повторениями и последующей фильтрацией. Зачета не будет.

E>При чём тут зачёт? Зачем мне нужны твои оценки?
E>Если у тебя есть идеи, как можно на тнезороподобных конструкциях написать переьорщик перестановок, например, то давай обсуждать...
Я не очень понимаю что такое тензороподобные конструкции — но генератор перестановок — это по силам, писал когда-то. Их и в инете полно, да и списать можно хоть с википедии, чуть подкрутив, что бы в виде генератора было.
E>Если нет, то ты максимум можешь помочь конструктивной критикой, когда кто-то, что-то таки предложит
Здесь например, есть красивый (рабочий ли не знаю) генератор перестановок на F#. Могу предложить посильную помощь в переводе на C#.

S>>Есть надежда сбить спесь. Не отвадить от написания языка, нет. Показать что он многого не знает и что без этого ему не стать хорошим специалистом в этой области при таком самомнении и манере вести дискуссии.

E>Ну воспитывайте, если вам это надо...
E>Только, если ты хочешь заиметь у него авторитет, тебе надо будет начать предлагать хорошие идеи для RS...
Сколько можно? По своему скромному мнению я фигню не предлагал. Но у него особое мнение на мой счет.

E>А то так и будете сраться. И тебе, IMHO, страться должно быть более стыдно, чем ТС. Тем более в его топике...
У меня другое мнение на этот счет. Я один из немногих кто тут застрял и втолковывает ему прописные истины, до которых он сам не дошел. Остальным его манеры не понравились (да и мне тоже), а я себя начинаю чувствовать редким извращенцем, потому как чего-то не могу откланяться.
Ну и как бы знаешь, разосремся — я то точно ничего не потеряю
Даже если дизайн языка устаканится и дело дойдет до реализации — там будет срача в разы больше. Со-мной уж точно. Это я гарантирую

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

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

PC_>>с этим никто не спорит. Молоток сертифицирован для забивания гвоздей и для колки орехов решительно не подходит.
PC_>>Функция сортировки сертифицирована для сравнения строк по алфавиту, отсортировать по цветам радуги решительно не сертифицирована,
PC_>>нужно написать такойже свой велосипед и заменить буквально одну строчку
S>Ты говоришь о хреновой функции и только.

функция то не хреновая, а как меня тут долго уверяли самая что не на есть деревяная и базовая.
Но главное что "вылечить" эту функцию может только целый комплект бубнов с всяки разными IComparable, доп. классом, дополнительной
функцией и другими бубнами. И всеравно функция не лечится до конца. Предусмотреть сортировку в одном месте для всех случаев в жизни практически
невозможно

E>>Циклами-то можно же записать? Так что можно и нерекурсивно, я думаю.
S>Циклами можно. Но сейчас RS умеет только декартово произведение счетчиков. Т.е. вложенные for-ы, которые он отрабатывает от начала и до конца. Дополнительные ветвления есть — условие на вход в итерацию, но больше ничего. На мой взгляд — этого недостаточно для решения размещений без повторений.

Там мона делать вот так, вы просто еще не все пасхальные яйца там знаете

a = i
[b = i + j]
a = 0

код конечно безсмысленен, но
он разворачивается примерно в это

for(int i=0; i<10; i++)
{
int a = i;
for(int j=0; j<10; j++)
b = i + j;

a = 0;
}

Тоесть вложены циклы есть, можно их строить любой причудливой формы.
Правда конструкция не ахти.

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

S>Фильтры типа (I>10?I) не ограничивают перебор. Он продолжает выполняться, даже если не нужен уже.
Почему? Если у тебя есть несколько независимых переборщиков, каждый из которых профильтрован, и при этом нам нужно их декартово произведение, то очень даже ограничим перебор...

E>>Предлагай хорошие.
S>устал предлагать
S>У меня такое ощущение, что если я опять скажу "генераторы", то ты опять это не заметишь...
Ну это неконкретно.
Ну принято иметь функции, вроде take map или toArray. И что?

Вот как ты предлагаешь организовать размещения без повторов, например?


E>>Один из путей, возможно правильный -- поручить самим переборщикам осуществлять всякие хитрые операции, вроде поиска, или разбиения на поддиапазоны, скажем... Поиска медианы, двухпутевого слияния, сортировки там или ещё чего. Так, по идее и транслятору будет оптимизировать проще, и писать код легче.
S>Выглядит будто ты придумал. Но я пытался сказать о том же

Господи! Да какая разница кто что придумал?

Ну и потом это в конце можно будет, а так мы без модельных задач останемся

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

PC_>>>та собственно уже почти оценено. На sql модератор хотел квадрат от прямоугольника пронаследовать и тогда я понял
PC_>>>идеальное христоматийное применение.
S>>В христоматиях это как раз классический пример нарушения LSP. Открывай иногда христоматии.

PC_>Не знаю чего там нарушении, но срачь получился тогда на sql зачетный. Две темы не могли разобраться что от чего наследовать,
Либо ты недоговариваешь, либо на sql нет людей, знакомых с LSP. Я как-то склоняюсь к первому.

PC_>Проблема есть и ООП ее не решает, а вот РС с фигурами может наконец разрулить так как надо
Проблема ООП в христоматийном примере наследования прямоугольника и квадрата лишь в недостаточном знании ООП.

S>>Ты где учил ООП?
PC_>У Страуструпа например
Поздравляю. Страуструп не относится к экспертам по ООП. Скорее вольный толкователь.

PC_>>>И что ? Получили бы тривиальную локализацию любой сложной системы на любой разговорный язык.
S>>Моя не понимаит.

PC_>Локализовать систему — задача простая. А на деле, если разработчики не продумали и весь код не писали с особым извращением, то все
Задача непростая

PC_>>>И вместо тотального решета трай кетч, получили бы чистинький код.
S>>Ты не понял. Проблема была в том, что бы скомпилировать. До лога там было не достать.

PC_>Почитай про аспектную парадигму в википедии.
Знаешь что аспекты работают в рантайме, то есть после компиляции?

PC_>>>Система ведет себя очень гибко.
S>>Недостаточно для решения некоторых задач.

PC_>ну разве что "некоторых"
некоторых обозначенных

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

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

S>>Увы, все нужное вставить нереально. А если разрабатывается язык общего назначения, то что нужно кому-то — даже и предположить сложно.

E>Что значит "всё нужное"? Есть базис некоторый. Во всяком случае есть вполне известный перечень того, что можно сделать эффективно. И более или менее понятны необходимые операции.
Я рад за тебя. Мне этот перечень не известен, особенно в языке общего назначения.

E>По крайней мере уже то, что так можно написать язык, который будет эффективно считаться и на КУДЕ и на обычном железе -- уже прикольно.
На самом деле хотя бы одно из двух было бы прикольно.

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

S>Это очень удобно.
Что именно удобно? Как ты функцию f писать будешь. Например мы хотим только такие строки, которые удовлетворяют какому-то регэкспу. И?

S>Паттерн 'итератор' чистой воды.
И?
S>Из прикольного что он предложил — неявный забег по нескольким итераторам из блока выражений в том же блоке выражений (спрятал for/foreach). Но получение декартового произведения итераторов — фишка известная и используемая в мэйнстриме и в частности в C#.

не, в С# всё-таки всё не так...