EG
На PHP обычно пофиг
s/На PHP о/О/
Size: a a a
2021 February 20
S
На PHP обычно пофиг
Обычно пофиг
EG
Обычно пофиг
s/.* ./П
S
Обычно пофиг
Пофиг
А⚙
s/.* ./П
Фига ты
EG
Пофиг
s/$/.
S
Пофиг
Пофиг.
EG
Пофиг.
Идеально.
ΑZ
А почему не читать тело кода? Из него, между прочим, вполне можно интерфейс параметров вывести
var foo = {a: 100, b: 200.0};
function bar(param) {
someLibraryBazzz(param);
log(param.a);
}
bar(foo)
Вопрос: какая сигнатура от param ожидается в этом случае? И как ты это узнаешь?Второй вопрос: если сигнатура не совпадает, то кто виноват: кривая функция которая неправильно требует или вызывающий код, который не доложил нужных данных?
IL
var foo = {a: 100, b: 200.0};
function bar(param) {
someLibraryBazzz(param);
log(param.a);
}
bar(foo)
Вопрос: какая сигнатура от param ожидается в этом случае? И как ты это узнаешь?Второй вопрос: если сигнатура не совпадает, то кто виноват: кривая функция которая неправильно требует или вызывающий код, который не доложил нужных данных?
1) Зависит от имлпементации someLibraryBazzz, и от того, как будет использоваться bar
2) Если ошибку можно вывести в имплементации вызываемой функции, то думаю, что лучше её показать в имплементации
2) Если ошибку можно вывести в имплементации вызываемой функции, то думаю, что лучше её показать в имплементации
IL
Компилятор должен быть в состоянии ответить, может ли программа остановиться. И тот факт, что данная проблема принципиально неразрешима, не оправдывает шероховастостей эвристики мейнстримовых моделей типизации. Это не делает их модель единственно верной, и не оправдывает неэргономичности.
ΑZ
1) Зависит от имлпементации someLibraryBazzz, и от того, как будет использоваться bar
2) Если ошибку можно вывести в имплементации вызываемой функции, то думаю, что лучше её показать в имплементации
2) Если ошибку можно вывести в имплементации вызываемой функции, то думаю, что лучше её показать в имплементации
То есть если someLibraryBazzz вызывает someLibraryBazzz1, someLibraryBazzz2, someLibraryBazzz3 и someLibraryBazzz4 ты предлагаешь мне их все рекурсивно обсматривать и запоминать кто где что использует?
ΑZ
Компилятор должен быть в состоянии ответить, может ли программа остановиться. И тот факт, что данная проблема принципиально неразрешима, не оправдывает шероховастостей эвристики мейнстримовых моделей типизации. Это не делает их модель единственно верной, и не оправдывает неэргономичности.
компилятор может это сделать, в хачкеле он это и делает. Но это считается дурным тоном
IL
компилятор может это сделать, в хачкеле он это и делает. Но это считается дурным тоном
Ничего себе какой в Хаскеле компилятор интересный! Это же прямо прорыв в науке. :) Кто-то написал компилятор, способный решить проблему останова.
ΑZ
Ничего себе какой в Хаскеле компилятор интересный! Это же прямо прорыв в науке. :) Кто-то написал компилятор, способный решить проблему останова.
проблема останова только если у тебя завтипы. Обычная лямбда2-ерунда доказывается элементарно
IL
То есть если someLibraryBazzz вызывает someLibraryBazzz1, someLibraryBazzz2, someLibraryBazzz3 и someLibraryBazzz4 ты предлагаешь мне их все рекурсивно обсматривать и запоминать кто где что использует?
Это должен делать компилятор, а не вы. И выдавать вам вменяемое описание ошибки.
ΑZ
Это должен делать компилятор, а не вы. И выдавать вам вменяемое описание ошибки.
ну он обычно и выдает. Только описание ошибки в реальной программе будет на килобайты
ΑZ
не очень-то удобно
IL
проблема останова только если у тебя завтипы. Обычная лямбда2-ерунда доказывается элементарно
Поэтому она не тьюринг-полна, и следовательно не может определить корректность логики базовой программы. Так же как и система зав. типов
ΑZ
и мы говорили про ЖС, там никакого компилятора нет чтобы что-то там выводить