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

Z>Влад, тут нужен просто ворнинг. Программист уже сам решит, нужно там вычисление или нет.
И что дальше? Будешь держать проект с ворнингом?

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

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

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

Как-то не задумывался об этом.
Однако да, 1-0 в пользу отброса 'new' :

using System.Console;
 
class A { public P : int { get { 0 } } }
 
def f(g)
{
  def x = g();
  WriteLine($"x.P - $(x.P)");
}
 
f(A)

x.P — 0

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

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

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

Зафиг вообще нужен ворнинг? Какая-то странная позиция. Вроде как считаем поведение ненормальным, но боимся назвать вещи своими именами.

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

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

Давайте вы покажите хотя бы одно обсуждение, где кто-то критиковал бы поведение принятое в C#.
Люди не даром ввели это требование. Это грабли и им не место в языке.

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

Очень смешно. Надеюсь ты просто очепятался и имелось в виду "мутабельной" (по русски говоря — изменяемой).

Не хватает? Ну, так сделай. Задачка не сложная.
Я вот почти не использую эти ref/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 это конструктор. Было бы странно, если бы в некоторых, ничем не выделяющихся контекстах он означал что-то другое.

Причем тут конструктор? memblock имеет тип memblock. В SizeOf требуется тип System.Type. Что странного что такое преобразование осуществляется не магически, а с помощью функции? На оборот, отлично видно что происходит в коде.

В общем, товарищ нашел к чему докопаться. Если нечего делать пусть сделает макрос SizeOf который будет принимать имя типа и возвращать System.Type.

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

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

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

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

Тут такой вопрос. Весь дизайн (ну, за исключением отдельных вопросов вроде точек в параметрах типов) серьезно продуман. Все сделано не с дури. Глупого копирования не было. Везде где в языках (из которых производилось заимствование) было что-то криво, кривые решения не брались. Из того же Шарпа много чего выикинули. Это и оператор as, и разрешение пегрузок при наличии виртульных членов, и много чего еще.

Кому не нравится что-то, может (в большинстве случаев) создать макросы которые это дело обходят. Так не сложно создать макросы которые сократят синтаксис того же SizeOf. Но это уже будут ваши личные, и что очень важно, локальные изыски.

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

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

Потому что это не малый объем работы.

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

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

Боюсь, что кое-где код может поломаться.

У кого есть время может попробовать на клоне.

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

VD>Давайте вы покажите хотя бы одно обсуждение, где кто-то критиковал бы поведение принятое в C#.
VD>Люди не даром ввели это требование. Это грабли и им не место в языке.

Лана, фик с ним. Убедили.

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

VD>Очень смешно. Надеюсь ты просто очепятался и имелось в виду "мутабельной" (по русски говоря — изменяемой).

Нет, я хочу именно иммутабельную. Ибо out это аналог инициализации переменной.

Хочется чего-то типа:

when (dict.TryGetValue(key, def out val))
{
  // use immutable val
}

сейчас приходится делать:

mutable val; // оно мне не надо в этой области видимости
when (dict.TryGetValue(key, def out val))
{
  // оно мне не надо мутабельное здесь
}

VD>Не хватает? Ну, так сделай. Задачка не сложная.

Задача сложная. Как правильно заметил Wolfhound не очень очевидна даже область видимости. Боюсь даже, что макрами это решить будет сложнее, чем компилятор править.

VD>Я вот почти не использую эти ref/out. Так что и проблем не испытываю.

Я тоже редко.

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

Z>Нет, я хочу именно иммутабельную. Ибо out это аналог инициализации переменной.

Предлагаю initonce:

initonce val;
// Тут mutable

when (dict.TryGetValue(key, out val))
{
  // Тут immutable
}
// Тут immutable

Как реализовать не знаю.

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


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

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

Я вот когда переходил на C# с С++ тоже испытывал неудовольствие, но совсем по другим поводам. Меня угнетало отсутствие шаблонов (тогда еще был C# 1.0 в котором даже дженериков не было) и множественного наследования (МН). Со временем понял, что без МН можно отлично жить. Есть другие подходы, а от МН не только польза, но и вред был не малый. А вот шаблоны — это уже бесспорный и объективный недостаток. Дженерики смогли снизить потребность, но устранить ее не смогли. В немерле я нашел отличную замену шаблонам. На них можно сделать все что угодно. Шаблонам такая гибкость и не снилось. И, главное, что все делается как следует, а не через задницу, как это часто бывало в плюсах.

_C_>некто хочет попробовать, пишет незамысловатый цикл с return или break и получает плюху. после кинется читать мануалы? сильно наврядли.

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

На практике таких проблем нет. Если кто-то умудрился не прочтя ни одной статьи сесть писать код на немерле, то он полезет на форумы или поглядит в чужой код. Пока что такую претензию только ты и высказал. Причем сам же признался, что решение проблемы тебе уже известно. Вот и другим известно. Лично я пишу return раз в месяц. А continue или break использую еще реже. Да что уж там? Практически не использую.

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

_C_> не хотят люди новых ограничений. хотят старые сбагрить.

