Всем привет.

Работая над подсветкой и рефакторингом внутри $-строк (являющихся шорткатом для макроса sprint, а значит) я наткнулся на следующую проблему.

В Nemerle бывают строки следующих видов:
* "строка" – может содержать эскейп-последовательности.
* @"строка" – может содержать концы строк и удвоенную кавычку (интерпретируемую как одна ковычка).
* <#строка#> – может содержать концы строк.

Не трудно заметить, что префиксы и суффиксы строк могут быть разной длинны (один или два символа). Кроме того строки могут содержать символы интерпретируемые по-разному.

Когда макросу sprint (или любому другому) передается строка, то максимум что можно добиться – чтобы она передавалась, как PExpr.Literal(Literal.String(содержимое_строки)).
Здесь "содержимое_строки" – это уже преобразованная строка – без ограничителей и с замененными эескейп-последовательностями. Для @-строк удвоенные кавычки заменяются на одинарные (т.е. строка @"a""b" будет преобразована в строку a"b.
Макросы вроде sprint производят парсинг строки выделяя из них "активные зоны". Конкретно для sprint – это или содержимое скобок предваряемых символом $:
$(содержимое)
или имя переменной предваряемое все тем же $-ом:
$имя
Далее sprint передает "содержимое" парсеру. Чтобы парсер назначил верные локешноы ему надо задать верный начальный локешон. Но этому препятствует то, что мы не знаем исходное содержимое строки или какой-то другой информации позволяющие вычислить правильный локешон.

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

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

Можно решить проблему заложив в Literal.String кроме развернутой строки еще и исходную строку с ограничивающими кавычками. Однако даже это является проблемой.
Проблема в том, что PExpr и Literal используются в паттерн-мтчинге через квази-цитирование. Попытка добавить поле в Literal.String приводит к тому, что компилятор не собирается, так как паттерн-матчинг по квази цитатам не проходит. Возможно я что-то делаю не так. В общем, мне нужна ваша помощь.
Я, конечно, могу добавить поле в сам вариант Literal, но тогда оно будет торчать в любом литерале. Что наверно не здорово. Хотя может быть это и не смертельно. Ведь иметь текстовое представление для литералов тоже удобно. Например, для цифр это тоже может быть важно. Ведь число 123456 может быть в Nemerle записано как 123_456 и даже как 0x1E240.

В общем, ваши мысли и тем более помощь приветствуется!