Здравствуйте, Erop, Вы писали:
E>Здравствуйте, samius, Вы писали:
E>>>Дык это очевидно... S>>И о чем спорили?
E>Так я и не спорю. Я говорю: приводи примеры как ты это видишь в RS...
знаешь, я не синтаксист-минимизатор и меня устраивает как это например в F# или Haskell, или даже Ela
let list = [ for (x = 1 when x % 2 == 0 to 10) x ];
Одно по поводу RS я могу сказать однозначно. !перед именем счетчика — это отстой, т.к. при использовании конструкции x..y в выражении (без инициализации переменной) совершенно неясно что использовать, массив, генератор, или счетчик.
Здравствуйте, samius, Вы писали:
S>>>Ты предлагаешь выкинуть все что не распараллеливается просто? Язык-то общего назначения, или для распараллеливания того что просто параллелится? E>>Нет, не предлагаю. Просто мне так кажется, что перебор множества, и некая рекурентно заданная последовательность -- это разные истории... S>Согласен. Причем эффективно перебрать множество рекурентной последовательностью иногда можно, а наоборот —
"Наоборот" -- это значит "перебрать множество"? Ну я бы не сказал. Во многих случаях тоже можно. А описывать множество непосредственно НАМНОГО УДОБНЕЕ и понятнее. Кроме того, с явно описанными множествами ПРОЩЕ РАБОТАТЬ аналитически, в том числе и ОПТИМИЗАТОРУ...
S>нет. Умеем получать набор наперед заданной длины и только. А такой набор нельзя скомбинировать с чем-то, что будет получать элементы до те пор, пока выполняется условие.
Ну это обозначает, что в RS не хватает описания переборщиков двух видов.
1) Перебирай пока что-то не случится. Хотя, вообще говоря, такой переборщик есть, это переборщик вида (ЧтоТоЕщёНеСлучилось(I)?I)
Но вопрос в том, что из таких записей в принципе можно реализовать хотя бы не катострофически неэффективно.
2) Перебирай пока ограничение не случится на другом слое. Хотя такой переборщик тоже есть, это I, но опять же не очевидна реализация.
Кроме того есть ещё три проблемы.
1) Нельзя описать внутри выражения переборщик и тут же на него сослаться.
В том числе нельзя удобно описать какую-то рекурентную формулу.
Для того, чтобы написать x.I = x.(I-1)+x.(I-2), нам надо сначала описать сам x, а, по идее, это не надо тут ни для чего. Сама по себе запись x.I = x.(I-1)+x.(I-2) даёт определение всего, кроме первого числа.
То есть x.I = (I==0?1:x.(I-1)+x.(I-2)) -- это уже полное определение бесконечного переборщика чисел Фибоначи. Но мы так не можем. Кроме того, нам неудобно описывать базу рекурсии.
2) неудобно описывать по каким именно переборщикам осуществляется свёртка, нет внятного способа связать один переборщик с текущим вариантом другого, если они не в рамках одного выражения написаны. Ну и вообще есть проблемы с всякими вложенными циклами.
3) Не понятно что с мемоизацией перебираемых вариантов. Понятно, что в простых случаях можно как-то это дело оптимизировать, и не хранить тупо всю последовательность... Но всё равно записать что-то вроде "и не делится на все простые меньше данного", а тем более, "и не делится на все простые, квадрат которых не превышает данного" так просто пока что нельзя...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
__>>using System.Console;
__>>using M;
__>>def a = $[1..5] \ _*_;
__>>WriteLine(a);
__>>def b = _*_ / $[5,4..1];
__>>WriteLine(b);
__>>def c = $[1..5] ` (_*2);
__>>WriteLine($"..$c");
__>>
Так прикольно, конечно. Но это сильно не в любой язык встраивается.
Да и не в том проблема. Проблема в другой лежит плоскости. Вот описал я какое-то выражение на каком-то множестве декларативно. Как библиотека составит и выполнит оптимальный или субоптимальный план его итерации?
Ну типа пишу я: "В таком-то выражении то-то и то-то на самом деле свободные валентности, и я хочу перебрать все варианты и что-то найти, или свернуть, или ещё чего". И что библиотека сможет? Тем более библиотека, встраиваемая в ЛЮБОЙ или хотя бы во МНОГИЕ языки?
А Немерле мне понравился. Просто у меня не получается долго посидеть с ним. Но это совершенно перпендикулярные вопросы. Мегамощная матчинг-машинка из немерле и тензороподобные выражения, предложенные PC_2.
По идее та часть RS, которая собственно нова, может быть встроена куда угодно, в этом Алексей прав. Я только сомневаюсь, что хватит только библиотеки. Вот для линка в С#, насколько я понимаю, не хватило, например...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, samius, Вы писали:
S>>Согласен. Причем эффективно перебрать множество рекурентной последовательностью иногда можно, а наоборот — E>"Наоборот" -- это значит "перебрать множество"? Ну я бы не сказал. Во многих случаях тоже можно. А описывать множество непосредственно НАМНОГО УДОБНЕЕ и понятнее. Кроме того, с явно описанными множествами ПРОЩЕ РАБОТАТЬ аналитически, в том числе и ОПТИМИЗАТОРУ...
Вот что мне интересно: это для тебя вроде как если и не очевидно, то хотя бы понятно, раз ПРОЩЕ? Поставлю метку (1)
E>Ну это обозначает, что в RS не хватает описания переборщиков двух видов.
E>1) Перебирай пока что-то не случится. Хотя, вообще говоря, такой переборщик есть, это переборщик вида (ЧтоТоЕщёНеСлучилось(I)?I) E>Но вопрос в том, что из таких записей в принципе можно реализовать хотя бы не катострофически неэффективно.
А вот это для тебя непонятно? См (1). Должно быть понятно. E>2) Перебирай пока ограничение не случится на другом слое. Хотя такой переборщик тоже есть, это I, но опять же не очевидна реализация.
См (1). ОПТИМИЗАТОР порешает
E>Кроме того есть ещё три проблемы. E>1) Нельзя описать внутри выражения переборщик и тут же на него сослаться. E>В том числе нельзя удобно описать какую-то рекурентную формулу.
Пока нельзя описать вообще хоть что-то и сослаться на него хотя бы снаружи. Рекурсия потом.
E>Для того, чтобы написать x.I = x.(I-1)+x.(I-2), нам надо сначала описать сам x, а, по идее, это не надо тут ни для чего. Сама по себе запись x.I = x.(I-1)+x.(I-2) даёт определение всего, кроме первого числа.
Генераторам нужны данные, их надо уметь передавать. E>То есть x.I = (I==0?1:x.(I-1)+x.(I-2)) -- это уже полное определение бесконечного переборщика чисел Фибоначи. Но мы так не можем. Кроме того, нам неудобно описывать базу рекурсии.
E>2) неудобно описывать по каким именно переборщикам осуществляется свёртка, нет внятного способа связать один переборщик с текущим вариантом другого, если они не в рамках одного выражения написаны. Ну и вообще есть проблемы с всякими вложенными циклами.
Да
E>3) Не понятно что с мемоизацией перебираемых вариантов. Понятно, что в простых случаях можно как-то это дело оптимизировать, и не хранить тупо всю последовательность... Но всё равно записать что-то вроде "и не делится на все простые меньше данного", а тем более, "и не делится на все простые, квадрат которых не превышает данного" так просто пока что нельзя...
По поводу мемоизации — есть решения, см. например хаскел. Ленивый список с запоминанием элементов этот вопрос решает. Беда только с расстановкой strict флагов. До сих пор рулит ручная расстановка, даже в Clean, где она есть автоматическая (вроде как).
Здравствуйте, Erop, Вы писали:
E>Да и не в том проблема. Проблема в другой лежит плоскости. Вот описал я какое-то выражение на каком-то множестве декларативно. Как библиотека составит и выполнит оптимальный или субоптимальный план его итерации?
Как? Твой ОПТИМИЗАТОР же!
E>Ну типа пишу я: "В таком-то выражении то-то и то-то на самом деле свободные валентности, и я хочу перебрать все варианты и что-то найти, или свернуть, или ещё чего". И что библиотека сможет? Тем более библиотека, встраиваемая в ЛЮБОЙ или хотя бы во МНОГИЕ языки?
Сможет то же самое что и ОПТИМИЗАТОР в РС. Не вижу причин, почему библиотечное решение будет уступать.
E>По идее та часть RS, которая собственно нова, может быть встроена куда угодно, в этом Алексей прав. Я только сомневаюсь, что хватит только библиотеки. Вот для линка в С#, насколько я понимаю, не хватило, например...
Линк — чисто библиотечное решение, для которого встроен небольшой сахарок. Но все что можно написать на сахаре можно написать и без него.
Вот то на чем линк основан — неявная генерация автомата по коду метода — это сделано отдельно от линка в более ранней версии языка. Но в основном эта фича использована для построения библиотеки линка, а так же при написании пользовательских генераторов. Тот же пример на F# с генерацией пароля — превращается компилятором в автомат, т.к. там lazy. Но изменив несколько символов мы превратим его в eager код, который не будет превращаться в автомат. Явно задаваемые strict флаги. В общем случае оптимизаторы не умеют эффективно ставить их сами.
Здравствуйте, Mamut, Вы писали:
M>Это какое-то недоступное мне альтернативное мышление. PC_2 мягко говоря обсирает другие языки, в частности, за использование встроенных и библиотечных функций. И при этом сам без зазрений совести вводит встроенные функции в язык.
Ну так если ты осуждаешь стиль поведения PC_2, то зачем ты САМ делаешь ТОЖЕ САМОЕ?
Чё за детский сад? "Мама! Он мне ногу оторвал! -- Ну и ты ему оторви!"
Ты лучше скажи, что именно ты хотел услышать в ответ на просьбу заюзать RND?
Насколько я понял ТС, суть его претензий в том, что во всяких генераторных штуках, и не только в них есть всякие конструкции "сделай то". Они конечно хорошие, но суть вопроса выразить не дают. Конечно люди, которые написали эти "грушки", как он выражается, сделали это не просто так, а потому, что лучше не смогли. Это понятно. И если изучить их логику, что ты тоже поймёшь, что лучше не придумать.
Но парадокс человеческого мышления состоит в том, что если не знать о том, что лучше не придумать, то часто таки удаётся придумать лучше...
Так что очень большая ценность усилий ТС состоит в том, что он не видит стен, которые видят люди отягощённые *излишним* образованием
Кроме того, он таки довольно компактный синтаксис предложить смог. Я думаю, что он ещё что-то хорошее на эту тему придумает.
Но его зачем-то дёргают какой-то фигнёй, вроде того, что типа а вот метод Ньютона так не запишешь. IMHO, то, что так не запишешь, это очевидно. И толку от таких замечаний -- ноль.
M>Конструктив тут прямой: разуть глаза и начать адекватный диалог.
Ну так начни.
Например, можешь разобраться, наконец, со своими идеями про клонов...
Или пояснить что именно ты хотел по поводу RND узнать... Может и что дельное хотел, но я вот, например, пока не понял, что именно.
Кроме того тут есть много всяких рассуждений не только от ТС, но и от меня, и от Алексея Шинкарёва.
Присоединяйтесь, барон!(с)...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, ambel-vlad, Вы писали:
AV>Да, но при этом не стоит бросаться с шашкой наголо и реализовывать первое что понравилось.
Дык какой вывод ты из этого делаешь?
Я например, делаю такой вывод, что не надо провоцировать коллегу на всякую ерунду...
AV>А в качестве аргументов называть оппонентов дураками.
Это, безусловно, лишнее. При этом это лишнее со всех сторон. Иногда трудно удержатьтся, конечно, но если уж не удержался, то надо потом извиниться, а не усугублять. Ну IMHO, так конструктивноае сотрудничество выглядит
AV>По идее сейчас максимум что стоит писать — это маленькие прототипы, чтобы проверить ту или иную идею. И писать спеку и писать спеку и еще раз писать спеку.
Ну так тебе кто-то мешает? Да? Если, например, ты напишешь спецификацию, то многие полуинтуитивно ясные вопросы станут яснее. Кроме того, имея какую-то спеку можно её потом править. Это намного проще...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, samius, Вы писали:
S>А МТ — это как раз такая вещь которая расширяет автоматы и формализует понятие алгоритма.
Она плохо применима на практике.
S>Что именно тебе не нравится в эффективности реализации в других языках? А то я не понимаю, что ты подразумеваешь под эффективно?
Три аспекта не нравится
1) Нельзя или неудобно описывать множества декларативно. Даже если тебя устраивает всего лишь субоптимальная итерация множества.
2) Совсем мало шансов у транслятора языка меня поправить, если я что-то не так надекларировал с точки зрения процедурного аспекта. В этом смысле у чистых деклараций есть тот плюс, что мы меньше мешаем оптимизатору. При этом можно подумать о каких-то подсказках, которые можно ему давать. Ну что-то типа inline в С++, например.
3) Трудно залудить несколько слоёв описания множества. Ну типа множество + маска.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
S>let list = [ for (x = 1 when x % 2 == 0 to 10) x ];
S>
Это тоже самое, что (I%2==0?I)
Ты вот с Take пример приведи, например...
S>Одно по поводу RS я могу сказать однозначно. !перед именем счетчика — это отстой, т.к. при использовании конструкции x..y в выражении (без инициализации переменной) совершенно неясно что использовать, массив, генератор, или счетчик.
Я вообще не уверен, что эти понятия надо различать. Это же всего лишь вопрос оптимизации -- хранить массив или генератор его значений. По идее хорошо бы сделать так, чтобы на основном пути, так сказать, мы это вообще не специфицировали, а оставили бы это дело RS. И только если очень надо, то мы могли бы подсказать, что типа "а этот переборщик, закэшируй таки в массив", или там "мемоизируй постранично, с такими-то страницами", или "мемоизируй на такую-то глубину", или ещё как...
Массив -- это всего лишь отображение пространства индексов на пространство значений. Какая разница, как RS внутри себя будет это отображение задавать?
Тем более, что вполне возможны переборщики, в которых даже пространство индексов не требуется, и порядок перебора не определён, пока какие-то специальные усилия не предпримешь...
Вообще, я вот не совсем согласен с PC_2 вот в каком аспекте. У него сейчас процедурный аспект очень выпячен. Это, IMHO, нехорошо, но сильно удешевляет интерпретатор. Хорошо бы двигаться в таком направлении, чтобы ВАЖНЫЕ вопросы, вроде того ЧТО НАМ НАДО писать коротко и понятно, а всякую процедурщину оставить RS. При этом такая процедурщена, с которой RS обычно сам справляется, может быть записываема сколь угодно криво.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, samius, Вы писали:
E>>"Наоборот" -- это значит "перебрать множество"? Ну я бы не сказал. Во многих случаях тоже можно. А описывать множество непосредственно НАМНОГО УДОБНЕЕ и понятнее. Кроме того, с явно описанными множествами ПРОЩЕ РАБОТАТЬ аналитически, в том числе и ОПТИМИЗАТОРУ... S>Вот что мне интересно: это для тебя вроде как если и не очевидно, то хотя бы понятно, раз ПРОЩЕ? Поставлю метку (1) E>>1) Перебирай пока что-то не случится. Хотя, вообще говоря, такой переборщик есть, это переборщик вида (ЧтоТоЕщёНеСлучилось(I)?I) E>>Но вопрос в том, что из таких записей в принципе можно реализовать хотя бы не катострофически неэффективно. S>А вот это для тебя непонятно? См (1). Должно быть понятно.
Ну как бы я ответа на такой вопрос не знаю.
S>Пока нельзя описать вообще хоть что-то и сослаться на него хотя бы снаружи. Рекурсия потом.
Ну рекурсия или не рекурсия, это не важно, как раз. Какая разница на себя ссылаться или нет?
E>>Для того, чтобы написать x.I = x.(I-1)+x.(I-2), нам надо сначала описать сам x, а, по идее, это не надо тут ни для чего. Сама по себе запись x.I = x.(I-1)+x.(I-2) даёт определение всего, кроме первого числа. S>Генераторам нужны данные, их надо уметь передавать.
Про данные не понял. Проблема тут носит чисто синтаксический характер. Нам всего лишь надо как-то сказать, что в этом выражении определяется конкретно х, а не что-то ещё...
E>>3) Не понятно что с мемоизацией перебираемых вариантов. Понятно, что в простых случаях можно как-то это дело оптимизировать, и не хранить тупо всю последовательность... Но всё равно записать что-то вроде "и не делится на все простые меньше данного", а тем более, "и не делится на все простые, квадрат которых не превышает данного" так просто пока что нельзя... S>По поводу мемоизации — есть решения, см. например хаскел. Ленивый список с запоминанием элементов этот вопрос решает. Беда только с расстановкой strict флагов. До сих пор рулит ручная расстановка, даже в Clean, где она есть автоматическая (вроде как).
Ну вот даже ответ на вопрос "для данной конкретной последовательности в этом конкретном запросе, мы мемоизируем всё, не мемоизируем ничего или используем какую-то смешанную стратегию?" мне не ясен, например.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, samius, Вы писали:
S>Сможет то же самое что и ОПТИМИЗАТОР в РС. Не вижу причин, почему библиотечное решение будет уступать.
Потому, что ему недоступен сам итерируемый код. Соответсвенно, не понятно где брать связи между переборщиками...
S>Вот то на чем линк основан — неявная генерация автомата по коду метода — это сделано отдельно от линка в более ранней версии языка. Но в основном эта фича использована для построения библиотеки линка, а так же при написании пользовательских генераторов. Тот же пример на F# с генерацией пароля — превращается компилятором в автомат, т.к. там lazy.
Ну вот если компилятор умеет делать из кода автомат, при этом представленный как-то так, что есть доступ к его структуре, то тогда всё получится.
Но это обозначает, что встроить это можно очень сильно не в любой язык...
S>Но изменив несколько символов мы превратим его в eager код, который не будет превращаться в автомат. Явно задаваемые strict флаги. В общем случае оптимизаторы не умеют эффективно ставить их сами.
Ну вот мне не ясно до конца, это с чем связано. С тем, что структура зависимостей не доступна оптимизатору, или с тем, что задача вообще не решается.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, samius, Вы писали:
S>>А МТ — это как раз такая вещь которая расширяет автоматы и формализует понятие алгоритма. E>Она плохо применима на практике.
Потому я и начал с лямбда счисления
S>>Что именно тебе не нравится в эффективности реализации в других языках? А то я не понимаю, что ты подразумеваешь под эффективно?
E>Три аспекта не нравится E>1) Нельзя или неудобно описывать множества декларативно. Даже если тебя устраивает всего лишь субоптимальная итерация множества.
Если честно — удобнее я видел только в РС, но очень очень ограниченный набор множеств, которые я использую. Я согласен, что множество простых можно записать так же декларативно как и было записано Фибоначчи в самом начале. Но до эффективной итерации по такой записи — очень далеко. А более детальные инструкции не позволяет задавать сам язык. E>2) Совсем мало шансов у транслятора языка меня поправить, если я что-то не так надекларировал с точки зрения процедурного аспекта. В этом смысле у чистых деклараций есть тот плюс, что мы меньше мешаем оптимизатору. При этом можно подумать о каких-то подсказках, которые можно ему давать. Ну что-то типа inline в С++, например.
Пока ты думаешь по накатанной годами дорожке. Подсказки широко используются при комбинировании ленивых генераторов. E>3) Трудно залудить несколько слоёв описания множества. Ну типа множество + маска.
Enumerable.Range(1, 10).Where(x => x%2==0);
Множество и маска в разных слоях. Или я что-то не понял?
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, samius, Вы писали:
S>>
S>>let list = [ for (x = 1 when x % 2 == 0 to 10) x ];
S>>
E>Это тоже самое, что (I%2==0?I)
Да E>Ты вот с Take пример приведи, например...
Не понимаю, что именно ты хочешь от меня увидеть.
let list2 = list.Take(2);
E>Я вообще не уверен, что эти понятия надо различать. Это же всего лишь вопрос оптимизации -- хранить массив или генератор его значений. По идее хорошо бы сделать так, чтобы на основном пути, так сказать, мы это вообще не специфицировали, а оставили бы это дело RS. И только если очень надо, то мы могли бы подсказать, что типа "а этот переборщик, закэшируй таки в массив", или там "мемоизируй постранично, с такими-то страницами", или "мемоизируй на такую-то глубину", или ещё как...
Дык так и делается во множестве языков
E>Массив -- это всего лишь отображение пространства индексов на пространство значений. Какая разница, как RS внутри себя будет это отображение задавать? E>Тем более, что вполне возможны переборщики, в которых даже пространство индексов не требуется, и порядок перебора не определён, пока какие-то специальные усилия не предпримешь...
Не исключены
E>Вообще, я вот не совсем согласен с PC_2 вот в каком аспекте. У него сейчас процедурный аспект очень выпячен. Это, IMHO, нехорошо, но сильно удешевляет интерпретатор. Хорошо бы двигаться в таком направлении, чтобы ВАЖНЫЕ вопросы, вроде того ЧТО НАМ НАДО писать коротко и понятно, а всякую процедурщину оставить RS. При этом такая процедурщена, с которой RS обычно сам справляется, может быть записываема сколь угодно криво.
Меня короткость не пугает. Меня пугает именно то, что непонятно что и как догадывается о том в каком диапазоне перебирать. Почему там 10 значений оказалось, а не 1000? Или наоборот, хотели 1000, а получили Int32.MaxValue
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, samius, Вы писали:
E>>>Но вопрос в том, что из таких записей в принципе можно реализовать хотя бы не катострофически неэффективно. S>>А вот это для тебя непонятно? См (1). Должно быть понятно.
E>Ну как бы я ответа на такой вопрос не знаю.
И я. Но задумка как бы твоя, поэтому я рассчитывал что у тебя какие-то соображения есть. А так — что мы обсуждаем, теоретическую возможность какой-то сферической оптимизаци?
S>>Пока нельзя описать вообще хоть что-то и сослаться на него хотя бы снаружи. Рекурсия потом. E>Ну рекурсия или не рекурсия, это не важно, как раз. Какая разница на себя ссылаться или нет?
Как же? А если рекурсивная декларация определяется внутри другой рекурсивной декларации? Ссылаешься на что, а на что именно — как понять?
S>>Генераторам нужны данные, их надо уметь передавать. E>Про данные не понял. Проблема тут носит чисто синтаксический характер. Нам всего лишь надо как-то сказать, что в этом выражении определяется конкретно х, а не что-то ещё...
Возьмем пример с Фибоначчи. Без двух начальных значений он не поедет.
S>>По поводу мемоизации — есть решения, см. например хаскел. Ленивый список с запоминанием элементов этот вопрос решает. Беда только с расстановкой strict флагов. До сих пор рулит ручная расстановка, даже в Clean, где она есть автоматическая (вроде как).
E>Ну вот даже ответ на вопрос "для данной конкретной последовательности в этом конкретном запросе, мы мемоизируем всё, не мемоизируем ничего или используем какую-то смешанную стратегию?" мне не ясен, например.
На форуме есть люди, которым этот ответ ясен и они расставляют strictness по некоторым соображениям. Я пока этим не занимался вплотную.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, samius, Вы писали:
S>>Сможет то же самое что и ОПТИМИЗАТОР в РС. Не вижу причин, почему библиотечное решение будет уступать. E>Потому, что ему недоступен сам итерируемый код. Соответсвенно, не понятно где брать связи между переборщиками...
А откуда РС берет, там взять библиотека не сможет? Из деклараций...
S>>Вот то на чем линк основан — неявная генерация автомата по коду метода — это сделано отдельно от линка в более ранней версии языка. Но в основном эта фича использована для построения библиотеки линка, а так же при написании пользовательских генераторов. Тот же пример на F# с генерацией пароля — превращается компилятором в автомат, т.к. там lazy.
E>Ну вот если компилятор умеет делать из кода автомат, при этом представленный как-то так, что есть доступ к его структуре, то тогда всё получится. E>Но это обозначает, что встроить это можно очень сильно не в любой язык...
В C++ встраивал
S>>Но изменив несколько символов мы превратим его в eager код, который не будет превращаться в автомат. Явно задаваемые strict флаги. В общем случае оптимизаторы не умеют эффективно ставить их сами. E>Ну вот мне не ясно до конца, это с чем связано. С тем, что структура зависимостей не доступна оптимизатору, или с тем, что задача вообще не решается.
Вообще решается, но это как с автораспараллеливанием. Т.е. ручное часто эффективнее чем авто.
Здравствуйте, Erop, Вы писали:
AV>>Да, но при этом не стоит бросаться с шашкой наголо и реализовывать первое что понравилось. E>Дык какой вывод ты из этого делаешь? E>Я например, делаю такой вывод, что не надо провоцировать коллегу на всякую ерунду...
Его никто не провоцировал. Во всяком случае в самом начале. А задавали закономерные вопросы. На что регулярно получали оскорбления.
Какой вывод я сделал? Что это мертворожденная (даже можно сказать, что мертвозачатая) игрушка, которую автор скоро выбросит. По причине невозможности дальше ее развивать и ее ненужности.
AV>>А в качестве аргументов называть оппонентов дураками. E>Это, безусловно, лишнее. При этом это лишнее со всех сторон. Иногда трудно удержатьтся, конечно, но если уж не удержался, то надо потом извиниться, а не усугублять. Ну IMHO, так конструктивноае сотрудничество выглядит
Вообще-то его оппоненты держались до последнего. Да и сейчас большей частью держатся. Но любое терпение рано или поздно заканчивается и человек слышит то, что о нем думают другие.
AV>>По идее сейчас максимум что стоит писать — это маленькие прототипы, чтобы проверить ту или иную идею. И писать спеку и писать спеку и еще раз писать спеку.
E>Ну так тебе кто-то мешает? Да?
Да? Вроде бы никто. За исключением того, что все это устареет раньше, чем будут закончены игры с прототипом.
E>Если, например, ты напишешь спецификацию, то многие полуинтуитивно ясные вопросы станут яснее.
Спеку чего я напишу? Своего языка или РС? Первое возможно. Второго — нет.
E>Кроме того, имея какую-то спеку можно её потом править. Это намного проще...
Править? Не знал, что переписывание чуть менее чем полностью называется правкой.
Здравствуйте, samius, Вы писали:
S>А откуда РС берет, там взять библиотека не сможет? Из деклараций...
Где она возьмёт код?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, samius, Вы писали:
S>И я. Но задумка как бы твоя, поэтому я рассчитывал что у тебя какие-то соображения есть. А так — что мы обсуждаем, теоретическую возможность какой-то сферической оптимизаци?
Ну я как бы не знаю всего. Что-то уже знаю, а что-то надо продумать...
S>Как же? А если рекурсивная декларация определяется внутри другой рекурсивной декларации? Ссылаешься на что, а на что именно — как понять?
Ну пока никто не предложил никакого формализма. Ни для сложной рекурсии, ни для простой...
S>Возьмем пример с Фибоначчи. Без двух начальных значений он не поедет.
Их тоже можно задать прямо в том же выражении...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, samius, Вы писали:
S>Не понимаю, что именно ты хочешь от меня увидеть.
Вот и я не понимаю. S>
S>let list2 = list.Take(2);
S>
Это бессодержательно, к сожалению...
E>>Вообще, я вот не совсем согласен с PC_2 вот в каком аспекте. У него сейчас процедурный аспект очень выпячен. Это, IMHO, нехорошо, но сильно удешевляет интерпретатор. Хорошо бы двигаться в таком направлении, чтобы ВАЖНЫЕ вопросы, вроде того ЧТО НАМ НАДО писать коротко и понятно, а всякую процедурщину оставить RS. При этом такая процедурщена, с которой RS обычно сам справляется, может быть записываема сколь угодно криво. S>Меня короткость не пугает. Меня пугает именно то, что непонятно что и как догадывается о том в каком диапазоне перебирать. Почему там 10 значений оказалось, а не 1000? Или наоборот, хотели 1000, а получили Int32.MaxValue
Ну из простого предиката всё добывается как раз.
Тебя же математическая запись вроде "для любого Х, такого что,.." не напрягает? Почему так нельзя записать на декларативном языке тогда?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, samius, Вы писали:
S>Enumerable.Range(1, 10).Where(x => x%2==0); S>Множество и маска в разных слоях. Или я что-то не понял?
Да, это то, только это очень просто. Если захотеть задачку посложнее, уже начнутся проблемы.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Его никто не провоцировал. Во всяком случае в самом начале. А задавали закономерные вопросы. На что регулярно получали оскорбления.