Ну, а что мы будем рассказывать тем кто с C# или Java-ы переходить? Мол, извиняйте добры молодцы. К нам тут до вас С++-ник заходил и мы под него язык поднастроили, чтобы ему привычнее по первой было? Ну, смешно же!

_C_>педантичные требования раздражают. если к ним не привык конечно. вот Scala

А что Scala в ней как раз ограничений и запретов выше крыши.

_C_> — не хотите не пишите точку для доступа к члену,

Да ладно! Там есть соврешенно непродуманное решение использовать методы как операторы. Проблем от него куда больше чем пользы. Приоритеты и ассоциативность ведь задать нельзя. В результате получается бардак. А осуществить доступ к члену без точки там точно так же нельзя. В С++, кстати, тоже. Ну, а в немерле ты можешь описать нужные тебе операторы в виде макросов. При этом для них можно задать приоритет и ассоциативность. А можешь и полноценный ДСЛ. Причем без приседений и ужимок.

Это как в плюсах. Есть вот метапрограммирование на шаблонах. Но через задницу, на другом языке, медленно, убого и с кучей ограничений. Ну, давай теперь немерл поругаем что он и это говнище не впихнул в себя. Зачем только? Ведь вместо этого есть полноценное прямое решение — макросы. Они гибче, быстрее и их можно писать на том же языке что они расширяют.

_C_>скобки вызова и т.п. и там нет протестов "запретите а то мы ошибемся, руки прочь от скобок!" — хотите пишите, не хотите не пишите.

В Скале ограничений куча. И после С++ на Скале уж точно не будешь себя в своей тарелке чувствовать.

Многие навороты в Скале были сделаны чтобы не вводя макросы позволить создавать ДСЛ-и и расширять язык. Итог фееричный — Одесски пришел к выводу, что нужно добавлять в Скалу макросы. Пока что, прада, без синтаксического расширения. Но если они что-то сделают, то это это будет только делом времени.

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

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

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

Компилятор то многое может разрулить. А вот человек — нет. Язык делается в первую очередь для человека.
И дизайн языка — это очень не простой вопрос. Каждую его деталь надо обкатывать на практике. Так что огульно сувать в язык разную хрень только ради того чтобы быть привычным все подряд — это не подход. Он приведет к превращению языка в помойку.

В Н2 мы планируем сделать языковый конструктор. Разработка языков и их модификаций на нем будет существенно упрощена. Кто хочет может попытать счастье в создании своего супер-языка. А немерл останется тем чем он есть сейчас — скрещиванием C#, ML и макросов.

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

Из всех твоих предложений я бы, пожалуй, пошел только на изменение дефолтных прав доступа для свойств (а не для структур, что смысла не имеет). Вот зачем каждый раз писать public к свойствам я действительно не понимаю. Ведь 99.9% свойств являются публичными, а для 0.1% можно и явно указать.

Но и это будем обсуждать и смотреть на реакцию народа. Ни то можно такого накуралисить...

_C_>юнит-тесты в помощь.

Ну, дык пиши на Жабаскрипте. Ограничений минимум. Без юнит-тестов вообще жить нельзя. Самое то. И МП есть (динамика ведь).

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

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

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

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

_C_>Dart вот идет по этому пути. А в Google не идиоты сидят. или и тут поспорим

Очень смешно. Пока что Гугль занимается откровенной херней. Лучше бы нас поддержали.

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

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

Мало что до этого не было? Теперь будет. Решение хорошее. А то что этого не было в недоязыках вроде С++, меня это мало интересует. Его дизайн только первопроходчеством можно оправдать.

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

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

Это выглядит как передача ссылки на конструктор. Вот это вполне корреткный код для немерла:

module Marshal
{
  public SizeOf[T](func : void -> T) : T { func() }
}
...
Marshal.SizeOf(memblock) // передаем ссылку на конструктор

Да и в любом случае memblock — это конкретный тип. А SizeOf требует другой тип System.Type. Как при этом получить тип для самого System.Type?

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

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

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

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

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

__>>Предлагаю initonce:
WH>Тогда уж просто def без инициализатора.
Тоже вариант
WH>Ты пойми тут проблема не в синтаксисе, а в куче работы по отслеживанию потока исполн\ения.
Это я как раз понимаю.

В Nemerle до сих пор есть баг с отслеживанием out аргументов

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

Z>Нет, я хочу именно иммутабельную. Ибо out это аналог инициализации переменной.
Z>Хочется чего-то типа:
Z>

Z>when (dict.TryGetValue(key, def out val))
Z>{
Z>  // use immutable val
Z>}
Z>

Z>сейчас приходится делать:
Z>

Z>mutable val; // оно мне не надо в этой области видимости
Z>when (dict.TryGetValue(key, def out val))
Z>{
Z>  // оно мне не надо мутабельное здесь
Z>}
Z>

Ах вот ты о чем?... Забавно. Ну, а что делать с ref?

Тогда лучше взять решение из F# — виртуально преобразовывать функции с ref/out-параметрами в функции возвращающие кортеж. Скажем функция:

Foo(a : int, b : ref string, c : out long) : bool

