А>А нельзя ли сделать вообще без всяких скобок:

А>

А>Map int int foo;
А>

А>?
А>(если глупость, не пинайте, я немерле пока не знаю, но планирую)

Тогда вложенные Map<int, Pair<int, string>> придётся писать в польской нотации или как-то ещё извращаться — уж лучше оставить [] как это сейчас.

С опусканием скобок проблемы могут быть с вложенными именами:

Foo!Bar.Baz // Foo!(Bar).Baz vs Foo!(Bar.Baz)

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

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

В Nemerle допустимо такое выражение (взято отсюда

Автор(ы): Сергей Туленцев, Владислав Чистяков
Дата: 23.05.2006
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка)и является неформальным введением в язык.

):

_multiDimArray : array[2, int] = array.[2][[1, 2, 3], [4, 5, 6]];

Если использовать синтаксис scala, как Вы предложили, точка уйдёт и получится неоднозначность.

Здравствуйте, Мишень-сан, Вы писали:

МС>В Nemerle допустимо такое выражение (взято отсюда

Автор(ы): Сергей Туленцев, Владислав Чистяков
Дата: 23.05.2006
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка)и является неформальным введением в язык.

):
МС>

МС>_multiDimArray : array[2, int] = array.[2][[1, 2, 3], [4, 5, 6]];
МС>

МС>Если использовать синтаксис scala, как Вы предложили, точка уйдёт и получится неоднозначность.

Не понял, какая неоднозначность? Приведи пример двух вариантов синтаксического разбора.

Здравствуйте, Мишень-сан, Вы писали:

МС>В Nemerle допустимо такое выражение (взято отсюда

Автор(ы): Сергей Туленцев, Владислав Чистяков
Дата: 23.05.2006
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка)и является неформальным введением в язык.

):
МС>

МС>_multiDimArray : array[2, int] = array.[2][[1, 2, 3], [4, 5, 6]];
МС>

МС>Если использовать синтаксис scala, как Вы предложили, точка уйдёт и получится неоднозначность.

Количество элементов при инициализации массива тоже придется указывать в круглых скобках. И это ИМХО плюс, так как в квадратных скобках указывается содержимое массива (или тип элементов).

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


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

Мне кажется, это безразлично, так как литерал 2 — это точно не тип.

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

А как вам такой вариант:
При объявлении типов/методов использовать синтаксис со стандартными угловыми скобками, а при использовании в условиях необходимости уточнить тип — уточнять его через двоеточие, как это уже принято в Немерле. И дать возможность избирательно уточнять тип параметров генерика, а не как в c# — или для всех параметров или ни для кого.

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

что то вроде этого:

class A<T1, T2>
{
  x : T1;
  y : T2;

  m<T>(x : int) : void {}  
}

def c = A:<int,int>();
def v = c.m:<int>();

или так:

def c = A:<T1:int>();

ну или так:

def c = A():<int,int>;

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

ИД>С опусканием скобок проблемы могут быть с вложенными именами:
ИД>

ИД>Foo!Bar.Baz // Foo!(Bar).Baz vs Foo!(Bar.Baz)
ИД>

Не уверен, что это будет проблемой для парсера. К тому же в D это работает.

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

J>Здравствуйте, Мишень-сан, Вы писали:

МС>>В Nemerle допустимо такое выражение (взято отсюда

Автор(ы): Сергей Туленцев, Владислав Чистяков
Дата: 23.05.2006
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка)и является неформальным введением в язык.

):
МС>>

МС>>_multiDimArray : array[2, int] = array.[2][[1, 2, 3], [4, 5, 6]];
МС>>

МС>>Если использовать синтаксис scala, как Вы предложили, точка уйдёт и получится неоднозначность.

J>Количество элементов при инициализации массива тоже придется указывать в круглых скобках. И это ИМХО плюс, так как в квадратных скобках указывается содержимое массива (или тип элементов).

array.[2] это не массив из 2-х элементов, а 2-мерный массив.

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

ИД>Вроде бы не упоминалось ещё: есть оператор |> для функций, симметричного ему <| пока нет, но это тоже не очень приятное перекрытие.

Важен открывающий символ.

Здравствуйте, Мишень-сан, Вы писали:

МС>array.[2] это не массив из 2-х элементов, а 2-мерный массив.

Понятно. Значит нужно думать что делать с многомерными массивами. Текущая форма записи тоже не очень очевидная. Интересно, как оно сделано в scala?

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

[]

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

def someFunc()
{
def items = [1, 2, 3];
def result = [items | items.Head >>> 1 ];
...
result.Count >> 0;
}

ы?

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

J>Понятно. Значит нужно думать что делать с многомерными массивами. Текущая форма записи тоже не очень очевидная. Интересно, как оно сделано в scala?

В Scala нет многомерных массивов, как и в Java. Вместо этого там используются вложенные массивы.

