Здравствуйте, VladD2, Вы писали:
VD>Собственно сделать это не сложно. Но есть три вопроса: VD>1. Какой синтаксис скобок выбрать для этого? Например, можно использовать скобки состоящие из двух символов (на подобии тех, что используются в квази-цитировании) — <( )>, [< >] или скобки в сочетании с некоторым символом: <% %>, <| |> и т.п. Скобки вида ([ ]) и [( )] лучше не использовать, так как они конфликтуют с имеющимися конструкциями.
Я бы предпочел синтаксис из скалы. Индексаторы это свойства с параметрами, а параметры указываютсяя в скабках. В васике тоже используются скобки и ничего плохого в это нет. Кроме того часто бывает нужно заменить вызов индексатора на вызов функции и тогда приходится менять квадратные скобки на круглые, а так не нужно будет.
VD>2. Нужно ли делать это до выпуска версии 1.0 или отложить смену синтаксиса до будущей версии?
Лучше до, чтобы не заботиься об обратной совместимости.
VD>3. Делать ли такую смену в виде ключа компиляции допускающего как квадратные скобки с точкой (как принято сейчас), так и новые скобки?
Здравствуйте, hi_octane, Вы писали:
_>Но неоднозначности появляются только в каких-то особых случаях, ведь так?
Неоднозначности или есть, или нет.
Конструкция: x[y] может рассматриваться или как тип с параметром типа, или как индекстатор.
В принципе вывод типов позволят понять, что за конструкцию мы разбираем. Но для этого приходится производить спекулятивные типизации.
Спекулятивная типизация — это попытка типизировать некое выражение как нечто на что оно похоже.
Общий алгоритм можно опсать так:
TypeExpr(expr : PExpr) : TExpr
{
match (TryTypeAsType())
{
| Some => TypeAsType()
| None =>
match (TryTypeAsLocalRef())
{
| Some => TypeAsLocalRef()
| None => TExpr.Error()
}
}
}
По большому счету это работает.
Но если углубиться, то можно заметить следующие проблемы:
1. Ухудшенная реакция на ошибки (по сравнению с однозначной грамматикой).
Скажем если у нас есть x[y] и программист ошибается в написании y или x, то типизация завершается неудачей и производится попытка интерпретировать выражение другим образом. Предположим программист подразумевал под x[y] выражение индексации, но компилятор может выдать сообщение об ошибке вроде "'y' не верный тип". Это введет программиста в заблуждение. Или он может выдать слишком общее сообщение, что тоже плохо.
2. Автодополнение при вводе. Тут возникают проблемы того же характера. Скажем программист опять же набрал x[y|] ("|" — это место в котором программист захотел дополнить идентификатор). Предположим, что с "y" начинаются тип "Yyy" и локальная переменная "yxz". В режиме автодополнения спекцляции бесполезны. Идентификатор ведь не полный. Если первой спекуляцией будет TryTypeAsType, то будет возращен список типов, а список локальных переменных возвращен не будет.
_> Может можно сделать простую свёртку с простыми угловыми скобками, а если уж нарисовалась неоднозначность и ничерта не компилируется — то пусть программист использует тот же символ @ для устранения неоднозначностей который был в C#? Показывая этим @< что имеется ввиду не пользовательский оператор <, а именно угловая скобка в объявлении типа.
1. Символ "@" уже используется в языке и делает любую последовательность символов идентификатором.
2. Мне не нравится сама идея применения чего-то в отдельных случаях. Это делает язык сложнее, забивая его не нужными частностями.
_>Я так ратую за простые треугольные скобки лишь потому что у Nemerle основной конкурент — не F#, не хаскель и не Скала, а именно C#. И для C# программиста знакомого Nemerle должен выглядеть эдаким шарпом на стероидах, в котором можно всё тоже самое только лучше и проще.
Ну, дык под "можно" наверно понимаеются возможности языка, а не синтаксическая идентичность. Так?
В немерле не мало отличий. Дух шарпа соблюден. На немерле можно писать как на шарпе на стеройдах. А уж буква...
Буквой приходится поступаться. На мой взгляд менее неоднозначная грамматика делает
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Блудов Павел, Вы писали:
БП>Уверен, что лет через двадцать, когда люди будут знать только две кодировки, utf-8 и utf-32, можно будет использовать для конструкций языка хоть иероглифы. А сейчас это будут по большей части грабли.
И utf-8, и utf-32 — это одна кодировка — Юникод. Просто разные форматы ее записи в файл.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jenyavb, Вы писали:
J>Здравствуйте, Воронков Василий, Вы писали: ВВ>>А что за проблемы с юникодом у notepad++? Сцинтилла вполне себе дружит с юникодом J>С каких это пор?
Ну вообще с давних. Я вот прекрасно редактирую файлы в UTF8 в Programmers Notepad.
Здравствуйте, jenyavb, Вы писали:
J>Здравствуйте, VladD2, Вы писали:
VD>>Собственно сделать это не сложно. Но есть три вопроса: VD>>1. Какой синтаксис скобок выбрать для этого? Например, можно использовать скобки состоящие из двух символов (на подобии тех, что используются в квази-цитировании) — <( )>, [< >] или скобки в сочетании с некоторым символом: <% %>, <| |> и т.п. Скобки вида ([ ]) и [( )] лучше не использовать, так как они конфликтуют с имеющимися конструкциями.
J>Я бы предпочел синтаксис из скалы. Индексаторы это свойства с параметрами, а параметры указываютсяя в скабках. В васике тоже используются скобки и ничего плохого в это нет. Кроме того часто бывает нужно заменить вызов индексатора на вызов функции и тогда приходится менять квадратные скобки на круглые, а так не нужно будет.
Хочу еще добавить, что для типов-аргументов любой синтаксис кроме A<T> и A[T] будет в некоторой степени неестественным. А вот для индексации массивов arr(x) = 1 будет почти таким же естественным как arr[x] = 1.
J>Я бы предпочел синтаксис из скалы. Индексаторы это свойства с параметрами, а параметры указываютсяя в скабках. В васике тоже используются скобки и ничего плохого в это нет. Кроме того часто бывает нужно заменить вызов индексатора на вызов функции и тогда приходится менять квадратные скобки на круглые, а так не нужно будет.
Собственный синтаксис для индексаторов — это ещё и подсказка что в данном случае имеем доступ к коллекции или чему-то мимикрирующуему под коллекцию. Круглые скобки это более универсально, но в каждом конкретном случае придётся разбираться коллекция ли там под капотом, или имеем вызов функции, которая что-то считает и возвращает какое-то разовое значение. Т.е. снижается наглядность при чтении кода.
Здравствуйте, nikov, Вы писали:
N>Мне больше всего нравится, как сделано в Scala: типы-параметры [], вызов индексатора () N>Это очень логично, потому что вызов индексатора вполне можно представлять себе как вызов функции, аргументы которой — это индексы.
А типы-параметры вполне можно представлять как вызов индексатора семейства типов.
Собственно смысла в смене "тип-параметр vs индексатор" на "индексатор vs вызов функции" нет, в контексте этой ветки.
N>Хочу еще добавить, что для типов-аргументов любой синтаксис кроме A<T> и A[T] будет в некоторой степени неестественным. А вот для индексации массивов arr(x) = 1 будет почти таким же естественным как arr[x] = 1.
В то время когда публике представляли C# 1.0 и VB.NET я читал бумажную статью о том что глядя на конструкцию X = y мы не знаем в реальности что она делает ни в C++ ни VB classic. Статья была красивая (жаль сейчас не найти), и цель её — была объяснить тем кто писал на C++ почему в C# не сделали переопределния оператора =, и ещё кучу всего. Глядя на конструкцию x = MyClass.MyProp(i); — я точно также не могу понять — что она делает, будет ли она что-то вычислять или вернёт готовое значение, стоит ли вообще пытаться писать MyClass.MyProp(i) = x, можно ли делать по ней select, и т.п. В общем одни минусы, при том что единственный плюс это то что синтаксис унифицирован внутри самого языка, и сделан подобным какому-то другому языку на какой-то другой платформе... не маловато-ли плюсов?
Введение () для индексаторов, это имхо такой же шаг назад на те же грабли как и возврат к set/get методам вместо свойств. И то и другое — синтаксический сахар к методам. Но этот сахар сделали что лучше передать смысл конструкций.
Здравствуйте, nikov, Вы писали:
N>Хочу еще добавить, что для типов-аргументов любой синтаксис кроме A<T> и A[T] будет в некоторой степени неестественным. А вот для индексации массивов arr(x) = 1 будет почти таким же естественным как arr[x] = 1.
Я как старый сишник считаю, что синтаксис arr(x) тоже не естественный.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Приветствуются любые мысли!
Еще есть вариант, как сделано в Java. Используются угловые скобки, но в тех случаях, когда при вызове метода type inference не сработал, и их надо указывать явно, они пишутся до имени метода, и грамматических неоднозначностей не возникает.
_>>Но неоднозначности появляются только в каких-то особых случаях, ведь так?
VD>Неоднозначности или есть, или нет. VD>Конструкция: x[y] может рассматриваться или как тип с параметром типа, или как индекстатор. VD>В принципе вывод типов позволят понять, что за конструкцию мы разбираем. Но для этого приходится производить спекулятивные типизации.
Я имел ввиду неоднозначности с <T>. Но за столь развёрнутый ответ спасибо — увы, наверное кроме двух-трёх человек никто толком не может рассказать насколько реализуемы и однозначны те или иные виды объявлений из всего фейерверка бурлесков который уже напредлагали в голосовании.
_>> Может можно сделать простую свёртку с простыми угловыми скобками, а если уж нарисовалась неоднозначность и ничерта не компилируется — то пусть программист использует тот же символ @ для устранения неоднозначностей который был в C#? Показывая этим @< что имеется ввиду не пользовательский оператор <, а именно угловая скобка в объявлении типа.
VD>1. Символ "@" уже используется в языке и делает любую последовательность символов идентификатором. VD>2. Мне не нравится сама идея применения чего-то в отдельных случаях. Это делает язык сложнее, забивая его не нужными частностями.
Так если эта частность будет всплывать только в 1-м случае из 10 и в конструкции вида X(T<Y, Z>) или какой-то подобной пользователя заставят написать X(T@<Y, Z>) — никто нам и слова не скажет. Да и лексер насколько я помню и так переписывать надо для in-line поддержки linq.
VD>Ну, дык под "можно" наверно понимаеются возможности языка, а не синтаксическая идентичность. Так?
Для человека который до этого писал только на шарпе — любая невозможность писать тем способом каким он привык, или уже знает — это те самые -100 баллов про которые часто пишут разработчики компилятора C# в своих блогах. Поэтому, имхо, там где возможно, нам стоит быть ближе и доступнее тем кто начинает писать на Nemerle.
Здравствуйте, hi_octane, Вы писали:
_>Для человека который до этого писал только на шарпе — любая невозможность писать тем способом каким он привык, или уже знает — это те самые -100 баллов про которые часто пишут разработчики компилятора C# в своих блогах. Поэтому, имхо, там где возможно, нам стоит быть ближе и доступнее тем кто начинает писать на Nemerle.
Этот вопрос решается по другому. Можно сделать поддержку C#-синтаксиса, так чтобы в проект можно было бы просто включать C#-файлы.
Это даже не очень сложно сделать. Я планировал это сделать до релиза, но к сожалению задержал Вольфхаунд который хотел реализовать PEG-парсер в виде макроса немерле, но так до сих пор его и не реализовал.
Будет построитель парсеров, обязательно сделаю.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Этот вопрос решается по другому. Можно сделать поддержку C#-синтаксиса, так чтобы в проект можно было бы просто включать C#-файлы.
И что, вы собираетесь делать честную поддержку сишарповских member lookup, type inference и overload resolution?
Здравствуйте, nikov, Вы писали:
N>И что, вы собираетесь делать честную поддержку сишарповских member lookup, type inference и overload resolution?
Не. На практике это никому и даром не нужно. В "гражданском" коде здоровые люди не пишут хитровылюбленных перегруженных методов. Более мощный вывод типов вообще не помеха. Так что реализовывать точную копию стандарта нет смысла.
У нас другая задача. Точнее их две:
1. Упростить перевод проектов на Nemerle. Люди смогут брать готовые C#-проекты и развивать их с помощью Немерле. Кроме того появится возможность заимствования из других C#-проектов. Ну, и за одно решится проблема "непривычности" и психологические проблемы.
2. Использовать дизайнеры и генераторы кода рассчитанные на C#.
ЗЫ
Что касается планов по второй версии (или это будет отдельный язык... скажем "N"), то возможно в ней реализуем некоторые настройки которые позволят эмулировать другие языки не только на синтаксическом уровне, но и на семантическом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hi_octane, Вы писали:
_>В то время когда публике представляли C# 1.0 и VB.NET я читал бумажную статью о том что глядя на конструкцию X = y мы не знаем в реальности что она делает ни в C++ ни VB classic. Статья была красивая (жаль сейчас не найти), и цель её — была объяснить тем кто писал на C++ почему в C# не сделали переопределния оператора =, и ещё кучу всего. Глядя на конструкцию x = MyClass.MyProp(i); — я точно также не могу понять — что она делает, будет ли она что-то вычислять или вернёт готовое значение, стоит ли вообще пытаться писать MyClass.MyProp(i) = x, можно ли делать по ней select, и т.п.
А теперь замени круглые скобки на квадратные — что изменилось? Да и не стоит забывать что в основном используются только дефолтные индексаторы.
_> В общем одни минусы, при том что единственный плюс это то что синтаксис унифицирован внутри самого языка, и сделан подобным какому-то другому языку на какой-то другой платформе... не маловато-ли плюсов?
Основной плюс — это то, что можно будет использовать естественные [] вместо всяких узвращений.
... << RSDN@Home 1.2.0 alpha 4 rev. 1325>>
Re[13]: Предлагаю подобрать скобки для типов...
От:
Аноним
Дата:
16.12.09 07:43
Оценка:
Здравствуйте, VladD2,
А нельзя ли сделать вообще без всяких скобок:
Map int int foo;
?
(если глупость, не пинайте, я немерле пока не знаю, но планирую)
J>А теперь замени круглые скобки на квадратные — что изменилось?
Ну сравни
x = MyClass.X(a, b);
с
x = MyClass.X[a, b];
И что изменилось? Как программист в случае индексации [] я получаю подсказку что имеет место обращение к коллекции, которая как-то индексируется. Что при повторном обращении с тем же набором индексов [a, b] — я получу тот же самый элемент что и в прошлый раз (в случае ссылочных типов — так и reference equal элемент), что я могу по этой коллекции прокатить foreach или select, и т.п. Повторюсь — индексаторы это костыль к методам, но не больший костыль чем свойства. Да и есть уже один язык который подвергся тотальной унификации и теперь сидит в очень узкой нише — lisp. Лиспу никаких скобок кроме круглых не надо, но и писать на нём готовы считанные люди.