АГ
о, я хочу это видеть
Ок, завтра поищу
Size: a a a
2020 September 24
2020 September 25
L
Yuuri: ошибка преобразования в число: String: if
K
Разные культуры, это "define только на верхнем уровне, а ниже let" VS "define на всех уровнях"
Мне нравится идея
let ... in ... на всех уровнях. При этом списки экспорта имею вполне натуральное происхождение.AT
"Братья-славяне" ищут Remote Scala Developer: https://codefactorygroup.com/careers_archive/scala-developer-1603/
AT
Мне нравится идея
let ... in ... на всех уровнях. При этом списки экспорта имею вполне натуральное происхождение.И ещё разделение на
let и let rec для ясности! 😉A
На крайний случай добавить
let non-recВот это бы хотелось.
AP
Мне нравится идея
let ... in ... на всех уровнях. При этом списки экспорта имею вполне натуральное происхождение.Я писал про лиспы в этом конкретном сообщении.
AP
Но всё равно сработало — "понабежали"
2020 September 28
MP
Как по мне, так все
let должны быть let rec.Пару раз делал ошибки вроде такой, пишу let n1 = n+1 in ..., а потом в теле путаю n1 и n. Потом придумал писать case n+1 of n -> ..., но красивее было бы, если бы был let, который не rec.
AI
@dshevchenko , смотрел все время твои фотки природы и завидовал - красота, воздух, не то что в городе...
AT
Такое ощущение, что для определений функций полезнее по умолчанию rec, для просто значений – nonrec для shadowing.
По моему опыту, 80-90% функций — НЕ рекурсивные. 🤷♀️
AT
Как бы крайне редко приходится писать явную рекурсию руками...
AV
let ?n1 = n+1
YS
ну началось
AV
что?!
YS
не так