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

WH>Но ломающие изменения предлагаю оставлять на 2.0

Если делать ломающие изменения, то гораздо лучше делать их до первого релиза.

С исходной посылкой согласен, фича вредная.

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

VD>>Я тоже склоняюсь, что данную фичу лучше запретить. От нее вреда больше чем пользы.
WH>плюс адын.
WH>Но ломающие изменения предлагаю оставлять на 2.0

Дык до релиза это даже и не ломающее изменение. А в 2.0 это уже будет точно несовместимость с предыдущей версией.

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

VD>Но действительно вреда от фичи куда больше чем достоинств.

+1

VD>Дело даже не в явном указании, а в том что немерл поддерживает неявное преобразование. Скажем если у нас есть функция с двумя параметрами, то в нее всегда можно передать кортеж. Если мы запрещаем неявное преобразование, то и эта фича отвалится. А будет ли это хорошо?

Вот этот сценарий — кортеж распаковываемый в аргументы функции, мне думается автоматизировать нужно.

Но обратная операция весьма спорная, так как код подобный этому выглядит весьма странно:

def f(a) ...

f(1,2)

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

ВВ>А какие проблемы с этим неявным приведением, кроме чисто технических? Неочевидно получается?

Да.
Например вот в таком коде:
http://code.google.com/p/nemerle/issues/detail?id=1268&can=1&sort=-id

def f (x, y)
{
 def f (x) 
 {
  f(x, y) 
 };

 if (x <= 0)
  y
 else
  f (x,1) + y 
}

f(1,3);

Вместо сообщения о том, что в функцию передается неверное количество параметров получается сообщение:

in argument #1, needed a ?, got (? * ?): the element with index 0 in tuple '(? * ?)' is recursive. This bug can be caused by the parametr to tuple transformation.

ВВ>Я в принципе вполне понимаю, почему поляки так сделали.

Все тоже — хотели как лучше.

ВВ>Совпадение синтаксиса вызова функции и литерала кортежа — не очень хорошо. Они фактически сделали финт ушами и говорят — они совпадают не просто так.

