А⚙
Причём количество символов
# с каждой стороны может быть произвольным (в том числе и ноль), лишь бы было одинаковым с каждой стороныSize: a a a
2021 April 07
AT
Объективно слегка похуже — больше синтаксического мусора. 😒
[
Ну, каждому своё.
У джавы вон == для Integer не работает нормально - никто не жалуется.
У джавы вон == для Integer не работает нормально - никто не жалуется.
D
В окамле можно выбирать, что запрещено писать внутри строки. В литерале
{regex|[A-Za-z]+|regex} допустимо использовать все, кроме |regex}.DF
Я вас удивлю но в перле было так же
D
да, here document аналогично работает
ДК
Типичная проблема всех этих экранирований - для многострочных текстов не понятно что делать с отступами и переводами строк в начале и в конце. И приходится изгаляться, чтобы лишнее не попало в строку.
[
.trim
.replace "/n +" with "/n"
.replace "/n +" with "/n"
AK
Если текст больше пары строчек и в нем важны пробелы (html-шаблон?), то его лучше вынести в отдельный файл и считать в рантайме, тем самым решив все проблемы с экранированием и заодно получив для него полноценный ide experience
ДК
Есть много языков, где пробелы и переводы строк влияют на результат.
Так можно докатиться до того, что вообще все строки в отдельные файлы выносить. Это не очень практично во многих случаях. Ну и гораздо лучше вообще не иметь проблемы, чем иметь и проблему и и её решение со своими трейдофами.
Так можно докатиться до того, что вообще все строки в отдельные файлы выносить. Это не очень практично во многих случаях. Ну и гораздо лучше вообще не иметь проблемы, чем иметь и проблему и и её решение со своими трейдофами.
M
Вопрос, а в каких языках / компиляторах используют linked-closure представление и конвертацию? Я так понял в v8 движке точно, для экономии памяти. Но если рантайм полагается на GC, то второй вариант только усугубляет положение и потребление памяти, разве нет?
AK
Я у себя в игрушечном языке так реализовал замыкания, потому что это казалось самым простым наивным способом
AK
Думаю что грамотнее было бы делать не всегда одну ссылку на скоуп на 1 выше, а прямые ссылки на каждый скоуп, переменные из которого используются в текущем, чтобы не было N переходов к родителю
h
если я правильно понял, то я также делал получается. Мне кажется так много где в pet проектах япов
ДК
Не только, ещё и для возможности изменения значения во внешнем скоупе.
M
Это CPS лямбды, там ничего не изменяется и не мутируется для free vars
ДК
Я про V8.
AT
Потребление памяти-то точно не выше, поскольку копирования (размножения) значений нет. Разве что в вырожденных случаях. Насчёт GC pressure из-за лишних ссылок "на глазок" сказать невозможно.
M
Вообще есть, так как корень списка не может быть собран сборщиком мусора пока на него ссылаются. В первом же случае они независимы и ортогональны хоть и избыточны в плане общих свободных переменных
M
Собственно читаю сейчас вот этот пейпер
https://www.cs.princeton.edu/~appel/papers/safe-closure.pdf
https://www.cs.princeton.edu/~appel/papers/safe-closure.pdf