преобразуется в:

Foo(a : int, b : string) : string * long * bool

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

Реализовать будет не просто, правда.

VD>>Не хватает? Ну, так сделай. Задачка не сложная.

Z>Задача сложная. Как правильно заметил Wolfhound не очень очевидна даже область видимости. Боюсь даже, что макрами это решить будет сложнее, чем компилятор править.

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

VD>>Я вот почти не использую эти ref/out. Так что и проблем не испытываю.

Z>Я тоже редко.

Так стоит тогда копья ломать?

VD>>>Не хватает? Ну, так сделай. Задачка не сложная.

Z>>Задача сложная. Как правильно заметил Wolfhound не очень очевидна даже область видимости. Боюсь даже, что макрами это решить будет сложнее, чем компилятор править.

VD>Я думал ты о поддержке в IDE говоришь. Ну, типа автоматом создавать переменную по кнопке.

VD>>>Я вот почти не использую эти ref/out. Так что и проблем не испытываю.

Использование ref out это от недоразвитости функциональных фич языка.

но в импортируемом коде такое бывает.

и.. в Nemerle если при возврате создается объект-кортеж, а функция крутится в долгом цикле, это может замедлить
код на порядок-два. и вот это проблема, почему даже здесь имеет смысл это использовать.
или есть козырьоптимизация в рукаве?

VD>В прочем, можно специально создать парочку шаблонов для начинающих с большим императивным стажем. Назвать только как-то, чтобы было понятно. Или сделать визард в котором чекбоксами предлагать нужные возможности выбрать.

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

_C_>>педантичные требования раздражают. если к ним не привык конечно. вот Scala
VD>А что Scala в ней как раз ограничений и запретов выше крыши.
Да там компилятор рулит и разруливает, все что можно.

_C_>> — не хотите не пишите точку для доступа к члену,

VD>Да ладно! Там есть соврешенно непродуманное решение использовать методы как операторы. Проблем от него куда больше чем пользы. Приоритеты и ассоциативность ведь задать нельзя. В результате получается бардак. А осуществить доступ к члену без точки там точно так же нельзя.

когда я интересовался было можно. видать староверы-параноики Одерски подкупили.

VD>Многие навороты в Скале были сделаны чтобы не вводя макросы позволить создавать ДСЛ-и и расширять язык.
Согласен!
VD>Итог фееричный — Одесски пришел к выводу, что нужно добавлять в Скалу макросы. Пока что, прада, без синтаксического расширения. Но если они что-то сделают, то это это будет только делом времени.
ссылку посмотрел бы. он противник, но идет навстречу пожеланиям масс.

VD>Компилятор то многое может разрулить. А вот человек — нет. Язык делается в первую очередь для человека.
VD>И дизайн языка — это очень не простой вопрос. Каждую его деталь надо обкатывать на практике. Так что огульно сувать в язык разную хрень только ради того чтобы быть привычным все подряд — это не подход. Он приведет к превращению языка в помойку.

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

VD>В Н2 мы планируем сделать языковый конструктор. Разработка языков и их модификаций на нем будет существенно упрощена. Кто хочет может попытать счастье в создании своего супер-языка. А немерл останется тем чем он есть сейчас — скрещиванием C#, ML и макросов.

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

VD>Из всех твоих предложений я бы, пожалуй, пошел только на изменение дефолтных прав доступа для свойств (а не для структур, что смысла не имеет). Вот зачем каждый раз писать public к свойствам я действительно не понимаю. Ведь 99.9% свойств являются публичными, а для 0.1% можно и явно указать.

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

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

_C_>>Dart вот идет по этому пути. А в Google не идиоты сидят. или и тут поспорим
VD>Очень смешно. Пока что Гугль занимается откровенной херней. Лучше бы нас поддержали.

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

VD>Мало что до этого не было? Теперь будет. Решение хорошее. А то что этого не было в недоязыках вроде С++, меня это мало интересует. Его дизайн только первопроходчеством можно оправдать.

постоянно спрашивать человека, в своем ли он уме, нетактично.

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

я уже покаялся, кто ж знал что дефолтный конструктор у вас без скобок

в своем ответе на этот пост я мог быть неправильно понят:

VD>Мало что до этого не было? Теперь будет. Решение хорошее. А то что этого не было в недоязыках вроде С++, меня это мало интересует. Его дизайн только первопроходчеством можно оправдать.

Я:постоянно спрашивать человека, в своем ли он уме, нетактично.

Имел ввиду со стороны компилятора, когда он постоянно спрашивает меня о ref и out требуя их явного указания.

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

VD>>Мало что до этого не было? Теперь будет. Решение хорошее. А то что этого не было в недоязыках вроде С++, меня это мало интересует. Его дизайн только первопроходчеством можно оправдать.

_C_>Имел ввиду со стороны компилятора, когда он постоянно спрашивает меня о ref и out требуя их явного указания.

Ну, и правильно делают. Ты один раз пишешь код и 100500 раз его читаешь. Так что лучше чуть-чуть покорячиться написав ref, но потом понимать, что переменная по ссылке передается.

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