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

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

VD>>>Пока писал, понял, что для ValueOption[T] нужно добавить ExtensionPattern и открыть тип содержащий его псевдо-конструкторы. Тогда его будет так же удобно использовать как и option[T]. Учитывая, что накладные расходы для ValueOption[T] минимальны (так как это структура) его можно использовать где угодно не опасаясь потери производительности.
__>>А этот VariantOption когда стоит использовать вместо option ?
__>>Только для производительности ? Ведь для юзер кода option должно хватить.

VD>Для нее, для родной. Лично я по причине оверхэда option[T] использую редко.
VD>ValueOption[T] дает совсем незаметный оверхэд. Так что его можно использовать где угодно.
VD>Я тут подумал... ValueOption[T] можно попробовать усовершенствовать еще сильнее. Создать версию для объектов, которая в качестве признака null будет использовать самое поле со значением. Тогда оверхэда по памяти вообще не будет. Вот только придется называть ее по другому. Например ObjectOption[T]. Жаль типы нельзя перегружать.

Нужен тип-макрос который преобразуется в правильный тип во время компиляции.
Везде пишем option[T], а компилятор подставит лучший тип в зависимости от T.
В С++ такое сделать вполне возможно.

А нельзя сделать variant, который сгенерировал бы структуру, а не класс чтобы еще и сопоставления работали для ValueOption?

Кстати, а почему не разделить option на 2 класса:
ValueOption[T] where T : struct
ObjectOption[T] where T : class

И используй класс по назначению.

VD>>>Ну, дык соберите команду тех кого интересует этот режим и устраните этот недочет.

__>>Можно попробовать, только боюсь ни у кого на это нет времени \

VD>Ну, а что же вы хотите? У меня тоже не было времени. Но было желание. Я сел и начал делать. На все у меня тоже времени не хватит.

Можно попробовать собрать людей, но у меня сейчас больше желания использовать Nemerle для написания программ, а не заниматься компилятором.

__>>Да и для меня скобочки не смертельный вариант.
__>>В С-подобных языках вообще выбора нет

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

Чем больше людей будут переходить с Boo , тем больше шансов на это. Ждем вас программисты на Boo.

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

_C_>Слишком вы тут осторожные, однако. Не хватает воображения, чтобы это давало какие-то проблемы.
_C_>У меня так точно не было, несмотря на многие годы интенсивного использования.

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

В прочем, на С++ я тоже не мало писал и даже привык к этому багодромногму языки. Я наплодил себе кучу правил "хорошего тона" и придерживался их. В итоге объем ошибок был не велик, но вот объем кода, требуемого для решения задач, был слишком велик, а моя производительность напротив слишком мала. C# поднял ее в несколько раз. Nemerle еще в несколько раз. При этом объем кода который требуется написать на немреле для решения той же задачи в разы меньше чем на C# и во много раз меньше чем при работе на C++. Потому я и полюбил этот язык.

_C_>а вот вместо сравнения написать присваивание — это сколько угодно.
_C_>Так что не согласен я с Каутским.

Ты не верно смотришь на проблему. Очевидно, что лишний контроль не помешает. Если бы это приводило к заметному раздуванию кода, то это могло бы породить другие проблемы. Однако на практике кода на Немерле нужно значительно меньше чем на C++ или даже Boo, так как язык обладает кучей возможностей поднимающих производительность программистов не на копейки (как какие-то там присвоения или умолчания при объявлении полей), а в разы (паттерн-матчинг, варианты, макросы).

_C_>>>в struct объявленные поля не public по умолчанию, но вообще-то на то он и struct, что у него все public.
_C_>>>или здесь особый struct?

Если говорить об изменяемых полях, то делать их по умолчанию public — это точно плохое решение. Изменяемое состояние — это главный источник ошибок в программах. Его нужно инкапсулирвоать.

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

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

Вот почему свойства по умолчанию private действительно не ясно. Они ведь придуманы именно чтобы использоваться в интерфейсе. Вот их имеет смысл сделать публичными. Лично я, в последнее время, в основном использую именно свойства.

Кстати, немерл открытый язык. Ты без труда создашь макрос который меняет умолчания для типа. Создай макрос PablicByDefault и сможешь регулировать это дело самостоятельно. А в параметрах макроса еще можно будет указать для чего нужно public по умолчанию задавать.

