Size: a a a

2021 February 15

JS

Jerzy Syrowiecki in Haskell Start
Sergey Sosnin
в python типизация динамическая и неявная, в хаскеле — статическая явная. На стадии компиляции нужно знать какой тип будет у результата. Неважно, что вы используете read или parsec — все равно придется написать функции конвертации в нужный тип.
input() возвращает строку, равно как и getLine, именно этот момент связан не с типизацией, а с чистотой
источник

SS

Sergey Sosnin in Haskell Start
Jerzy Syrowiecki
input() возвращает строку, равно как и getLine, именно этот момент связан не с типизацией, а с чистотой
ну идея в том, что в python вы не обязаны заранее выписать к чему в итоге вашу строку нужно привести, ибо динамическая типизация. Скорее всего вопрос "пишешь input и все" подразумевал то, что строку можно считать не указывая тип заранее . Так то, я думаю в любом ЯП input который данные из stdin ест, ест их в виде строк
источник

SS

Sergey Sosnin in Haskell Start
у меня тут вопрос: есть у меня список сущностей, в количестве over 100 (допустим, элементы таблицы менделеева).
Я могу:
хранить их в виде конструкторов: data Element = H | He | ...
хранить их в виде строк — ну тут понятно
хранить их в виде байт Word8 —  что удобно с точки зрения производительности
Вопрос, насколько разумна идея N1 создать кучу конструкторов данных?
источник

SS

Sergey Sosnin in Haskell Start
В варианте 1 хорошо будет работать pattern matching, это несомненный плюс
источник

AP

Aleksei (astynax) Pi... in Haskell Start
между input(), всегда возвращающей строку, и getLine, всегда возвращающей строку, с точки зрения типизации результата нет никакой разницы
источник

AP

Aleksei (astynax) Pi... in Haskell Start
Обе функции возвращают строку. Вне зависимости от "явности" типизации
источник

AP

Aleksei (astynax) Pi... in Haskell Start
read приводит строку к числу (в обсуждаемом примере), int() приводит строку к числу. И в Haskell, и в Python это делается явно
источник

JS

Jerzy Syrowiecki in Haskell Start
Sergey Sosnin
у меня тут вопрос: есть у меня список сущностей, в количестве over 100 (допустим, элементы таблицы менделеева).
Я могу:
хранить их в виде конструкторов: data Element = H | He | ...
хранить их в виде строк — ну тут понятно
хранить их в виде байт Word8 —  что удобно с точки зрения производительности
Вопрос, насколько разумна идея N1 создать кучу конструкторов данных?
если числами они хорошо идентифицируются, то будет проще/удобнее newtype над Word
источник

JS

Jerzy Syrowiecki in Haskell Start
Sergey Sosnin
ну идея в том, что в python вы не обязаны заранее выписать к чему в итоге вашу строку нужно привести, ибо динамическая типизация. Скорее всего вопрос "пишешь input и все" подразумевал то, что строку можно считать не указывая тип заранее . Так то, я думаю в любом ЯП input который данные из stdin ест, ест их в виде строк
мне показалось, вопрос был о применении read к getLine, а это вопрос о чистоте и эффектах
источник

SS

Sergey Sosnin in Haskell Start
Jerzy Syrowiecki
мне показалось, вопрос был о применении read к getLine, а это вопрос о чистоте и эффектах
возможно, автору вопроса нужно уточнить что он имеет в виду.
источник

JS

Jerzy Syrowiecki in Haskell Start
Sergey Sosnin
у меня тут вопрос: есть у меня список сущностей, в количестве over 100 (допустим, элементы таблицы менделеева).
Я могу:
хранить их в виде конструкторов: data Element = H | He | ...
хранить их в виде строк — ну тут понятно
хранить их в виде байт Word8 —  что удобно с точки зрения производительности
Вопрос, насколько разумна идея N1 создать кучу конструкторов данных?
точнее, если важнее удобство написания разных вычислений, особенно над номерами, лучше newtype над Word

а если важнее корректность, то перечислить конструкторы
источник

T

The Lord of Hypercom... in Haskell Start
Sergey Sosnin
ну идея в том, что в python вы не обязаны заранее выписать к чему в итоге вашу строку нужно привести, ибо динамическая типизация. Скорее всего вопрос "пишешь input и все" подразумевал то, что строку можно считать не указывая тип заранее . Так то, я думаю в любом ЯП input который данные из stdin ест, ест их в виде строк
Имелось в виду, что если данные упоминаются один раз, для них можно не создавать отдельную переменную
Типа
Вместо чего-то вроде
s=input()
n=int(s)
a=n+10
print(a)

Можно написать что-то вроде
print(int(input())+3)
источник

T

The Lord of Hypercom... in Haskell Start
Sergey Sosnin
возможно, автору вопроса нужно уточнить что он имеет в виду.
Я имел в виду примерно следующее:
Для работоспособности моего кода на хаскелле мне необходимо создать промежуточную переменную s<-getLine, ибо иные варианты я, как новичок, не осознаю. В аналогичной программе на пайтоне это не является необходимостью, можно написать int(input())  вместо s=input(); …int(s)…
источник

JS

Jerzy Syrowiecki in Haskell Start
The Lord of Hypercomplex Numbers
Имелось в виду, что если данные упоминаются один раз, для них можно не создавать отдельную переменную
Типа
Вместо чего-то вроде
s=input()
n=int(s)
a=n+10
print(a)

Можно написать что-то вроде
print(int(input())+3)
в Хаскеле это тоже можно упаковать в одно выражение-цепочку (исчисление комбинаторов это доказывает), но из-за учёта эффектов будут не одинаковые скобки для каждого вызова, а разные операторы
источник

T

The Lord of Hypercom... in Haskell Start
The Lord of Hypercomplex Numbers
Я имел в виду примерно следующее:
Для работоспособности моего кода на хаскелле мне необходимо создать промежуточную переменную s<-getLine, ибо иные варианты я, как новичок, не осознаю. В аналогичной программе на пайтоне это не является необходимостью, можно написать int(input())  вместо s=input(); …int(s)…
.
источник

T

The Lord of Hypercom... in Haskell Start
Jerzy Syrowiecki
в Хаскеле это тоже можно упаковать в одно выражение-цепочку (исчисление комбинаторов это доказывает), но из-за учёта эффектов будут не одинаковые скобки для каждого вызова, а разные операторы
Можно, но какой сложности будет результат?
источник

JS

Jerzy Syrowiecki in Haskell Start
The Lord of Hypercomplex Numbers
Можно, но какой сложности будет результат?
print =<< (+ 3) . read @Int <$> getLine

сложность тут субъективная
источник

JS

Jerzy Syrowiecki in Haskell Start
во многих случаях лучше создавать промежуточные переменные
источник

A

Arjaz in Haskell Start
The Lord of Hypercomplex Numbers
Имелось в виду, что если данные упоминаются один раз, для них можно не создавать отдельную переменную
Типа
Вместо чего-то вроде
s=input()
n=int(s)
a=n+10
print(a)

Можно написать что-то вроде
print(int(input())+3)
Там не будет создаваться новая переменная, никакого оверхеда (в отличии от питона) не будет
источник

JS

Jerzy Syrowiecki in Haskell Start
промежуточные переменные обычно улучшают читаемость (и очень радко ухудшают)
источник