Re: Предлагаю подобрать скобки для типов...
От: jenyavb  
Дата: 15.12.09 15:34
Оценка: 13 (2) +1
Здравствуйте, VladD2, Вы писали:

VD>Собственно сделать это не сложно. Но есть три вопроса:

VD>1. Какой синтаксис скобок выбрать для этого? Например, можно использовать скобки состоящие из двух символов (на подобии тех, что используются в квази-цитировании) — <( )>, [< >] или скобки в сочетании с некоторым символом: <% %>, <| |> и т.п. Скобки вида ([ ]) и [( )] лучше не использовать, так как они конфликтуют с имеющимися конструкциями.

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

VD>2. Нужно ли делать это до выпуска версии 1.0 или отложить смену синтаксиса до будущей версии?


Лучше до, чтобы не заботиься об обратной совместимости.

VD>3. Делать ли такую смену в виде ключа компиляции допускающего как квадратные скобки с точкой (как принято сейчас), так и новые скобки?


Тогда упрощения кода и вывода типов не получится.
... << RSDN@Home 1.2.0 alpha 4 rev. 1325>>
Re[8]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.12.09 15:35
Оценка: 1 (1)
Здравствуйте, 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 должен выглядеть эдаким шарпом на стероидах, в котором можно всё тоже самое только лучше и проще.


Ну, дык под "можно" наверно понимаеются возможности языка, а не синтаксическая идентичность. Так?
В немерле не мало отличий. Дух шарпа соблюден. На немерле можно писать как на шарпе на стеройдах. А уж буква...

Буквой приходится поступаться. На мой взгляд менее неоднозначная грамматика делает
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.12.09 15:37
Оценка:
Здравствуйте, Блудов Павел, Вы писали:

БП>Уверен, что лет через двадцать, когда люди будут знать только две кодировки, utf-8 и utf-32, можно будет использовать для конструкций языка хоть иероглифы. А сейчас это будут по большей части грабли.


И utf-8, и utf-32 — это одна кодировка — Юникод. Просто разные форматы ее записи в файл.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Предлагаю подобрать скобки для типов...
От: Воронков Василий Россия  
Дата: 15.12.09 15:44
Оценка: 8 (1)
Здравствуйте, jenyavb, Вы писали:

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

ВВ>>А что за проблемы с юникодом у notepad++? Сцинтилла вполне себе дружит с юникодом
J>С каких это пор?

Ну вообще с давних. Я вот прекрасно редактирую файлы в UTF8 в Programmers Notepad.
Re[2]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 15.12.09 15:45
Оценка: 1 (1)
Здравствуйте, jenyavb, Вы писали:

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


VD>>Собственно сделать это не сложно. Но есть три вопроса:

VD>>1. Какой синтаксис скобок выбрать для этого? Например, можно использовать скобки состоящие из двух символов (на подобии тех, что используются в квази-цитировании) — <( )>, [< >] или скобки в сочетании с некоторым символом: <% %>, <| |> и т.п. Скобки вида ([ ]) и [( )] лучше не использовать, так как они конфликтуют с имеющимися конструкциями.

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


Хочу еще добавить, что для типов-аргументов любой синтаксис кроме A<T> и A[T] будет в некоторой степени неестественным. А вот для индексации массивов arr(x) = 1 будет почти таким же естественным как arr[x] = 1.
Re[5]: Предлагаю подобрать скобки для типов...
От: Воронков Василий Россия  
Дата: 15.12.09 15:47
Оценка:
Здравствуйте, jenyavb, Вы писали:

ВВ>>А что за проблемы с юникодом у notepad++? Сцинтилла вполне себе дружит с юникодом

J>С каких это пор?

Собственно:
Re[2]: Предлагаю подобрать скобки для типов...
От: hi_octane Беларусь  
Дата: 15.12.09 15:48
Оценка:
J>Я бы предпочел синтаксис из скалы. Индексаторы это свойства с параметрами, а параметры указываютсяя в скабках. В васике тоже используются скобки и ничего плохого в это нет. Кроме того часто бывает нужно заменить вызов индексатора на вызов функции и тогда приходится менять квадратные скобки на круглые, а так не нужно будет.

Собственный синтаксис для индексаторов — это ещё и подсказка что в данном случае имеем доступ к коллекции или чему-то мимикрирующуему под коллекцию. Круглые скобки это более универсально, но в каждом конкретном случае придётся разбираться коллекция ли там под капотом, или имеем вызов функции, которая что-то считает и возвращает какое-то разовое значение. Т.е. снижается наглядность при чтении кода.
Re[2]: Предлагаю подобрать скобки для типов...
От: Иванков Дмитрий Россия  
Дата: 15.12.09 15:57
Оценка: 4 (1) +2
Здравствуйте, nikov, Вы писали:

N>Мне больше всего нравится, как сделано в Scala: типы-параметры [], вызов индексатора ()

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