Здравствуйте, Константин Л., Вы писали:

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

Путанница будет еще та.

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

S>А как вам такой вариант:
S>При объявлении типов/методов использовать синтаксис со стандартными угловыми скобками, а при использовании в условиях необходимости уточнить тип — уточнять его через двоеточие, как это уже принято в Немерле. И дать возможность избирательно уточнять тип параметров генерика, а не как в c# — или для всех параметров или ни для кого.

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

Надо бы выяснить у тех, кто хорошо знает потроха компилятора, останутся ли проблемы с неоднозначностью если чистые угловые скобки будут только в объявлениях. Из того, что VladD2 до сих пор говорил, следует, что проблемы есть только при вызовах.

Как по мне, то вариант с двоеточием выглядит приятнее чем с восклицательным знаком, собакой или точкой. Для сравнения

def map = Dictionary:<long,List:<int>>();

def map = Dictionary!<long,List!<int>>();

def map = Dictionary@<long,List@<int>>();

def map = Dictionary.<long,List.<int>>();

Я бы за первое проголосовал

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

S>>И дать возможность избирательно уточнять тип параметров генерика, а не как в c# — или для всех параметров или ни для кого.
SAS>Возможность избирательно уточнять выглядит привлекательно, но ортогональна к теме дискуссии. Мы тут пока даже по исходному вопросу договориться не можем.

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

SAS>Надо бы выяснить у тех, кто хорошо знает потроха компилятора, останутся ли проблемы с неоднозначностью если чистые угловые скобки будут только в объявлениях. Из того, что VladD2 до сих пор говорил, следует, что проблемы есть только при вызовах.

Мне тоже кажется с ":<" неоднозначностей быть не должно, так и не придумал, в каких еще случаях может появиться такая комбинация. Но если остановиться на синтаксисе с двоеточием и угловыми скобками, то придется перелопатить парсинг объявления классов и методов — вернуть поддержку угловых скобок.

Есть еще сомнения Влада по поводу разных синтаксисов определения и вызова:

VD>На мой взгляд синтаксис определения и вызова должны быть едины.
VD>Вопрос конечно тоже дискутируемый, но моя позиция в данном вопросе очень проста. Чем меньше нужно запоминать и объснять, тем лучше.
VD>То, что в одном случае нужно писать одно, а в другом другое — это придется объяснять и запоминать.

Тут в качестве аргумента могу написать что использование двоеточия для указания типа — это уже объяснено и запомнено, нужно только немного расширить область применения двоеточия.

Аргумент против квадратных скобок, вернее просто мое имхо — парсить вызовы функций, типизованных "квадратными скобками", перемешанные с вызовами индексаторов — то еще удовольствие, тем более для старого шарпера. Лично я начал воспринимать двоеточия буквально с первой строки листинга на Немерле, а квадратные скобки меня до сих пор напрягают (правда мое знакомство с языком ограничивается статьями Влада и нескольким самодельными примерами).

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

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

А почему бы не убрать необязательную точку из type application expression и ввести её для indexed lookup expression, как в F#?

def list = List[int]()
def uups = list.[0]

В F# достаточно удобно + есть такая штука, как slice expression:

let arr = [| 1; 2; 3 |]
let two = arr.[1]
let slice = arr.[0..1]

З.Ы. я против <|T|>, неудобно набирать + 2 символа + не скажу, что приятный на глаз синтаксис, хотя C-подобность есть, если издалека посмотреть
З.Ы.Ы. в F# (что то шибко много раз я употребил эти два символа в этом форуме ) pipeline-оператор |> выглядит няшно только когда выстроен в вертикальный ряд... после такого:

show <| filter <| map <| x

...хаскельный оператор $ выглядит намного приятнее, хоть и непонятнее для новичков:

show $ filter $ map $ x

Короче ИМХО нафиг эту геометрию из < | >

Здравствуйте, Пельмешко, Вы писали:

П>А почему бы не убрать необязательную точку из type application expression и ввести её для indexed lookup expression, как в F#?
П>

П>def list = List[int]()
П>def uups = list.[0]
П>

Шило на мыло. К тому же доступ по индексу в Немерле встречается намного чаше чем описание параметров типа внутри кода.

П>В F# достаточно удобно + есть такая штука, как slice expression:
П>

П>let arr = [| 1; 2; 3 |]
П>let two = arr.[1]
П>let slice = arr.[0..1]
П>

Это здорово, но к делу не относится.

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

S>...имхо — парсить вызовы функций, типизованных "квадратными скобками", перемешанные с вызовами индексаторов — то еще удовольствие, тем более для старого шарпера.

Имелось ввиду — "парсить" исходники глазами, читая код с листа. Говорить за парсер Немерле я не могу )

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

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

Вы учтите, что в C# некоторые вещи запатентованы, так что имеет смысл заранее поговорить с юристом.