Дефекты #55/#56 Нехорошее сообщение об ошибке (no well error
От: FDSC Россия consp11.github.io блог
Дата: 22.08.11 23:55
Оценка:
Предлагаю обсудить здесь, т.к. в багтрекере поведение разработчиков Nemerle абсолютно неадекватное: дефекты закрывает только тот, кто их открывает, по крайней мере, пока явно очевидно, что пользователь может быть несогласен, а у меня уже два закрытых дефекта при том, что в обоих случаях никто с моим мнением считаться даже не желает. Да уж, тут подумаешь насчёт "фобий".

Копия дефектов (мои комментарии напишу в ответ на это сообщение):

Нехорошее сообщение об ошибке (no well error)
Code:
public compareFiles(f1: string, f2: string):  int * int * int
{
  (0, 0, 0)
}

private RetryCompareButton_Click (sender : object,  e : System.EventArgs) : void
{
  if (!String.IsNullOrEmpty(fileNameBox1.Text) && !String.IsNullOrEmpty(fileNameBox2.Text))
    compareFiles(fileNameBox1.Text, fileNameBox2.Text);
  else
    _ = MessageBox.Show("Извините, в текстовых полях отсутствуют имена файлов для сравнения:\r\n нажмите кнопку \"Сравнить\" или введите их вручную"): void;
}


Must be error in compareFiles, but error in MessageBox

error : expected (int * int * int)-, got void in computation branch: (int * int * int) is not a subtype of void [simple require]
fdsc and someone-with-default-username are participating in this issue.

someone-with-default-username commented

about 4 hours ago

This is not an error. You should understand that "if" is not statement — this is expression, so until types in expressions is unified compiler does not start checking for unused function return results. Here compiler implies that int*int*int is the type of "if" expression. Remember that types in match ("if" is translated into match) branches should be unifyable. Triplet of ints is not unifyable with void (assign to wildcard is always void) — so you see this error.

see closed #55 (I does not reopen)

"if" expression can not be int*int*int type in sample function, but compiler error message requires this.
Compiler error message must be easy to understand and must have well location. if compiler can not inference of type "if" expression, it must say about this with correct form.

therefore, #55 is a bug.
fdsc, VladD2, and rampelstinskin are participating in this issue.

VladD2 commented

about 2 hours ago

Что не понятного в "expected (int * int * int)-, got void in computation branch" и куда должно указывать это сообщение, если не на само выражение if?
Closed

VladD2 closed the issue about 2 hours ago

rampelstinskin commented

about 2 hours ago

Ты просто привык.
Он говорит ровно то же что говорил я во время флейма про типизацию Н2.
Типизация раскрытых макросов порождает, и будет порождать страшные сообщения об ошибках.

VladD2 commented

about an hour ago

Вообще-то — это не форум. Хочешь вернуться к обсуждению, давай, но на форуме.

Здесь вопрос о том, что человек хочет увидеть. Может мой взгляд и правда замылен и я привык к чему-то не тому, но по-моему очевидно, что компилятор вычислил одну из веток как int * int * int, а другую как void, и говорит об этом.

Возможно, я уже думаю как компилятор и для меня это очевидно. Вот и хочу услышать от тех кто с незамещенным взглядом, что он хочет "услышать" от компилятора.

Похоже что человеку совершенно все равно будут ли в сообщении слова про if. Он, скорее всего, хочет услышать, что-то другое. Его реальная ошибка — это забытое возвращаемое значение функции. Вот только компилятор то не телепат. У него есть алгоритм и он ему следует. Раз не может быть у if-а разных типов в разных ветках, то не может. ИИ еще не изобрели и алгоритм не может понять, что человек сделал другую ошибку которая привела к этой. Причем ошибка сделанная по привычке выработанной другим языком (шарпом).

ЗЫ

На, раз уж ты превратил ветку в форум, то можно тебя спросить? Как дела с твоим прототипом?
Re: Дефекты #55/#56 Нехорошее сообщение об ошибке (no well e
От: FDSC Россия consp11.github.io блог
Дата: 23.08.11 00:13
Оценка:
VD>Что не понятного в "expected (int * int * int)-, got void in computation branch" и куда должно указывать это сообщение, если не на само выражение if?
VD>Closed

Разве я говорил где-то, что мне что-то непонятно. Я сказал, что сообщение низкого качества, а должно быть лёгким для понимания — высокого качества. Ошибка состоит в том, что возвращаемое значение if не void, а мне компилятор говорит, что ожидается (int * int * int). Если это невозможно или трудно исправить, это не значит, что это не дефект.


VD>Здесь вопрос о том, что человек хочет увидеть. Может мой взгляд и правда замылен и я привык к чему-то не тому, но по-моему очевидно, что компилятор вычислил одну из веток как int * int * int, а другую как void, и говорит об этом.


Компилятор мне говорит, что он ожидает int * int * int там, где он не должен ожидать его, кроме этого, он говорит мне о том, что у меня ошибка совсем не на той строке, где есть, о чём я написал в дефекте #56.

VD>Возможно, я уже думаю как компилятор и для меня это очевидно. Вот и хочу услышать от тех кто с незамещенным взглядом, что он хочет "услышать" от компилятора.


Что я хочу, я написал в дефекте #56: человеческое сообщение об ошибке, которое учитывает:

FDS>"if" expression can not be int*int*int type in sample function, but compiler error message requires this.

1. Что if типа void, т.к. у него есть вся информация для этого

FDS>Compiler error message must be easy to understand and must have well location. if compiler can not inference of type "if" expression, it must say about this with correct form.

2. Или что совершенно не обязательно, что if написан программистом ошибочно именно во второй ветке: тогда нужно давать ссылку на весь if и говорить, что его параметры по типам не совпадают: один одного типа, второй — другого, а не что expected ...

VD>Похоже что человеку совершенно все равно будут ли в сообщении слова про if.

По-моему, я довольно ясно написал про "if"-expression в описании бага и про то, что слова должны быть именно про него.

VD> Он, скорее всего, хочет услышать, что-то другое. Его реальная ошибка — это забытое возвращаемое значение функции.

В идеале, я хочу услышать, что ожидается void, но получен int * int * int с сообщением на строке с ошибкой, т.е. пункт первый. В реале, хотя бы пункт второй (см. выше).

VD> Вот только компилятор то не телепат. У него есть алгоритм и он ему следует. Раз не может быть у if-а разных типов в разных ветках, то не может. ИИ еще не изобрели и алгоритм не может понять, что человек сделал другую ошибку которая привела к этой.

1. Он может понять, что у if тип — void
2. Он может писать нормальную ошибку про несовпадающие типы, а не говорить, что он ждёт конкретный тип: это заставляет вчитываться в сообщение об ошибке, обычно со сложным типом и утверждением, что object не есть наследник File, вместо того, чтобы просто и ясно понять, что компилятор ожидает, что выражение выбора будет одного типа в разных ветках.

VD> Причем ошибка сделанная по привычке выработанной другим языком (шарпом).


ok, мне платят за код на шарпе. Будешь платить за код на Nemerle, я избавлюсь от этих привычек. На самом деле, просто код был перенесён из другой функции в эту и ещё не дописан как надо.
Re[2]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.08.11 02:37
Оценка: 1 (1) +2
Здравствуйте, FDSC, Вы писали:

FDS>Разве я говорил где-то, что мне что-то непонятно. Я сказал, что сообщение низкого качества, а должно быть лёгким для понимания — высокого качества. Ошибка состоит в том, что возвращаемое значение if не void, а мне компилятор говорит, что ожидается (int * int * int). Если это невозможно или трудно исправить, это не значит, что это не дефект.


Дело в том, что вы с компилятором исходите из разных предпосылок.

Твоя логика такая: Я писал if который ничего не возвращает, но забыл, что функция compareFiles возвращает значение.

Логика же компилятора такая: орел писал выражение if в котором первая ветка имеет тип А, а вторая Б. Типы не соответствуют, так что я не могу дальше производить компиляцию.

FDS>Компилятор мне говорит, что он ожидает int * int * int там, где он не должен ожидать его, кроме этого, он говорит мне о том, что у меня ошибка совсем не на той строке, где есть, о чём я написал в дефекте #56.


Дык он просто не знает где у тебя ошибка! Он же автомат, тупая машина!
Это ты знаешь, что ошибочно возвратил из if-а значение. А компилятор знает только, что выражение в первой ветке имеет тип отличный от второй. И угадать что ты ошибся именно вверху, а не внизу он не в силах.

VD>>Возможно, я уже думаю как компилятор и для меня это очевидно. Вот и хочу услышать от тех кто с незамещенным взглядом, что он хочет "услышать" от компилятора.


FDS>Что я хочу, я написал в дефекте #56: человеческое сообщение об ошибке, которое учитывает:


Ты только забыл написать как оно должно выглядеть.

FDS>>"if" expression can not be int*int*int type in sample function, but compiler error message requires this.

FDS>1. Что if типа void, т.к. у него есть вся информация для этого

Нет никакого if типа void. Есть правило по кототорому типы выражений вычисляются с лева на права, сверху вниз. Компилятор встречая в первой ветке тип кортеж из трех int считает, что другая ветка так же должна унифиировться с этим типом. Но второй тип void. О чем он и говорит.

Возможно тут можно ввести некую эвристику для конкретного случая (в общем случае тут все правильно) или просто изменить текст сообщения.


FDS>>Compiler error message must be easy to understand and must have well location. if compiler can not inference of type "if" expression, it must say about this with correct form.

FDS>2. Или что совершенно не обязательно, что if написан программистом ошибочно именно во второй ветке: тогда нужно давать ссылку на весь if и говорить, что его параметры по типам не совпадают: один одного типа, второй — другого, а не что expected ...

Вот это можно сделать. Тем более, что фактически это сообщение не if-а, а match-а в который if раскрывается (о чем и говорил Вольфхаунд в той ветке). А в match вхождений может быть более одного.

Еще, как вариант, можно выдавать хинт ко второй ветке.

VD>>Похоже что человеку совершенно все равно будут ли в сообщении слова про if.

FDS>По-моему, я довольно ясно написал про "if"-expression в описании бага и про то, что слова должны быть именно про
него.

Ну, так написал бы сообщение так как ты хотел бы его видеть.

Проблема в том, что сообщение это не от if-а. Такое поведение будет в любом месте где несколько выражений должны унифицироваться (соотвествовать одному типу/иерархии типов).

VD>> Он, скорее всего, хочет услышать, что-то другое. Его реальная ошибка — это забытое возвращаемое значение функции.

FDS>В идеале, я хочу услышать, что ожидается void, но получен int * int * int с сообщением на строке с ошибкой, т.е. пункт первый. В реале, хотя бы пункт второй (см. выше).

Ошибись во второй ветке и услышишь именно это .

Пойми, компилятор не может думать.

Единственное что приходит на ум, это попробовать использовать ограничение внешнего выражения, и если оно задано в тип соответствующий одной из подветок, то разворачивать сообщение об ошибке в обратную стороу (типа — ожидалось void, а нашли черт знает что). Но не уверен, что это во всех случаях сработает. Точнее уверен в обратном.

FDS>1. Он может понять, что у if тип — void


Нет.

FDS>2. Он может писать нормальную ошибку про несовпадающие типы, а не говорить, что он ждёт конкретный тип: это заставляет вчитываться в сообщение об ошибке, обычно со сложным типом и утверждением, что object не есть наследник File, вместо того, чтобы просто и ясно понять, что компилятор ожидает, что выражение выбора будет одного типа в разных ветках.


Елы палы. Ну, напиши по русски как ты хотел бы слышать это сообщение. Если получится хорошо, то заменим. Ты же говоришь как не надо, но ничего конкретного не предлагаешь, кроме потребовать от компилятора телепатических способностей.

VD>> Причем ошибка сделанная по привычке выработанной другим языком (шарпом).


FDS>ok, мне платят за код на шарпе. Будешь платить за код на Nemerle, я избавлюсь от этих привычек. На самом деле, просто код был перенесён из другой функции в эту и ещё не дописан как надо.


Да причем тут платят? Я не пытался тебя унизить или оскорбить. Я говорю, что ошибка характерна для тех кто имеет привычку программирования на шарпе. В шарпе if — это стэйтмент. Он всегда void. Плюс шапр просто беззвучно пропускает потерю вычисляемых значений. Например, частые шарповские грабли:
"abc".Remove("b");

Шарп без звука пропустит этот код. Немерл выдаст сообщение, что значение потеряно, потому как в фунциональном языке это почти всегда ошибка. Но обратная сторона монеты, что там где ты терял значения по делу, теперь ты получаешь предупреждения.

Твой же случай — это чистая ошибка. В шарпе она проскочила бы в рантайм. Тут же тебе ее поймали.

В общем, из конструктивных предложений я пока услышал только — о распространении сообщения на весь if.

Что касается более внятного сообщения, то его нужно придумать. Если оно окажется более понятным, то заменим за пять минут.

Можно сделать так. Сообщение изменить так:

Detected incompatible types (int * int * int)- and void in computation branchs

и сообщение будет указывать на заголовок if-а, а не на его кишки. Или на обе ветки.

Так пойдет?

Если пойдет, можно попробовать это реализовать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: Аноним  
Дата: 23.08.11 03:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Дык он просто не знает где у тебя ошибка! Он же автомат, тупая машина!


RetryCompareButton_Click (sender : object, e : System.EventArgs) : void


Справедливости ради, метод-то объявлен как void, так что в этом случае можно однозначно сказать что ошибка в первой ветке.
Re[2]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: Аноним  
Дата: 23.08.11 07:59
Оценка: 1 (1) +1 -1
Здравствуйте, FDSC, Вы писали:


VD>>Что не понятного в "expected (int * int * int)-, got void in computation branch" и куда должно указывать это сообщение, если не на само выражение if?

VD>>Closed

FDS>Если это невозможно или трудно исправить, это не значит, что это не дефект.


Довольно странное утверждение. По этой логике, если я заведу Issue #58 "компилятор не готовит мне кофе", то этот баг нельзя будет закрыть, пока Nemerle таки не научится варить мне кофе. Ведь если это невозможно или трудно исправить, это не значит, что это не дефект.
Re: Дефекты #55/#56 Нехорошее сообщение об ошибке (no well e
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 23.08.11 08:23
Оценка:
На мой взгляд, текущее сообщение вполне адекватно, но в идеале хотелось бы что-то вроде: "Conditional expression branches have incompatible types: (int * int * int)- and void".
Ce n'est que pour vous dire ce que je vous dis.
Re[2]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: Аноним  
Дата: 23.08.11 08:46
Оценка: -4 :)
Здравствуйте, Don Reba, Вы писали:

DR>На мой взгляд, текущее сообщение вполне адекватно, но в идеале хотелось бы что-то вроде: "Conditional expression branches have incompatible types: (int * int * int)- and void".


Не, я реально офигеваю. И это немерлисты считают идеальным сообщением об ошибке???
Лично меня в такой ситуации устраивает только "void function can not return a value", как в общем-то во всех нормальных языках.
Re[3]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 23.08.11 09:13
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Не, я реально офигеваю. И это немерлисты считают идеальным сообщением об ошибке???

А>Лично меня в такой ситуации устраивает только "void function can not return a value", как в общем-то во всех нормальных языках.

При чём тут это? Как из "void function cannot return a value" FDSC должен заключить, что забыл явно проигнорировать значение compareFiles? От попыток сделать компилятор телепатом будет только хуже. Единственное, что в этой ситуации требуется, это генерировать сообщение из макроса 'if', а не 'match' в который он переписывается.
Ce n'est que pour vous dire ce que je vous dis.
Re[4]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: Аноним  
Дата: 23.08.11 09:23
Оценка:
Здравствуйте, Don Reba, Вы писали:

DR>При чём тут это? Как из "void function cannot return a value" FDSC должен заключить, что забыл явно проигнорировать значение compareFiles?


Вот честно, я не понимаю как это может быть не понятно
void f()
{
  if (true) {
    return 42;
  }
  else {
    printf("Hello, world");
  }
}


В подобном коде сишный компилятор указывает на строку return 42, и ругается чем-то наподобие void function cannot return a value.
Да, в Н returnы неявные, но это принципиально не мешает сделать аналогичную ошибку. И меня искренне удивляет, что разработчики даже отказываются признавать, что сообщение об ошибке сейчас мягко говоря не дотягивает по информативности до сишного.

Другое дело, что это может быть трудно реализуемо, но тут все понимают что проект "на энтузиазме" и никто бы и не обиделся если бы вы сказали, что проблема минорная или затраты на решение не пропорциональны создаваемым неудобствам.
Re[5]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: _nn_ www.nemerleweb.com
Дата: 23.08.11 09:34
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Don Reba, Вы писали:


DR>>При чём тут это? Как из "void function cannot return a value" FDSC должен заключить, что забыл явно проигнорировать значение compareFiles?


А>Вот честно, я не понимаю как это может быть не понятно

А>
А>void f()
А>{
А>  if (true) {
А>    return 42;
А>  }
А>  else {
А>    printf("Hello, world");
А>  }
А>}
А>


В Nemerle if и else обязанны возвращать один и тот же тип.
Соответственно ошибка должна быть совсем другой.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[5]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 23.08.11 09:37
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Вот честно, я не понимаю как это может быть не понятно

А>
А>void f()
А>{
А>  if (true) {
А>    return 42;
А>  }
А>  else {
А>    printf("Hello, world");
А>  }
А>}
А>


В этом примере ошибка действительно в том, что из void функции возвращается int. Проблема же FDSC в том, что он забыл явно проигнорировать значение compareFiles.
Ce n'est que pour vous dire ce que je vous dis.
Re[5]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 23.08.11 09:53
Оценка:
Вот что компилятор С++ сообщает для аналогичного кода на самом деле:

bool condition() { return true; }

int intF() { return 0; }

void voidF() { }

void f()
{
    return condition() ? intF() : voidF();
}

int main()
{
    f();
}