А типы-параметры вполне можно представлять как вызов индексатора семейства типов.
Собственно смысла в смене "тип-параметр vs индексатор" на "индексатор vs вызов функции" нет, в контексте этой ветки.
Re[3]: Предлагаю подобрать скобки для типов...
От: hi_octane Беларусь  
Дата: 15.12.09 16:04
Оценка: 2 (1)
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 методам вместо свойств. И то и другое — синтаксический сахар к методам. Но этот сахар сделали что лучше передать смысл конструкций.
Re[3]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.12.09 16:13
Оценка: +1
Здравствуйте, nikov, Вы писали:

N>Хочу еще добавить, что для типов-аргументов любой синтаксис кроме A<T> и A[T] будет в некоторой степени неестественным. А вот для индексации массивов arr(x) = 1 будет почти таким же естественным как arr[x] = 1.


Я как старый сишник считаю, что синтаксис arr(x) тоже не естественный.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 15.12.09 16:23
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Приветствуются любые мысли!


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

x.<T>Foo(y);
Re[9]: Предлагаю подобрать скобки для типов...
От: hi_octane Беларусь  
Дата: 15.12.09 16:27
Оценка:
_>>Но неоднозначности появляются только в каких-то особых случаях, ведь так?

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.
Re[10]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.12.09 16:56
Оценка:
Здравствуйте, hi_octane, Вы писали:

_>Для человека который до этого писал только на шарпе — любая невозможность писать тем способом каким он привык, или уже знает — это те самые -100 баллов про которые часто пишут разработчики компилятора C# в своих блогах. Поэтому, имхо, там где возможно, нам стоит быть ближе и доступнее тем кто начинает писать на Nemerle.


Этот вопрос решается по другому. Можно сделать поддержку C#-синтаксиса, так чтобы в проект можно было бы просто включать C#-файлы.

Это даже не очень сложно сделать. Я планировал это сделать до релиза, но к сожалению задержал Вольфхаунд который хотел реализовать PEG-парсер в виде макроса немерле, но так до сих пор его и не реализовал.
Будет построитель парсеров, обязательно сделаю.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 15.12.09 17:00
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Этот вопрос решается по другому. Можно сделать поддержку C#-синтаксиса, так чтобы в проект можно было бы просто включать C#-файлы.


И что, вы собираетесь делать честную поддержку сишарповских member lookup, type inference и overload resolution?
Re[12]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.12.09 17:20
Оценка:
Здравствуйте, nikov, Вы писали:

N>И что, вы собираетесь делать честную поддержку сишарповских member lookup, type inference и overload resolution?


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

У нас другая задача. Точнее их две:
1. Упростить перевод проектов на Nemerle. Люди смогут брать готовые C#-проекты и развивать их с помощью Немерле. Кроме того появится возможность заимствования из других C#-проектов. Ну, и за одно решится проблема "непривычности" и психологические проблемы.
2. Использовать дизайнеры и генераторы кода рассчитанные на C#.

ЗЫ

Что касается планов по второй версии (или это будет отдельный язык... скажем "N"), то возможно в ней реализуем некоторые настройки которые позволят эмулировать другие языки не только на синтаксическом уровне, но и на семантическом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Предлагаю подобрать скобки для типов...
От: jenyavb  
Дата: 16.12.09 04:31
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я как старый сишник считаю, что синтаксис arr(x) тоже не естественный.


В си у [] это просто упрощенный синтакис для доступа к памяти. В Nemerle даже unsafe нет, так что смысла копировать си тоже нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1325>>
Re[4]: Предлагаю подобрать скобки для типов...
От: jenyavb  
Дата: 16.12.09 04:31
Оценка: 1 (1)
Здравствуйте, 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;

?
(если глупость, не пинайте, я немерле пока не знаю, но планирую)
Re: вариант <| |>
От: Иванков Дмитрий Россия  
Дата: 16.12.09 08:11
Оценка:
Вроде бы не упоминалось ещё: есть оператор |> для функций, симметричного ему <| пока нет, но это тоже не очень приятное перекрытие.
Re[5]: Предлагаю подобрать скобки для типов...
От: hi_octane Беларусь  
Дата: 16.12.09 08:15
Оценка:
J>А теперь замени круглые скобки на квадратные — что изменилось?

Ну сравни

x = MyClass.X(a, b);
     с 
x = MyClass.X[a, b];


И что изменилось? Как программист в случае индексации [] я получаю подсказку что имеет место обращение к коллекции, которая как-то индексируется. Что при повторном обращении с тем же набором индексов [a, b] — я получу тот же самый элемент что и в прошлый раз (в случае ссылочных типов — так и reference equal элемент), что я могу по этой коллекции прокатить foreach или select, и т.п. Повторюсь — индексаторы это костыль к методам, но не больший костыль чем свойства. Да и есть уже один язык который подвергся тотальной унификации и теперь сидит в очень узкой нише — lisp. Лиспу никаких скобок кроме круглых не надо, но и писать на нём готовы считанные люди.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.