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

L>>Найду — обязательно поделюсь, пока не вспомню.

EC>Это?
EC>Искал так.

Точно

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

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

L>>>Найду — обязательно поделюсь, пока не вспомню.

EC>>Это?
EC>>Искал так.

L>Точно

Эй! Обещал на голландском, а подсовываешь на эстонском

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

D>Эй! Обещал на голландском, а подсовываешь на эстонском

Это одинаковые языки. В том смысле, что я их одинаково не знаю

Здравствуйте, Денис Москвин (перевод), Вы писали:

ДМП>Статья:
ДМП>Мягкое введение в Haskell

Автор(ы): Пол Хьюдак, Джон Петерсон, Джозеф Фасел
Дата: 03.03.2007
Задача данного материала – обеспечить «мягкое» введение в программирование на Haskell для имеющих опыт программирования, по крайней мере, на одном языке, желательно функциональном (даже если это «почти функциональный» язык, такой как ML или Scheme).

Спасибо за перевод, очень ценный материал.
Но позвольте немного позанудствовать:

В качестве примера пользовательской функции, работающей со списками, рассмотрим задачу подсчёта количества элементов в списке:

length                  :: [a] -> Integer
length []               =  0
length (x:xs)           =  1 + length xs

Данный код выдает ошибку:
Ambiguous variable occurrence "length"
*** Could refer to: Main.length Hugs.Prelude.length

дело в том, что в Prelude есть функция length, которая возвращает количество элементов, поэтому название для функции нужно изменить, например:

myLength                  :: [a] -> Integer
myLength []               =  0
myLength (x:xs)           =  1 + myLength xs

[q]

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

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

U>дело в том, что в Prelude есть функция length, которая возвращает количество элементов, поэтому название для функции нужно изменить, например:

Ну или явно импортировать Prelude и захайдить length:

import Prelude hiding (length)

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

RK>Ну или явно импортировать Prelude и захайдить length:

Маленькая поправка. Не явно, а квалифицировано (qualified).

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

U>Данный код выдает ошибку:
U>Ambiguous variable occurrence "length"
U>*** Could refer to: Main.length Hugs.Prelude.length

U>дело в том, что в Prelude есть функция length, которая возвращает количество элементов, поэтому название для функции нужно изменить, например:

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

Вообще-то сообщение более чем внятное.
Компилятор, что не показал на место где была ошибка?

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

L>Здравствуйте, R.K., Вы писали:

RK>>Ну или явно импортировать Prelude и захайдить length:

L>Маленькая поправка. Не явно, а квалифицировано (qualified).

Выдержка из того же "мягкого введения":

Programs implicitly import the Prelude module. An explicit import of the Prelude overrides the implicit import of all Prelude names. Thus,

import Prelude hiding length

will not import length from the Standard Prelude, allowing the name length to be defined differently.

А вот квалифицировано это будет примерно так:

import qualified Prelude as P

length                  :: [a] -> P.Int
length []               =  0
length (x:xs)           =  (P.+) 1 (length xs)

main = P.print (length [1,2,3])

Тоже можно, но в данном случае я предпочту явный импорт

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

VD>Вообще-то сообщение более чем внятное.
VD>Компилятор, что не показал на место где была ошибка?

Внятное сообщение об ошибке еще не является оправданием того, что бы простейшие примеры конфликтовали со стандартным пространством имен. Как бы вам понравилось если бы в аналогичном простейшем С++-примере расчитанному на дилетантов именовали бы функцию как printf или SendMessage

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

U>Внятное сообщение об ошибке еще не является оправданием того, что бы простейшие примеры конфликтовали со стандартным пространством имен. Как бы вам понравилось если бы в аналогичном простейшем С++-примере расчитанному на дилетантов именовали бы функцию как printf или SendMessage

Просто в обучении Хаскеллу сложилась такая практика — разбирать в качестве примеров реализацию функций из стандартной библиотеки. Во многих руководствах соответствующее предупреждение (о необходимости переименования) присутствует. В GIH в этом отношении, действительно, есть некоторая недоработка.

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

RK>>>Ну или явно импортировать Prelude и захайдить length:

L>>Маленькая поправка. Не явно, а квалифицировано (qualified).

RK>Выдержка из того же "мягкого введения":

А черт, я прочёл это как два варианта решения "явно импортировать" ИЛИ "захайдить length" :-)
Ночью писал.

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

D>Просто в обучении Хаскеллу сложилась такая практика — разбирать в качестве примеров реализацию функций из стандартной библиотеки. Во многих руководствах соответствующее предупреждение (о необходимости переименования) присутствует. В GIH в этом отношении, действительно, есть некоторая недоработка.