g++

In function 'void f()':
Line 9: error: 'voidF()' has type 'void' and is not a throw-expression
compilation terminated due to -Wfatal-errors.


Visual Studio вообще не находит ошибки.
Ce n'est que pour vous dire ce que je vous dis.
Re[6]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: Аноним  
Дата: 23.08.11 10:00
Оценка:
Здравствуйте, Don Reba, Вы писали:

А>>Вот честно, я не понимаю как это может быть не понятно

А>>
А>>void f()
А>>{
А>>  if (true) {
А>>    return 42;
А>>  }
А>>  else {
А>>    printf("Hello, world");
А>>  }
А>>}
А>>


DR>В этом примере ошибка действительно в том, что из void функции возвращается int.


эээ.. если я этот код перепишу в синтаксисе Н, какая будет генериться ошибка?
f() : void
{
  if (true) {
    42;
  }
  else {
    printf("Hello, world");
  }
}


В принципе, с одной стороны _nn_ пояснил уже:

В Nemerle if и else обязанны возвращать один и тот же тип.
Соответственно ошибка должна быть совсем другой.


Но возникает вопрос, кому должна? Людям или компилятору? Человек спросил нельзя ли сделать сообщение более людским:

Разве я говорил где-то, что мне что-то непонятно. Я сказал, что сообщение низкого качества, а должно быть лёгким для понимания — высокого качества. Ошибка состоит в том, что возвращаемое значение if не void, а мне компилятор говорит, что ожидается (int * int * int). Если это невозможно или трудно исправить, это не значит, что это не дефект.

Если для этого придётся полкомпилятора переписать, я думаю он бы не стал настаивать чтобы вы заимплементировали это до конца недели. А у Влада логика такая что люди созданы для того чтобы писать программы на Н, а не компилятор для них, сразу огрызаться начинает.
Re[6]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: Аноним  
Дата: 23.08.11 10:06
Оценка:
Здравствуйте, Don Reba, Вы писали:

DR>Вот что компилятор С++ сообщает для аналогичного кода на самом деле:


А с if-ами без тренарного оператора чем ругается?
И да, в этом случае сишное сообщение об ошибке — говно. И я не думаю, что есть на свете кто-нибудь, кто стал бы утверждать что оно идеальное.
Какие-то ветки очевидно вылизаны, какие-то менее используемые нет — в студии вообще печаль, но этот баг от этого багом быть не перестанет, о чем собственно и речь.
Re[7]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 23.08.11 10:27
Оценка: +3
Здравствуйте, Аноним, Вы писали:

DR>>Вот что компилятор С++ сообщает для аналогичного кода на самом деле:


А>А с if-ами без тренарного оператора чем ругается?


Код с if-ами не аналогичен. Как уже обьяснили, в Немерле if это выражение, также как и оператор ?: в С++. Код FDSC не пытается вернуть что либо из функции, просто потому что внутреннее выражение не имеет смысла.
Ce n'est que pour vous dire ce que je vous dis.
Re: Дефекты #55/#56 Нехорошее сообщение об ошибке (no well e
От: para  
Дата: 23.08.11 11:06
Оценка:
Здравствуйте, FDSC, Вы писали:

Товарищи, предлагаю именно для ифа сделать дополнительный хинт, чтобы пояснять новичкам из С# причину ошибки

правда для случаев со сложной типизацией это где-то может быть не особо просто сделать,

но на относительно простых вариантах типа этого, надо дать начинающим помощь
Re[3]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: BogdanMart Украина  
Дата: 23.08.11 11:38
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Нет никакого if типа void. Есть правило по кототорому типы выражений вычисляются с лева на права, сверху вниз. Компилятор встречая в первой ветке тип кортеж из трех int считает, что другая ветка так же должна унифиировться с этим типом. Но второй тип void. О чем он и говорит.


VD>Возможно тут можно ввести некую эвристику для конкретного случая (в общем случае тут все правильно) или просто изменить текст сообщения.


Может сделать чтобы все классы наследовались от Void, точнее чтобы Object наследовался от Void, тогда подобная проблема с ифом отпадет сама собой, так как сработает автоматический downcast к типу Void
Re[3]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: FDSC Россия consp11.github.io блог
Дата: 23.08.11 13:09
Оценка:
Здравствуйте, Аноним, Вы писали:

FDS>>Если это невозможно или трудно исправить, это не значит, что это не дефект.


А>Довольно странное утверждение. По этой логике, если я заведу Issue #58 "компилятор не готовит мне кофе", то этот баг нельзя будет закрыть, пока Nemerle таки не научится варить мне кофе. Ведь если это невозможно или трудно исправить, это не значит, что это не дефект.


Компилятор и не обязан готовить мне кофе, а выводить правильные сообщения об ошибках — обязан, если это промышленный компилятор.
Re[3]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: FDSC Россия consp11.github.io блог
Дата: 23.08.11 13:21
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FDS>>Разве я говорил где-то, что мне что-то непонятно. Я сказал, что сообщение низкого качества, а должно быть лёгким для понимания — высокого качества. Ошибка состоит в том, что возвращаемое значение if не void, а мне компилятор говорит, что ожидается (int * int * int). Если это невозможно или трудно исправить, это не значит, что это не дефект.


VD>Дело в том, что вы с компилятором исходите из разных предпосылок.


VD>Твоя логика такая: Я писал if который ничего не возвращает, но забыл, что функция compareFiles возвращает значение.


С чего это ты взял, что моя логика такая? Я писал if, который возвращает void, что явно указано в описании функции, но забыл, что функция compareFiles возвращает значение. И я был крайне удивлён, когда компилятор сказал мне, что if возвращает мне вовсе не void.

Сам подумай, если я пишу def a: string = if (условие) 1 else "2"
и мне компилятор на строке "2" говорит, что, мол, ожидается int, очевидно, меня это смущает, т.к. я явно указал, что a: string, и я ожидаю, что компилятор поймёт, что if как раз типа string.

VD>Логика же компилятора такая: орел писал выражение if в котором первая ветка имеет тип А, а вторая Б. Типы не соответствуют, так что я не могу дальше производить компиляцию.


Вот как раз если бы он думал так, я бы не был бы против. Но он сейчас думает так: "первая ветка имеет тип A, вторая — тип B, это неверно, во второй ветке тоже должен быть тип B". Понимаешь разницу?
В одном случае мне приходится читать сообщение типа "ожидается тип (int * int * int), но передан void, которые не является int"
В другом случае, который я ожидаю, я хочу прочитать более понятное сообщение вида:
"оператор if должен возвращать выражение одного типа из каждой ветви, однако первая ветвь возвращает (int * int * int), а вторая string"
а в идеале вида
"оператор if имеет тип string, однако ветвь оператора возвращает int, который не является подтипом string"

Первое сообщение я хочу видеть на строке с if, а второе на строке, которая содержит ошибку (но второе более сложно сделать).

FDS>>Компилятор мне говорит, что он ожидает int * int * int там, где он не должен ожидать его, кроме этого, он говорит мне о том, что у меня ошибка совсем не на той строке, где есть, о чём я написал в дефекте #56.


VD>Дык он просто не знает где у тебя ошибка! Он же автомат, тупая машина!


Ну да, вот я и хочу, чтобы если он не знает, он бы говорил только то, что знает. Путь тупица молчит о том, что не знает!

VD>Это ты знаешь, что ошибочно возвратил из if-а значение. А компилятор знает только, что выражение в первой ветке имеет тип отличный от второй. И угадать что ты ошибся именно вверху, а не внизу он не в силах.


Пусть так и напишет, а не угадывает, что я ошибся внизу. Сейчас он именно угадывает.
К тому же, у него достаточно информации, чтобы определить тип if

VD>Ты только забыл написать как оно должно выглядеть.


FDS>>>"if" expression can not be int*int*int type in sample function, but compiler error message requires this.

FDS>>1. Что if типа void, т.к. у него есть вся информация для этого

VD>Нет никакого if типа void. Есть правило по кототорому типы выражений вычисляются с лева на права, сверху вниз.


Это проблемы компилятора, а не программиста, который в итоге вверху объявляет функцию типа void, а в низу получает сообщение, что возвращаемое значение этой функции ожидается int*int*int

VD> Компилятор встречая в первой ветке тип кортеж из трех int считает, что другая ветка так же должна унифиировться с этим типом.


Неверно считает, это и есть дефект, о котором я говорю.

VD>Но второй тип void. О чем он и говорит.


Но if типа void, и компилятору достаточно исходного кода для того, чтобы это понять.

VD>Возможно тут можно ввести некую эвристику для конкретного случая (в общем случае тут все правильно) или просто изменить текст сообщения.


А я о чём пишу? Ты бы хоть дефект бы прочитал, там же даже название "Нехорошее сообщение об ошибке" и дальше в дефекте #56 я явно пишу о том, что сообщение должно быть легко для понимания.

Вот на этот код

def a: int = "2";

компилятор соверешнно верно отвечает
error : expected int, got string in type-enforced expression: System.String is not a subtype of System.Int32 [simple require]

и прекрасно понимает, что это не "от a ожидается тип string".

А вот на этот код, хотя это абсолютно то же, он отвечает

def a: int = if (true) "2" else 1;


error : expected string-, got int in computation branch: System.Int32 is not a subtype of System.String [simple require]

и далее каким-то абсолютно громоздким сообщением

error : expected int, got FixedType.Intersection(System.IConvertible, System.IComparable[int], System.IEquatable[string], System.IComparable)- in type-enforced expression: FixedType.Intersection(System.IConvertible, System.IComparable[int], System.IEquatable[string], System.IComparable) is not a subtype of int [simple require, intersection]

в котором нужно разбираться, чего вообще от меня хочет компилятор. Блин, я же не программист компилятора, чтобы знать, что такое FixedType.Intersection ! Неужели нельзя понятнее сделать хотя бы одно из сообщений об ошибке?


FDS>>>Compiler error message must be easy to understand and must have well location. if compiler can not inference of type "if" expression, it must say about this with correct form.

FDS>>2. Или что совершенно не обязательно, что if написан программистом ошибочно именно во второй ветке: тогда нужно давать ссылку на весь if и говорить, что его параметры по типам не совпадают: один одного типа, второй — другого, а не что expected ...

VD>Вот это можно сделать. Тем более, что фактически это сообщение не if-а, а match-а в который if раскрывается (о чем и говорил Вольфхаунд в той ветке). А в match вхождений может быть более одного.


Вот я и прошу сделать одно и двух, о чём писал в #56 и нафига его было закрывать, если непонятно, что я просил, я не понимаю.

VD>Еще, как вариант, можно выдавать хинт ко второй ветке.


Плохой вариант

VD>>>Похоже что человеку совершенно все равно будут ли в сообщении слова про if.

FDS>>По-моему, я довольно ясно написал про "if"-expression в описании бага и про то, что слова должны быть именно про
VD>него.

VD>Ну, так написал бы сообщение так как ты хотел бы его видеть.


С чего я знаю, как его правильно написать и где оно выводится. if — это ж макрос. Я написал описание дефекта, а не то, как его нужно исправлять.

VD>Ошибись во второй ветке и услышишь именно это .


Спасибо, но я ошибся в первой.

VD>Пойми, компилятор не может думать.


Вот я и хочу, чтоб он не думал и не догадывался, а говорил только то, в чём уверен: чётко и ясно, безо всяких там ссылок по поводу "почитайте мои исходники, может чего-нибудь поймёте".

VD>Единственное что приходит на ум, это попробовать использовать ограничение внешнего выражения, и если оно задано в тип соответствующий одной из подветок, то разворачивать сообщение об ошибке в обратную стороу (типа — ожидалось void, а нашли черт знает что). Но не уверен, что это во всех случаях сработает. Точнее уверен в обратном.


Значит надо хотя бы сообщение исправить, чтоб нормально писалось.

FDS>>1. Он может понять, что у if тип — void


VD>Нет.


Скажем так, программист на его месте используя только синтаксис, без семантики, это сделать может. Т.е. такая информация там есть и доступна компилятору.

FDS>>2. Он может писать нормальную ошибку про несовпадающие типы, а не говорить, что он ждёт конкретный тип: это заставляет вчитываться в сообщение об ошибке, обычно со сложным типом и утверждением, что object не есть наследник File, вместо того, чтобы просто и ясно понять, что компилятор ожидает, что выражение выбора будет одного типа в разных ветках.


VD>Елы палы. Ну, напиши по русски как ты хотел бы слышать это сообщение. Если получится хорошо, то заменим. Ты же говоришь как не надо, но ничего конкретного не предлагаешь, кроме потребовать от компилятора телепатических способностей.


Ну дык спроси, я предложу (см. выше). И укажи мне место, где я требовал от компилятора хоть намёк на телепатию: нигде такого не было.

VD>Да причем тут платят? Я не пытался тебя унизить или оскорбить.

Зато великолепно это сделал

VD>Я говорю, что ошибка характерна для тех кто имеет привычку программирования на шарпе. В шарпе if — это стэйтмент. Он всегда void.


Это как раз не было причиной ошибки.

VD> Плюс шапр просто беззвучно пропускает потерю вычисляемых значений.


Да, это было частью причины ошибки.

VD>Твой же случай — это чистая ошибка. В шарпе она проскочила бы в рантайм. Тут же тебе ее поймали.


Да нет, в шарпе это не было бы ошибкой вообще (я не хотел ничего получать из функции, и она была пустой).

VD>В общем, из конструктивных предложений я пока услышал только — о распространении сообщения на весь if.


Ещё ты услышал о том, что компилятор мог бы понять, что if — типа void. Телепатии здесь не требуется, достаточно лишь посмотреть на то, какое выражение требует функция и что if как раз возвращает это выражение.

VD>Можно сделать так. Сообщение изменить так:

VD>

VD>Detected incompatible types (int * int * int)- and void in computation branchs

VD>и сообщение будет указывать на заголовок if-а, а не на его кишки. Или на обе ветки.

Ну да, лучше если оно будет содержать весь регион выражения if.

VD>Так пойдет?


Я бы предложил сначала вынести само сообщение, чтобы программист его видел: иногда этого достаточно.
Т.е. примерно так:

Detected incompatible types in computation branchs: (int * int * int), void

Re[4]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: FDSC Россия consp11.github.io блог
Дата: 23.08.11 13:22
Оценка:
Здравствуйте, BogdanMart, Вы писали:

BM>Может сделать чтобы все классы наследовались от Void, точнее чтобы Object наследовался от Void, тогда подобная проблема с ифом отпадет сама собой, так как сработает автоматический downcast к типу Void


По-моему, это ужасно
Re[4]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: dsorokin Россия  
Дата: 23.08.11 13:25
Оценка: 1 (1) -3
Здравствуйте, FDSC, Вы писали:

FDS>Компилятор и не обязан готовить мне кофе, а выводить правильные сообщения об ошибках — обязан, если это промышленный компилятор.


По-моему вы просто придираетесь к мелочам. Правильное понимание того, что if есть выражение, возвращающее результат, приходит достаточно быстро.

Есть еще такой момент. Не надо во всем потакать новичкам. Цель не будет все равно достигнута, и ничего хорошего из этого не выйдет. Пусть сами поднимают свой уровень.
Re[2]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: FDSC Россия consp11.github.io блог
Дата: 23.08.11 13:26
Оценка:
Здравствуйте, para, Вы писали:

P>Товарищи, предлагаю именно для ифа сделать дополнительный хинт, чтобы пояснять новичкам из С# причину ошибки


По-моему, это не нужно: если сообщение будет читаемым, то и новички смогут понять.
Просто надоело каждый раз получать муру и вчитываться в неё, когда можно просто и легко прочитать, что ветки возвращают разные значения.
Re[5]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: FDSC Россия consp11.github.io блог
Дата: 23.08.11 13:31
Оценка:
Здравствуйте, dsorokin, Вы писали:

D>По-моему вы просто придираетесь к мелочам.


Эта мелочь очень утомляет.

D> Правильное понимание того, что if есть выражение, возвращающее результат, приходит достаточно быстро.


И? Как это мне поможет читать сообщения, что компилятор от меня хочет получить какой-то невообразимый тип там, где его и в помине нет и быть не должно?

D>Есть еще такой момент. Не надо во всем потакать новичкам. Цель не будет все равно достигнута, и ничего хорошего из этого не выйдет. Пусть сами поднимают свой уровень.


Извините, я на немерле программирую с 2007 года и мне надоело читать гадость вместо нормальных сообщений об ошибках. Если раньше компилятор был сырой, то теперь это уже не смешно, когда тратишь минуту на то, чтобы разобраться в той каше, что компилятор написал, вместо того, чтобы по первым двум словам сообщения уже понять, что нужно искать.

Так что сами поднимайте свой уровень, а я хочу работать с сообщениями об ошибках эффективно.
Re[4]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: Аноним  
Дата: 23.08.11 13:34
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Здравствуйте, Аноним, Вы писали:


FDS>>>Если это невозможно или трудно исправить, это не значит, что это не дефект.


А>>Довольно странное утверждение. По этой логике, если я заведу Issue #58 "компилятор не готовит мне кофе", то этот баг нельзя будет закрыть, пока Nemerle таки не научится варить мне кофе. Ведь если это невозможно или трудно исправить, это не значит, что это не дефект.


FDS>Компилятор и не обязан готовить мне кофе, а выводить правильные сообщения об ошибках — обязан, если это промышленный компилятор.


Любой функциональный язык даст похожее сообщение об ошибке. Вот например F#
> if true then 1 else "a";;

if true then 1 else "a";;
--------------------^^^

stdin(2,21): error FS0001: This expression was expected to have type
int
but here has type
string
>
Re[5]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: FDSC Россия consp11.github.io блог
Дата: 23.08.11 13:42
Оценка: :)
Здравствуйте, Аноним, Вы писали:

