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

def x = 5;
def y = "hello, ";

def quote = <[ $y + ($x).ToString() ]> // == <[ $(PExpr.Literal(Literal.Integer(5))) + ($(PExpr.Literal(...))).ToString() ]>

Теоретически, особых сложностей возникнуть не должно.

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

C>Было бы круто, если бы при конструировании квазицитат можно было использовать значения напрямую как литералы:
C>

C>def x = 5;
C>def y = "hello, ";

C>def quote = <[ $y + ($x).ToString() ]> // == <[ $(PExpr.Literal(Literal.Integer(5))) + ($(PExpr.Literal(...))).ToString() ]>
C>

C>Теоретически, особых сложностей возникнуть не должно.

def quote = <[ $(y : string) + $(x : int).ToString() ]>

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

C>Было бы круто, если бы при конструировании квазицитат можно было использовать значения напрямую как литералы:

C>

C>def x = 5;
C>def y = "hello, ";

C>def quote = <[ $y + ($x).ToString() ]> // == <[ $(PExpr.Literal(Literal.Integer(5))) + ($(PExpr.Literal(...))).ToString() ]>
C>

C>Теоретически, особых сложностей возникнуть не должно.

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

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

VD>

VD>def quote = <[ $(y : string) + $(x : int).ToString() ]>
VD>

О.о работает.. ну вот, век живи, век учись

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

VD>>

VD>>def quote = <[ $(y : string) + $(x : int).ToString() ]>
VD>>

C>О.о работает.. ну вот, век живи, век учись

Буквально же недавно это описывал здесь

Автор(ы): Чистяков Владислав Юрьевич
Дата: 22.09.2011
Данная часть посвящена макросам Nemerle.

.

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

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

Сплайс ожидает PExpr (или специальные типы для цитат с префиксами). При этом сплайсы разруливаются на стадии парсинга. Так что сделать в текущей реализации автопределение не просто.

Можно попробовать поступить как в случае с цитатой типа typed. Там парсер вставляет вызов перегруженного метода, который может принимать как TypeVar, так и TExpr. Можно попробовать провернуть такой же фокус и с литералами и PExpr. Но это обязательно замедлит компиляцию сплайсов, так как разрешение перегрузки (особенно массовое) — это самое узкое место в типизаторе Nemerle 1.x.

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

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

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

VD>Сплайс ожидает PExpr (или специальные типы для цитат с префиксами). При этом сплайсы разруливаются на стадии парсинга. Так что сделать в текущей реализации автопределение не просто.

VD>Можно попробовать поступить как в случае с цитатой типа typed. Там парсер вставляет вызов перегруженного метода, который может принимать как TypeVar, так и TExpr. Можно попробовать провернуть такой же фокус и с литералами и PExpr. Но это обязательно замедлит компиляцию сплайсов, так как разрешение перегрузки (особенно массовое) — это самое узкое место в типизаторе Nemerle 1.x.

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

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

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

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

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

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

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

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

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

CU>Ну вот сообщение об ошибке можно и исправить,

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

CU>а если делать неявные раскрытия сплайсов, без подсказок, да еще на поздних этапах типизации, это может дать еще больше непонятных ошибок.

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

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

В компиляторе уже есть место где используется перегрузка. Сплайс $(x : typed) может принимать как значение типа TExpr, так и TypeVar.
Ни одной жалобы (на это) я еще не видел.
Так что подозреваю, что кроме замедления компиляции сплайсов других проблем это не вызовет.

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

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

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

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

VD>В компиляторе уже есть место где используется перегрузка. Сплайс $(x : typed) может принимать как значение типа TExpr, так и TypeVar.
VD>Ни одной жалобы (на это) я еще не видел.
VD>Так что подозреваю, что кроме замедления компиляции сплайсов других проблем это не вызовет.

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

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

CU>в типизаторе всего кода из квазицитаты, надо дополнительно анализировать, прежде чем генерировать код, который будет создавать объекты квазицитат

В том то и дело, что квази-цитаты не типизируются отдельно. Они сначала трансформируются в АСТ (производится лифтинг), а уже потом получившийся код типизируется.

CU>ну хорошо, но я думаю если и делать то оставлять оригинальный вариант, с явным указанием подсказки и этот вариант сделать надстройкой.

Да там не нужно что-то особенное делать. Весь трюк заключается в том, что в конкретные конструкторы PExpr нужно добавить перегрузки принимающие конкретные типы (string, int, long, ...). Только нужно хорошенько продумать какие конструкторы расширять, чтобы не появлялось странных эффектов. Старый синтаксис это не затронет ни разу.

CU>При этом надо оставить текущее дерево то есть PExpr.Literal, кстати не помешает ли это анализировать код, когда указан сразу PExpr.Literal то его легко можно распознавать, а когда что то с отложенной типизацией, то это сложно. И что ты предлагаешь в качестве решения?

Еще раз повторяю — изменять АСТ для этого не потребуется. Но увеличение перегрузок замедлит типизацию полученного, из квази-цитат, АСТ.

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

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

CU>>в типизаторе всего кода из квазицитаты, надо дополнительно анализировать, прежде чем генерировать код, который будет создавать объекты квазицитат

VD>В том то и дело, что квази-цитаты не типизируются отдельно. Они сначала трансформируются в АСТ (производится лифтинг), а уже потом получившийся код типизируется.

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

VD>Да там не нужно что-то особенное делать. Весь трюк заключается в том, что в конкретные конструкторы PExpr нужно добавить перегрузки принимающие конкретные типы (string, int, long, ...). Только нужно хорошенько продумать какие конструкторы расширять, чтобы не появлялось странных эффектов. Старый синтаксис это не затронет ни разу.

VD>Еще раз повторяю — изменять АСТ для этого не потребуется. Но увеличение перегрузок замедлит типизацию полученного, из квази-цитат, АСТ.

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

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

CU>ну замедление не так существенно мне кажется, тот кто хочет использовать такой вариант будет и платить за это решение

На строках, в сплайсах вида ..$x, это дало существенное замеделение.

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

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

CU>>ну замедление не так существенно мне кажется, тот кто хочет использовать такой вариант будет и платить за это решение

VD>На строках, в сплайсах вида ..$x, это дало существенное замеделение.

Надо сделать и реально оценить, каковы изменения в производительности, насколько существенные по разным видам литералов.

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

C>Было бы круто, если бы при конструировании квазицитат можно было использовать значения напрямую как литералы:

C>

C>def x = 5;
C>def y = "hello, ";

C>def quote = <[ $y + ($x).ToString() ]> // == <[ $(PExpr.Literal(Literal.Integer(5))) + ($(PExpr.Literal(...))).ToString() ]>
C>

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

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

VD>Реализовал через перегрузки. Просьба протестировать не замедлилась ли компиляция.

Отчет от Nemerle.Statechart, время компиляции генератора (которые использует литералы в квазицитировании):
на старом варианте:
12.63
12.48
12.47

на новом варианте (с улучшенными сплайсами):
12.53
12.46
12.49

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

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

CU>В двух случаях показания лучше чем у старого варианта,

Это погрешности измерения. Быстрее оно стать не должно было.

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

ОК. Оно уже в мастере.