Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, varenikAA, Вы писали:
H>Тип обобщить можно, но размерность — только через рефлексивные фичи рантайма: H>Array.CreateInstance и Array.SetValue.
Спасибо за ответ, я правда немного не то имел ввиду,
у меня получилось то что я хотел, просто хотел использовать локальные функции без указания типов,
кол-во представлений и их длину я передаю параметрами.
Локальный вывод типов рулит. Получилось так. Немного непривычно, что требуется фоновая перекомпиляция, чтобы ошибка исчезла.
module Program
{
GetArray[T]() : array[2, T]
{
array.[2][];
}
Main() : void
{
def initArray(rank, size, init)
{
def a = array(rank, size);
for(mutable i = 0, i < rank ; i++)
for(mutable j=0;j<size; j++)
a[i,j] = init();
a
}
def printArray(a, rank, size)
{
for(mutable i = 0, i < rank ; i++)
{
WriteLine();
for(mutable j=0;j < size; j++)
Write("{0,3}", a[i,j]);
}
}
def mixArray(a, rank, size, repeatCount)
{
def rand = Random(Environment.TickCount);
for(mutable i = 0, i < repeatCount ; i++)
{
def i1 = rand.Next(0,rank);
def j1 = rand.Next(0,size);
def i2 = rand.Next(0,rank);
def j2 = rand.Next(0,size);
unless(i1==i2 && j1==j2)
{
def t = a[i1,j1];
a[i1,j1] = a[i2,j2];
a[i2,j2] = t;
}
}
}
def copyArray(a, rank, size)
{
def b = array(rank, size);
for(mutable i = 0, i < rank ; i++)
for(mutable j=0;j < size; j++)
b[i,j] = a[i,j];
b
}
def checkArray(a, b, rank, size)
{
def ret = return: {
for(mutable i = 0, i < rank ; i++)
for(mutable j=0;j < size; j++)
when( b[i,j] != a[i,j])
return (false);
true;}
ret;
}
mutable x = -1;
def g ()
{
x++;
x
}
def a = initArray(4,4, g);
def e = copyArray(a,4,4);
WriteLine(checkArray(a,e,4,4));
repeat(10)
mixArray(a,4, 4, 10);
WriteLine(checkArray(a,e,4,4));
printArray(a,4, 4);
WriteLine($"\n\r$(String('#',80))");
def s = GetArray.[string]();
_ = ReadLine();
}
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, varenikAA, Вы писали:
_NN>Лучше так: _NN>
_NN> foreach (i in [0 .. rank - 1])
_NN>
Спасибо, не подумал!
_NN>Зачем так сложно ? _NN>
_NN> def ret = return: {
_NN> ...
_NN>
Блоки вроде как фишка Nemerle? Стараюсь избавиться от императивщины в своем коде.
Даже Роберт Мартин в последних книгах пишет, что будущее за ФП.
Хотя и является отцом-основателем ООП. Да и опять же любой лишний using это лишняя зависимость, а дядя Боб
учить избегать ненужных зависимостей.
_NN>А вообще можно и через LINQ или встроенные методы типа Exists
Вот это по ФПшному! Но я еще не разобрался со списком Nemerle, поэтому стараюсь базовый синтаксис помучать.
Хочется заметить, что вики хоть и достаточно большое, но не очень удобное в качестве методички по изучению языка.
В том же F# было немного проще разобраться в работе со списками.
AA>Блоки вроде как фишка Nemerle? Стараюсь избавиться от императивщины в своем коде.
В Kotlin есть нечто подобное.
using Nemerle.Imperative и макрос return делает блок автоматически.
Использование: https://github.com/rsdn/nemerle/blob/master/lib/Nemerle.Collections.n#L365
AA>Даже Роберт Мартин в последних книгах пишет, что будущее за ФП. AA>Хотя и является отцом-основателем ООП. Да и опять же любой лишний using это лишняя зависимость, а дядя Боб AA>учить избегать ненужных зависимостей.
Стоит поменьше слушать всяких дядей.
В теории всё красиво, а на практике императивщина банально работает быстрее.
А вообще код надо писать сперва читаемым, а потом только оптимизировать.
_NN>>А вообще можно и через LINQ или встроенные методы типа Exists AA>Вот это по ФПшному! Но я еще не разобрался со списком Nemerle, поэтому стараюсь базовый синтаксис помучать. AA>Хочется заметить, что вики хоть и достаточно большое, но не очень удобное в качестве методички по изучению языка. AA>В том же F# было немного проще разобраться в работе со списками.
printArray по любому императивным будет , ведь WriteConsole надо как-то вызывать
_NN>В Kotlin есть нечто подобное.
Зная историю Nemerle, меня это не удивляет
_NN>using Nemerle.Imperative и макрос return делает блок автоматически.
В этом есть смысл.
_NN>В теории всё красиво, а на практике императивщина банально работает быстрее. _NN>А вообще код надо писать сперва читаемым, а потом только оптимизировать.
Вот это заставило задуматься, нет ли противоречия? Ведь общепринятое мнение, что ФП более читабельно.
_NN>
_NN>a[i1,j1] <-> a[i2, j2]
_NN>
Уже заюзал, вообще пытаюсь решить задачу 15 puzzle, со смешиванием все получилось, а вот решения в лоб пока не вижу.
Что интересно, сам эту головоломку с малых лет складываю иногда секунд за 30, а вот компьютеру объяснить как это делается не знаю.
_NN>С документация да есть проблемы, но в F# то вкладывается денег гораздо больше.
С этим F# что-то не так, я потратил не меньше года на его изучение, синтаксис неплохой, но когда
доходишь до практического применения, то выясняется, что, например, провайдеры типов, работают 50 на 50,
при этом в сообществе в телеграмме, фаны сами ругают эту технологию как не рабочую, и это при том,
что их мэйнтит главный архитектор языка Дон Сайм. Конкретно, пытаюсь слить данные из экселя в базу, в редакторе
все работает, типы выводятся, компилишь — и раз провайдер экселя уже не видит библиотеки.
Такое чувство, что изначально, язык задумывался как скриптовый для прототипирования в режиме REPL.
Тут да, круто, почти как в лисп в емаке. В лиспе круто, что можно каждую функцию отдельно перекомпилить.
Но потом, когда я прочитал про основные различия Nemerle и F#, я понял что F# это очень примитивный язык. Единственное что делает его крутым это
имутабельность и вычислительные выражения типа async {} seq {} и знаменитый MailboxProcessor. Надо полагать, это для тех кто ничего слаще морковки не ел
Лирика.
Здравствуйте, varenikAA, Вы писали:
_NN>>В теории всё красиво, а на практике императивщина банально работает быстрее. _NN>>А вообще код надо писать сперва читаемым, а потом только оптимизировать. AA>Вот это заставило задуматься, нет ли противоречия? Ведь общепринятое мнение, что ФП более читабельно.
Это кто решил ?
ФП хорошо в одном, ООП хорошо в другом.
Система снаружи это изменяемое состояние, внутри функциональные блоки.
В этом плане Nemerle очень удобен.
Позволяет совместить парадигмы.
AA>Но потом, когда я прочитал про основные различия Nemerle и F#, я понял что F# это очень примитивный язык. Единственное что делает его крутым это AA>имутабельность и вычислительные выражения типа async {} seq {} и знаменитый MailboxProcessor. Надо полагать, это для тех кто ничего слаще морковки не ел AA>Лирика.
Вывод типов в F# конечно не такой серьёзный да и макросов нет.
Но за ним есть корпорация
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, varenikAA, Вы писали:
_NN>>>В теории всё красиво, а на практике императивщина банально работает быстрее. _NN>>>А вообще код надо писать сперва читаемым, а потом только оптимизировать. AA>>Вот это заставило задуматься, нет ли противоречия? Ведь общепринятое мнение, что ФП более читабельно. _NN>Это кто решил ?
Вспоминаются различные статьи и лекции(Сошников(автор учебника по ФП на основе F#) точно такое говорил на ютубе),
где сравнивают рекурсивную и императивные реализации quicksort в пользу рекурсивной.
Естественно, речь о ФПшниках.
Согласен, что заявление спорное, но оно есть.
AA>где сравнивают рекурсивную и императивные реализации quicksort в пользу рекурсивной. AA>Естественно, речь о ФПшниках. AA>Согласен, что заявление спорное, но оно есть.
ФП-шный quicksort выглядит примерно так:
-- haskell
quicksort [] = []
quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater)
where
lesser = filter (< p) xs
greater = filter (>= p) xs
-- или такой вариант, близок к варианту на Эрланге ниже
quicksort [] = []
quicksort (x:xs) =
let smallerSorted = quicksort [a | a <- xs, a <= x]
biggerSorted = quicksort [a | a <- xs, a > x]
in smallerSorted ++ [x] ++ biggerSorted
# erlang
qsort([]) -> [];
qsort([Pivot|T]) ->
qsort([X || X <- T, X < Pivot])
++ [Pivot] ++
qsort([X || X <- T, X >= Pivot]).
Людям, знакомым с list comprehensions (erlang) и/или байндингами и гардами в Хаскеле, эта запись может быть сразу понятна, потому что она, по сути, описывает алгоритм так, как он есть. Но чисто технически это «не чистый» quicksort
Здравствуйте, _NN_, Вы писали: _NN>Лучше так: _NN>
_NN> foreach (i in [0 .. rank - 1])
_NN>
Обратил внимание, что в данном случае сначала идет генерация всего списка, а
это на больших (от 1000 элементов) размерах заметная просадка. Не знаю, есть ли аналогичные конструкции для ленивых генераторов в немерле.
Поэтому, в большинстве случаев предпочтительней for(.