А>>>Довольно странное утверждение. По этой логике, если я заведу Issue #58 "компилятор не готовит мне кофе", то этот баг нельзя будет закрыть, пока Nemerle таки не научится варить мне кофе. Ведь если это невозможно или трудно исправить, это не значит, что это не дефект.


FDS>>Компилятор и не обязан готовить мне кофе, а выводить правильные сообщения об ошибках — обязан, если это промышленный компилятор.


А>Любой функциональный язык даст похожее сообщение об ошибке. Вот например F#


Значит этот дефект есть и в F#. Что поделаешь, и Microsoft не идеален

Если где-то вы нашли неверную работу, это не значит, что и Nemerle должен неверно работать. Если в C#, и в других ОО-языках, не было до появления Nemerle вывода типов, то это не значит, что в Nemerle его не должно быть.
Re[6]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: Аноним  
Дата: 23.08.11 14:02
Оценка: 4 (1)
Здравствуйте, FDSC, Вы писали:

FDS>Здравствуйте, Аноним, Вы писали:


А>>>>Довольно странное утверждение. По этой логике, если я заведу Issue #58 "компилятор не готовит мне кофе", то этот баг нельзя будет закрыть, пока Nemerle таки не научится варить мне кофе. Ведь если это невозможно или трудно исправить, это не значит, что это не дефект.


FDS>>>Компилятор и не обязан готовить мне кофе, а выводить правильные сообщения об ошибках — обязан, если это промышленный компилятор.


А>>Любой функциональный язык даст похожее сообщение об ошибке. Вот например F#


FDS>Значит этот дефект есть и в F#. Что поделаешь, и Microsoft не идеален


FDS>Если где-то вы нашли неверную работу, это не значит, что и Nemerle должен неверно работать. Если в C#, и в других ОО-языках, не было до появления Nemerle вывода типов, то это не значит, что в Nemerle его не должно быть.


А вообще Вы правы, в F# ошибка в случае, когда функция объявляется как unit (аналог void) дается на первую ветку ифа,
а в случае, когда тип функции не ставится — на вторую, значит можно сделать.
Только там вывод типов используется Хиндли-Милнера и у него куча других ограничений.
Хотя не знаю, может здесь вывод типов и не при чем.

Подробности:

> let f () = (1,2,3);;


val f : unit -> int * int * int

> let y b : unit = if b then f() else ();;


let y b : unit = if b then f() else ();;
---------------------------^^^

stdin(8,28): error FS0001: This expression was expected to have type
unit
but here has type
int * int * int

> let y b = if b then f() else ();;


let y b = if b then f() else ();;
-----------------------------^^

stdin(9,30): error FS0001: This expression was expected to have type
int * int * int
but here has type
unit
>
Re[4]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.08.11 14:05
Оценка:
Здравствуйте, BogdanMart, Вы писали:

VD>>Возможно тут можно ввести некую эвристику для конкретного случая (в общем случае тут все правильно) или просто изменить текст сообщения.


BM>Может сделать чтобы все классы наследовались от Void, точнее чтобы Object наследовался от Void, тогда подобная проблема с ифом отпадет сама собой, так как сработает автоматический downcast к типу Void


Это предложение я даже понять не могу. Не то что оценить. Для меня это звучит дико.

Куда могут деться проблемы я тоже не понимаю.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Вот и F# ситуацию распознал в отличие от Nemerle
От: FDSC Россия consp11.github.io блог
Дата: 23.08.11 14:12
Оценка:
см.
http://rsdn.ru/forum/nemerle/4390829.1.aspx
Автор:
Дата: 23.08.11
Re[4]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.08.11 15:39
Оценка:
Здравствуйте, FDSC, Вы писали:

VD>>Твоя логика такая: Я писал if который ничего не возвращает, но забыл, что функция compareFiles возвращает значение.


FDS>С чего это ты взял, что моя логика такая? Я писал if, который возвращает void, что явно указано в описании функции, но забыл, что функция compareFiles возвращает значение. И я был крайне удивлён, когда компилятор сказал мне, что if возвращает мне вовсе не void.


Что в лоб, что по лбу. Смысл от перестановки слов не меняется. Ты полностью повторил мои слова.

FDS>Сам подумай, если я пишу def a: string = if (условие) 1 else "2"

FDS>и мне компилятор на строке "2" говорит, что, мол, ожидается int, очевидно, меня это смущает, т.к. я явно указал, что a: string, и я ожидаю, что компилятор поймёт, что if как раз типа string.

Очевидно это исключительно для тебя. В прочем, я уже повторясь.

Проблема в том, что ты не осознаешь всей сложности алгоритмов вывода типа. Языки вроде C# вообще не учитывают возвращаемое значение при выводе типов. И на то есть свои причины.

Потом ты приводишь частный случай, а по жизни связь может быть отнюдь не явной. if может быть глубоко вложен в другие выражения, а типы могут быть попросту не известны до какого-то времени.

Как я уже неоднократно говорил ИИ пока что не изобретен. По этому приходится использовать алгоритмы. В немерле используется описанный мной алгоритм. Отсюда и результат. Изменить его, конечно, можно, но не факт, что получится лучше. Есть ведь и другие случаи. Например, возвращемый тип функции может совпадать с случайно появившимся значением:
def f() : string
{
  if (cond)
    WriteLine("..."); // void
  else
    ReadLine(); // возвращает строку

  "a"
}


По твоей логике, компилятор радостно отрапортует, что WriteLine() возвращает не тот тип. Хотя ошибка скорее в том, что не тот тип возвращает ReadLine().

FDS>Вот как раз если бы он думал так, я бы не был бы против.


То у него был бы ИИ.

FDS>Вот на этот код

FDS>
FDS>def a: int = "2";
FDS>

FDS>компилятор соверешнно верно отвечает
FDS>error : expected int, got string in type-enforced expression: System.String is not a subtype of System.Int32 [simple require]

VD>>Твой же случай — это чистая ошибка. В шарпе она проскочила бы в рантайм. Тут же тебе ее поймали.


FDS>Да нет, в шарпе это не было бы ошибкой вообще (я не хотел ничего получать из функции, и она была пустой).


Бала бы. Ты вызвал чистую функцию не порождающую побочных эффектов и потерял ее значение. Это чистой воды ошибка. Только сообщения об этом ты не получишь. А значит и не узнаешь о ней. Будет просто неверное поведение.

VD>>Можно сделать так. Сообщение изменить так:

VD>>

VD>>Detected incompatible types (int * int * int)- and void in computation branchs

VD>>и сообщение будет указывать на заголовок if-а, а не на его кишки. Или на обе ветки.

FDS>Ну да, лучше если оно будет содержать весь регион выражения if.


VD>>Так пойдет?


FDS>Я бы предложил сначала вынести само сообщение, чтобы программист его видел: иногда этого достаточно.

FDS>Т.е. примерно так:
FDS>

FDS>Detected incompatible types in computation branchs: (int * int * int), void


Ну, можно и так. Это уже детали.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: FDSC Россия consp11.github.io блог
Дата: 23.08.11 15:50
Оценка:
Здравствуйте, VladD2, Вы писали:

FDS>>Сам подумай, если я пишу def a: string = if (условие) 1 else "2"

FDS>>и мне компилятор на строке "2" говорит, что, мол, ожидается int, очевидно, меня это смущает, т.к. я явно указал, что a: string, и я ожидаю, что компилятор поймёт, что if как раз типа string.

VD>Очевидно это исключительно для тебя. В прочем, я уже повторясь.


Ну если для тебя не очевидно, что если компилятор ожидает некий тип там, где его нет, то это неудобно, то мне тебя жаль.

VD>Проблема в том, что ты не осознаешь всей сложности алгоритмов вывода типа. Языки вроде C# вообще не учитывают возвращаемое значение при выводе типов. И на то есть свои причины.


Мне и не нужно ничего осознавать. Я лишь пишу дефект с просьбой что-нибудь исправить: или вывод типов, если возможно, или сообщение об ошибке.
В F# вот, как тут в теме показали, вывод типов вполне справился.

VD>Потом ты приводишь частный случай, а по жизни связь может быть отнюдь не явной. if может быть глубоко вложен в другие выражения, а типы могут быть попросту не известны до какого-то времени.


Здесь он был известен.

VD>
VD>def f() : string
VD>{
VD>  if (cond)
VD>    WriteLine("..."); // void
VD>  else
VD>    ReadLine(); // возвращает строку

VD>  "a"
VD>}
VD>


VD>По твоей логике, компилятор радостно отрапортует, что WriteLine() возвращает не тот тип. Хотя ошибка скорее в том, что не тот тип возвращает ReadLine().


Ты вообще читаешь, что я пишу? По-моему нет.

FDS>>Вот как раз если бы он думал так, я бы не был бы против.


VD>То у него был бы ИИ.


У F# есть ИИ? Почему он так думает?

VD>>>Твой же случай — это чистая ошибка. В шарпе она проскочила бы в рантайм. Тут же тебе ее поймали.


FDS>>Да нет, в шарпе это не было бы ошибкой вообще (я не хотел ничего получать из функции, и она была пустой).


VD>Бала бы. Ты вызвал чистую функцию не порождающую побочных эффектов и потерял ее значение. Это чистой воды ошибка.

Это не ошибка: мне так и нужно было на данном этапе работы с кодом.

FDS>>Я бы предложил сначала вынести само сообщение, чтобы программист его видел: иногда этого достаточно.

FDS>>Т.е. примерно так:
FDS>>

FDS>>Detected incompatible types in computation branchs: (int * int * int), void


VD>Ну, можно и так. Это уже детали.


Это как раз очень важные детали: так лучше читается, а баг, как никак, об этом.
Re: Дефекты #55/#56 Нехорошее сообщение об ошибке (no well e
От: hardcase Пират http://nemerle.org
Дата: 23.08.11 17:21
Оценка: -2
Здравствуйте, FDSC, Вы писали:

FDS>у меня уже два закрытых дефекта при том, что в обоих случаях никто с моим мнением считаться даже не желает.


Может быть ты просто "докопался до столба?"

Подобные ошибки — это пробел в понимании языка, но не проблема в компиляторе. ИМХО.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[2]: [оффтопик]
От: FDSC Россия consp11.github.io блог
Дата: 23.08.11 18:39
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Подобные ошибки — это пробел в понимании языка, но не проблема в компиляторе. ИМХО.



Скажи мне, чего я не понимаю
Re[3]: [оффтопик]
От: hardcase Пират http://nemerle.org
Дата: 23.08.11 18:41
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Скажи мне, чего я не понимаю


Того, что в Nemerle нету стейтментов.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[4]: [оффтопик]
От: FDSC Россия consp11.github.io блог
Дата: 23.08.11 19:03
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Того, что в Nemerle нету стейтментов.


Кто тебе сказал, что я этого не понимаю?
Re[3]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.08.11 20:24
Оценка:
Здравствуйте, Аноним, Вы писали:

DR>>На мой взгляд, текущее сообщение вполне адекватно, но в идеале хотелось бы что-то вроде: "Conditional expression branches have incompatible types: (int * int * int)- and void".


А>Не, я реально офигеваю. И это немерлисты считают идеальным сообщением об ошибке???

А>Лично меня в такой ситуации устраивает только "void function can not return a value", как в общем-то во всех нормальных языках.

Вот тебе аналог на "нормальном" языке:
class Program
{
  static void Main(string[] args)
  {
    return args.Length < 0 
      ? args 
      : 1; // error CS0173: Type of conditional expression cannot be determined because there is no implicit conversion between 'string[]' and 'int'
  }
}


Как видишь, ни слова про "void function can not return a value". Более того, сообщение по смыслу очень похоже на немерловое.

Немерловый if — это полный аналог тернарного оператора C#. Просто в Nemerle void считается обычным типом и выражения могут возвращать его. Отсюда вместо 1 в Nemerle можно вставить то, что в C# называется statment.

И что характено, даже указание ошибки на той же сроке!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.08.11 20:30
Оценка:
Здравствуйте, Don Reba, Вы писали:

А>>А с if-ами без тренарного оператора чем ругается?


DR>Код с if-ами не аналогичен. Как уже обьяснили, в Немерле if это выражение, также как и оператор ?: в С++. Код FDSC не пытается вернуть что либо из функции, просто потому что внутреннее выражение не имеет смысла.


Самое прикольное в этой ситуации, что компилятор немерла ловит ошибки которые компиляторы других языков даже не выяляют порой. Но при этом те кто привык к компиляторам глотающим ошибки еще и в минус это немерлу записывают.

Интересно, есть кто-то кто написал на немерле приложение средних размеров и при этом не согласный с утверждением, что немрел значительно лучше защищает от глупых ошибок (вроде этой) нежели "обычные" языки?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.08.11 20:32
Оценка:
Здравствуйте, hardcase, Вы писали:

FDS>>у меня уже два закрытых дефекта при том, что в обоих случаях никто с моим мнением считаться даже не желает.


H>Может быть ты просто "докопался до столба?"


H>Подобные ошибки — это пробел в понимании языка, но не проблема в компиляторе. ИМХО.


Скажу больше, тут вообще ошибок нет никаких. Ошибка у автора кода и она успешно выявлена компилятором.

Единственное, что имеет смысл — сделать сообщение более информативным и чтобы оно указывало на шапку if-а, а не на одну из подветок.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [оффтопик]
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.08.11 20:33
Оценка:
Здравствуйте, FDSC, Вы писали:

H>>Того, что в Nemerle нету стейтментов.


FDS>Кто тебе сказал, что я этого не понимаю?


Тогда должен понмать, что сравнивать if немерла нужно с ?: С, а не со стейтментом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: FDSC Россия consp11.github.io блог
Дата: 23.08.11 20:38
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Самое прикольное в этой ситуации, что компилятор немерла ловит ошибки которые компиляторы других языков даже не выяляют порой. Но при этом те кто привык к компиляторам глотающим ошибки еще и в минус это немерлу записывают.


Если выявляет, пусть делает это качественно.

Средних размеров приложение, это сколько?
Re[4]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: FDSC Россия consp11.github.io блог
Дата: 23.08.11 20:39
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Вот тебе аналог на "нормальном" языке:

VD>
VD>class Program
VD>{
VD>  static void Main(string[] args)
VD>  {
VD>    return args.Length < 0 
VD>      ? args 
VD>      : 1; // error CS0173: Type of conditional expression cannot be determined because there is no implicit conversion between 'string[]' and 'int'
VD>  }
VD>}
VD>


VD>Как видишь, ни слова про "void function can not return a value". Более того, сообщение по смыслу очень похоже на немерловое.


VD>Немерловый if — это полный аналог тернарного оператора C#. Просто в Nemerle void считается обычным типом и выражения могут возвращать его. Отсюда вместо 1 в Nemerle можно вставить то, что в C# называется statment.


VD>И что характено, даже указание ошибки на той же сроке!


Зато само сообщение гораздо приятнее.
Re[6]: [оффтопик]
От: FDSC Россия consp11.github.io блог
Дата: 23.08.11 20:40
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Тогда должен понмать, что сравнивать if немерла нужно с ?: С, а не со стейтментом.


А я вообще ни с чем не сравнивал. Тут другие сравнивали, в т.ч. с F# (аноним) и C# (ты, кстати). В обоих случаях языки сработали не идеально, но лучше
Re[5]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.08.11 21:12
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Зато само сообщение гораздо приятнее.


Это поправить не сложно. Сделаем.

В немерловом компиляторе много не очень внятных сообщений, к сожалению.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [оффтопик]
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.08.11 21:13
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>А я вообще ни с чем не сравнивал. Тут другие сравнивали, в т.ч. с F# (аноним) и C# (ты, кстати). В обоих случаях языки сработали не идеально, но лучше


Ты это делал подсознательно. Это видно из твоих требований.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: [оффтопик]
От: FDSC Россия consp11.github.io блог
Дата: 23.08.11 21:17
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FDS>>А я вообще ни с чем не сравнивал. Тут другие сравнивали, в т.ч. с F# (аноним) и C# (ты, кстати). В обоих случаях языки сработали не идеально, но лучше


VD>Ты это делал подсознательно. Это видно из твоих требований.


По-моему, ты их на 50-ый раз только прочитал, и то невнимательно.
Из них такого вывода принципиально сделать невозможно.
Re[8]: [оффтопик]
От: Аноним  
Дата: 24.08.11 13:50
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FDS>>А я вообще ни с чем не сравнивал. Тут другие сравнивали, в т.ч. с F# (аноним) и C# (ты, кстати). В обоих случаях языки сработали не идеально, но лучше


VD>Ты это делал подсознательно. Это видно из твоих требований.


Я вот сравнивал вполне сознательно. И с удивлением обнаружил, что F# определяет правильную ветку, для которой выводить ошибку.
Был бы благодарен за любые комментарии относительного того, можно ли такое сделать в Nemerle.
Re[9]: [оффтопик]
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.08.11 14:18
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Я вот сравнивал вполне сознательно. И с удивлением обнаружил, что F# определяет правильную ветку, для которой выводить ошибку.


В частном, случае? Согласен, у F# получается не плохо. Моно попробовать делать так же.

