Здравствуйте, pgregory, Вы писали:
P>Это -- чушь. Доказательство (GHCi, version 6.10.1):
А вот тоже смешно:
Prelude> let f = 42
Prelude> :t f
f :: Integer
Prelude> :t 42
42 :: (Num t) => t
Я доказал, что 42 — это не 42!
Re[32]: [haskell] considered mainstream
От:
Аноним
Дата:
11.03.09 17:30
Оценка:
Здравствуйте, pgregory, Вы писали:
K>>Если не знать что такое коммутативное кольцо с единицей — можно написать, например, b+0, хотя это то же свамое, что и b, а если не знать что такое монады можно написать P>
P>a <- foo
P>return a
P>
K>>хотя это то же самое, что и просто foo.
P>Вот вы и попались!
P>Это -- чушь. Доказательство (GHCi, version 6.10.1):
Ага, интерпретатором вы пользоваться умеете, осталось ещё мозг подключить.
Какое отношение приведённый код имеет к аналогии со знанием свойств кольца и знанием monad laws?
P>Комментарии нужны?
P>Да, я понимаю, что вы хотели сказать. Но, как видите, у вас не получилось
Здравствуйте, lomeo, Вы писали:
L>А вот тоже смешно:
L>
L>Prelude> let f = 42
L>Prelude> :t f
L>f :: Integer
L>Prelude> :t 42
L>42 :: (Num t) => t
L>
L>Я доказал, что 42 — это не 42!
:-)
Ок, вижу, комментарии все же нужны.
В моем примере подразумевалась необходимость связки типа -XNoMonomorphismRestriction + import Control.Monad + liftM для превращения одного в другое. Если нужда в этой связке -- лишь плод моего воображения, я признаю, что неправ. Иначе вы признаете, что я прав.
Здравствуйте, pgregory, Вы писали:
P>В моем примере подразумевалась необходимость связки типа -XNoMonomorphismRestriction + import Control.Monad + liftM для превращения одного в другое. Если нужда в этой связке -- лишь плод моего воображения, я признаю, что неправ. Иначе вы признаете, что я прав.
P>Идет?
Было сказано: do { a <- foo; return foo} то же самое, что и foo.
Напиши такое монадическое значение foo, для которого нельзя заменить do {...} на foo.
Тогда я признаю, что ты прав.
Очевидно, что для монады это сделать невозможно. Иначе это будет не монада. Игры же с типами совершенно несерьёзны и показывают, что ты не понимаешь, о чём говорил твой оппонент. В частности, в твоём определении f2 надо писать let f2 (x :: Monad m => m a) = x.
Здравствуйте, Klapaucius, Вы писали:
P>>Да, я понимаю, что вы хотели сказать. Но, как видите, у вас не получилось
K>От меня все пули ушли. Так что проблемы на принимающей стороне.
Здравствуйте, lomeo, Вы писали:
P>>В моем примере подразумевалась необходимость связки типа -XNoMonomorphismRestriction + import Control.Monad + liftM для превращения одного в другое. Если нужда в этой связке -- лишь плод моего воображения, я признаю, что неправ. Иначе вы признаете, что я прав.
L>... Очевидно, что для монады это сделать невозможно. Иначе это будет не монада. Игры же с типами совершенно несерьёзны и показывают, что ты не понимаешь, о чём говорил твой оппонент. В частности, в твоём определении f2 надо писать let f2 (x :: Monad m => m a) = x.
Согласен и с тем, и с тем. Нет проблем — признаю, что был не прав. Ответил, погорячившись.
Займусь-ка я теперь хаскелем посерьезней (возрадуйся, thesz! )
Здравствуйте, z00n, Вы писали:
Z>В ObjectiveC 2.0 уже 3 года как консервативный GC. Tim Sweeney применяет его в UnrealEngine2/3 уже несколько лет на приставках без виртуальной памяти.
Здравствуйте, Alxndr, Вы писали:
Z>В ObjectiveC 2.0 уже 3 года как консервативный GC. Tim Sweeney применяет его в UnrealEngine2/3 уже несколько лет на приставках без виртуальной памяти.
A>Ни в слайдах, ни в комментариях нет упоминания Objective-C.
Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, Alxndr, Вы писали:
A>>Ни в слайдах, ни в комментариях нет упоминания Objective-C. Z>Местоимение 'его' относилось к GC.
Здравствуйте, thesz, Вы писали:
T>>>Ты не поверишь, но не кто иной, как Джон Кармак по выпуску первого Quake говаривал, что C++ для игр не предназначен, у него нельзя контролировать расход памяти и задержки по времени из-за перегрузки и конструкторов-декструкторов. T>>>См. на Doom3 инструменты 2005 года. RD>>Вы наверное удивитесь, но мир не стоит на месте. И в то время C++ возможно (ВОЗМОЖНО) действительно не подходил для написания игр. Но если ДАЖЕ он не подходил ТОГДА, то сейчас, после долгой эволюции уже подходит.
T>За счёт чего это? Те же конструкторы, те же деструкторы, то же непредсказуемое время из-за перегрузки.
Здравствуйте, thesz, Вы писали: T>>>За счёт чего это? Те же конструкторы, те же деструкторы, то же непредсказуемое время из-за перегрузки. T>C++ не даёт создавать свои операторы, поэтому все перегружают уже существующие. T>Получается, что a << b может означать и сдвиг, и вывод в файл. T>Без профайлера и ассемблерного листинга не разобраться, Одного code review не достаточно.
Это у вас какой-то неправильный мёд! Его наверное готовят неправильные пчёлы.
Никакой неоднозначности нет. Зная типы a и b знаешь всё.
Профайлеров и листинов ассемблера не нужно.
Все затраты времени в языке детерминированы и могут быть учтены кроме внешних вызовов.
Чего не наблюдается в haskell-е, ну дык он вроде не для того.
T>>>>За счёт чего это? Те же конструкторы, те же деструкторы, то же непредсказуемое время из-за перегрузки. T>>C++ не даёт создавать свои операторы, поэтому все перегружают уже существующие. T>>Получается, что a << b может означать и сдвиг, и вывод в файл. T>>Без профайлера и ассемблерного листинга не разобраться, Одного code review не достаточно. T>Это у вас какой-то неправильный мёд! Его наверное готовят неправильные пчёлы.
Это не у меня. Это у Джона Кармака. Хотя и у меня тоже, надо сказать.
T>Никакой неоднозначности нет. Зная типы a и b знаешь всё. T>Профайлеров и листинов ассемблера не нужно. T>Все затраты времени в языке детерминированы и могут быть учтены кроме внешних вызовов.
Какая сложность у new/delete для произвольного класса?
Зависит ли скорость выделения/освобождения памяти от количества и других параметров объектов, выделенных ранее?
Скорость работы C++ недостаточно детерминирована. Для её приемлемой определённости необходимо поработать ручками.
T>Чего не наблюдается в haskell-е, ну дык он вроде не для того.
Именно это и говорили про C++ в 1993-5 годах.
Удивительно даже.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
)
