Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
if ($count == 1 or $count == 21 or $count == 31 or $count == 41 or $count == 51 or $count == 61 or $count == 71 or $count == 81) ( $str = ' товар');
if ($count == 2 or $count == 3 or $count == 4 or $count == 22 or $count == 23 or $count == 24 or $count == 32 or $count == 33 or $count == 34 or $count == 42 or $count == 43 or $count == 44 or $count == 52 or $count == 53 or $count == 54 or $count == 62 or $count == 63 or $count == 64) ( $str = ' товара');
if ($count == 5 or $count == 6 or $count == 7 or $count == 8 or $count == 9 or $count == 10 or $count == 11 or $count == 12 or $count == 13 or $count == 14 or $count == 15 or $count == 16 or $count == 17 or $count == 18 or $count == 19 or $count == 20 or $count == 25 or $count == 26 or $count == 27 or $count == 28 or $count == 29 or $count == 30 or $count == 35 or $count == 36 or $count == 37 or $count == 38 or $count == 39 or $count == 40 or $count == 45 or $count == 46 or $count == 47 or $count == 48 or $count == 49 or $count == 50 or $count == 55 or $count == 56 or $count == 57 or $count == 58 or $count == 59 or $count == 60 or $count == 65) ( $str = ' товаров');
if ($count > 81){
$str=" тов";
}
voretions = [set(),set(),set()]
for x in range(1, 100500):
print(x, "(1)товар (2)товара (3)товаров")
voretions[int(input())-1].add(x)
for (vorec, name) in zip(voretions, ('товар', 'товара', 'товаров')):
print('if(%s) ($str = "%s");' % (' or '.join(['$count == %d' % v for v in vorec]), name))
cache = {}
def voreate(word, number):
if word not in cache:
cache[word] = {}
if number not in cache[word]:
cache[word][number] = input("Как пишется {0} если их {1}? ".format(word, number))
return cache[word][number]
def voreate(word, number):
key = (word, number)
if key not in cache:
cache[key] = input("Как пишется {0} если их {1}? ".format(word, number))
return cache[key]
require 'ostruct'
$cache = {}
def plur(word, count)
key = OpenStruct.new(word: word, count: count)
p "How do you say '#{count} of #{word}'?" and ($cache[key] = gets.chomp) unless $cache[key]
$cache[key]
end
Такими темпами я все лабы на руби сдам и уйду на летние каникулы с пятеркой
А где утверждается, что это синтаксически неверно? Синтаксически всё верно, тут ошибка типизации.
Приоритеты операторов значения не имеют, т.к. все операторы записаны в функциональной форме. В этом выражении вызывается функция
(:) :: a -> [a] -> [a]
с 4-мя аргументами:
1 :: Num t => t
(++) :: [a] -> [a] -> [a]
[2, 3] :: Num t => [t]
[4,5,6] :: Num t => [t]
Я собрал все баллы в первой части, местами было интересно, некоторые задачки нетривиальные. Лекции слушал в бэкграунде в полуха. Врядли ты из первой части что-то прям новое узнаешь.
Вторая часть мне кажется гораздо интересней, можешь с неё сразу начать. Там ключевые вещи из Typeclassopedia разбираются. Интереснее всего смотреть чужие решения, чакры раскрываются.
Я там засрался на одном, поревьюй. Тайм лимит эксидед.
Определенный интеграл функции на отрезке методом трапеций.
integration :: (Double -> Double) -> Double -> Double -> Double
integration f a b = get f a b where
space a b c | a >= b = (b * c) + ((a - b) * c / 2)
| True = (a * c) + ((b - a) * c / 2)
get f a b | a <= b = helper f a b 0 (f a)
| True = - (helper f b a 0 (f b))
s :: Double
s = abs (a - b) / 1000
helper f a b i t | a > b = i
| True = let t' = f (a + s) in helper f (a + s) b (i + (space t t' s)) t'
Ну получилась вот такая вореция, тест прошло, но мне кажется, я императивно мыслю. Можно короче?
integration :: (Double -> Double) -> Double -> Double -> Double
integration f a b = h * ((((f a) + (f b)) / 2) + (helper f a 0 (n - 1))) where
h = (b - a) / n
n = 1000
helper f a s 0 = s
helper f a s i = helper f a (s + (f (a + i * h))) (i - 1)
integration :: (Double -> Double) -> Double -> Double -> Double
integration f a b = h * ((f a + f b) / 2 + (sum $ map g [1..n-1]))
where h = (b - a) / n
n = 1000
g i = f (a + i * h)
при желании можно заменить g на (f . (a +) . (* h)), но это, кмк, менее читабельно.
Почему тут ответ 9 и какого именно вида эти функции.
Сколько разных всегда завершающихся функций с типом a -> (a,b) -> a -> (b,a,a) можно реализовать?
Почему функция, которую возвращает carry id имеет тип a -> b -> (a, b). Нигде ничего не смог начитать, карринг же наоборот все тьюплы превращает в последовательность вызовов, какого рожна?
Я мало знаю хаскель, но тип curry id можно получить следующим способом:
curry f = \x y -> f (x, y)
curry id = \x y -> id (x, y)
-- найдём тип curry id как тип \x y -> id (x, y)
id :: a -> a
id x :: a -- применяя к аргументу
id (x, y) :: (a, b)
\y -> id (x, y) :: b -> (a, b) -- навешивая аргумент
\x y -> id (x, y) :: a -> b -> (a, b)
> Нигде ничего не смог начитать, карринг же наоборот все тьюплы превращает в последовательность вызовов, какого рожна?
curry работает для функций, которые по смыслу бинарные, а id унарна. Соответственно, тут здравый смысл не работает, а работает только математика со своими упоротыми неинтуитивными выводами.
Банальная комбинаторика: b в результате можо выбрать только одним способом, два a можно выбрать 3^2 способами (использовать первый аргумент два раза, первый + второй, второй + первый, второй два раза и т.д.)
> Нигде ничего не смог начитать
ghci использовать не пробовал?
:t curry
curry :: ((a, b) -> c) -> a -> b -> c
:t id
id :: t -> t
Первый аргумент curry имеет вид
(a, b) -> c
Давай решим уравнения
t -> t = (a, b) -> c
t = (a, b)
t = c
-----
c = (a, b)
следовательно, тип c = (a, b), а у id в этом контексте должен быть тип
id :: (a, b) -> (a, b)
подставляем c = (a, b) в curry, получаем
curry :: ((a, b) -> (a, b)) -> a -> b -> (a, b)
> c = (a, b)
А, то есть смысл всё же есть. Область определения id сужается до кортежа, и по сути она становится некаррированным конструктором кортежа (uncurry (,)) - принимает кортеж и возвращает кортеж. curry делает из этого конструктор кортежа нормального человека (который не требует кортеж для создания кортежа)
И, соответственно, curry id = (,)
> Почему тут ответ 9 и какого именно вида эти функции.
> > a -> (a,b) -> a -> (b,a,a)
> Банальная комбинаторика: b в результате можо выбрать только одним способом, два a можно выбрать 3^2 способами (использовать первый аргумент два раза, первый + второй, второй + первый, второй два раза и т.д.)
Роман какой-то умный, я месяц назад его ответ так и не понял.
На случай, если кто-то столь же простой умом, сколь и я, будет мимопроходить и читать обсуждение:
1. Первое, что приходит в голову - мы можем написать их бесконечность, т.к. существует бесконечность типов a, b и у них может быть до бесконечности значений.
2. Это неверно, т.к. на самом деле из-за максимально свободного выбора типов (a, b - любое) у нас связаны руки, и мы минимально свободны. Мы должны написать такую функцию, которая подходила бы для любого типа, даже для неба, Аллаха, пустого кортежа и т.п.
3. Т.к. у нас связаны руки, мы не имеем никакой возможности сконструировать значение (нет универсального конструктора значения для любого типа), и единственное, что мы можем сделать - возвратить уже имеющееся значение.
4. a -> a - одна функция, т.к. передают одно значение и вернуть можем только его
(a, a) -> a - две функции, т.к. передают два значение и вернуть можем либо одно, либо другое
a -> a -> a, (a, a) -> a, a -> b -> a -> a, (a, b) -> a -> a, (a, b, a) -> a - снова две функции, т.к. на входе два значения типа a, а на выходе - одно, и не важно, во сколько этапов их передавали и как зашумляли ввод другими типами
5. (a, a, a) -> (a, a) - 9 вариантов, т.к. возвращаем два a, и каждое из них можно выбрать из трёх вариантов (то, о чём говорил Роман).
a -> b -> (c, a) -> a -> d -> (a, a, b) - снова 9 вариантов, т.к. на входе каким-то способом передали те же 3a, а вернуть надо 2a.
На самом деле в каждом языке есть свой подход к таким вот "on demand рекордам (структурам?)".
Котлин предлагает data classes. Руби предлагает Struct или OpenStruct (у последней равенство проверяется по всем полям, по утячьи) в питоне изначально это были туплы.
Очень много методов в API которые возвращают кортежи типа (день, месяц, год).
И только в джаве нифига нет кроме громоздкого класса с полями, конструктором и геттерами.
Даже си умеет структуры
Today I committed the first 5112 lines of D code to Facebook's repository. The project is in heavy daily use at Facebook. Compared to the original version (written in C++) we've measured massive wins in all of source code size, build speed, and running speed.
In all likelihood we'll follow up with a blog post describing the process.
Дикты -- да. Но по какой-то причине обычно в питоне юзают туплы, а не дикты.
Хотя учитывая иммутабельность строк и наличие пула строковых литералов вполне могли бы дикты (как в javascript)
но более всего я бешусь когда кортежи юзают как рид-онли листы. вбивав би!
> но более всего я бешусь когда кортежи юзают как рид-онли листы. вбивав би!
+1
Хотя, это вина создателя языка, что он либо назвал список кортежем, либо дал кортежу интерфейс списка.
Если сравнивать использование списка и использование неизменяемого списка, то второе в общем случае лучше, т.к. меньше шансов выстрелить себе в ногу при смешивании передачи по ссылке и мутабельности.
А вообще, подобная питушня свойственна утиной типизации:
cons(1, 2) // кортеж из 1, 2
cons(1, nil) // список из 1
P.S. Какие базисные векторы типизации у нас есть? строгость, статичность-динамичность, явность, утиность, что-нибудь ещё? Кажется, что утиность не является линейной комбинацией строгости, -ичности и явности:
полиморфные питухи в Haskell - статическая, строгая, неявная, утиная
шаблоны C++ - статическая, строгая, явная, утиная
JS - динамическая, слабая, неявная, утиная
python - динамическая, строгая, неявная, утиная
C - статическая, слабая, явная, не утиная
>>что он либо назвал список кортежем, либо дал кортежу интерфейс списка.
На самом деле не совсем так.
В питоне роль "интерфейсов" часто играют протоколы: нужно просто реализовать метод foo чтобы стать "foo-like объектом". В какой-то момент это всех заебало и появились Abstract Base Classes (ака ABC), но это уже другая сказка.
Собственно, в этом и есть смысл утки: не нужно явно наследовать какой-то интерфейс, городить адаптеры итд, достаточно реализовать нужный метод и правильно его назвать.
Чтобы быть "Iterable" надо иметь метод ``__iter__`` который вернет iterator, и тогда по тебе можно делать "for spam in ТЫ", можно делать тебе next() итд.
Ну вот list (мутабельный список) и tuple (кортеж) успешно этот "контракт" реализуют. Не понимаю нафига это делает тупл: К кортежу надо по индексу обращаться, за желание итерироваться по картежу надо бы пиздить наверное.
Достаточно было реализовать __get__, imho.
В какой-то момент чуваки поняли что тупл это такая славная защита для всякого рода констант и дефалтных значений аргументов чтобы никто их не поменял, и понеслась.
>> что он либо назвал список кортежем, либо дал кортежу интерфейс списка.
> На самом деле не совсем так.
Я здесь использую слово "интерфейс" в более общем смысле.
Чтобы было "так", исправлю "интерфейс списка" на "интерфейс массива", т.к. ожидаемый интерфейс списка - это next(node) и isnull(node), а не element(list, index) и length(list), что является интерфейсом массива.
Кстати да. То, что списку дан интерфейс массива (или массив назван списком) - тоже странно.
> Достаточно было реализовать __get__, imho.
Действительно. Смотрелось бы более близко к привычным людям кортежам.
Впрочем, доступ по индексу на практике удобнее. Более полезно было бы переименовать существующие list, tuple и array в array, const_array и fast_array, чтобы не путать людей. А кортежи в интерпретируемой динамической питушне с массивами и словарями вроде как и не нужны.
Здесь, видимо, имеется в виду list в общем смысле (просто список значений, без деталей реализации), а не конкретный linked list (как в няшной и функциональщине).
Лист реализован через массив.
Я думаю что список это такой тип, по которому можно итерироваться и обращаться по индексу. А как он там внутри сделан (через linked list или array) это уже детали.
Тащемто в жабе так и есть: interface List раследуют ArrayList и LinkedList (и еще пяток-другой всяких других).
O(1) у массива ровно потому, что в x86 (и других современных процах) можно сделать
mov eax, [началоМассива + индексМассива]
Это куда как более низкоуровневые детали, чем понятие список
Полиморфные питухи - функции без указания типа. Утиные потому, что работают для всего того, что имеет свойства, требуемые реализацией самого полиморфного питуха.
Например, f в следующих определениях:
duck = (+ 1)
f xs = map duck xs
duck = (: [])
f xs = map duck xs
f требует, чтобы xs было списком чего-то, а duck преобразовывала бы это конкретное что-то куда-то во что угодно. Соответственно, f работает для списков многих типов и с разными (с точки зрения типов) реализациями duck. (И с разными реализациями map)
Аналогично, если бы f x y было бы просто x + y, f бы работала для любых типов, над которыми бы определили сложение. Не просто для какого-то там общего Num, а для всего, лишь бы + как-то определили.
> f x y было бы просто x + y, f бы работала для любых типов, над которыми бы определили сложение
Нет, f будет требовать тайпкласс, который определяет +. "Утиная" типизация локальна, она вычисляет минимальные требования исходя из использования. Хаски, конечно, выведет наиболее общий тип, но не с точностью до конкретных операций.
Толи дело OCaml.
# let dot a b = a#x *. b#x +. a#y *. b#y +. a#z *. b#z;;
val dot :
< x : float; y : float; z : float; .. > ->
< x : float; y : float; z : float; .. > -> float = <fun>
У меня такое ощущение, что тут таится какая-то стервозная математическая питушня вроде бесконечных лент или отрицания императивности do-нотации при признании императивности кода на C, когда на самом деле вся питушня между точками следования в C работает с разными world, который в C просто передаётся неявно в каждое новое выражение (синтаксический сахар такой).
А именно: вопрос философский, выводы зависят от способа подгона к нему теории; либо требуется количественное измерение характеристики, а не просто "да"/"нет".
Как со строгостью Python/Java, где =/+ нестрогие и со слабостью JS, где точка строгая.
> но не с точностью до конкретных операций.
Для стороннего наблюдателя различие с истинно утиными языками только в том, что тут из-за этого надо при определении полиморфной функции заранее определять конкретные операции, чтобы где-то внутри вычислился тип. Но это требование для стороннего наблюдателя ничем не хуже требования определить функцию перед её вызовом.
Haskell менее утиный, чем python/JS, но более утиный, чем C++ без шаблонов.
Но ведь так оно и есть, я отравился ворециями все эти свойства типизации имеют свою шкалу, а не могут быть описаны наличием/отсутствием фичи.
Строгость типизации в C++ можно нивелировать перегрузкой операторов и шаблонами. Статичность типизации - нагромождением своих приблуд с void* или virtual (см. мой пример динамических слабых питухов в C++).
Все эти обзывательства в адрес типизаций отражают лишь положение по умолчанию и оценку "по большей степени".
Но C++ без перегрузки операторов и операторов-кастов, без указателей и virtual и без шаблонов предоставлял бы намного меньше возможностей для динамической слабой питушни. Аналогично - с boost::any, std::any и моей питушнёю. В первом случае возможность где-то есть, но не официально в языке, во втором - возможность официально в языке, в третьем - в сторонней библиотеке или в обычном коде. И мой код в теории может пройти путь от сторонней библиотеки до std и синтаксического сахара, меняя положение C++ в пространстве типизации, меняя сложность использования (от скачивания сторонней питушни до использования на уровне конструкций языка или стандартной библиотеки).
И бинарное да/нет только смущает, порождая холивары и оговорки. Впрочем, в моём случае холивары были бы насчёт характеристической функции типизации.
Всё же утка не совсем про строгость типизации, и уж точно не про статичность: она про отсутствие отдельного, явно описанного интерфейса.
Интерфейс там выводится, точно как тип.
Вот тебе пример строгой, статической, и при этом утиной типизации в волшебном псевдо языке. (Подобные штуки есть в статически типизированных функциональных языках)
Fun AcceptStudent(student : [hasProperty(name:String), hasProperty(age:Int)])
В нее можно скормить любой объект, у которого есть проперти нужного типа с нужными именами. Ему не нужно явно имплементить интерфейс, достаточно просто иметь такие проперти.
Это вполне можно проверить статически, например на этапе компиляции.
> Всё же утка не совсем про строгость типизации, и уж точно не про статичность
Где-то выше (http://govnokod.ru/23492#comment393616) я как раз писал, что мне кажется, что утка - отдельное измерение в пространстве типизации.
В последнем комментарии я показывал, что в C++ можно манипулировать строгостью и статичностью вплоть до их искоренения, намекая на то, что и по оси утиности можно двигаться туда-сюда.
> AcceptStudent
> в волшебном псевдо языке
Крестошаблоны какие-то. Их я даже в том комментарии неделю назад упоминал.
Как же компилятор поймет, что я переставил местами два целочисленных поля?
> пока ты не захочешь использовать их как ключи в мапе
Вообще я за структуры, у которых надо явно указывать имена полей в инициализаторах. Типа кортеж с адресацией полей по имени, а не индексу. Это конечно фантазии, а не питон.
Такими темпами я все лабы на руби сдам и уйду на летние каникулы с пятеркой
А где утверждается, что это синтаксически неверно? Синтаксически всё верно, тут ошибка типизации.
Приоритеты операторов значения не имеют, т.к. все операторы записаны в функциональной форме. В этом выражении вызывается функция
(:) :: a -> [a] -> [a]
с 4-мя аргументами:
1 :: Num t => t
(++) :: [a] -> [a] -> [a]
[2, 3] :: Num t => [t]
[4,5,6] :: Num t => [t]
В задании на stepik.org. Там говорится: выберите синтаксически верные выражения. Это считается неверным.
Вторая часть мне кажется гораздо интересней, можешь с неё сразу начать. Там ключевые вещи из Typeclassopedia разбираются. Интереснее всего смотреть чужие решения, чакры раскрываются.
В общем, на твоё усмотрение, курс бесплатный.
Определенный интеграл функции на отрезке методом трапеций.
Возможно, когда a == b, a > b в helper никогда не выполняется.
У тебя слишком много кода, лучше всего написать определение из вики, его точно принимает, и кода мало получается.
при желании можно заменить g на (f . (a +) . (* h)), но это, кмк, менее читабельно.
Почему тут ответ 9 и какого именно вида эти функции.
Сколько разных всегда завершающихся функций с типом a -> (a,b) -> a -> (b,a,a) можно реализовать?
Почему функция, которую возвращает carry id имеет тип a -> b -> (a, b). Нигде ничего не смог начитать, карринг же наоборот все тьюплы превращает в последовательность вызовов, какого рожна?
> Нигде ничего не смог начитать, карринг же наоборот все тьюплы превращает в последовательность вызовов, какого рожна?
curry работает для функций, которые по смыслу бинарные, а id унарна. Соответственно, тут здравый смысл не работает, а работает только математика со своими упоротыми неинтуитивными выводами.
Банальная комбинаторика: b в результате можо выбрать только одним способом, два a можно выбрать 3^2 способами (использовать первый аргумент два раза, первый + второй, второй + первый, второй два раза и т.д.)
> Нигде ничего не смог начитать
ghci использовать не пробовал?
:t curry
curry :: ((a, b) -> c) -> a -> b -> c
:t id
id :: t -> t
Первый аргумент curry имеет вид
(a, b) -> c
Давай решим уравнения
t -> t = (a, b) -> c
t = (a, b)
t = c
-----
c = (a, b)
следовательно, тип c = (a, b), а у id в этом контексте должен быть тип
id :: (a, b) -> (a, b)
подставляем c = (a, b) в curry, получаем
curry :: ((a, b) -> (a, b)) -> a -> b -> (a, b)
А, то есть смысл всё же есть. Область определения id сужается до кортежа, и по сути она становится некаррированным конструктором кортежа (uncurry (,)) - принимает кортеж и возвращает кортеж. curry делает из этого конструктор кортежа нормального человека (который не требует кортеж для создания кортежа)
И, соответственно, curry id = (,)
> > a -> (a,b) -> a -> (b,a,a)
> Банальная комбинаторика: b в результате можо выбрать только одним способом, два a можно выбрать 3^2 способами (использовать первый аргумент два раза, первый + второй, второй + первый, второй два раза и т.д.)
Роман какой-то умный, я месяц назад его ответ так и не понял.
На случай, если кто-то столь же простой умом, сколь и я, будет мимопроходить и читать обсуждение:
1. Первое, что приходит в голову - мы можем написать их бесконечность, т.к. существует бесконечность типов a, b и у них может быть до бесконечности значений.
2. Это неверно, т.к. на самом деле из-за максимально свободного выбора типов (a, b - любое) у нас связаны руки, и мы минимально свободны. Мы должны написать такую функцию, которая подходила бы для любого типа, даже для неба, Аллаха, пустого кортежа и т.п.
3. Т.к. у нас связаны руки, мы не имеем никакой возможности сконструировать значение (нет универсального конструктора значения для любого типа), и единственное, что мы можем сделать - возвратить уже имеющееся значение.
4. a -> a - одна функция, т.к. передают одно значение и вернуть можем только его
(a, a) -> a - две функции, т.к. передают два значение и вернуть можем либо одно, либо другое
a -> a -> a, (a, a) -> a, a -> b -> a -> a, (a, b) -> a -> a, (a, b, a) -> a - снова две функции, т.к. на входе два значения типа a, а на выходе - одно, и не важно, во сколько этапов их передавали и как зашумляли ввод другими типами
5. (a, a, a) -> (a, a) - 9 вариантов, т.к. возвращаем два a, и каждое из них можно выбрать из трёх вариантов (то, о чём говорил Роман).
a -> b -> (c, a) -> a -> d -> (a, a, b) - снова 9 вариантов, т.к. на входе каким-то способом передали те же 3a, а вернуть надо 2a.
А почему тогда у тебя "Синьор Помидор" на аватарке?
Как выходишь ты к базару,
Так за ним видать собор,
Я пришел сюда сегодня,
Чтоб нажраться помидор.
На весах – мордатый дядя,
Груда ящиков за ним,
Подмигнул ему я хитро:
Выдвигай, мол, всё съедим!
Ну а он мне прямо в рыло
Волосатый свой кулак:
Ты уматывай отселе,
Быстро чтобы и вот так!
Не с твоим свинячьим рылом
Вкусный кушать помидор.
Я в грустях ушел с базара,
С коего видать собор.
И сказать по-правде нужно:
Братцы, грубь-то нам зачем?
И на кой руками в рыло?
Помидор охотно всем.
Помидорчиков захотелось?
Помидор охотно всем.
На самом деле в каждом языке есть свой подход к таким вот "on demand рекордам (структурам?)".
Котлин предлагает data classes. Руби предлагает Struct или OpenStruct (у последней равенство проверяется по всем полям, по утячьи) в питоне изначально это были туплы.
Очень много методов в API которые возвращают кортежи типа (день, месяц, год).
И только в джаве нифига нет кроме громоздкого класса с полями, конструктором и геттерами.
Даже си умеет структуры
https://docs.microsoft.com/ru-ru/dotnet/csharp/language-reference/keywords/struct
https://kotlinlang.org/docs/reference/data-classes.html
А правда D юзают в facebook и ebay?
netflix тоже
In all likelihood we'll follow up with a blog post describing the process.
Andrei
-- http://forum.dlang.org/post/l37h5s$2gd8$1@digitalmars.com
Возможно, он имеет ввиду вот эту поделку
очко сжимается от мысли о том, как это все сломается при изменении полей.
Хотя учитывая иммутабельность строк и наличие пула строковых литералов вполне могли бы дикты (как в javascript)
но более всего я бешусь когда кортежи юзают как рид-онли листы. вбивав би!
+1
Хотя, это вина создателя языка, что он либо назвал список кортежем, либо дал кортежу интерфейс списка.
Если сравнивать использование списка и использование неизменяемого списка, то второе в общем случае лучше, т.к. меньше шансов выстрелить себе в ногу при смешивании передачи по ссылке и мутабельности.
А вообще, подобная питушня свойственна утиной типизации:
P.S. Какие базисные векторы типизации у нас есть? строгость, статичность-динамичность, явность, утиность, что-нибудь ещё?
Кажется, что утиность не является линейной комбинацией строгости, -ичности и явности:
На самом деле не совсем так.
В питоне роль "интерфейсов" часто играют протоколы: нужно просто реализовать метод foo чтобы стать "foo-like объектом". В какой-то момент это всех заебало и появились Abstract Base Classes (ака ABC), но это уже другая сказка.
Собственно, в этом и есть смысл утки: не нужно явно наследовать какой-то интерфейс, городить адаптеры итд, достаточно реализовать нужный метод и правильно его назвать.
Чтобы быть "Iterable" надо иметь метод ``__iter__`` который вернет iterator, и тогда по тебе можно делать "for spam in ТЫ", можно делать тебе next() итд.
Ну вот list (мутабельный список) и tuple (кортеж) успешно этот "контракт" реализуют. Не понимаю нафига это делает тупл: К кортежу надо по индексу обращаться, за желание итерироваться по картежу надо бы пиздить наверное.
Достаточно было реализовать __get__, imho.
В какой-то момент чуваки поняли что тупл это такая славная защита для всякого рода констант и дефалтных значений аргументов чтобы никто их не поменял, и понеслась.
> На самом деле не совсем так.
Я здесь использую слово "интерфейс" в более общем смысле.
Чтобы было "так", исправлю "интерфейс списка" на "интерфейс массива", т.к. ожидаемый интерфейс списка - это next(node) и isnull(node), а не element(list, index) и length(list), что является интерфейсом массива.
Кстати да. То, что списку дан интерфейс массива (или массив назван списком) - тоже странно.
https://wiki.python.org/moin/TimeComplexity
Похоже, либо я не умею в О-нотацию, либо перед нами массив.
> Достаточно было реализовать __get__, imho.
Действительно. Смотрелось бы более близко к привычным людям кортежам.
Впрочем, доступ по индексу на практике удобнее. Более полезно было бы переименовать существующие list, tuple и array в array, const_array и fast_array, чтобы не путать людей. А кортежи в интерпретируемой динамической питушне с массивами и словарями вроде как и не нужны.
Я думаю что список это такой тип, по которому можно итерироваться и обращаться по индексу. А как он там внутри сделан (через linked list или array) это уже детали.
Тащемто в жабе так и есть: interface List раследуют ArrayList и LinkedList (и еще пяток-другой всяких других).
O(1) у массива ровно потому, что в x86 (и других современных процах) можно сделать
mov eax, [началоМассива + индексМассива]
Это куда как более низкоуровневые детали, чем понятие список
P.S. Для полноты картины осталось найти ещё десять языков.
Кто такие полиморфные питухи в Хаски и почему они утиные?
P.S.
Самец утки называется се́лезень, а не питух.
A male duck is called a drake.
Например, f в следующих определениях:
f требует, чтобы xs было списком чего-то, а duck преобразовывала бы это конкретное что-то куда-то во что угодно. Соответственно, f работает для списков многих типов и с разными (с точки зрения типов) реализациями duck. (И с разными реализациями map)
Аналогично, если бы f x y было бы просто x + y, f бы работала для любых типов, над которыми бы определили сложение. Не просто для какого-то там общего Num, а для всего, лишь бы + как-то определили.
> f x y было бы просто x + y, f бы работала для любых типов, над которыми бы определили сложение
Нет, f будет требовать тайпкласс, который определяет +. "Утиная" типизация локальна, она вычисляет минимальные требования исходя из использования. Хаски, конечно, выведет наиболее общий тип, но не с точностью до конкретных операций.
Толи дело OCaml.
А именно: вопрос философский, выводы зависят от способа подгона к нему теории; либо требуется количественное измерение характеристики, а не просто "да"/"нет".
Как со строгостью Python/Java, где =/+ нестрогие и со слабостью JS, где точка строгая.
> но не с точностью до конкретных операций.
Для стороннего наблюдателя различие с истинно утиными языками только в том, что тут из-за этого надо при определении полиморфной функции заранее определять конкретные операции, чтобы где-то внутри вычислился тип. Но это требование для стороннего наблюдателя ничем не хуже требования определить функцию перед её вызовом.
Haskell менее утиный, чем python/JS, но более утиный, чем C++ без шаблонов.
ты отравился ворециями, скорее вызывай скорую
Строгость типизации в C++ можно нивелировать перегрузкой операторов и шаблонами. Статичность типизации - нагромождением своих приблуд с void* или virtual (см. мой пример динамических слабых питухов в C++).
Все эти обзывательства в адрес типизаций отражают лишь положение по умолчанию и оценку "по большей степени".
Но C++ без перегрузки операторов и операторов-кастов, без указателей и virtual и без шаблонов предоставлял бы намного меньше возможностей для динамической слабой питушни. Аналогично - с boost::any, std::any и моей питушнёю. В первом случае возможность где-то есть, но не официально в языке, во втором - возможность официально в языке, в третьем - в сторонней библиотеке или в обычном коде. И мой код в теории может пройти путь от сторонней библиотеки до std и синтаксического сахара, меняя положение C++ в пространстве типизации, меняя сложность использования (от скачивания сторонней питушни до использования на уровне конструкций языка или стандартной библиотеки).
И бинарное да/нет только смущает, порождая холивары и оговорки.
Впрочем, в моём случае холивары были бы насчёт характеристической функции типизации.
Интерфейс там выводится, точно как тип.
Вот тебе пример строгой, статической, и при этом утиной типизации в волшебном псевдо языке. (Подобные штуки есть в статически типизированных функциональных языках)
В нее можно скормить любой объект, у которого есть проперти нужного типа с нужными именами. Ему не нужно явно имплементить интерфейс, достаточно просто иметь такие проперти.
Это вполне можно проверить статически, например на этапе компиляции.
Я точно помню что в каком-то функциональном оно было, может быть в OCaml?
Я двумя комментами выше об этом написал.
>> Толи дело OCaml.
Где-то выше (http://govnokod.ru/23492#comment393616) я как раз писал, что мне кажется, что утка - отдельное измерение в пространстве типизации.
В последнем комментарии я показывал, что в C++ можно манипулировать строгостью и статичностью вплоть до их искоренения, намекая на то, что и по оси утиности можно двигаться туда-сюда.
> AcceptStudent
> в волшебном псевдо языке
Крестошаблоны какие-то. Их я даже в том комментарии неделю назад упоминал.
В нормальных языка это фича. Компилятор найдёт за тебя все места, которые нужно проапдейтить.
> Дикты пизже
пока ты не захочешь использовать их как ключи в мапе
Да, я имею в виду, что дикты нельзя использовать как ключи диктов.
Но вообще я не уверен что я хочу видеть дикты с диктами внутри. Такие композиты лучше строить уже из объектов, имхо
> пока ты не захочешь использовать их как ключи в мапе
Вообще я за структуры, у которых надо явно указывать имена полей в инициализаторах. Типа кортеж с адресацией полей по имени, а не индексу. Это конечно фантазии, а не питон.
А тремя строчками выше Роман написан
>>Key = collections.namedtuple('Key', ['word', 'number'])
В питоне это литерал для set, кстати.
Мне казалсоь что даже в няшной можно
нет?
Я думал что в крестах всё почти можно, что в няшной. Всё таки C99 уже давно все умеют.
ААА
A few additions to C99 (compared with C89) were deliberately not adopted in C++:
[1] Variable-length arrays (VLAs); use vector or some form of dynamic array а alloca можно?
[2] Designated initializers; use constructors
блин! Теперь я ТОЧНО знаю что НЕЛЬЗЯ писать через слешик "c/c++"
а кроме шуток такие штуки надо делать через gnu gettext
https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html
``<meta name="Generator" content="makeinfo">``
Так что должен один-в-один повторять info gettext
Даже как-то удивительно что хоть что-то в этом мире делается ПРАВИЛЬНО