Только это частный случай. Значение всего выражения будет известно не всегда (особенно в F#, который выводит обобщенные типы). Так что довольно быстро ты получишь ситуацию когда понять что за тип у выражения будет невозможно.

А>Был бы благодарен за любые комментарии относительного того, можно ли такое сделать в Nemerle.


Потенциально, наверно, можено. Но, в немерле вывод типов сильно сложнее. По этому боюсь, что число случаев в которых тип всего выражения будет заранее известен будет мало. Не аннотировать же типы у всего подряд?

Вот что будет в F#, если убрать аннотацию типов?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Развитие Nemerle
От: FDSC Россия consp11.github.io блог
Дата: 24.08.11 14:20
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Потенциально, наверно, можено. Но, в немерле вывод типов сильно сложнее. По этому боюсь, что число случаев в которых тип всего выражения будет заранее известен будет мало. Не аннотировать же типы у всего подряд?


VD>Вот что будет в F#, если убрать аннотацию типов?


Влад, я, например, в сложных местах специально аннотирую типы, даже если не требуется, как раз в надежде, что компилятор мне подскажет, если я ошибусь, верное место ошибки, где я вернул неверный относительно аннотации тип. Поэтому, как ты понимаешь, не очень приятно получать неверное место ошибки, когда используешь компилятор совсем для иного.
Re[10]: [оффтопик]
От: Аноним  
Дата: 24.08.11 14:34
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Аноним, Вы писали:


А>>Я вот сравнивал вполне сознательно. И с удивлением обнаружил, что F# определяет правильную ветку, для которой выводить ошибку.


VD>В частном, случае? Согласен, у F# получается не плохо. Моно попробовать делать так же.


VD>Только это частный случай. Значение всего выражения будет известно не всегда (особенно в F#, который выводит обобщенные типы). Так что довольно быстро ты получишь ситуацию когда понять что за тип у выражения будет невозможно.


А>>Был бы благодарен за любые комментарии относительного того, можно ли такое сделать в Nemerle.


VD>Потенциально, наверно, можено. Но, в немерле вывод типов сильно сложнее. По этому боюсь, что число случаев в которых тип всего выражения будет заранее известен будет мало. Не аннотировать же типы у всего подряд?


VD>Вот что будет в F#, если убрать аннотацию типов?


Чуда, конечно, не произойдет, о чем я уже писал.
Сообщение об ошибке будет на первую ветку. Но тут уже без вариантов, т.к. компилятор не телепат.
Мне вообщем и было интересно как разница в выводе типов влияет на такие вещи.
Re[11]: [оффтопик]
От: Аноним  
Дата: 24.08.11 14:46
Оценка:
А>Чуда, конечно, не произойдет, о чем я уже писал.
А>Сообщение об ошибке будет на первую ветку. Но тут уже без вариантов, т.к. компилятор не телепат.
А>Мне вообщем и было интересно как разница в выводе типов влияет на такие вещи.

Очепятка. Правильно читать "Сообщение об ошибке будет на вторую ветку."
Re[11]: Развитие Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.08.11 17:22
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Влад, я, например, в сложных местах специально аннотирую типы, даже если не требуется,


Ну, вот в Немерле этого не требуется. И это очень хорошо.
Ты и твои предпочтения это одно, а язык — другое. Он не только под твои предпочтения заточен.

FDS>как раз в надежде, что компилятор мне подскажет, если я ошибусь, верное место ошибки, где я вернул неверный относительно аннотации тип. Поэтому, как ты понимаешь, не очень приятно получать неверное место ошибки, когда используешь компилятор совсем для иного.


Как я уже сказал, проблема решается улучшением сообщения и выдачей его на сам if. Это более надежное решение, так как работает независимо от наличия аннотаций и других обстоятельств.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: [оффтопик]
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.08.11 17:30
Оценка:
Здравствуйте, Аноним, Вы писали:

VD>>Вот что будет в F#, если убрать аннотацию типов?


А>Чуда, конечно, не произойдет, о чем я уже писал.

А>Сообщение об ошибке будет на первую ветку. Но тут уже без вариантов, т.к. компилятор не телепат.

Вот, последняя мысль очень верная. Не телепат.
Правильным же вариантом, похоже, является выдача сообщения на сам if.

А>Мне вообщем и было интересно как разница в выводе типов влияет на такие вещи.


Если тебе интересны подробности алгоритмов, то (я думаю), что тут дело во так обстоит.

При типизации выражения с одной стороны выводится тип этого выражения путем анализа его содержимого, а с другой есть так называемый ожидаемый (expected) тип. Ожидаемый тип позволяет связать подвыражение и внешний контекст (другой выражение, или, например, тело метода). В F#, скорее всего при обнаружении проблемы унификации подвыражений if-а пытаются унифицировать обе ветки с этим самым ожидаемым типом. Это дает более ожидаемый ответ. Вот только если унифицировать не с чем (что встречается сплошь и рядом), то ответ будет все равно не правильный. А лучше бы иметь всегда понятный ответ.

В F# отсутствует неявное приведение типов. По этому для выявления "неправильности" достаточно унификации типов. В Nemerle же (как и в C#) унификации мало. Нужно пытаться подбирать приведение типов. Это так же осложняет алгоритм.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Развитие Nemerle
От: FDSC Россия consp11.github.io блог
Дата: 24.08.11 18:20
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FDS>>Влад, я, например, в сложных местах специально аннотирую типы, даже если не требуется,


VD>Ну, вот в Немерле этого не требуется. И это очень хорошо.


Как раз в Немерле это и требуется: в остальных языках аннотации типов всё равно приходится задавать всегда.

VD>Ты и твои предпочтения это одно, а язык — другое. Он не только под твои предпочтения заточен.


Однако это одно из достоинств языка лично для меня: на других языках так делать нельзя.

FDS>>как раз в надежде, что компилятор мне подскажет, если я ошибусь, верное место ошибки, где я вернул неверный относительно аннотации тип. Поэтому, как ты понимаешь, не очень приятно получать неверное место ошибки, когда используешь компилятор совсем для иного.


VD>Как я уже сказал, проблема решается улучшением сообщения и выдачей его на сам if. Это более надежное решение, так как работает независимо от наличия аннотаций и других обстоятельств.


Это не более надёжное решение: это решение одной из двух описанных мною проблем: неверного места выдачи и неиспользования всех доступных для вывода типов данных.
Опять же, ты просто отбрасываешь вторую проблему, потому что она сложная. Я не против, но надо чётко и ясно заявлять, что проблема есть, а не говорить, что "это не требуется". У тебя всё, что сложно сделать, получает метку "никому не нужно". Те же Enum в шаблонных типах например.
Re[12]: [оффтопик]
От: FDSC Россия consp11.github.io блог
Дата: 24.08.11 18:28
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Аноним, Вы писали:


VD>>>Вот что будет в F#, если убрать аннотацию типов?

А>>Чуда, конечно, не произойдет, о чем я уже писал.

Влад, а ты знаешь, что в том коде, что я дал как баг, аннотацию убрать невозможно? Чуда не произойдёт, в том месте Nemerle требует аннотацию.

А>>Сообщение об ошибке будет на первую ветку. Но тут уже без вариантов, т.к. компилятор не телепат.


VD>Вот, последняя мысль очень верная. Не телепат.


Из-за чего требует указания необходимой для вывода информации.

VD>Правильным же вариантом, похоже, является выдача сообщения на сам if.


Влад, однако Nemerle какой-то паршивый F# обставил там, где телепатия не нужна: он сообразил, на какую ветку указывать ошибку, если задавать аннотацию, которую не задать в Nemerle невозможно в данном конкретном реальном коде. Если ты не пишешь аннотаций нигде — это твоё дело, Nemerle не специально под тебя заточен , а ты подходишь к нему как к языку, который является твоей собственностью. Я не против, если чего-то в языке нет — я за него ничего не плачу и могу лишь указать, что что-то не так, но будь добр, признавай право других программистов программировать так, как они хотят на языке, который специально предоставляет для этого кучу возможностей, в том числе возможность создавать классы и объекты с обязательной аннотацией, которая лично меня крайне раздражает, но при этом не используется там, где могла бы облегчить ему жизнь.
Re[13]: Развитие Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.08.11 19:04
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Как раз в Немерле это и требуется: в остальных языках аннотации типов всё равно приходится задавать всегда.


Это просто говорят твои привычки. Те кто по опытнее в Н, типы указывают очень редко. Внутри выражений, так почти никогда. И никаких проблем не возникает. Компилятор весьма качественно находит ошибки.

VD>>Ты и твои предпочтения это одно, а язык — другое. Он не только под твои предпочтения заточен.


FDS>Однако это одно из достоинств языка лично для меня: на других языках так делать нельзя.


Ничего не понял.

Я говорю о том, что компилятор должен выдавать хорошую диагностику без учета того, есть аннотации типов или нет.
Иначе их придется писать всем и всегда.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: [оффтопик]
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.08.11 19:14
Оценка:
Здравствуйте, FDSC, Вы писали:

VD>>>>Вот что будет в F#, если убрать аннотацию типов?

А>>>Чуда, конечно, не произойдет, о чем я уже писал.

FDS>Влад, а ты знаешь, что в том коде, что я дал как баг, аннотацию убрать невозможно? Чуда не произойдёт, в том месте Nemerle требует аннотацию.


Это, вообще-то, цитата другого человека.

Что касается "того места", то у тебя там баг на баге. Убери баги и аннотация скорее всего не потребуется.

Реально аннотация требуется при неоднозначностях. У тебя ее я не заметил.

VD>>Вот, последняя мысль очень верная. Не телепат.


FDS>Из-за чего требует указания необходимой для вывода информации.


У них алгоритм слабенький, вот и требует. В немреле ничего не требуется.

FDS>Влад, однако Nemerle какой-то паршивый F# обставил


Ой, только не надо этой демагогии. Он и C# "обствил". Поправим сообщение и проблема исчезнет. А то что вывод типов у F# в разы слабее — это факт не приложный. И то что F# частенько выдает сообщения об ошибках которые без пол литры понять нельзя, тоже факт. Аннотации в нем тоже требуются раз в 10 чаще. А сколько он не умеет того что Nemerle и C# умеет? В общем, в F# гордиться можно только тем, что их алгоритм вывода типов быстрый и линейный.

FDS> там, где телепатия не нужна: он сообразил,


В этом случае сообразил. В другом лажанет. Чем меньше аннотаций, тем больше будет лажать.

FDS>на какую ветку указывать ошибку, если задавать аннотацию, которую не задать в Nemerle невозможно в данном конкретном реальном коде.


Прямо таки невозможно? Код (компилируемый) в студию!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Развитие Nemerle
От: FDSC Россия consp11.github.io блог
Дата: 24.08.11 19:17
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Это просто говорят твои привычки. Те кто по опытнее в Н, типы указывают очень редко. Внутри выражений, так почти никогда.

Влад, не считай других неопытными дураками: это невежливо и глупо, уж извини. То, что я указываю в Nemerle типы, это следствие
1. Того, что компилятор от меня это требует при декларациях классов, что ОЧЕНЬ меня достаёт
2. Моего опыта программирования на Nemerle, т.к. я знаю, что если вообще никогда не указывать типы, то мне потом самому тяжелее код читать, где на 500 строк ни одной явно типизированной декларации нет и компилятор зачастую при моих ошибках ошибается строк эдак на 150-200 в анализе того, где я допустил ошибку в типах.

VD>Я говорю о том, что компилятор должен выдавать хорошую диагностику без учета того, есть аннотации типов или нет.


Согласен в том смысле, что компилятор вообще должен хорошо работать. И если аннотация по каким-то причинам есть, то диагностика не должна превращаться в плохую, т.е. не учитывающую аннотацию.
Понимаешь?

Я не говорю, что это просто сделать, но если программист уже указал аннотацию, тем более, если он не мог её не указать, то хороший компилятор эту аннотацию учтёт. И это лишнее достоинство языка, а не его недостаток. Мне очень радостно, что я могу указывать типов в 10 раз меньше, чем обычно, и думать над этим в 30 раз меньше, чем обычно, но мне не радостно, что если уж я указал тип, то компилятор на это наплевал. Здесь вступает в силу обратный закон: лично мне удобно использовать мощь компилятора указывая аннотации типов, потому что если я укажу один тип из 10 или 20-ти это меня не затормозит, но код сделает читаемей и компилятору будет дополнительная подсказка, где я ошибся. В итоге программировать на таком языке становится удобнее.
Re[14]: [оффтопик]
От: FDSC Россия consp11.github.io блог
Дата: 24.08.11 19:27
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>>>Вот что будет в F#, если убрать аннотацию типов?

А>>>>Чуда, конечно, не произойдет, о чем я уже писал.

FDS>>Влад, а ты знаешь, что в том коде, что я дал как баг, аннотацию убрать невозможно? Чуда не произойдёт, в том месте Nemerle требует аннотацию.


VD>Это, вообще-то, цитата другого человека.


Влад, где цитата другого человека? Вот эта:
VD>>>>>Вот что будет в F#, если убрать аннотацию типов?

Ты читай всю цитату, что приводится.

VD>Что касается "того места", то у тебя там баг на баге. Убери баги и аннотация скорее всего не потребуется.


Давай тогда скажем, что вообще сообщения об ошибках компилятора не нужны: давай всё сами сделаем. Да и вывод типов не нужен: сам аннотируй, и всё будет хорошо.
Что касается "баг на баге" — этот код реальный из недописанного приложения, и всё, что нужно, он делает без ошибок вообще. Так что ошибки там чисто синтаксичесекие.

VD>Реально аннотация требуется при неоднозначностях. У тебя ее я не заметил.


Влад, а ты не заметил, что это декларация метода класса, и аннотация там требуется, потому что Nemerle иначе работать отказывается?

VD>У них алгоритм слабенький, вот и требует. В немреле ничего не требуется.


Требуется. Я был бы рад не указать аннотацию там, где мне её пришлось указать, т.к. этого требует компилятор Nemerle.

FDS>>Влад, однако Nemerle какой-то паршивый F# обставил


VD>Ой, только не надо этой демагогии. Он и C# "обствил". Поправим сообщение и проблема исчезнет.


Проблема не исчезнет до конца, т.к. Nemerle не использовал аннотацию типа, а вот F# — использовал.

VD> А сколько он не умеет того что Nemerle и C# умеет?


Влад, я не программирую на F#, поэтому мне не важно, что он не умеет. Я программирую на Nemerle, и мне важно, что в другом языке есть фича, которой в Nemerle нет. И я всего лишь навсего хочу, чтобы ты это признал. Может быть тогда когда-нибудь эта фича появится.


FDS>> там, где телепатия не нужна: он сообразил,


VD>В этом случае сообразил. В другом лажанет. Чем меньше аннотаций, тем больше будет лажать.


Согласен. Но здесь Nemerle сам принудил меня сделать аннотацию, так что меньше аннотаций здесь не станет.

FDS>>на какую ветку указывать ошибку, если задавать аннотацию, которую не задать в Nemerle невозможно в данном конкретном реальном коде.


VD>Прямо таки невозможно? Код (компилируемый) в студию!


Пожалуйста, вот тебе компилируемый код: убери аннотацию с любого метода


using Nemerle.Collections;
using Nemerle.Text;
using Nemerle.Utility;
using Nemerle.Compiler;
using Nemerle.Compiler.Parsetree;
using Nemerle.Compiler.Typedtree;

using System;
using System.Collections.Generic;
using System.Linq;

using System.IO;
using System.Text;

using Nemerle.Imperative;

namespace TabFile
{
    macro forToMacro(v, index1, index2, body)
    syntax ("for", v, "from", index1, "to", index2, "do", body)
    {
        Console.WriteLine(v.GetType().ToString());
        def id = (v:> PExpr.Ref).name.Id;
        <[ 
            mutable $(id: dyn): int = $index1;
            def     e = $index2;
            for (; $(id: dyn) <= e; $(id: dyn)++)
            {
                $body
            }
        ]>
    }

    macro for0Macro(v, index2, body)
    syntax ("for0", v, "to", index2, "do", body)
    {
        Console.WriteLine(v.GetType().ToString());
        def id = (v:> PExpr.Ref).name.Id;
        <[ 
            mutable $(id: dyn): int = 0;
            def     e = $index2;
            for (; $(id: dyn) <= e; $(id: dyn)++)
            {
                $body
            }
        ]>
    }

    macro forDowntoMacro(v, index1, index2, body)
    syntax ("for", v, "from", index1, "downto", index2, "do", body)
    {
        Console.WriteLine(v.GetType().ToString());
        def id = (v:> PExpr.Ref).name.Id;
        <[ 
            mutable $(id: dyn): int = $index1;
            def     e = $index2;
            for (; $(id: dyn) >= e; $(id: dyn)--)
            {
                $body
            }
        ]>
    }

    public class TabFileReader
    {
        public class TabTreeElement
        {
            public Name:    string;
            public parent:  TabTreeElement;

            public childs: List[TabTreeElement];

            public this(Name: string, parent: TabTreeElement)
            {
                this.Name   = Name;
                this.parent = parent;

                childs = List(4);
            }

            public write(): string
            {
                def sb = StringBuilder();
                write("", sb);
                sb.ToString();
            }


            public write(tab: string, sb: StringBuilder): void
            {
                def newTab = 
                    if (parent != null)
                    {
                        _ = sb.AppendLine(tab + Name);
                        tab + "\t"
                    }
                    else tab;

                foreach (child in childs)
                    child.write(newTab, sb);
            }
        }

        public tabFileName: string;
        public this(tabFileName: string)
        {
            def fi = FileInfo(tabFileName);
            unless (fi.Exists)
                throw FileNotFoundException($"Файл '$tabFileName' не найден.\r\n[полный путь '$(fi.FullName)']\r\nОбъект TabFileReader принимает имя только существующего файла.");

            this.tabFileName = fi.FullName;
        }

        public parse(): TabTreeElement
        {
            def root = TabTreeElement("", null);
            _ = parse(File.ReadAllLines(tabFileName), 0, "", root);
            root;
        }

        public parse(lines: array[string], curLine: int, curTab: string, curTreeTabParent: TabTreeElement): bool * int
        {
            when (lines.Length <= curLine)
                return (false, curLine);

            def line = lines[curLine];
            def subtreeContinue(): bool
            {
                line.StartsWith(curTab)
            }

            def getCurName()
            {
                line.Substring(curTab.Length)
            }

            def emptyLine()
            {
                line.Length <= curTab.Length && line.Trim().Length == 0;
            }

            when (emptyLine())
                return parse(lines, curLine + 1, curTab, curTreeTabParent);

            when (!subtreeContinue())
                return (false, curLine);

            def current = TabTreeElement(getCurName(), curTreeTabParent);
            curTreeTabParent.childs.Add(current);

            def childParse = parse(lines, curLine + 1, curTab + "\t", current);
            if (childParse[0])
                throw Exception("Фатальная ошибка алгоритма TabFileReader.parse: распарсены все потомки, но childParse - истинный")
            else
                parse(lines, childParse[1], curTab, curTreeTabParent);
        }
    }
}
Re[15]: [оффтопик]
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.08.11 20:15
Оценка:
Здравствуйте, FDSC, Вы писали:

VD>>>>>>Вот что будет в F#, если убрать аннотацию типов?

А>>>>>Чуда, конечно, не произойдет, о чем я уже писал.

FDS>>>Влад, а ты знаешь, что в том коде, что я дал как баг, аннотацию убрать невозможно? Чуда не произойдёт, в том месте Nemerle требует аннотацию.


VD>>Это, вообще-то, цитата другого человека.


FDS>Влад, где цитата другого человека? Вот эта:

VD>>>>>>Вот что будет в F#, если убрать аннотацию типов?

Выделено жирным.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: [оффтопик]
От: FDSC Россия consp11.github.io блог
Дата: 24.08.11 20:20
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>>>>>Вот что будет в F#, если убрать аннотацию типов?
VD>А>>>>>Чуда, конечно, не произойдет, о чем я уже писал.

FDS>>>>Влад, а ты знаешь, что в том коде, что я дал как баг, аннотацию убрать невозможно? Чуда не произойдёт, в том месте Nemerle требует аннотацию.


VD>>>Это, вообще-то, цитата другого человека.


FDS>>Влад, где цитата другого человека? Вот эта:

VD>>>>>>>Вот что будет в F#, если убрать аннотацию типов?

VD>Выделено жирным.


Подчеркнул
Re[16]: [оффтопик]
От: Аноним  
Дата: 25.08.11 10:55
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


VD>>>>>>>Вот что будет в F#, если убрать аннотацию типов?

VD>А>>>>>Чуда, конечно, не произойдет, о чем я уже писал.

FDS>>>>Влад, а ты знаешь, что в том коде, что я дал как баг, аннотацию убрать невозможно? Чуда не произойдёт, в том месте Nemerle требует аннотацию.


VD>>>Это, вообще-то, цитата другого человека.


FDS>>Влад, где цитата другого человека? Вот эта:

VD>>>>>>>Вот что будет в F#, если убрать аннотацию типов?

VD>Выделено жирным.


Извините, может быть я не точно выразился.
Метод не требует аннотации. В этом можно убедиться в случае когда он не содержит ошибки.
> let f () = (1,2,3);;

val f : unit -> int * int * int

> let f2 () = (3,4,5);;


val f2 : unit -> int * int * int

> let g cond = if (cond) then f() else f2();;


val g : bool -> int * int * int

В случае же, когда типы в ветках условий разные, то программист мог ошибиться как в первом, так и во втором случае (и никто кроме него самого это не скажет).
Компилятор указывает на второй, и я думаю этому есть логическое объяснение, связанное с тем что во время обработки второй ветки тип ифа уже вычислен.
Причем назвать это ошибочным не совсем верно, т.к. в половине случаев он угадывает .
Re[17]: [оффтопик]
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.08.11 16:14
Оценка: :)
Здравствуйте, Аноним, Вы писали:

VD>>>>>>>>Вот что будет в F#, если убрать аннотацию типов?

VD>>А>>>>>Чуда, конечно, не произойдет, о чем я уже писал.

FDS>>>>>Влад, а ты знаешь, что в том коде, что я дал как баг, аннотацию убрать невозможно? Чуда не произойдёт, в том месте Nemerle требует аннотацию.


VD>>>>Это, вообще-то, цитата другого человека.


FDS>>>Влад, где цитата другого человека? Вот эта:

VD>>>>>>>>Вот что будет в F#, если убрать аннотацию типов?

VD>>Выделено жирным.


А>Извините, может быть я не точно выразился.

А>Метод не требует аннотации. В этом можно убедиться в случае когда он не содержит ошибки.

Орлы, вы что, сговорились? Один отвечает мне цитируя при этом чужие слова. Другой извиняется передо мной за что-то.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: [оффтопик]
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.08.11 16:39
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>VD>>>>>>>Вот что будет в F#, если убрать аннотацию типов?

VD>>А>>>>>Чуда, конечно, не произойдет, о чем я уже писал.

FDS>>>>>Влад, а ты знаешь, что в том коде, что я дал как баг, аннотацию убрать невозможно? Чуда не произойдёт, в том месте Nemerle требует аннотацию.


VD>>>>Это, вообще-то, цитата другого человека.


FDS>>>Влад, где цитата другого человека? Вот эта:

VD>>>>>>>>Вот что будет в F#, если убрать аннотацию типов?

VD>>Выделено жирным.


FDS>Подчеркнул


А ты не подчеркивай. Ты цитируй то что нужно, а не что попало. И цитировать нужно в ответе на то письмо в котором цитата прозвучала, а не там где ее по третьему разу перецитировали. А то получается просто бессмыслица.

Я вот так и не понял что и где там обязательно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Развитие Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.08.11 16:46
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Влад, я, например, в сложных местах специально аннотирую типы, даже если не требуется, как раз в надежде, что компилятор мне подскажет, если я ошибусь, верное место ошибки, где я вернул неверный относительно аннотации тип. Поэтому, как ты понимаешь, не очень приятно получать неверное место ошибки, когда используешь компилятор совсем для иного.


Ага. Только ты не там аннотируешь. Если ты хочешь конкретное выражение аннотировать, то надо не у переменной тип указать, а у выражения. Например, так:
(if (...) ... else ...) : X


Ты же ведь не берешь в расчет кучи деталей. В Nemerle, в отличии от F#, поддерживается неявное приведение типов. Это многое меняет. Nemerle выводит значительно более сложные случаи. Но в следствии этого, простой унификации между внешним выражением и его внутренностями задать нельзя.

Так, например, при типизации тела метода, тип возвращаемого значения не учитывается при выводе типов. По окончании типизации для выведенного типа производится подобрать неявное приведение типов (если нет прямой унификации). Это позволяет не писать тучи явных приведений типов, но не дает унифицировать тип возвращаемого значения с типом тела в лоб.

И таких нюансов довольно много.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Развитие Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.08.11 16:57
Оценка:
Здравствуйте, FDSC, Вы писали:

VD>>Ну, вот в Немерле этого не требуется. И это очень хорошо.


FDS>Как раз в Немерле это и требуется: в остальных языках аннотации типов всё равно приходится задавать всегда.


Ты сам себе противоречишь. К тому же в подобных случаях в C# и F# типы можно не задавать. Так что ты еще и ошибаешься.

VD>>Как я уже сказал, проблема решается улучшением сообщения и выдачей его на сам if. Это более надежное решение, так как работает независимо от наличия аннотаций и других обстоятельств.


FDS>Это не более надёжное решение: это решение одной из двух описанных мною проблем: неверного места выдачи и неиспользования всех доступных для вывода типов данных.


Тут уж извини, но твоей компетенции не хватает. Хочешь разбирайся в тонкостях алгоритмов вывода типов, и потом поговорим на подобающем уровне, или просто поверь, что то что ты предлагаешь не реально в рамках алгоритма немерла. Точнее, то что ты предлагаешь и так делается. Вот только все сильно сложнее чем ты себе представляешь. В игру вступают неявные приведения типов, которые многое меняют.

FDS>Опять же, ты просто отбрасываешь вторую проблему, потому что она сложная. Я не против, но надо чётко и ясно заявлять, что проблема есть, а не говорить, что "это не требуется". У тебя всё, что сложно сделать, получает метку "никому не нужно". Те же Enum в шаблонных типах например.


Понимаешь ли в чем дело? Есть проблема и ее следствие. Компилятор выявляет основную проблему — несоответствие между ветвями if-а. Остальные проблемы (какими бы они не были) наложенные. Если программист исправит основную проблему, то с огромной вероятностью исчезнет и наложенные.

Отсюда простое следствие — нам нужно качественно и развернуто объяснить программисту в чем он ошибся. Если программист это поймет, то он поймет и как устранить ошибку. Ведь у программиста же есть реальный интеллект. А значит ему это по силам.

Решение из F# в Nemerle в общем случае невозможно. Более того, оно и в F# в общем случае невозможно (просто частных случаев в F# чуть, больше, так как он неявного приведения типов не поддерживает). По сему попытка сделать что-то умное скорее всего выльется в замедление компилятора и приведет к невнятным сообщениям в не рассмотренных случаях. А дополнительных проблем никому не нужно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Развитие Nemerle
От: FDSC Россия consp11.github.io блог
Дата: 25.08.11 17:12
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>Ну, вот в Немерле этого не требуется. И это очень хорошо.


FDS>>Как раз в Немерле это и требуется: в остальных языках аннотации типов всё равно приходится задавать всегда.


VD>Ты сам себе противоречишь. К тому же в подобных случаях в C# и F# типы можно не задавать. Так что ты еще и ошибаешься.


В подобных? Ты об объявлении публичного метода?
В C#, насколько я знаю, типы можно не задавать только при объявлении анонимного делегата (и то не помню, редко этим пользуюсь) или использовании var, а для методов типы задавать обязательно.

VD>Тут уж извини, но твоей компетенции не хватает.


Извини, моей компетенции вполне хватает, чтобы понять, что то, что сейчас, не очень хорошо.

VD>Хочешь разбирайся в тонкостях алгоритмов вывода типов, и потом поговорим на подобающем уровне, или просто поверь, что то что ты предлагаешь не реально в рамках алгоритма немерла


Я лишь говорю, что это было бы неплохо, а вот реально или нет — я об этом не спорю. Я уже говорил, что если дефект сложно или невозможно исправить, это не значит, что это не дефект: моё дело маленькое, я — пользователь. Я говорю о дефекте и о том, что то, что ты назвал "более надёжным решением" есть не альтернатива, а лишь одно из двух требуемых исправлений. Если второе невозможно реализовать в рамках Nemerle — мне очень жаль. Потерпим.

VD>Точнее, то что ты предлагаешь и так делается. Вот только все сильно сложнее чем ты себе представляешь. В игру вступают неявные приведения типов, которые многое меняют.


Мне-то это зачем знать? Я знаю, что тип возвращаемого значения void — это тип void и к нему не приведёшь (int * int * int), а значит, инфомации у компилятора достаточно. Если алгоритмы не позволяют — это недостаток алгоритмов и никаким образом нехорошести это не отменяет.


FDS>>Опять же, ты просто отбрасываешь вторую проблему, потому что она сложная. Я не против, но надо чётко и ясно заявлять, что проблема есть, а не говорить, что "это не требуется". У тебя всё, что сложно сделать, получает метку "никому не нужно". Те же Enum в шаблонных типах например.


VD>Понимаешь ли в чем дело? Есть проблема и ее следствие. Компилятор выявляет основную проблему — несоответствие между ветвями if-а. Остальные проблемы (какими бы они не были) наложенные. Если программист исправит основную проблему, то с огромной вероятностью исчезнет и наложенные.


Ты отбрасываешь момент, что компилятор может помочь найти верное место алгоритма. Да, это сахар, и, видимо, его трудно сделать, но то, что компилятор не до конца использует имеющуюся у него однозначно трактуемую информацию о типе match — это факт.

VD>Отсюда простое следствие — нам нужно качественно и развернуто объяснить программисту в чем он ошибся. Если программист это поймет, то он поймет и как устранить ошибку. Ведь у программиста же есть реальный интеллект. А значит ему это по силам.


Вот и я о том же: чем более качественно объясним — тем лучше. Поэтому лучше не только исправить сообщение об ошибке, но и научить компилятор использовать явные указания типов, если уж они есть.

VD>Решение из F# в Nemerle в общем случае невозможно. Более того, оно и в F# в общем случае невозможно (просто частных случаев в F# чуть, больше, так как он неявного приведения типов не поддерживает). По сему попытка сделать что-то умное скорее всего выльется в замедление компилятора и приведет к невнятным сообщениям в не рассмотренных случаях. А дополнительных проблем никому не нужно


Согласен.
Но есть разница между "в общем случае невозможно" и "не нужно". Ты же всё, что невозможно, начинаешь объявлять ненужным. Невозможно не значит не нужно, а ты просто не хочешь признавать, что чего-то в яызке не достаёт. Сказал бы, что невозможно, хотя и нужно, на этом бы спор закончился. Но ты утверждаешь, что это и не нужно, а это уже не так, это уже подтасовка статистики и преувеличение возможностей.
Re[15]: Развитие Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.08.11 17:19
Оценка:
Здравствуйте, FDSC, Вы писали:

VD>>Это просто говорят твои привычки. Те кто по опытнее в Н, типы указывают очень редко. Внутри выражений, так почти никогда.

FDS>Влад, не считай других неопытными дураками: это невежливо и глупо, уж извини.

Ты уж извини, то я все же возьму на себя смелость оценивать опыт человека в Nemerle, иначе придется потакать откровенным заблуждениям.

FDS>То, что я указываю в Nemerle типы, это следствие...


Да мне глубоко по фигу указываешь их ты или нет. Мне важно, что есть люди которые это делают (которых меньшинство) и те, которые не делают. Эти факты заставляют меня выбирать алогритмы так, чтобы они как минимум одинаково приемлемо работали как при наличии дополнительных аннотаций, так и при их отуствии.

Отсюда я делаю простой вывод. Если решение даст приемлемый результат в случае наличии аннотации, и не приемлемый в обратном случае, то такое решение не приемлемо, так как пострадает большинство.

С другой стороны, решение которое будет давать одинаковый, приемлемый результат в обоих случаях (с и без аннотаций типов) для меня предпочтительнее.

Далее остается ответить на вопрос насколько имеет смысл пытаться извернуться для частного случая и к каким затратам (увеличение времени компиляции, объем необходимых работ и т.п.). Если объем велик и есть риск замедлить компиляцию, то лично я откажусь от такого решения.

FDS>1. Того, что компилятор от меня это требует при декларациях классов, что ОЧЕНЬ меня достаёт


Зря. Это очень разумное требование. Если это очень серьезно, то используй другие языки (F#). Эту проблему решишь, но получишь букет других. Выбор за тобой.

FDS>2. Моего опыта программирования на Nemerle, т.к. я знаю, что если вообще никогда не указывать типы, то мне потом самому тяжелее код читать, где на 500 строк ни одной явно типизированной декларации нет и компилятор зачастую при моих ошибках ошибается строк эдак на 150-200 в анализе того, где я допустил ошибку в типах.


Твой опыт программирования на Nemerle примерно нулевой. Не обижайся. Мой опыт как раз говорит об обратном. Но я даже не хочу это обсуждать (хотя, если интересно, то могу поделиться опытом). Я просто не имею права закладываться, на то что код будет содержать аннотации типов. Я буду ориентироваться на более общий случай, в котором аннотации могут быть, а могут не быть. И для него нужно добиться приемлемого результата. То что на сегодня результат не приемлем — это плохо. Вот это мы и исправим.

В прочем, я уже повторился много раз. Мне кажется уже достаточно.

VD>>Я говорю о том, что компилятор должен выдавать хорошую диагностику без учета того, есть аннотации типов или нет.


FDS>Согласен в том смысле, что компилятор вообще должен хорошо работать. И если аннотация по каким-то причинам есть, то диагностика не должна превращаться в плохую, т.е. не учитывающую аннотацию.

FDS>Понимаешь?

Понимаю. Но это не верная логика. Диагностика должны быть достаточно для выявления ошибок в любом случае. "Есть" тут просто не катит.

FDS>Я не говорю, что это просто сделать, но если программист уже указал аннотацию, тем более, если он не мог её не указать, то хороший компилятор эту аннотацию учтёт.


Не указать программист мог. Это аксиома. Всегда можно не указывать.

То что какой-то человек не имеющий серьезного опыта в компиляторостроении делает какие-то предположения, еще не означает, что его предположения верны.

Так когда он делает предположение, что указав тип возвращаемого значения метода он, тем самым, дает подсказку компилятору, он сильно ошибается.

Наличие приведения типов не позволяет использовать эту подсказку напрямую. Кроме того между выражением где реально встретилась ошибка и телом метода может быть туча подвыражений каждое из которых так же может содержать ошибку. Наложение этих ошибок может привести к тому, что шибко умный компилятор укажет на место которое лежит очень далеко от того места где реальная ошибка возникла. А это, согласись, совсем не то чего мы хотели бы добиться.

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

Ну, а так как первой выявляется ошибка несовпадения типов подвыражений условных операторов, то о ней и нужно говорить. Только говорить более детально, умно и понятно.

Короче, я устал повторять, казалось бы (для меня) прописные истины. Лучше я потрачу время на устранение проблемы так как считаю нужным, а не на пустую теоретическую дискуссию. Ну, а там сможешь оценить сам насколько полученные сообщения помогут тебе выявлять ошибки.

FDS> И это лишнее достоинство языка, а не его недостаток. Мне очень радостно, что я могу указывать типов в 10 раз меньше, чем обычно, и думать над этим в 30 раз меньше, чем обычно, но мне не радостно, что если уж я указал тип, то компилятор на это наплевал. Здесь вступает в силу обратный закон: лично мне удобно использовать мощь компилятора указывая аннотации типов, потому что если я укажу один тип из 10 или 20-ти это меня не затормозит, но код сделает читаемей и компилятору будет дополнительная подсказка, где я ошибся. В итоге программировать на таком языке становится удобнее.


Компилятору не наплевать. Специально никто не теряет никакие проверки. Просто все сильно сложнее нежели ты себе представляешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Развитие Nemerle
От: FDSC Россия consp11.github.io блог
Дата: 25.08.11 17:20
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FDS>>Влад, я, например, в сложных местах специально аннотирую типы, даже если не требуется, как раз в надежде, что компилятор мне подскажет, если я ошибусь, верное место ошибки, где я вернул неверный относительно аннотации тип. Поэтому, как ты понимаешь, не очень приятно получать неверное место ошибки, когда используешь компилятор совсем для иного.


VD>Ага. Только ты не там аннотируешь. Если ты хочешь конкретное выражение аннотировать, то надо не у переменной тип указать, а у выражения. Например, так:

VD>
VD>(if (...) ... else ...) : X
VD>


VD>Ты же ведь не берешь в расчет кучи деталей. В Nemerle, в отличии от F#, поддерживается неявное приведение типов. Это многое меняет. Nemerle выводит значительно более сложные случаи. Но в следствии этого, простой унификации между внешним выражением и его внутренностями задать нельзя.


Т.е. какой-то тип у нас приводится к void? Получается, что вместо унификации компилятор вообще позволяет любой тип приводить к любому другому неявно. Забавно.
Но ведь он как-то поймёт, что здесь ошибка def a: int = "sfsdfasdf" и неявное приведение типов ему не помешает? По сути, if — это ветка, где всё вполне аналогично: каждая ветка возвращает значение, так или иначе приводимое к нужному типу, если это не так: это ошибка уже не несоответствия типов ветвей if (чему, кстати, тоже вполне может мешать приведение типов), это уже ошибка несоответствия возвращаемого значения из ветви ожидаемому из неё снаружи значению.

VD>Так, например, при типизации тела метода, тип возвращаемого значения не учитывается при выводе типов. По окончании типизации для выведенного типа производится подобрать неявное приведение типов (если нет прямой унификации). Это позволяет не писать тучи явных приведений типов, но не дает унифицировать тип возвращаемого значения с типом тела в лоб.


Недостаток алгоритма, так и скажи. Не учитывает информации, что поделаешь. Я не заставляю никого это исправлять, я лишь говорю, что это не есть хорошо.

VD>И таких нюансов довольно много.


Которые важны для людей, поддерживающих компилятор, но о которых совершенно не должен думать прикладной программист в подавляющем большинстве случаев (лучше вообще даже не знать). Конечно, если мы говорим о языке промышленного уровня.
Re[18]: [оффтопик]
От: FDSC Россия consp11.github.io блог
Дата: 25.08.11 17:23
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>А ты не подчеркивай. Ты цитируй то что нужно, а не что попало.

Я что нужно и процитировал

VD> И цитировать нужно в ответе на то письмо в котором цитата прозвучала, а не там где ее по третьему разу перецитировали. А то получается просто бессмыслица.


Я цитировал то твоё сообщение, на которое хотел ответить. А чтобы ответить на него, пришлось вспомнить и те твои сообщения, что были ранее. Я, слава богу не конечный автомат, могу запоминать не только текущее состояние, но и что было раньше.

VD>Я вот так и не понял что и где там обязательно.


У меня есть метод.
У меня есть из него возвращаемое значение, которое получается из if.
На метод я обязан поставить аннотацию возвращаемого типа

Т.е. убрать аннотацию я не могу, а ты выше предлагал её убрать. После того, как её убрали, естественно, результат изменился. Однако в моём коде убрать её было невозможно.
Re[15]: Развитие Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.08.11 17:37
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>В подобных? Ты об объявлении публичного метода?


Почему обязательно метода? Ты же сам приводил пример с переменной.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Развитие Nemerle
От: FDSC Россия consp11.github.io блог
Дата: 25.08.11 18:07
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>Это просто говорят твои привычки. Те кто по опытнее в Н, типы указывают очень редко. Внутри выражений, так почти никогда.

FDS>>Влад, не считай других неопытными дураками: это невежливо и глупо, уж извини.

VD>Ты уж извини, то я все же возьму на себя смелость оценивать опыт человека в Nemerle, иначе придется потакать откровенным заблуждениям.


Извини, но ты сначала не читаешь сообщения этого человека или понимаешь их неверно исходя из того, что у меня опыт незначительный и в целом я заблуждаюсь, а потом исходя из того, как понял сообщения начинаешь оценивать мой опыт. В т.ч. говорить о том, что я что-то не понимаю, что я понимал и использовал в 2007 году, что я указываю лишние аннотации, когда компилятор от меня их требует и т.п.

FDS>>То, что я указываю в Nemerle типы, это следствие...


VD>Да мне глубоко по фигу указываешь их ты или нет. Мне важно, что есть люди которые это делают (которых меньшинство) и те, которые не делают.


Ты опять прочитал моё сообщение невнимательно, хотя я уже раз 8, если не больше, в теме указал, что там аннотация была указана исключительно потому, что её требовал компилятор.

Если бы ты хотя бы внимательно прочитал ту часть предыдущего сообщения, на которую ты отвечаешь, ты бы увидел
FDS>1. Того, что компилятор от меня это требует при декларациях классов, что ОЧЕНЬ меня достаёт

Т.е. ВСЕ программирующие на Nemerle указывают аннотации там же, где и я в данном случае, иначе их программы просто не скомпилируются.

Я возьму смелость по твоим сообщениям сказать, что ты ни разу не написал ни одной программы на Nemerle, раз не знаешь, что в функциях модулей и методах классов типы указываются обязательно (насколько я помню, всегда, т.к. программист принуждается явно объявить интерфейс, чтобы типы не дай бог нигде не плавали потом).

VD> иначе придется потакать откровенным заблуждениям


Ты просто потакаешь своему способу использования языка, как будто он единственно правильный, и относишься к нему как к собственности.

VD>Мне важно, что есть люди которые это делают (которых меньшинство)


У тебя есть статистика по этому вопросу?
Зная тебя на этом форуме не первый год, могу сказать, что за большинство ты взял себя, а за меньшинство всех, кого не знаешь.

VD>Эти факты заставляют меня выбирать алогритмы так, чтобы они как минимум одинаково приемлемо работали как при наличии дополнительных аннотаций, так и при их отуствии.


Я разве против?

VD>Отсюда я делаю простой вывод. Если решение даст приемлемый результат в случае наличии аннотации, и не приемлемый в обратном случае, то такое решение не приемлемо, так как пострадает большинство.


Согласен.

VD>С другой стороны, решение которое будет давать одинаковый, приемлемый результат в обоих случаях (с и без аннотаций типов) для меня предпочтительнее.


Конечно.

VD>Далее остается ответить на вопрос насколько имеет смысл пытаться извернуться для частного случая и к каким затратам (увеличение времени компиляции, объем необходимых работ и т.п.). Если объем велик и есть риск замедлить компиляцию, то лично я откажусь от такого решения.


Согласен. Однако почему-то ты при этом обвиняешь меня в том, что я нефига не смыслю в программировании на Nemerle и в том, что предлагаю не нужные вещи. Влад, я нужные вещи предлагаю, а уж если их тяжело сделать — увы. Но от этого их нужность не уменьшается

FDS>>1. Того, что компилятор от меня это требует при декларациях классов, что ОЧЕНЬ меня достаёт


VD>Зря. Это очень разумное требование.


Не против, но это довольно часто встречается. В частности, в моём примере аннотация была указана именно по потому что этого требовал компилятор.

FDS>>2. Моего опыта программирования на Nemerle, т.к. я знаю, что если вообще никогда не указывать типы, то мне потом самому тяжелее код читать, где на 500 строк ни одной явно типизированной декларации нет и компилятор зачастую при моих ошибках ошибается строк эдак на 150-200 в анализе того, где я допустил ошибку в типах.


VD>Твой опыт программирования на Nemerle примерно нулевой. Не обижайся.


Не обижаюсь. Твой опыт не на много больше . Просто ты гораздо глубже изучал язык и программировал без перерывов.
А вообще, крайне невежливо себя ведёшь.

VD>Мой опыт как раз говорит об обратном. Но я даже не хочу это обсуждать (хотя, если интересно, то могу поделиться опытом).


Делись, я не против. Уж давно просил поделится, ещё лет 5 назад, но так ничего хорошего и не увидел. Жду.

VD>Я просто не имею права закладываться, на то что код будет содержать аннотации типов.


А я где-то тебе советовал на него закладываться? Покажи мне это место?

VD>Я буду ориентироваться на более общий случай, в котором аннотации могут быть, а могут не быть. И для него нужно добиться приемлемого результата. То что на сегодня результат не приемлем — это плохо. Вот это мы и исправим.


Если бы аннотаций можно было бы не делать совсем, это был бы полностью верный путь. Однако если аннотации принуждает делать язык, то можно подумать и об использовании аннотаций. Естественно, без ухудшений свойств языка там, где их нет.


VD>>>Я говорю о том, что компилятор должен выдавать хорошую диагностику без учета того, есть аннотации типов или нет.


FDS>>Согласен в том смысле, что компилятор вообще должен хорошо работать. И если аннотация по каким-то причинам есть, то диагностика не должна превращаться в плохую, т.е. не учитывающую аннотацию.

FDS>>Понимаешь?

VD>Понимаю. Но это не верная логика.


Поясни. Пока голословное утверждение, ничем не обоснованное. Чем плохо, если компилятор укажет мне на ошибку более точно и интеллектуально, в случаях когда это возможно, я не понимаю. Если только тем, что тебе не хочется признавать, что это вообще надо делать.

VD>Диагностика должны быть достаточно для выявления ошибок в любом случае.


Согласен полностью. Никогда с этим не спорил.

VD>"Есть" тут просто не катит.

Вообще не вижу никакой логики. Не верной, ни неверной. Как это соотносится с тем, что я говорил?

FDS>>Я не говорю, что это просто сделать, но если программист уже указал аннотацию, тем более, если он не мог её не указать, то хороший компилятор эту аннотацию учтёт.


VD>Не указать программист мог. Это аксиома. Всегда можно не указывать.


Влад, ты издеваешься что ли?

Я тебе выше по твоей просьбе дал компилируемый код, где есть аннотации типов методов и их невозможно убрать. Пожалуйста, покажи, как их "всегда можно не указывать". Я очень тебя прошу, мне тоже очень хочется не указывать типы полей и методов.


VD>То что какой-то человек не имеющий серьезного опыта в компиляторостроении делает какие-то предположения, еще не означает, что его предположения верны.


Я никаких предположений в опыте компиляторостроения не делаю и не делал.

VD>Так когда он делает предположение, что указав тип возвращаемого значения метода он, тем самым, дает подсказку компилятору, он сильно ошибается.


Совершенно не ошибается. Видимо, у тебя нет достаточного опыта программирования, чтобы знать, как ведёт себя компилятор. А одних теоретических знаний о его устройстве тут недостаточно. Не, я серьёзно. После добавления типов на функции местоположение и текст ошибки компиляции иногда очень сильно изменяются.


VD>Наличие приведения типов не позволяет использовать эту подсказку напрямую.

Напрямую — возможно. Но вот косвенно он её точно использует.

VD>Кроме того между выражением где реально встретилась ошибка и телом метода может быть туча подвыражений каждое из которых так же может содержать ошибку.


Да, как раз в этих случаях аннотации типов и помогают.

VD>Наложение этих ошибок может привести к тому, что шибко умный компилятор укажет на место которое лежит очень далеко от того места где реальная ошибка возникла. А это, согласись, совсем не то чего мы хотели бы добиться.


Ну да. Именно поэтому я указываю типы функций, когда не могу понять, что не нравится компилятору, и ошибка перемещается на нужное место.

VD>По этому, вместо того, чтобы пытаться снабдить компилятор ИИ, нам нужно выявлять ошибки как можно рано и сообщять о них в как можно более развернутой форме, так чтобы человек мог понять происходящее (во всех случаях, а не только в частных) и исправить ошибку.


Ну да. В частности, если метод помечен как void, а возвращаемое значение не может быть к нему приведено, компилятор должен выявить эту ошибку как можно раньше, а не думать, что это программист просто так указал, что метод возвращает void и продолжать компиляцию как ни в чём не бывало
Снабжать его ИИ я никогда не предлагал.

VD>Ну, а так как первой выявляется ошибка несовпадения типов подвыражений условных операторов, то о ней и нужно говорить. Только говорить более детально, умно и понятно.


Здесь обе ошибки одинакового ранга:
одна, что ветка match возвращает значение, не приводимое к некоторому указанному типу
вторая, что ветки возвращают разные значения.

Только не говори, что компилятор хочет оценить тип match в целом — это уже внутренности компилятора, о которых программисту чем меньше нужно знать, тем лучше этот компилятор.

VD>Короче, я устал повторять, казалось бы (для меня) прописные истины.


Я ничего, кроме выпадов в адрес моего опыта на Nemerle пока не заметил. По крайней мере, ничего, чего бы не знал до этого. Повторюсь, если ты считаешь других людей априори идиотами, не равными себе, ты всегда будешь уставать повторять им прописные истины, потому что сколько не повторяй, они с тобой пытаются говорить совсем о другом, а истины эти давно знают и о них с тобой не спорят.

VD>Лучше я потрачу время на устранение проблемы так как считаю нужным, а не на пустую теоретическую дискуссию.


Опять ты считаешь, что знаешь о Nemerle лучше всех на свете и обладаешь даром ясновидения. Надо внимательно работать с пользователями, в т.ч. с теми, кто ещё не привык к несуразностям и ошибкам языка, зарывшись в них по самую голову.

FDS>> И это лишнее достоинство языка, а не его недостаток. Мне очень радостно, что я могу указывать типов в 10 раз меньше, чем обычно, и думать над этим в 30 раз меньше, чем обычно, но мне не радостно, что если уж я указал тип, то компилятор на это наплевал. Здесь вступает в силу обратный закон: лично мне удобно использовать мощь компилятора указывая аннотации типов, потому что если я укажу один тип из 10 или 20-ти это меня не затормозит, но код сделает читаемей и компилятору будет дополнительная подсказка, где я ошибся. В итоге программировать на таком языке становится удобнее.


VD>Компилятору не наплевать. Специально никто не теряет никакие проверки. Просто все сильно сложнее нежели ты себе представляешь.


Я вижу код и знаю, что if возвращает void. Компилятор не знает. Значит компилятор эту проверку теряет. То, что он теряет их специально — я никогда не утверждал. Но по семантике приведённого кода if однозначно имеет тип void, а проверки этого нет.
Re[16]: Развитие Nemerle
От: FDSC Россия consp11.github.io блог
Дата: 25.08.11 18:09
Оценка:
Здравствуйте, VladD2, Вы писали:

FDS>>В подобных? Ты об объявлении публичного метода?


VD>Почему обязательно метода? Ты же сам приводил пример с переменной.


В описании дефекта я приводил пример с методом.
Re: Дефекты #55/#56 Нехорошее сообщение об ошибке (no well e
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.08.11 01:29
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Предлагаю обсудить здесь, т.к. в багтрекере поведение разработчиков Nemerle абсолютно неадекватное: дефекты закрывает только тот, кто их открывает, по крайней мере, пока явно очевидно, что пользователь может быть несогласен, а у меня уже два закрытых дефекта при том, что в обоих случаях никто с моим мнением считаться даже не желает. Да уж, тут подумаешь насчёт "фобий".


Отвечу на счет адекватности и прав на закрытие. Точнее про процедуру которая принята в данном проекте.

Закрывают issue-ы админы или те кто чинит ошибку (если issue — это ошибка).
Любой житель земли может добавить в issues запись любого содержимого. Наша задача оценить насколько она адекватна, чем является и что с ней делать дальше.

Хорошо продуманный и оформленный issue является очень важным подспорьем в решении этого вопроса (пожалуй именно так лучше всего переводится issue).

Если issue является непродуманным, ошибочным или того хуже, автору задаются наводящие вопросы. Если он не отвечат на них в течении какого-то времени, то issue закрывается с пометкой "Not a bug".

Создание копий закрытых тем — это уже форменное вредительство. За такое вообще банить надо.

Разумной реакцией на закрытие является добавление еще одного сообщения. Если issue закрыт не по делу, то его откроют. Это не проблема.

Кроме того, чтобы issue не был закрыти или удален, нужно отучать на вопросы заданные по нему.

Что касается конкретно issue #56:
1. Это был дубликат, причем сделанный намеренно. По уму его просто нужно было грохнуть.
2. Вопрос был оформлен невнятно. Вместо описания своих затруднений и непонимания, так приводятся какие-то странные рассуждения на не очень внятном (мягко говоря) английском языке.
3. На вопросы администратора ответа, в разумные сроки, получено не было.
4. Поднятый вопрос весьма спорный.

На будущее, советую сначала обсуждать подобные вопросы на форумах, и добавлять issue, только когда будет выработано какое-то понимание.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.08.11 01:38
Оценка:
Здравствуйте, FDSC, Вы писали:


VD>>Что не понятного в "expected (int * int * int)-, got void in computation branch" и куда должно указывать это сообщение, если не на само выражение if?

VD>>Closed

FDS>Разве я говорил где-то, что мне что-то непонятно. Я сказал, что сообщение низкого качества, а должно быть лёгким для понимания — высокого качества.


Извини, но понять это из того что там было написано довольно сложно.
Вообще не дело описывать что где должно быть. Это уже мы решим. Описывать нужно "проблему". И уже после ее описания можно привести свое видение ее решения.

FDS>Ошибка состоит в том, что возвращаемое значение if не void, а мне компилятор говорит, что ожидается (int * int * int). Если это невозможно или трудно исправить, это не значит, что это не дефект.


Вот этот набор слов просто не нужен. Нужно описывать свою проблему. Ну, типа — "Компилятор мне сообщил "..." из чего я не смог понять (смог понять с огромным трудом), что от меня хочет компилятор.". И потом можно уже поговорить о своих ожиданиях и т.е.

Предположения же "возвращаемое значение if не void" — это домыслы, которые сразу заставляют смотреть на issue с огромным скепсисом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: FDSC Россия consp11.github.io блог
Дата: 30.08.11 06:45
Оценка:
Здравствуйте, VladD2, Вы писали:


FDS>>Разве я говорил где-то, что мне что-то непонятно. Я сказал, что сообщение низкого качества, а должно быть лёгким для понимания — высокого качества.


VD>Извини, но понять это из того что там было написано довольно сложно.


Читать надо внимательно: даже дефект называется "no well error message".
Если не понял — не закрывать дефект, а переспросить, что имеется в виду.

VD>Вообще не дело описывать что где должно быть. Это уже мы решим. Описывать нужно "проблему". И уже после ее описания можно привести свое видение ее решения.


Я, вообще-то, проблему и описал.

FDS>>Ошибка состоит в том, что возвращаемое значение if не void, а мне компилятор говорит, что ожидается (int * int * int). Если это невозможно или трудно исправить, это не значит, что это не дефект.


VD>Вот этот набор слов просто не нужен. Нужно описывать свою проблему. Ну, типа — "Компилятор мне сообщил "..." из чего я не смог понять (смог понять с огромным трудом), что от меня хочет компилятор.". И потом можно уже поговорить о своих ожиданиях и т.е.


Влад, по-моему, очевидно, что если человек указывает, что ошибка компиляции должна быть на другой строке, то это — описание проблемы. Или для тебя ошибка не на той строке — это не проблема?
Далее в #56 я указал, что компилятор возвращает мне не тот тип, которым может быть if. Это тоже не проблема?

VD>Предположения же "возвращаемое значение if не void" — это домыслы, которые сразу заставляют смотреть на issue с огромным скепсисом.


Какие ещё домыслы и предположения? Это компилятор так пишет, для него if возвращает int * int * int.
Читать надо внимательно
Re[2]: Влад, ты что хамишь, а?
От: FDSC Россия consp11.github.io блог
Дата: 30.08.11 07:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Закрывают issue-ы админы или те кто чинит ошибку (если issue — это ошибка).


Само по себе странное соглашение, если учесть, что постер дефекта не может сделать reopen. Тем более, если речь идёт о закрытии бага, который содержал описание "в котором трудно было что-то понять", судя по твоим же словам. Такие баги надо уточнять, благо ответы приходят на почту.

Если issue закрывают те, кто чинит ошибку, то у постера должно быть открыто право на reopen, т.к. именно и только постер может окончательно заключить, исправлена ошибка или нет.


VD>Хорошо продуманный и оформленный issue является очень важным подспорьем в решении этого вопроса (пожалуй именно так лучше всего переводится issue).


Влад, я пользователь, и у меня свои проблемы. Куча других пользователей вообще плюёт на ошибки и пользуется бажным ПО годами, ленясь написать хоть что-то.

VD>Если issue является непродуманным, ошибочным или того хуже, автору задаются наводящие вопросы. Если он не отвечат на них в течении какого-то времени, то issue закрывается с пометкой "Not a bug".


Влад, мне никаких вопросов никто не задавал.

VD>Создание копий закрытых тем — это уже форменное вредительство. За такое вообще банить надо.


Влад, если поведение закрывающего неадекватно, то приходится создавать новые темы вместо старых. Т.к. закрыт был дефект неадекватно, в т.ч. по твоим словам мне должны были задать наводящие вопросы, а их не было, я запостил дефект заново. Но он опять был закрыт
Знаешь, за такое отношение к постеру, вообще-то, положено приносить официальные извинения и долго каяться перед начальством (в данном случае денег тебе не платят, так что каяться не перед кем).

VD>Разумной реакцией на закрытие является добавление еще одного сообщения. Если issue закрыт не по делу, то его откроют. Это не проблема.


По моему опыту, это реакция не разумна, т.к. закрытые дефекты часто автоматом снимаются с оповещений и любые сообщения в них просто не читаются. Бывает даже неназначенные дефекты не читаются. Т.к. я не знаю, что у вас там "нормальная реакция", я исхожу из своего профессионального опыта в постинге багов.

VD>Кроме того, чтобы issue не был закрыти или удален, нужно отучать на вопросы заданные по нему.


К сожалению, никаких вопросов мне задано не было, хотя я очень ждал.

VD>Что касается конкретно issue #56:

VD>1. Это был дубликат, причем сделанный намеренно. По уму его просто нужно было грохнуть.

Влад, а тебя надо забанить было за неправомерно закрытый дефект и неуважительное отношение к пользователю. Иди бань

VD>2. Вопрос был оформлен невнятно. Вместо описания своих затруднений и непонимания, так приводятся какие-то странные рассуждения на не очень внятном (мягко говоря) английском языке.


И? Я должен быть англичанином, чтобы пользоваться Nemerle? Влад, я пользователь, как умею, так и завожу. Напиши внятно, что можно на русском, я напишу внятно описание на русском.

VD>3. На вопросы администратора ответа, в разумные сроки, получено не было.


Влад, на какие вопросы администратора? Мне НЕ ЗАДАВАЛОСЬ НИКАКИХ ВОПРОСОВ!

VD>4. Поднятый вопрос весьма спорный.


Если так, почему оба дефекта были закрыты без каких-либо вопросов ко мне?

VD>На будущее, советую сначала обсуждать подобные вопросы на форумах, и добавлять issue, только когда будет выработано какое-то понимание.


Я не думал, что этот вопрос настолько спорный — для меня это просто дефект. Надо было написать в issue, чтобы обсудил на форуме. Кроме этого, issue сам по себе не подразумевает каких-либо предварительных обсуждений на форуме.

На будущее советую себя корректно вести и извинится за некорректное и неадекватное поведение с твоей стороны.
Re[3]: Влад, ты что хамишь, а?
От: YF Германия  
Дата: 30.08.11 12:41
Оценка:
Здравствуйте, FDSC, Вы писали:

Просто не отработана процедура обработки багов. Сейчас это работало примерно так:
ты открыл #55. Пришел hardcase, ответил тебе в багтрекере и тут же его закрыл.
Ты пришел, и тебя это не устроило (по каким-то причинам). Ты взял и открыл еще один issue, #56, сославшись в нем на предыдущий.
VladD2, разумеется, это увидел, оставил комментарий и закрыл его, справедливо полагая, что hardcase тебе уже все сказал. Другое дело, что тебя этот ответ не устроил.
Проблема в том, что закрывают issue и не ожидают обратной реакции того, кто issue создал.
В нашей конторе используется TestTrackPro — кто-то создет issue, то при любом его изменении он (и я) получае емаил. И я, программист, сам issue не закрываю(хотя и могу) — это делает тестировщик, т.е. тот,кто ее создал.
Кроме этого, если багу(issue) я пофиксил, то она автоматически системой присваивается тому, кто ее создал. Он проверяет, и, если считает вопрос исчерпаным, закрывает.
Здесь же никто реакции пользователя не ждал. Объяснили и закрыли.
Насчет хамства- ну побойся Б-га, он же совершенно бескорыстно возится тут со всеми, как с детьми малыми, развернуто отвечая на все вопросы и ничего не требуя взамен.
Re[4]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.08.11 15:03
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Читать надо внимательно:


Я несколько раз прочел.

FDS>даже дефект называется "no well error message".


Это то понятно, но информации от этого не много.

FDS>Если не понял — не закрывать дефект, а переспросить, что имеется в виду.


Да я как раз понял. Но дефектом это уж точно не является. Если бы было просто написано, что сообщение не понятно, то можно было бы счесть за пожелание к улучшению сообщения.

Но там же ведь были какие-то домыслы по поводу того что и где ищет компилятор. Из них явно следует, что автор просто не знает языка и делает не верные предположения. Соответственно исправить "дефект" не представляется возможным. На вопросы автор тоже не реагировал. Такие темы сразу же закрываются.

VD>>Вообще не дело описывать что где должно быть. Это уже мы решим. Описывать нужно "проблему". И уже после ее описания можно привести свое видение ее решения.


FDS>Я, вообще-то, проблему и описал.


Этот сумбур и домыслы никак не является описанием проблемы. В следующий раз остановись на том, что тебе не ясно сообщение об ошибке. Будет куда конструктивнее.

FDS>>>Ошибка состоит в том, что возвращаемое значение if не void, а мне компилятор говорит, что ожидается (int * int * int). Если это невозможно или трудно исправить, это не значит, что это не дефект.


VD>>Вот этот набор слов просто не нужен. Нужно описывать свою проблему. Ну, типа — "Компилятор мне сообщил "..." из чего я не смог понять (смог понять с огромным трудом), что от меня хочет компилятор.". И потом можно уже поговорить о своих ожиданиях и т.е.


FDS>Влад, по-моему, очевидно, что если человек указывает, что ошибка компиляции должна быть на другой строке,


Да. Очевидно. Очевидно, что человек в компиляторе ничего не понимает, но пытается чего-то там предвидеть.

В общем, ты меня извини, но если ты не понял моих слов, то значит не судьба. Тратить остаток своей жизни на беседы с тобой я не намерен.

FDS>то это — описание проблемы. Или для тебя ошибка не на той строке — это не проблема?


Отвечаю последний раз. Это твои домыслы. По текущей логике работы компилятора ошибка на той строке, что нужно. Компилятор не может знать в какой из веток был возвращен неверный тип.

FDS>Далее в #56 я указал, что компилятор возвращает мне не тот тип, которым может быть if. Это тоже не проблема?


Ага проблема твоего понимания.

FDS>Какие ещё домыслы и предположения? Это компилятор так пишет, для него if возвращает int * int * int.

FDS>Читать надо внимательно

Ага. Пишет. У него алгоритм такой. Это не ошибка.

Ну, а то что сообщение не внятное — это отдельный вопрос. Никак не связанный с алгоритмом. И путей решения проблемы тут несколько. Один из них — понять что происходит тебе. Другой усложнить алгоритм (что может быть чревато другими проблемами), изменить сообщение чтобы оно давало больше информации. Там, кстати, еще hint выдается, которые подсказывает что происходит. Но ты его смело проигнорировал.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: YF Германия  
Дата: 30.08.11 15:13
Оценка:
Здравствуйте, VladD2, Вы писали:

Сообщение об ошибке там вываливается такое:
error : expected (int * int * int)-, got void in computation branch: (int * int * int) is not a subtype of void [simple require]
Если сделать по нему двойной клик (оно есть в списке сообщений об ошибке, кстати), то в редакторе выделяется не весь if, а
именно строчка с MessageBox. т.е. куда уж точнее.
Вопрос: в части сообщения "computation brach", нельзя ли указать "else", может эта информация у компилятора есть? А то "computation branch", это и правда не очень понятно.
Re[3]: Влад, ты что хамишь, а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.08.11 15:24
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Само по себе странное соглашение, если учесть, что постер дефекта не может сделать reopen.


Почему не может? Вроде как может. Но если даже не может, то это даже хоршо.

Главное, что он может добавить комментарий в котором разяснить свою позицию (или связаться с админом по другим каналам).

FDS>Тем более, если речь идёт о закрытии бага, который содержал описание "в котором трудно было что-то понять", судя по твоим же словам. Такие баги надо уточнять, благо ответы приходят на почту.


Если был бы внятный ответ, то открыли бы. Это не проблема. Или завели бы другой issuse в котором уже было бы описано все правильно.

Тут еще вот что нужно понимать. Issuse-ы используются для формирования лога изменений в инсталляторах и как средство слежения за текущим состоянием проекта. По сему невнятной фигни в них быть не должно. Открытые issuse-ы должны отражать список проблем которые мы намереваемся решить. А закрытые и помеченные специальными тегами являются информацией о проделанной работе.

FDS>Если issue закрывают те, кто чинит ошибку, то у постера должно быть открыто право на reopen, т.к. именно и только постер может окончательно заключить, исправлена ошибка или нет.


Ну, вот совсем недавно был случай. Починил я баг и закрыл его, так как считал, что все ОК. Но автор issuse-а обнаружил, что есть определенные случаи где баг все же проявляется. Он написал об этом соответствующее сообщение и я переоткрыл issuse.

В твоем случае все будет несколько иначе. Так как сообщение совршенно не внятное, то будет создан новый issuse. Вопрос только какой. Если примем решение принять измененный алгоритм
Автор: VladD2
Дата: 29.08.11
, то создадим issuse-Фича-реквест описывающий этот алгоритм. В нем уже сошлемся на твой issuse, как на смежный. Если, же алгоритм окажется отклонен, то просто исправим сообщение об ошибке, и место его дислакации. При этом будет создан другой issuse, в котором будет описана проблема и принятое решение.

В любом случае нам нужно полноценное описание чтобы те кто получит новую версию могли понять, что же за проблема была, и как ее устранили.

Так понятнее?

FDS>Влад, я пользователь, и у меня свои проблемы. Куча других пользователей вообще плюёт на ошибки и пользуется бажным ПО годами, ленясь написать хоть что-то.


Никто ни на что не плюет. Ну, не по-твему немного. Ничего страшного. Ты сам в этом виноват.

Иди сходи на багтреккеры МС. Погляди как там дела осбтоят. Там тебе вежливо ответят, что твое мнение услышано и точно так же закроют запись, только при этом ничего не объяснят.

VD>>Если issue является непродуманным, ошибочным или того хуже, автору задаются наводящие вопросы. Если он не отвечат на них в течении какого-то времени, то issue закрывается с пометкой "Not a bug".


FDS>Влад, мне никаких вопросов никто не задавал.


О, как? А это что?

FDS>Влад, если поведение закрывающего неадекватно,


Не тебе судить о поведении закрывающего. Считаешь, что он ошибся — добавь сообщение в ту же тему. Или создай тему на форуме. Тут еще не было случаев когда кого-то игнорировали.

А вот истерик и обвинений — не надо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Влад, ты что хамишь, а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.08.11 15:31
Оценка:
Здравствуйте, YF, Вы писали:

YF>VladD2, разумеется, это увидел, оставил комментарий и закрыл его, справедливо полагая, что hardcase тебе уже все сказал. Другое дело, что тебя этот ответ не устроил.


Надо уточнить. Оставил комментарий, не дождался ответа на него, и только потом закрыл.

YF>Проблема в том, что закрывают issue и не ожидают обратной реакции того, кто issue создал.


Ну, почему же? Очень даже ожидают. Но если реакции нет, то других средств уже не остается.
Если проблема есть, то ее все равно поднимут снова и снова. Кто-нибудь обязательно опишет ее более корректно и она будет решена.

YF>В нашей конторе используется TestTrackPro — кто-то создет issue, то при любом его изменении он (и я) получае емаил.


Здесь, насколько я знаю, все точно так же. Только, возможно, уведомления настраиваются. Лично я получаю все уведомления.

YF>И я, программист, сам issue не закрываю(хотя и могу) — это делает тестировщик, т.е. тот,кто ее создал.

YF>Кроме этого, если багу(issue) я пофиксил, то она автоматически системой присваивается тому, кто ее создал. Он проверяет, и, если считает вопрос исчерпаным, закрывает.

У нас нет отдельных тестеров. Так что это точно не для нас.

YF>Здесь же никто реакции пользователя не ждал. Объяснили и закрыли.


Не правда. Реакцию ждали, но она не последовала. Плюс было явное не понимание происходящего тем кто создал issue. Сочетание отсутствия ответа, невнятности issue и явно неверных предпосылок автора и привело к данному решению.

Учитывая, что ответ можно дать и после закрытия проблемой это не является. Будет внятное объяснение, issue можно и переоткрыть.

YF>Насчет хамства- ну побойся Б-га, он же совершенно бескорыстно возится тут со всеми, как с детьми малыми, развернуто отвечая на все вопросы и ничего не требуя взамен.


Вот именно. Хорошо, что хоть кто-то это понимает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Влад, ты что хамишь, а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.08.11 15:33
Оценка: +1 -1
Здравствуйте, FDSC, Вы писали:

Это. Ты бы лучше чем тратить свое и чужое время, попробовал бы Новый алгоритм типизации match
Автор: VladD2
Дата: 29.08.11
. Возможно он удовлетворит тебя.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.08.11 15:42
Оценка:
Здравствуйте, YF, Вы писали:

YF>Сообщение об ошибке там вываливается такое:

YF>error : expected (int * int * int)-, got void in computation branch: (int * int * int) is not a subtype of void [simple require]
YF>Если сделать по нему двойной клик (оно есть в списке сообщений об ошибке, кстати), то в редакторе выделяется не весь if, а
YF>именно строчка с MessageBox. т.е. куда уж точнее.
YF>Вопрос: в части сообщения "computation brach", нельзя ли указать "else", может эта информация у компилятора есть? А то "computation branch", это и правда не очень понятно.

Нельзя. Ключевые слова — это части макроса. Они не доступны типизатору. Типизатор типизирует то во что раскрываются макросы.

Но проблема решает проще. Можно выдавать два сообщения об ошибке (идущие друг за другом) указывающее на обе ветви, и сделать текст более понятным для новичка в языке. Именно это я и предлагал сделать. Но в ответ получил нудную дисскуссию.

В прочем, в процессе решения проблемы поднятой
Автор: Ziaw
Дата: 25.08.11
Ziaw, я сильно переделал алгоритм вывода типов для match (в который, в частности, переписывается и if). Так что теперь компилятор реагирует на подобные ошибки иначе (близко к тому, что хотел FDSC).

Проблема только в том, что новый алгоритм медленнее предыдущего. Сейчас вот думаем имеет ли смысл применять его, или просто улучшить сообщение об ошибке (без изменения алгоритма). Без изменения же алгоритма добиться того что хочет FDSC невозможно в принципе.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Влад, ты что хамишь, а?
От: FDSC Россия consp11.github.io блог
Дата: 31.08.11 06:27
Оценка:
Здравствуйте, VladD2, Вы писали:

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


YF>>VladD2, разумеется, это увидел, оставил комментарий и закрыл его, справедливо полагая, что hardcase тебе уже все сказал. Другое дело, что тебя этот ответ не устроил.


VD>Надо уточнить. Оставил комментарий, не дождался ответа на него, и только потом закрыл.


Он минуту ждал или две? Дефект был открыт 22 августа и закрыт в 11:55 утра того же дня. Если это называется "не дождался реакции", то я тебя поздравляю.

VD>Ну, почему же? Очень даже ожидают. Но если реакции нет, то других средств уже не остается.


И сколько же ждали? Я вижу, что его закрыли сразу же в тот же день.

VD>Если проблема есть, то ее все равно поднимут снова и снова. Кто-нибудь обязательно опишет ее более корректно и она будет решена.


Полная чушь. Если есть проблема, она может годами висеть, отпугивать и мешать пользователям, но программист о ней узнает совершенно случайно, а то и не узнает вообще.

YF>>Здесь же никто реакции пользователя не ждал. Объяснили и закрыли.


VD>Не правда. Реакцию ждали, но она не последовала.


Наглая ложь.

VD>Плюс было явное не понимание происходящего тем кто создал issue. Сочетание отсутствия ответа, невнятности issue и явно неверных предпосылок автора и привело к данному решению.


А это уже хамство.

VD>Учитывая, что ответ можно дать и после закрытия проблемой это не является. Будет внятное объяснение, issue можно и переоткрыть.


Учитывая, что пользователь не знает, будет ли реакция на его ответ ПОСЛЕ закрытия бага, это является серьёзной проблемой.

VD>Вот именно. Хорошо, что хоть кто-то это понимает.


Влад, спасибо, что "возишься", но хамство это не отменяет.

P.S. Я, кстати, тебе писал личное сообщение через форум, оно до тебя дошло? Мне никакого ответа назад что-то не пришло, а писал давно.
Re[5]: Дефекты #55/#56 Нехорошее сообщение об ошибке (no wel
От: FDSC Россия consp11.github.io блог
Дата: 31.08.11 06:41
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я несколько раз прочел.


Не верю. Судя по тому, что ты мне писал пару дней в ответ на мои сообщения, ты поверхностно просмотрел то, о чём я писал. В том числе, не смотрел код.

VD>Это то понятно, но информации от этого не много.


Достаточно, чтобы понять, что я говорю о том, что мне не нравится сообщение об ошибке

FDS>>Если не понял — не закрывать дефект, а переспросить, что имеется в виду.


VD>Но там же ведь были какие-то домыслы по поводу того что и где ищет компилятор.


Таких домыслов там не было.

VD>Из них явно следует, что автор просто не знает языка и делает не верные предположения.


Соотв., из них ничего не могло следовать.

VD>Соответственно исправить "дефект" не представляется возможным.


Соотв., об исправлении даже никто не подумал

VD>На вопросы автор тоже не реагировал.


Потому что их никто не ждал ни секунды.

VD>Такие темы сразу же закрываются.


Вот и я про то же.

VD>Этот сумбур и домыслы никак не является описанием проблемы. В следующий раз остановись на том, что тебе не ясно сообщение об ошибке. Будет куда конструктивнее.


Это было в заголовке: "нехорошее сообщение об ошибке". Так что я на этом сразу же и остановился, никаких следующих разов и не нужно.
Плюс к этому, так как я не знаю, как работал компилятор, в #56 я указал конкретно, что оно не просто плохо, но ещё и не на то место.

VD>Да. Очевидно. Очевидно, что человек в компиляторе ничего не понимает, но пытается чего-то там предвидеть.


Я про внутренности компилятора ни слова не сказал. А где должна быть ошибка любому пользователю компилятора ясно, если он не погряз в дебрях условностей.

FDS>>то это — описание проблемы. Или для тебя ошибка не на той строке — это не проблема?


VD>Отвечаю последний раз. Это твои домыслы. По текущей логике работы компилятора ошибка на той строке, что нужно.


Так любой дефект можно убрать: "по текущей логике САУ здесь атомный реактор взрывается — это не дефект".

VD> Компилятор не может знать в какой из веток был возвращен неверный тип.


1. Это было учтено при написании дефекта #56, где я изложил всё подробнее
2. В данном случае вполне мог знать, и твой новый алгоритм даже должен это понять, насколько я его понял.

FDS>>Далее в #56 я указал, что компилятор возвращает мне не тот тип, которым может быть if. Это тоже не проблема?


VD>Ага проблема твоего понимания.


Понимания чего?
Это проблема твоего понимания, что то "как работает компилятор" не есть то, что однозначно хорошо.

FDS>>Какие ещё домыслы и предположения? Это компилятор так пишет, для него if возвращает int * int * int.

FDS>>Читать надо внимательно

VD>Ага. Пишет. У него алгоритм такой. Это не ошибка.


"по текущей логике САУ здесь атомный реактор взрывается — это не дефект". Ну да, у неё алгоритм такой, а то, что кто-то говорит, что это не так, просто ламер.

VD>Ну, а то что сообщение не внятное — это отдельный вопрос. Никак не связанный с алгоритмом.


Только что ты говорил, что я нефига не понимаю алгоритма, и тут же, что вопрос этот не связан с алгоритмом. Ты уж определись.

VD> И путей решения проблемы тут несколько. Один из них — понять что происходит тебе.


И? От этого сообщение станет внятнее, а компилятор — умнее?

VD> Другой усложнить алгоритм (что может быть чревато другими проблемами), изменить сообщение чтобы оно давало больше информации.


VD> Там, кстати, еще hint выдается, которые подсказывает что происходит. Но ты его смело проигнорировал.


Он подсказывает ровно то же, что и само сообщение об ошибке. Естественно, всё поняв из сообщения об ошибке, я не стал дальше читать никаких хинтов — зачем мне на что-то ещё тратить время, если я вижу, где ошибка?
Re[4]: Влад, ты что хамишь, а?
От: FDSC Россия consp11.github.io блог
Дата: 31.08.11 07:04
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Почему не может? Вроде как может. Но если даже не может, то это даже хоршо.


Не может

VD>Главное, что он может добавить комментарий в котором разяснить свою позицию (или связаться с админом по другим каналам).


Но он не знает, прочтёт ли кто-то этот комментарий после закрытия дефекта. Особенно если учесть, что сам по себе дефект был закрыт с бессмысленной и оскорбительной формулировкой.


FDS>>Тем более, если речь идёт о закрытии бага, который содержал описание "в котором трудно было что-то понять", судя по твоим же словам. Такие баги надо уточнять, благо ответы приходят на почту.


VD>Если был бы внятный ответ, то открыли бы.


Внятный ответ на бессодержательное сообщение? И я его должен постить в пустоту, не зная, будет он прочтён или нет?

VD>Это не проблема. Или завели бы другой issuse в котором уже было бы описано все правильно.


Ну я и завёл другой issue, чтобы на него обратили внимание, и описал там подробнее. Но его тоже закрыли не дожидаясь от меня никакой реакции.

VD>Тут еще вот что нужно понимать. Issuse-ы используются для формирования лога изменений в инсталляторах и как средство слежения за текущим состоянием проекта. По сему невнятной фигни в них быть не должно. Открытые issuse-ы должны отражать список проблем которые мы намереваемся решить. А закрытые и помеченные специальными тегами являются информацией о проделанной работе.


Это ваш неверный способ использования issue как списка todo, т.к. вы не привыкли, что к вам приходят сторонние пользователи и постят баги.
Очередной нонсенс, вызванный чувством собственности к языку.

FDS>>Если issue закрывают те, кто чинит ошибку, то у постера должно быть открыто право на reopen, т.к. именно и только постер может окончательно заключить, исправлена ошибка или нет.


VD>Ну, вот совсем недавно был случай. Починил я баг и закрыл его, так как считал, что все ОК. Но автор issuse-а обнаружил, что есть определенные случаи где баг все же проявляется. Он написал об этом соответствующее сообщение и я переоткрыл issuse.


Этот алгоритм работы закрытий-переоткрытий совершенно не очевиден человеку, который хоть сколько нибудь работал с багтрекерами в реальных проектах. Его надо описывать, чтобы ему можно было следовать.

VD>В твоем случае все будет несколько иначе. Так как сообщение совршенно не внятное, то будет создан новый issuse. Вопрос только какой. Если примем решение принять измененный алгоритм
Автор: VladD2
Дата: 29.08.11
, то создадим issuse-Фича-реквест описывающий этот алгоритм. В нем уже сошлемся на твой issuse, как на смежный. Если, же алгоритм окажется отклонен, то просто исправим сообщение об ошибке, и место его дислакации. При этом будет создан другой issuse, в котором будет описана проблема и принятое решение.


Безграмотное и нелогичное использование багтрекера, с какой стороны не посмотри.
В данном случае, если уж issue не внятный, его надо прояснить и закрыть, открыв два других, или отредактировать первоначальную версию, или открыть два других со перекрёстными ссылками, где всё внятно описано.

Если мы создаём вместо него другой issue, то он должен не отражать то, что "принято" или "не принято", а то, что должно быть (в данном случае, дефект на сообщение и фич-реквест на алгоритм вывода типов). Если алгоритм не будет принят, то issue по алгоритму должен быть отклонён, а по изменению сообщения об ошибке — исправлен и закрыт. При этом количество issue остаётся всегда одним и тем же, так как это issue определяют, что будет делаться, а не факт того, что что-то сделано или не сделано определяет наличие issue.

VD>В любом случае нам нужно полноценное описание чтобы те кто получит новую версию могли понять, что же за проблема была, и как ее устранили.


Согласен.

FDS>>Влад, я пользователь, и у меня свои проблемы. Куча других пользователей вообще плюёт на ошибки и пользуется бажным ПО годами, ленясь написать хоть что-то.


VD>Никто ни на что не плюет.


Плюют, и очень часто.

VD> Ну, не по-твему немного. Ничего страшного. Ты сам в этом виноват.


В том, что баги есть в компиляторе, issue используется извращёнными методами, а пользователям хамят — виноват явно не я.

VD>Иди сходи на багтреккеры МС. Погляди как там дела осбтоят. Там тебе вежливо ответят, что твое мнение услышано и точно так же закроют запись, только при этом ничего не объяснят.


Влад, у меня есть опыт постинга в Microsoft сообщений о багах. Там вежливо благодарят за найденный баг, если не поняли, переспрашивают, и указывают, что он будет исправлен в новом релизе, а не хамят и чего-то закрывают с сообщениями, что я нефига не понимаю.

VD>>>Если issue является непродуманным, ошибочным или того хуже, автору задаются наводящие вопросы. Если он не отвечат на них в течении какого-то времени, то issue закрывается с пометкой "Not a bug".


FDS>>Влад, мне никаких вопросов никто не задавал.


VD>О, как? А это что?


Это уже вопрос на второй дефект, причём он сразу был после этого закрыт, причём после этого я эту тему и открыл — т.е. ответ на этот вопрос разработчикам с моей стороны поступил. Поступил через форум, т.к. использование багтрекера разработчиками неадекватно.

FDS>>Влад, если поведение закрывающего неадекватно,


VD>Не тебе судить о поведении закрывающего.


Очень даже мне судить. Благо и сам баги закрывал, и заводил.

VD>Считаешь, что он ошибся — добавь сообщение в ту же тему.


Данный шаблон поведения не очевиден, мало того, я отказался от этого шаблона, т.к. в большинстве систем багтрекинга он был бы просто забыт.

VD>Или создай тему на форуме. Тут еще не было случаев когда кого-то игнорировали.


В итоге пришлось создать.

VD>А вот истерик и обвинений — не надо.


Истерик я тут не вижу, а вот обвинения здесь вполне уместны, т.к. поведение в багтрекере разработчиков неадекватно и оскорбительно.
Re[4]: Влад, ты что хамишь, а?
От: FDSC Россия consp11.github.io блог
Дата: 31.08.11 07:25
Оценка:
Здравствуйте, YF, Вы писали:


YF>VladD2, разумеется, это увидел, оставил комментарий и закрыл его, справедливо полагая, что hardcase тебе уже все сказал. Другое дело, что тебя этот ответ не устроил.


В том то и дело, что пользователь вряд ли будет просто так открывать ещё один дефект. И "справедливо полагать" надо было то, что что-то не так и что-то не сказано, а пользователь почему-то не продолжил работу в предыдущем дефекте (видимо, были какие-то препятствия этому, о чём надо было задать вопрос). Затем прочитать оба дефекта и сделать нужные действия.

YF>Проблема в том, что закрывают issue и не ожидают обратной реакции того, кто issue создал.


Мало того, закрывают не разобравшись что к чему. Легкомысленно относятся к багтрекеру.

YF>Насчет хамства- ну побойся Б-га, он же совершенно бескорыстно возится тут со всеми, как с детьми малыми, развернуто отвечая на все вопросы и ничего не требуя взамен.


Хамства это не отменяет. В своё время я тоже кое с кем совершенно бескорыстно возился и был наделён полномочиями казнить и миловать, так что опыт есть. И если кто-то говорил, что я что-то не так сказал, мы это обсуждали с другим, таким же бескорыстным, человеком и, если приходили к тому, что я не прав, я официально извинялся и менял своё поведение.
Re[6]: Влад, ты что хамишь, а?
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 31.08.11 08:12
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Полная чушь.

FDS>Наглая ложь.
FDS>А это уже хамство.

Сбавляем обороты

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[4]: Замечания
От: FDSC Россия consp11.github.io блог
Дата: 31.08.11 08:45
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Это. Ты бы лучше чем тратить свое и чужое время,


Это не лучше, это само собой.


VD> попробовал бы Новый алгоритм типизации match
Автор: VladD2
Дата: 29.08.11
. Возможно он удовлетворит тебя.


Собственно, сам алгоритм, видимо, работает, однако сообщения об ошибках плохие.


public c(a: int): int
{
    if (a == 1)
        ()
    else
        (1);
}


Данный код выдаёт ошибку "error : expected int, got void in function return value: void is not a subtype of int"
на строке с объявлением заголовка функции
Ожидается, что сообщение будет выдано на ветку. Фраза в данном случае устраивает

Аналогично

public c(a: int): int
{
    def b()
    {
        if (a == 2)
            1
        else
           ();
    }

    if (a == 1)
        b()
    else
        (1);
}


выдаёт ошибку "error : expected int, got void in computation branch: void is not a subtype of int"
на строке "if (a == 2)",
хотя в самом сообщении явно речь идёт о "computation branch"

Далее


public c2(a: int): void
{
    def b()
    {
        if (a == 2)
            1
        else
           ();
    }

    if (a == 1)
        b()
    else
        (1);
}

Выдаёт ошибку на "if (a == 2)" и на ветвях, что в принципе, вполне приемлемо. Причём ошибка не самого понятного для непосвящённого содержания:
"error : typing fails on delayed typing of conditional expression computation branchs"

Конечно, здесь идёт вложенный match, так что алгоритм в данной редакции и не должен понимать что как, но сообщение об ошибке лучше поправить на более понятное, если есть возможность.

Такой код
public c2(a: int): void
{
    def b()
    {
        if (a == 2)
            1
        else
           ();
    }

    if (a == 1)
        b()
    else
        ();
}

вызывает вполне нормальное предупреждение


Плюс, не смог собрать сборку с помощью DevBuildForCommit.cmd . Почему-то лезет в каталог C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v9.0 , он существует, но 2008-ой студии на компе у меня нет и никогда не было и он не находит там файла с целями для билда. Пришлось дособирать DevBuildQuick-4.cmd, но вроде после этого всё равно алгоритм работает новый, насколько я могу судить.
Стало гораздо удобнее.
Re[5]: Замечания
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.08.11 17:02
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Собственно, сам алгоритм, видимо, работает, однако сообщения об ошибках плохие.


FDS>
FDS>public c(a: int): int
FDS>{
FDS>    if (a == 1)
FDS>        ()
FDS>    else
FDS>        (1);
FDS>}
FDS>


FDS>Данный код выдаёт ошибку "error : expected int, got void in function return value: void is not a subtype of int"

FDS>на строке с объявлением заголовка функции
FDS>Ожидается, что сообщение будет выдано на ветку. Фраза в данном случае устраивает

Некрасиво, конечно, но закономерно. Там ведь приведение типов идет.

Попробую подхимичить. Главное чтобы от этого не прибавилось тормозов.

FDS>Плюс, не смог собрать сборку с помощью DevBuildForCommit.cmd . Почему-то лезет в каталог C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v9.0 , он существует, но 2008-ой студии на компе у меня нет и никогда не было и он не находит там файла с целями для билда. Пришлось дособирать DevBuildQuick-4.cmd, но вроде после этого всё равно алгоритм работает новый, насколько я могу судить.

FDS>Стало гораздо удобнее.

DevBuildForCommit.cmd собирает версию для 2008-й студии.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Влад, ты что хамишь, а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.09.11 17:44
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Наглая ложь.

FDS>А это уже хамство.

Хамишь тут ты. То что с твоим мнением не согласны нисколько не означает что тебе хамят.

ЗЫ

Больше я на подобные сообщения отвечать не буду. Буду отвечать только на технические вопросы вроде этого
Автор: FDSC
Дата: 31.08.11
.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Замечания
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.09.11 04:06
Оценка:
Здравствуйте, FDSC, Вы писали:

FDS>Собственно, сам алгоритм, видимо, работает, однако сообщения об ошибках плохие.


Переработал алгоритм еще раз. К сожалению, без ломающих изменений не обошлось. Новый алгоритм мне нравится больше, но он дал некоторые побочные эффекты. В сложных случаях может потребоваться аннотация типов. Но, зато, алгоритм стал умнее. Поддерживает приведения типов и "берет" типы из внешних выражений.


FDS>
FDS>public c(a: int): int
FDS>{
FDS>    if (a == 1)
FDS>        ()
FDS>    else
FDS>        (1);
FDS>}
FDS>


FDS>Данный код выдаёт ошибку "error : expected int, got void in function return value: void is not a subtype of int"

FDS>на строке с объявлением заголовка функции
FDS>Ожидается, что сообщение будет выдано на ветку. Фраза в данном случае устраивает

Фразу я кое-где поменял на "Cannot implicitly convert type 'А' to 'Б'.".

Все приведенные примеры теперь выдают вменяемые сообщения. Ну, по крайней мере, на мой взгляд .

Просьба протестировать что получилось.

ЗЫ

Любопытные могут наблюдать новое поведение компилятора в изменениях тестов.
здесь и здесь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.