VD>>Есть только один тип в котором по умолчанию поля public — это вхождение вариантов. Во всех стальных местах по умолчанию все члены являются private. Это соглашение всех без исключения C-подобных языков.

_C_>в С++ открытые. значит в С# стали чудить, но я на нем не пишу. но это потому что в Майкрософте народу много, чтобы всех занять придумывают раздутый синтаксис, из пальца высосанные ограничения и низкий уровень языков.

С++ — это пример безграмотного проектирования. На него лучше не ссылаться. В нем все через зад.
В Яве и Шарпе не зря пошли другим путем.

Потом в С++ структура и класс вообще различий почти не имеют. Вот дефолт для доступа пришпандорили. В дотнете же структура — это значимый тип. В общем, совсем другая сущность. Более подходящая по названию.

_C_>Смотрю регулярно, хорошо написано, но понятно не все.

К сожалению, не все там хорошо написано. Ну, а то что по началу не понятно, так это нормально. На то он и новый язык. Я вот твои макросы читал и тоже не все понимал .

_C_>что-нибудь милое и знакомое оставить надо. для психики лучше. и для кода тоже.

Ну, тогда пиши и отлаживай со скобками, а потом преобразуй в отступный синтаксис. Читать и компилировать его можно.

_C_>еще вот не понял как простые стандартные фиксированные массивы создаются (которые в шарпе типа System.Int32[])
_C_>есть ли короткая запись для такого типа?

Дык просто пишешь array[1, 2, 3] и все. Или array(размер) (если нужен незаполенный).
Внутри тел методов типы им указывать не надо. Сами выведутся. А при описании полей и свойств указываешь тип array[тип_элемента].

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

VD>>Да... очень советую почитать это

Автор: VladD2
Дата: 04.09.11

. Там как раз даются примеры создания нетривиальных макросов.

_C_>а как этот XML как текст читать, чем?

Это вордовский файл.

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

__>Кстати, а почему не разделить option на 2 класса:
__>ValueOption[T] where T : struct
__>ObjectOption[T] where T : class

__>И используй класс по назначению.

Потому что иногда нужно реализовывать обобщенные алогритмы которые могут принимать любое T. С Nullable уже эту глупость сделали, ограничив типы структурами. Так что сделать

ObjectOption[T] where T : class

можно. Это будет оптимизация.
А вот

ValueOption[T]  where T : struct

это глупость уже.
Нужен Option[T] который будет принимать любой тип и при этом будет структурой (не будет создавать сильного оверхэда).

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

_C_>вот это что дает и что за global ?

Прочитай статью на которую я ссылку дал. Там все описано.

