Кстати, не понимаю почему все считают что в руби полно синтаксического сахара. По мне так не больше чем в питоне ни тебе list comprehension, ни аннотаций. Синтаксис гибче, да, но сахара примерно столькоже.
Мне не нравится Python в основном потому, что я не понимаю, как в нем делать «desugare». По правде говоря, не понимаю даже, из чего состоит Python семантически. Вы не могли бы помочь мне вникнуть?
Например, в Ruby все сводиться к отправке методов объектам, а в Python — к чему?
Возьмем пример «list comprehension» из Вики.
В Ruby сахар
Например, в Ruby все сводиться к отправке методов объектам, а в Python — к чему?
У питона и руби разный взгляд на объектную модель: в руби все-методы, а в питоне все - поля. тоесть методы в питоне - это обычные поля, объекты которых, по счастливой случайности, имеют метод __run__. Оба подхода имеют свою плюсы и свои минусы.
В python это тает в просто в соответсвующий импеартивный код, без всяких лямбд и замыканий.
Вот сейчас загугливаю «python for loop» и не нахожу в результатах ссылок на исходники. Что крайне непривычно после успеха с «ruby select» и «ruby collect».
Вот сейчас загугливаю «python for loop» и не нахожу в результатах ссылок на исходники. Что крайне непривычно после успеха с «ruby select» и «ruby collect».
Неловко спросить - а зачем это? очобенно учитывая что реализаций питона, и не все они нативны: IronPython, PyPy, etc.
Неловко спросить - а зачем это? очобенно учитывая что реализаций питона, и не все они нативны: IronPython, PyPy, etc.
Ну как это — зачем? Чтобы лучше понимать, что происходит во время выполнения кода.
То что у Python'a много реализаций — только плюс. Например, хитросплетения MRI не всегда полностью понятны, и тогда бывает полезно взглянуть, как это сделано в Rubinius'e.
В Python списковые генераторы это прямое заимствование haskell'ных:
[2 * x | x <- [0..100], x ** 2 > 3] -- на чужом компе платформа не установлена, а tryhaskell.org почему-то список float'ов выдает; какого х?
Сначала записывается выражение, по кот. будут вычисляться элементы генерируемого списка, затем итерируемая сущность(и) с «переменной» и guard'ы.
В питоне синтаксис l.c. пластично адаптирован к родным для языка сущностям, глаз выхватывает и распознает привычные конструкции. Тут даже точно так же неявно создается реальная переменная, как и при использовании цикла for.
То есть это обычный цикл for (или несколько вложенных), только более быстрый, немного вычурно записанный. Ничего более.
Там как бы про возведение в степень разговор идёт, а не про умножение. Исходных данных, кажется, достаточно, чтобы вывести тип Int для элементов результирующего списка. Вообще этот сервис (tryhaskell) странноват. Хотелось бы иметь поведение, как в сессии ghci, а не нелепые ошибки.
Вообще этот сервис (tryhaskell) странноват. Хотелось бы иметь поведение, как в сессии ghci, а не нелепые ошибки.
GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude>
Prelude> [2 * x | x <- [0..100], x ** 2 > 3]
[4.0,6.0,8.0,10.0,12.0,14.0,16.0,18.0,20.0,22.0,24.0,26.0,28.0,30.0,32.0,34.0,36.0,38.0,40.0,42.0,44.0,46.0,48.0,50.0,52.0,54.0,56.0,58.0,60.0,62.0,64.0,66.0,68.0,70.0,72.0,74.0,76.0,78.0,80.0,82.0,84.0,86.0,88.0,90.0,92.0,94.0,96.0,98.0,100.0,102.0,104.0,106.0,108.0,110.0,112.0,114.0,116.0,118.0,120.0,122.0,124.0,126.0,128.0,130.0,132.0,134.0,136.0,138.0,140.0,142.0,144.0,146.0,148.0,150.0,152.0,154.0,156.0,158.0,160.0,162.0,164.0,166.0,168.0,170.0,172.0,174.0,176.0,178.0,180.0,182.0,184.0,186.0,188.0,190.0,192.0,194.0,196.0,198.0,200.0]
Prelude> [2 * x | x <- [0..100], x ^ 2 > 3]
[4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78,80,82,84,86,88,90,92,94,96,98,100,102,104,106,108,110,112,114,116,118,120,122,124,126,128,130,132,134,136,138,140,142,144,146,148,150,152,154,156,158,160,162,164,166,168,170,172,174,176,178,180,182,184,186,188,190,192,194,196,198,200]
По-моему, вы заблуждаетесь. А какое поведение вы наблюдаете в ghci?
Там как бы про возведение в степень разговор идёт, а не про умножение. Исходных данных, кажется, достаточно, чтобы вывести тип Int для элементов результирующего списка.
Prelude> :info (**)
class Fractional a => Floating a where
...
(**) :: a -> a -> a
...
-- Defined in `GHC.Float'
infixr 8 **
Prelude> :info (*)
class Num a where
...
(*) :: a -> a -> a
...
-- Defined in `GHC.Num'
infixl 7 *
Под «копипастой» здесь вы имеете в виду кусочки из ghci?
Тогда ответ — да. На мой взляд, это хороший способ более наглядно проиллюстрировать мысль. При этом я потратил меньше времени, чем если бы пытался донести то же естественным языком.