Скажу больше. Никакого совпадения не было. Это было задумано с самого начала. В системе типов функция описывается так: "тип -> тип" и подразумевается, что если параметров более одного, то "тип" — это кортеж:

  public variant FixedType : TypeVar
  {
...
    | Fun { from : TypeVar; [RecordIgnore] public argsCount : int; to : TypeVar;
...
    | Tuple { args : list [TypeVar]; }

Потому я и высказываю сомнения, что удастся легко отключить эту фичу.

Выделенное поле я ввел специально чтобы учитывать в эвристике является ли полученная перегрузка прямой или получена в результате картежного преобразования. Ранее в компиляторе было вообще невозможно отличить эти варианты и как следствие невозможно было применять LINQ.

ВВ>Ведь параметры функции это и есть кортеж. И отсюда следуют все ваши неявные приведения. Т.е. это не просто неявные приведения, это, получается, часть дизайна языка.

Так и есть. Но в условиях библиотек написанных для шарпа где таких неявных преобразований нет — это часто приводит к проблемам.

ВВ>Кардинальным решением было бы изменить литерал кортежа на что-то более другое и бесскобочное.

Литерал тут в общем-то не причем. Дело в логике работы с функциями.

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

VD>def a = (1,2);

VD>def f(x,y) {}

VD>f(a) // Error
VD>f(..a) // OK

А можно так?

def tuple = (1,2);
def f(x,y) {}
f tuple;//cкобки уже есть в tuple :)

//или так:
f $ tuple;

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

VD>Дык до релиза это даже и не ломающее изменение. А в 2.0 это уже будет точно несовместимость с предыдущей версией.

Ну ты приколист.
Тут на самом деле как не крути, а ломающее изменение будет — что в 1.0 по сравнению с 0.9.х, что в 2.0 по сравнению с 1.0.

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

VD>Дык до релиза это даже и не ломающее изменение. А в 2.0 это уже будет точно несовместимость с предыдущей версией.
2.0 один хрен будет не совместима с 1.0.
У нас просто нет ресурсов чтобы в 2.0 воспроизвести все баги 1.0

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

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

H>>

H>>def f(a) ...

H>>f(1,2)
H>>

ВВ>Я так понимаю, это ввели отчасти из-за... "эстетических" причин. Т.к. с Си-подобным синтаксисом вызов бы выглядел так:

ВВ>

ВВ>f((1,2))
ВВ>

Что-то нечасто я вдел чтобы функция принимала чисто кортеж.

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

Что вызовется в этом случае:

module Program
{
  Run[T](_ : T) : void { Console.WriteLine("_ : T"); }
  Run[T](params _ : array[T]) : void { Console.WriteLine("params _ : array[T]"); }

  Main() : void
  {
    Run(1, 2);
  }
}

Или почему этот код компилируется, а не выдает ошибку ?

def f(a)
{
  | (x, y) => ()
  | _ => ()
}

f(1, 2);

Все дело в неявном создании кортежа.
Посему и вопрос не стоит ли эту фичу убрать и явно указывать создание кортежа ?

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

__>Все дело в неявном создании кортежа.

Ага.

__>Посему и вопрос не стоит ли эту фичу убрать и явно указывать создание кортежа ?

Откровенно говоря эта хрень мня тоже достала, но:
1. Она весьма глубоко встроена в систему типов. Придется курочить все начиная с солвера.
2. Довольно много кода использует эту фичу. Боюсь, что даже в компиляторе его будет не мало.

Но действительно вреда от фичи куда больше чем достоинств.

Что касается явного указания, то надо предложить синтаксис.
Дело даже не в явном указании, а в том что немерл поддерживает неявное преобразование. Скажем если у нас есть функция с двумя параметрами, то в нее всегда можно передать кортеж. Если мы запрещаем неявное преобразование, то и эта фича отвалится. А будет ли это хорошо? Если нет, то нужен синтаксис позволяющий явно указать, что нам нужно передать элементы кортежа в качестве параметров методов.

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

VD>Но действительно вреда от фичи куда больше чем достоинств.

VD>Что касается явного указания, то надо предложить синтаксис.
VD>Дело даже не в явном указании, а в том что немерл поддерживает неявное преобразование. Скажем если у нас есть функция с двумя параметрами, то в нее всегда можно передать кортеж. Если мы запрещаем неявное преобразование, то и эта фича отвалится. А будет ли это хорошо? Если нет, то нужен синтаксис позволяющий явно указать, что нам нужно передать элементы кортежа в качестве параметров методов.

Согласен, нужно это хорошо продумать.

Тут много вариантов как указать.
Скажем как-то так:

def a = (1,2);

def f(x,y) {}

f(a) // Error
f(*a) // OK

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

__>Тут много вариантов как указать.
__>Скажем как-то так:
__>

__>def a = (1,2);

__>def f(x,y) {}

__>f(a) // Error
__>f(*a) // OK
__>

Это все не очевидно. А унарное "умножение" может еще и столку сбить.

Возможно более красивым ходом было бы использовать аналог раскрытия списков в квази-цитировании:
>

def a = (1,2);

def f(x,y) {}

f(a) // Error
f(..a) // OK

Но опять же надо подумать.

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

Народ! Высказываетесь по этому поводу!

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

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

VD>Народ! Высказываетесь по этому поводу!

VD>Я тоже склоняюсь, что данную фичу лучше запретить. От нее вреда больше чем пользы.

Лично мне она не мешает. Несколько раз использовал её, но если её не станет, то не расстроюсь.

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

VD>Я тоже склоняюсь, что данную фичу лучше запретить. От нее вреда больше чем пользы.
плюс адын.
Но ломающие изменения предлагаю оставлять на 2.0

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

VD>Народ! Высказываетесь по этому поводу!

VD>Я тоже склоняюсь, что данную фичу лучше запретить. От нее вреда больше чем пользы.

Мне нравится (кажется удобным), что можно написать [(1,2)].Map(fun(a,b){ ... }) не смотря на то, что Map имеет тип 'a->'b. Если фичу запретить, то придется писать [(1,2)].Map(fun(_){ | (a,b) => ... }), что менее элегантно. С другой стороны именно неявными преобразованиями меня пугает scala.

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

РД>Мне нравится (кажется удобным), что можно написать [(1,2)].Map(fun(a,b){ ... }) не смотря на то, что Map имеет тип 'a->'b.

Тут можно будет писать [(1,2)].Map(fun((a,b)){ ... })

РД>Если фичу запретить, то придется писать [(1,2)].Map(fun(_){ | (a,b) => ... }), что менее элегантно. С другой стороны именно неявными преобразованиями меня пугает scala.

Проблема в том, что это преобразование создает невероятное количество вариантов при работе с LINQ-ом.

Я был вынужден ввести очень не простые эвристики в алгоритм разрешения перегрузки, чтобы это дело наконец-то заработало. Причем в режиме интеграции (когда код не дописан до конца) это все равно приводит к проблемам.

Соглашаюсь с удалением этой фичи(бага)
Мне кажется, что если пишем def a = (1,2); , то a уже кортеж и использовать её как массив смысла нет... Хотя если можно это оставить, то почему бы и нет. С магическим синтаксисом, например f([a])

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

РД>Мне нравится (кажется удобным), что можно написать [(1,2)].Map(fun(a,b){ ... }) не смотря на то, что Map имеет тип 'a->'b. Если фичу запретить, то придется писать [(1,2)].Map(fun(_){ | (a,b) => ... }), что менее элегантно.

По всей видимости поляки именно ради такого использования внедрили эту фичу.

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

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

WH>>Но ломающие изменения предлагаю оставлять на 2.0

SAS>Если делать ломающие изменения, то гораздо лучше делать их до первого релиза.
+1
Раз эта фича не полезна, то лучше ее продумать и внести изменения до 2-й версии.
Т.к. проблему 1-й версии это решит уже сейчас, а 2-я версия будет не очень скоро.

SAS>С исходной посылкой согласен, фича вредная.

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

H>

H>def f(a) ...

H>f(1,2)
H>

Я так понимаю, это ввели отчасти из-за... "эстетических" причин. Т.к. с Си-подобным синтаксисом вызов бы выглядел так:

f((1,2))

И в глаза бросается некоторая излишняя скобочность. Мне и самому такое не нравится. Хотя проблему отчасти решают пайпы:

f <| (1, 2)

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

H>Что-то нечасто я вдел чтобы функция принимала чисто кортеж.

Ну это может быть, к примеру, каррированная (в вашем случае — "частично примененная") функция. В таком случае сценарий не столь уж и редкий.

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

А какие проблемы с этим неявным приведением, кроме чисто технических? Неочевидно получается?
Я в принципе вполне понимаю, почему поляки так сделали. Совпадение синтаксиса вызова функции и литерала кортежа — не очень хорошо. Они фактически сделали финт ушами и говорят — они совпадают не просто так. Ведь параметры функции это и есть кортеж. И отсюда следуют все ваши неявные приведения. Т.е. это не просто неявные приведения, это, получается, часть дизайна языка.

Кардинальным решением было бы изменить литерал кортежа на что-то более другое и бесскобочное.

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

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

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

fun(1,2,)

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

A>А можно так?
A>

A>def tuple = (1,2);
A>def f(x,y) {}
A>f tuple;//cкобки уже есть в tuple :)

A>//или так:
A>f $ tuple;
A>

Это будет крайне трудно объяснить людям (а первое вообще противоречит концепциям языка).

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

VD>Это будет крайне трудно объяснить людям (а первое вообще противоречит концепциям языка).

А как тебе такой костыль:

fun(1,2,)

Т.е. запятая в конце — список параметров надо преобразовать в кортеж.

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

ВВ>А как тебе такой костыль:

ВВ>

ВВ>fun(1,2,)
ВВ>

Плохо — это и так допустимая конструкция. Да и опять же не очевидно.

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

ВВ>>Совпадение синтаксиса вызова функции и литерала кортежа — не очень хорошо. Они фактически сделали финт ушами и говорят — они совпадают не просто так.
VD>Скажу больше. Никакого совпадения не было. Это было задумано с самого начала. В системе типов функция описывается так: "тип -> тип" и подразумевается, что если параметров более одного, то "тип" — это кортеж:

А что это дает с точки зрения языка? Т.е. я понимаю, что да, в статьях вроде как написано — считается, что параметры функции описываются через кортеж. Но мне казалось, что это больше "идейное" утверждение. Т.е. завтра можно сказать, что параметры функции ни через какой кортеж не описываются, и функция типа int -> (int * int) имееет на самом деле тип int -> int -> int.

Что-нибудь, кроме этой самой неявной упаковки/распаковки кортежа, будет противоречить этому утверждению?

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

ВВ>А что это дает с точки зрения языка? Т.е. я понимаю, что да, в статьях вроде как написано — считается, что параметры функции описываются через кортеж. Но мне казалось, что это больше "идейное" утверждение. Т.е. завтра можно сказать, что параметры функции ни через какой кортеж не описываются, и функция типа int -> (int * int) имееет на самом деле тип int -> int -> int.

ВВ>Что-нибудь, кроме этой самой неявной упаковки/распаковки кортежа, будет противоречить этому утверждению?

Текущая реализация. А так по идее должно все взлететь.

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

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

VD>Плохо — это и так допустимая конструкция.

Используется для создания кортежа из одного элемента?

VD>Да и опять же не очевидно.

Ну тут хз. Интересно было бы посмотреть на другие варианты. Как и на другие варианты бесскобочного литерала для кортежа. Наверняка можно придумать что-нибудь интересное.

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

ВВ>Используется для создания кортежа из одного элемента?

Используется теми кому в лом при копипасте редактированием заниматься. Просто можно вбивать в любом перечислении лишнюю запитую.

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

VD>Скажу больше. Никакого совпадения не было. Это было задумано с самого начала. В системе типов функция описывается так: "тип -> тип" и подразумевается, что если параметров более одного, то "тип" — это кортеж:
VD>

VD>  public variant FixedType : TypeVar
VD>  {
VD>...
VD>    | Fun { from : TypeVar; [RecordIgnore] public argsCount : int; to : TypeVar;
VD>...
VD>    | Tuple { args : list [TypeVar]; }
VD>

VD>Потому я и высказываю сомнения, что удастся легко отключить эту фичу.

Есть вероятность это это все таки возможно ?

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

__>Есть вероятность это это все таки возможно ?

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

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

VD>Народ! Высказываетесь по этому поводу!

VD>Я тоже склоняюсь, что данную фичу лучше запретить. От нее вреда больше чем пользы.

Может для начала сделать ворнинг с сообщением о том, что в будущем фича будет запрещена?

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

KK>Может для начала сделать ворнинг с сообщением о том, что в будущем фича будет запрещена?

Тут вопрос в другом — предположительно снос бошки этой "фиче" позволит некисло ускорить вывод типов (а имеено выбор перегрузок) и уменьшить время компиляции.

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

KK>Может для начала сделать ворнинг с сообщением о том, что в будущем фича будет запрещена?

Как-то времени не остается. Релиз на носу. Надо или пробовать ее удалять, или оставпить все как есть.

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

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

__>>Есть вероятность это это все таки возможно ?

VD>Дык тут надо пробовать. Так ничего сказать нельзя. Учитывая, что народная поддержка вроде как есть, можно попробовать.

Поддержка есть
IMHO нужно пробовать.