_C_> ($("_N_continue" : global)

Это значит, что имя созданное с помощью сплайса будет относиться к глобальному контексту. По умолчанию макросы гигиеничны и имя созданное в макросе не будет видно за его приделами. А вот чтобы сослаться на глобальное имя надо делать так как показано выше.

_C_>вот это непонятно что в match получается

_C_>

_C_>match (cases)
_C_>      {
_C_>        | <[ match ($_) { ..$cases } ]> =>
_C_>

Это распознование оператора match с любым содержимым. При этом проверяемое в match значение значение игнорируется ("_" — это символ игнорирующий значения), а входждения match-а помещаются в переменную cases, которая является списком выражений (о чем говорит сплайс "..$").

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

VD>>Пока писал, понял, что для ValueOption[T] нужно добавить ExtensionPattern и открыть тип содержащий его псевдо-конструкторы. Тогда его будет так же удобно использовать как и option[T]. Учитывая, что накладные расходы для ValueOption[T] минимальны (так как это структура) его можно использовать где угодно не опасаясь потери производительности.

_C_>я б про это почитал бы.

Про что конкретно? Про ValueOption[T] или про ExtensionPattern-ы?

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

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

VD>>>Пока писал, понял, что для ValueOption[T] нужно добавить ExtensionPattern и открыть тип содержащий его псевдо-конструкторы. Тогда его будет так же удобно использовать как и option[T]. Учитывая, что накладные расходы для ValueOption[T] минимальны (так как это структура) его можно использовать где угодно не опасаясь потери производительности.

_C_>>я б про это почитал бы.

VD>Про что конкретно? Про ValueOption[T] или про ExtensionPattern-ы?

да про все. слова незнакомые, чувствую, что-то стоящее.

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

__>А NotNull нельзя приделать к методу ? Чтобы одним махом все проверять на null:
__>

__>[NotNull] public F(a : int, b : string, c : object, d : long) : void { ... }
__>

__>Превращается в ==>
__>

__>public F(a : int, [NotNull] b : string, [NotNull] c : object, d : long) : void { ... }
__>

Ты как маленький прямо. Заходишь в директорию макросов и делаешь поиск по NotNull...

В общем, на сегодня он применим только к параметрам. Даже к возвращаемому значению не применим. Хотя можно использовать макросы Design by Contract для тех же целей.

В общем, если тебе хочется, то можешь добавить макрос на метод и даже на класс (а то и на пространство имен).

__>А этот VariantOption когда стоит использовать вместо option ?

Ага.

__>Только для производительности ? Ведь для юзер кода option должно хватить.

Ну, вот в парсере использовать option[T] очень не выгодно, например. И в компиляторе тоже. Думаю замена с option[T] на ValueOption[T], а еще лучше на ObjectOption[T] даст заметное ускорение компилятора.

VD>Смысл в этом очевидный. Компилятор выявляет ошибки и указывает программисту на это. Это из той же оперы что и необходимость объявления переменной. Физически без этого обойтись можно, но это провоцирует ошибки.

Да все провоцирует на ошибки. Но это в наименьшей степени.

_C_>>нафига использующей стороне знать детали реализации моего класса?

VD>Статические методы не являются частью реализации класса. Выражение идущее до точки (при вызове метода) — это дополнительный параметр. Не находишь, что странно передавать функции лишний параметр?


_C_>>Я могу изменить экземплярное на статическое или наоборот — вызывающий код зачем переделывать?

VD>Если хочешь чтобы вызовы статических методов выглядели как экзеплярные, делай их методами-расширениями.
VD>Только при этом логично было бы, чтобы статический метод получал бы значение объекта в первом параметре. Иначе будет лишний (неиспользуемый параметр).

я так скажу, если даже идти на поводу у параноиков из Майкрософта, это может быть предупреждением, но никак не ошибкой.

VD>Ну, а если метод не обращается к типу к которому он объявлен, то с огромной вероятностью этот метод лежит не там где следовало бы. Таким методам место в отдельных модулях.

_C_>>потому что в Майкрософте им виднее ..

VD>В МС тоже не идиоты сидят. Проектируя C# в МС сделали многое чтобы сделать язык более безопасным (не допускающим случайных ошибок). К сожалению, без проблем тоже не обошлось и косяки в язык добавили. Например, оператор as. Но в целом дизайн C# лучший из мэйстрим-языков.

не идиоты. но ничего умного по части языков / компиляторов ими не было придумано / внедрено. Идеи .Net датируются серединой 80-х, идея C# и реализация .Net -беглых из Borland, и т. д. Вот и Nemerle им кость в горле. а вы говорите — ну нет, вряд ли они тупые, вот скопируем вот это, не зря же они
тут лохмотьев намотали. а вот и зря. нет там гениев. или их к программированию не допускали.

VD>При проектировании Nemerle концепция недопущения случайных ошибок была поставлена во главу угла. В процессе работы над языком было выкинуто ряд решений которые могли приводить к случайным ошибкам. На сегодня немерл один из самых устойчивых к ошибкам языков из практически применимых ЯП.

Да много лишних слов и конструкций, которые вызывают откровенное недоумение, потому что реально Nemerle крут, но рябые C# уши торчат во многих местах.

Вот например нафига при вызове функций с ref out каждый раз его явно указывать. я уже сказать компилятору что там ref,
чего я как попугай должен это постоянно повторять. или вдруг это может стать по-другому? но время я на этом теряю. вижу ошибки, начинаю пугаться, править.

или typeof для шаблонного параметра, если я его передаю в функцию требующую System.Type, почему я должен писать typeof(T), хотя
коню понятно что речь о типе, о чем же еще? где тут устойчивость к ошибкам? нету, но есть лишний маразматический код, любезно перенятый у мелкомягких.

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

_C_>да про все. слова незнакомые, чувствую, что-то стоящее.

ExtensionPattern — это способ дать возможность использовать более простой паттерн (при паттерн-матчинге).

ValueOption[T] — это структура — аналог типа optin[T]. ValueOption[T] банально быстрее optin[T] так как optin[T] — ссылочный тип, а ValueOption[T] структура.

optin[T] — это принятый в мире ФП паттерн представления необязательного значения. Вместо того чтобы допускать null в качестве значения мы описываем тип переменной как option[T] (option[T] — это вариантный тип). Далее, если есть значение, то мы его оборачивам в значение optin[T].Some(42), а если нет, то используем optin[T].None() который не имеет значения.

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

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

При этом у таких оберток есть развитый интерфейс для работы с ними. Так с ними работают операторы ?. и ??. Первый вовращает дефволт-значнеие, если ссылка нулевая. Второй позволяет задать конкретное дефолтное значение, если ссылка нулевая.

Но у option[T] есть еще одно преимущество. Так как option[T] вариант, то его значения можно распознавать с помощью сопоставления с образцом.

Например:

def Plus(x : optin[int], y : optin[int])
{
  | (Some(x), None)    => x
  | (None,    Some(y)) => y
  | (Some(x), Some(y)) => x + y
}

Для ValueOption[T] так не сделаешь, так как ValueOption[T] не вариантный тип. Можно конечно использовать его в сопоставлении с образцом следующим образом (с использованием паттерна where):

def Plus(x : ValueOption[int], y : ValueOption[int])
{
  | (ValueOption where(HasValue=true, Value=x), ValueOption where(HasValue=false))         => x
  | (ValueOption where(HasValue=false),         ValueOption where(HasValue=true, Value=y)) => y
  | (ValueOption where(HasValue=true, Value=x), ValueOption where(HasValue=true, Value=y)) => x + y
}

Но это слишком громоздко.

Так вот можно написать ExtensionPattern который опишет более простой паттерн и отобразит его в более сложный, но применимый к структуре.

Вот как выглядят ExtensionPattern-атрибуты для типа ValueOption[T]:

  [ExtensionPattern(VSome(value) = ValueOption where(HasValue=true, Value=value))]
  [ExtensionPattern(VNone()      = ValueOption where(HasValue=false))]
  public struct ValueOption[T]
  {
    ...

Теперь в сопоставлении с образцом можно использовать следующий код:

def Plus(x : ValueOption[int], y : ValueOption[int])
{
  | (VSome(x), VNone)    => x
  | (VNone,    VSome(y)) => y
  | (VSome(x), VSome(y)) => x + y
}

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

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

_C_>Да все провоцирует на ошибки. Но это в наименьшей степени.

Примеры в студию! Тогда и обсудим.

_C_>я так скажу, если даже идти на поводу у параноиков из Майкрософта, это может быть предупреждением, но никак не ошибкой.

По-моему все очевидно. Не нужен функции лишний праметр, но его передают. Это может быть ошибка ил небрежность. Такого допускать нельзя. Не нужен параметр — не передавай. Там в ведь может быть не хилое вычисление a.f(42, "ss").Y.Foo(); Зачем его высчитывать, если Foo даже не имеет такого параметра?

Другой вопрос. А нужно ли вообще производить это вычисление? Ведь "a.f(42, "ss").Y" испоьзуется только для вычисления типа. Что бы он не вернул тип будет один и тем же. Но этот код может создать побочные эффекты и выкидывать его нельзя.

В общем, вопросов выше крыши.

А с запретом проблем нет.

_C_>Вот и Nemerle им кость в горле.

Они упорно делают вид, что не замечают Nemerle. Какая тут кость?

_C_> а вы говорите — ну нет, вряд ли они тупые, вот скопируем вот это, не зря же они
_C_>тут лохмотьев намотали. а вот и зря. нет там гениев. или их к программированию не допускали.

Ну, мы то как раз ничего бездумно не копируем. Все ошибки Хейльсберга мы выбросили.

_C_>Да много лишних слов и конструкций, которые вызывают откровенное недоумение, потому что реально Nemerle крут, но рябые C# уши торчат во многих местах.

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

_C_>Вот например нафига при вызове функций с ref out каждый раз его явно указывать.

Откровенно говоря сама идея передачи значений по ссылкам мне не нравится. Будь возврат кортежей эффективне, я бы советовал вообще не использовать ref/out-параметров, так как они неудобны и императивны.

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

В С++ как раз это было сделано до безобразия бездарно. Тут нужно отдать должное Хельсбергу. Хотя лучше бы он изучил что такое кортежи. Они куда лучше подходят для возврата значений. А ссылки в любом случае зло.

_C_>я уже сказать компилятору что там ref,
_C_>чего я как попугай должен это постоянно повторять.

Чтобы понимать, что происходит. Что значение переменной переданной в параметр может измениться.

_C_>или вдруг это может стать по-другому?

Ага. Поменял описание метода и вдруг нежданно не гадагно переменная которая раньше не изменялась вдруг начала изменяться. И фиг поймешь где и как. Короче — грабли. А тут тебя заставляют такие места явно описать и обвесить флажками (как волчий загон).

_C_>но время я на этом теряю. вижу ошибки, начинаю пугаться, править.

_C_>или typeof для шаблонного параметра, если я его передаю в функцию требующую System.Type, почему я должен писать typeof(T), хотя коню понятно что речь о типе, о чем же еще? где тут устойчивость к ошибкам? нету, но есть лишний маразматический код, любезно перенятый у мелкомягких.

Тут ты чего-то странное говоришь. typeof() возвращает рантайм-тип (объект описывающий тип). В качестве параметра он получает имя типа времени компиляции. Как typeof() узнает, что ты хочешь получить информацию о типе T, а не о каком-то другом?

VD>Другой вопрос. А нужно ли вообще производить это вычисление? Ведь "a.f(42, "ss").Y" испоьзуется только для вычисления типа. Что бы он не вернул тип будет один и тем же. Но этот код может создать побочные эффекты и выкидывать его нельзя.
Побочные эффекты можно создать любым кодом. Ошибки в вызове по ссылке на экземпляр нет логически. Я не могу вспомнить ни одного языка с таким диким ограничением. поэтому зацепило..

VD>В общем, вопросов выше крыши.
VD>А с запретом проблем нет.

Вот многовато запретов. Человек заходит с С++ или Питона (первые ищут жизнь полегче, вторые — скорости) к примеру, а ему тут запреты. дайте хоть путь обойти. "вот модуль, пишите почти как раньше. получите бонусы. но учтите, что истина где-то рядом" — было бы разумно.
Ценность Nemerle не в текущей спецификации языка (хороша, но есть сильные конкуренты), а в его потенциальной мимикрии к чему угодно, в архитектуре Core (конкурентов нет).
Приди в голову кому-нибудь написать систему макросов для того же Python — и большинство Питон-кода получат 20x ускорения. (для этого правда вывод типов должен быть и для возвращаемых значений, но уверен, это искусственное ограничение).
Или Ruby, CoffeeScript, .. то же самое. текущий синтакс с его ограничениями может впечатлить выходцев с С# и Java, остальные будут постоянно
натыкаться на строгости, которые, увы, оценят только шарписты. чего стоит недружелюбность — отсутствие Imperative в генерируемых в проекте фалах.
некто хочет попробовать, пишет незамысловатый цикл с return или break и получает плюху. после кинется читать мануалы? сильно наврядли. не хотят люди новых ограничений. хотят старые сбагрить. педантичные требования раздражают. если к ним не привык конечно. вот Scala — не хотите не пишите точку для доступа к члену, скобки вызова и т.п. и там нет протестов "запретите а то мы ошибемся, руки прочь от скобок!" — хотите пишите, не хотите не пишите. Одерски вместе со мной считаем, если компилятор может разрулить,пусть этим и занимается. и чем меньше я напишу и чем больше получу- тем ясно лучше. а для контроля юнит-тесты в помощь.
умный язык должен предоставлять разумную систему умолчаний на все. а там, если мало, пиши ограничения, уточняй, наяривай.
и платформу скрывать на которой работает с ее косяками. потому что человек может прийти с другой, и эти С# "инновации" ему не нужны даже бесплатно.
Dart вот идет по этому пути. А в Google не идиоты сидят. или и тут поспорим


VD>Хорошие уши торчат. Плохие нет. Надо говорить конкретно. Пока что тебе не нравится то, что другим очень даже нравится.

_C_>>Вот например нафига при вызове функций с ref out каждый раз его явно указывать.

VD>Откровенно говоря сама идея передачи значений по ссылкам мне не нравится. Будь возврат кортежей эффективне, я бы советовал вообще не использовать ref/out-параметров, так как они неудобны и императивны.

VD>Но раз уж они есть — этот синтаксис самый удобный и безопасный. Он заставляет человека четко понимать что происходит. Читая код видно, что я передал ссылку.

да нету такого нигде (C# не в счет). раз объявил и все. а тут — "мы не тупой, но повторяю снова"

VD>Тут ты чего-то странное говоришь. typeof() возвращает рантайм-тип (объект описывающий тип). В качестве параметра он получает имя типа времени компиляции. Как typeof() узнает, что ты хочешь получить информацию о типе T, а не о каком-то другом?

вот код:
def delta : int = Marshal.SizeOf(typeof(memblock)) //memblock — struct
если я напишу
def delta : int = Marshal.SizeOf(memblock)
это ошибка, но что еще в данном контексте может значить memblock? кроме типа.. строку? число?

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

VD>>Другой вопрос. А нужно ли вообще производить это вычисление? Ведь "a.f(42, "ss").Y" испоьзуется только для вычисления типа. Что бы он не вернул тип будет один и тем же. Но этот код может создать побочные эффекты и выкидывать его нельзя.

Влад, тут нужен просто ворнинг. Программист уже сам решит, нужно там вычисление или нет.

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

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

_C_>некто хочет попробовать, пишет незамысловатый цикл с return или break и получает плюху. после кинется читать мануалы? сильно наврядли. не хотят люди новых ограничений. хотят старые сбагрить. педантичные требования раздражают. если к ним не привык конечно. вот Scala — не хотите не пишите точку для доступа к члену, скобки вызова и т.п. и там нет протестов "запретите а то мы ошибемся, руки прочь от скобок!" — хотите пишите, не хотите не пишите. Одерски вместе со мной считаем, если компилятор может разрулить,пусть этим и занимается. и чем меньше я напишу и чем больше получу- тем ясно лучше. а для контроля юнит-тесты в помощь.
_C_>умный язык должен предоставлять разумную систему умолчаний на все. а там, если мало, пиши ограничения, уточняй, наяривай.
_C_>и платформу скрывать на которой работает с ее косяками. потому что человек может прийти с другой, и эти С# "инновации" ему не нужны даже бесплатно.
_C_>Dart вот идет по этому пути. А в Google не идиоты сидят. или и тут поспорим

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

_C_>>>Вот например нафига при вызове функций с ref out каждый раз его явно указывать.

_C_>да нету такого нигде (C# не в счет). раз объявил и все. а тут — "мы не тупой, но повторяю снова"

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

_C_>вот код:
_C_>def delta : int = Marshal.SizeOf(typeof(memblock)) //memblock — struct
_C_>если я напишу
_C_>def delta : int = Marshal.SizeOf(memblock)
_C_>это ошибка, но что еще в данном контексте может значить memblock? кроме типа.. строку? число?

В Nemerle memblock это конструктор. Было бы странно, если бы в некоторых, ничем не выделяющихся контекстах он означал что-то другое.

спасибо! впечатлило!

Z>В nemerle 2 можно будет подумать о диалекте без скобок и точек с запятой. Диалекты там будут делаться и подключаться проще. Реализовать это в первом немерле имеющимися силами просто нереально.

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

_C_>>>>Вот например нафига при вызове функций с ref out каждый раз его явно указывать.

_C_>>да нету такого нигде (C# не в счет). раз объявил и все. а тут — "мы не тупой, но повторяю снова"

Z>А мне нравится. Именно тем, что я не гадаю, как там передается параметр. Не хватает только возможности автоматического объявления переменной в out по месту. Иммутабельной.

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

_C_>>вот код:
_C_>>def delta : int = Marshal.SizeOf(typeof(memblock)) //memblock — struct
_C_>>если я напишу
_C_>>def delta : int = Marshal.SizeOf(memblock)
_C_>>это ошибка, но что еще в данном контексте может значить memblock? кроме типа.. строку? число?

Z>В Nemerle memblock это конструктор. Было бы странно, если бы в некоторых, ничем не выделяющихся контекстах он означал что-то другое.

не знал. так конечно. я ж то думал .. а так да, согласен.

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

VD>В общем, если тебе хочется, то можешь добавить макрос на метод и даже на класс (а то и на пространство имен).

Попробую, думаю, макрос будет полезен

__>>А этот VariantOption когда стоит использовать вместо option ?

VD>Ага.

__>>Только для производительности ? Ведь для юзер кода option должно хватить.

VD>Ну, вот в парсере использовать option[T] очень не выгодно, например. И в компиляторе тоже. Думаю замена с option[T] на ValueOption[T], а еще лучше на ObjectOption[T] даст заметное ускорение компилятора.

Почему не заменить ? Учитывая возможности ExtensionPattern, можно получить вполне удобное применение без проигрыша производительности.
Если это еще улучшает скорость компилятора, то вообще

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

_C_>Вот многовато запретов. Человек заходит с С++ или Питона (первые ищут жизнь полегче, вторые — скорости) к примеру, а ему тут запреты. дайте хоть путь обойти. "вот модуль, пишите почти как раньше. получите бонусы. но учтите, что истина где-то рядом" — было бы разумно.

Как раз в Python много запретов и это считается хорошим тоном.
Как же Python Zen: "There should be one—and preferably only one—obvious way to do it" ?

_C_>да нету такого нигде (C# не в счет). раз объявил и все. а тут — "мы не тупой, но повторяю снова"

Вот в С++ если есть указатель не вполне ясно что код делает:

void f(int* a) { }

int x;
f(&x);

Тут меняем переменную, инициализируем или просто работаем со значением ?

Как раз в C# правильно сделали. Позволяет легче понимать код.
А вообще ref/out в Nemerle практически не нужны, разве что в местах критичных для производительности.
Кортежи и variant-ы решают проблему возврата множества значений.
Если у вас в Nemerle коде много ref/out , то замените их на более удобные фичи языка.

Скажем стандартный паттерн TryParse:

// C#
class My
{
  public static bool TryParse(string s, out My m) { ... }
}

// Nemerle
class My
{
  public static TryParse(s : string) : option[My] { ... }
}

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

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

Calling static methods on type parameters is illegal, part one
Calling static methods on type parameters is illegal, part two
Calling static methods on type parameters is illegal, part three

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

P.S.
Woraround:

typeof(<type name>).GetMethod("<method name>").Invoke(null, new object[]{<list of parameters if any>});

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

VD>ValueOption[T] — это структура — аналог типа optin[T]. ValueOption[T] банально быстрее optin[T] так как optin[T] — ссылочный тип, а ValueOption[T] структура.

А почему бы сам option[T] не переделать в структуру? Сделать Extension Pattern с теми же именами Some(value) и None, чтобы внешне все выглядело так же и существующий код нормально компилировался.
Или где-то требуется, чтобы он был ссылочным типом?

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


Z>>А мне нравится. Именно тем, что я не гадаю, как там передается параметр. Не хватает только возможности автоматического объявления переменной в out по месту. Иммутабельной.

_C_>это привычка . как одноглазая баба, с которой, живя в лесу, привыкаешь и не замечаешь, и находишь даже очаровательной со временем.
_C_>но появись двуглазая альтернатива- исход будет решен.

Да ладно. Рассказывай такие сказки тем, у кого действительно нет альтернатив. Я знаком с достаточно большим количеством языков. ref и out это редко используемые костыли, низкоуровневые оптимизации. Очень хорошо, что они видны в коде. В С++ глядя на вызов можно легко предположить, что передается ссылка, они там чаще чем по значению ходят. А вот в дотнете ref/out настолько редкая птица, что мозг без подсказок этот вариант просчитывать не будет.

Z>>В Nemerle memblock это конструктор. Было бы странно, если бы в некоторых, ничем не выделяющихся контекстах он означал что-то другое.

_C_>не знал. так конечно. я ж то думал .. а так да, согласен.

В отличии от C#, конструктор в nemerle не оператор (new typename(..)), а функция typename(...). Она может быть использована как любая другая функция в качестве ФВП.