Дык сложилась, не сложилась... неужели трудно дать рабочий пример? С тем же экспортом и явным исключением.

В С-шных книгах тоже часто разбирают язык на базе фукцний из стандартных библиотек, но что-то я не видел каких-то конфликтов.

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

VD>Дык сложилась, не сложилась... неужели трудно дать рабочий пример? С тем же экспортом и явным исключением.

Я, вообще-то, лишь переводчик, а не соавтор.

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

D>Я, вообще-то, лишь переводчик, а не соавтор.

Дык это вообще-то не к тебе претензия. Просто так потянуло повозмущаться. Тем более что у нас тут много народу лазиет. Глядишь странслируют автору.

Например, основной тип функции head – это [a]->a; типы [b]->a, b->a (в исходном тексте опечатка, a->a – прим.пер.) или даже a являются верными, но избыточно общими, в то время как типы вроде [Integer]->Integer являются слишком частными

В примечании неточность — в исходном тексте правильно. Поясню.
Тип [a]->a в переводе на русский: для списка элементов a вернуть результат типа a.
Тип [b]->a : для списка каких-то элементов вернуть результат какого-то типа.
Тип b->a : для какого-то типа (может быть и список, а может и не быть) вернуть результат какого-то типа.
Т.е. [a]->a является частным случаем [b]->a, который в свою очередь является частным случаем b->a.

PS спасибо за статью. это мой первый источник информации по haskell

Не сообразил сразу что именно в исходном тексте написано неправильно (a->a), а в вашем варианте правильно ([b]->a). Подумал что вы в примечании указали правильный вариант.

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

S>

S>Например, основной тип функции head – это [a]->a; типы [b]->a, b->a (в исходном тексте опечатка, a->a – прим.пер.) или даже a являются верными, но избыточно общими, в то время как типы вроде [Integer]->Integer являются слишком частными

S>В примечании неточность — в исходном тексте правильно. Поясню.
S>Тип [a]->a в переводе на русский: для списка элементов a вернуть результат типа a.
S>Тип [b]->a : для списка каких-то элементов вернуть результат какого-то типа.
S>Тип b->a : для какого-то типа (может быть и список, а может и не быть) вернуть результат какого-то типа.
S>Т.е. [a]->a является частным случаем [b]->a, который в свою очередь является частным случаем b->a.

Не очень понял. Ваши рассуждения правильны, но в исходном тексте, насколько я помню, было a->a, что не верно, то есть не является ни избыточным обобщением, ни частным случаем principle type.

Здравствуйте, Денис Москвин (перевод), Вы писали:

ДМП>Статья:
ДМП>Мягкое введение в Haskell

Автор(ы): Пол Хьюдак, Джон Петерсон, Джозеф Фасел
Дата: 03.03.2007
Задача данного материала – обеспечить «мягкое» введение в программирование на Haskell для имеющих опыт программирования, по крайней мере, на одном языке, желательно функциональном (даже если это «почти функциональный» язык, такой как ML или Scheme).

ДМП>Авторы:
ДМП> Денис Москвин (перевод)

ДМП>Аннотация:
ДМП>Задача данного материала — обеспечить ''мягкое'' введение в программирование на Haskell для имеющих опыт программирования, по крайней мере, на одном языке, желательно функциональном (даже если это ''почти функциональный'' язык, такой как ML или Scheme).
Я тоже сделал перевод этой статьи Gentle Introduction to Haskell russian translation — и даже чуть раньше (11 сентября 2006 года). Как видите, язык у нас совсем разный, и форматирование тоже (у меня PDF приближенный к исходному). Надеюсь что и мой перевод будет прочтён вами.

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

T>Я тоже сделал перевод этой статьи Gentle Introduction to Haskell russian translation — и даже чуть раньше (11 сентября 2006 года). Как видите, язык у нас совсем разный, и форматирование тоже (у меня PDF приближенный к исходному). Надеюсь что и мой перевод будет прочтён вами.

Пусть расцветает сто цветов.
(c) Председатель Мао, Обращение к китайской интеллигенции, 1957

tonykent wrote:

> даже чуть раньше (11 сентября 2006 года). Как видите, язык у нас совсем
> разный, и форматирование тоже (у меня PDF приближенный к исходному).
> Надеюсь что и мой перевод будет прочтён вами.

А что ж у тебя в PDF-е-то буквы прыгают в стоках, как будто их
кипятком внизу полили ?