M>>Причем тут списки? M>>Так никто про списки изначально и не говорил SR>Притом, что в ваших образцах в большинстве случаев приводятся списки. SR>То есть, что-то типа {obj1, obj2, _, {obj3, _ }, _}. SR>Я же вам в который раз отвечаю, что такие образцы легко релизуются в java. Легко по сравнению со вторым типом. SR>А вот более интересные типа Obj1(Obj2(_, Obj3())) у вас встречаются значительно реже.
{a, b, c} — это кортеж
[a, b, c] — это список
Птаница в незнакомом синтаксисе просто произошла
Таким образом,
match({a, b, c})
это сопоставление с экземпляром класса типа
class Elem {
a;
b;
c;
}
где a, b, c — это поля произвольного типа
поэтому все остальное поскипано, потому что мы возвращаемся к коду из первого примера:
class Term
case class Num(n: int) extends Term
case class Var(name: String) extends Term
case class Mul(l: Term, r: Term) extends Term
case class Add(l: Term, r: Term) extends Term
// Now let's say we want to implement some simplification rules on such terms.
// Two useful simplifications apply the equalities:
// 0 * x = 0
// 1 * x = x
def simplify(term: Term) = term match {
case Mul(Num(0), x) => Num(0)
case Mul(Num(1), x) => x
case _ => term
}
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, SmbdRsdn, Вы писали:
M>>>Более того, если нас не интересует тимп полей, а только их структура? SR>>Что же не привели образец для сопоставления? Уверен я легко мог бы сделать такой и на Java. C>Нельзя. Точнее, можно, но совершенно непрактично.
Так нельзя или можно?
Если можно, то в чем будет непрактичность?
M>>>Сколько перегруженых операторов equals придется писать для каждого отдельного случая? SR>>0. equals пишется для вариантов, но при поддержке компилятора и среды его можно и не писать. C>?? equals можно автоматически сгенерировать с помощью IDE.
Это был вопрос? Если да, то что удивляет? Чего только сейчас IDE не генерируют.
Например Eclipse по
class A {
final Object b;
Object c;
}
в несколько щелчков мышью сделает
class A {
final Class1 b;
Class2 c;
public A(Class1 b, Class2 c) {
this.b = b;
this.c = c;
}
public Class1 getB() {
return b;
}
public void setC(Class2 c) {
this.c = c;
}
public Class2 getC() {
return c;
}
}
Сами понимаете, что добавить еще и equals не сложно.
Re[22]: Действительно ли ML языки хороши в компиляторописани
Здравствуйте, WolfHound, Вы писали:
WH>Это вобще туплы.
Будем считать частным случаем нетипизированного списка, у которого в качестве элемента может быть другой список.
WH>В этот нельзя. WH>Язык статически типизированный. WH>В динамически типизированных языках таких как erlang можно.
Как раз в последних сообщениях разговор, насколько я понимаю, шел про erlang.
WH>Теоритически все можно сделать... особенно на словах...
Теоретически и опровергнуть можно, особенно на словах.
WH>Покажи код увидишь.
Может быть покажете свою мощь на уже выложенных мной примерах?
WH>Устойчивость к дуракам типа меня.
Уже боюсь. WH>Ну и чтобы лишних проверок не делал.
Что, совсем?
WH>Вот еще за тебя делать твою работу.
Что значит за меня, я ее уже проделал.
WH>Ты где настолько умные компиляторы видел?
Про интеллект компиляторов тоже отвечал. Могу только повторить.
Да, собственно в теме уже приводился пример, который развертывает сопоставление с образцом в набор if'ов на lua. WH>Я покачто видел только компиляторы которые генерили оптимальный код только если точно знали что происходит.
Так и тут.
SR>>"Грязь" — там только в необходимости заранее объявлять переменные. WH>Там ее еще много.
Да вроде все чисто. Впрочем с благодарностью приму указание на конкретную грязь.
WH>Аргументов за нет и быть не может. WH>Ибо невозможно обосновать наличие текста который совершенно ничего не дает.
Все-таки это вопрос стиля конкретного языка. Есть в которых объявляют, а есть в которых нет.
SR>>так и против использования переменных без их объявления. WH>А это вобще бред. WH>Переменные объявляются в коде паттерна.
Пусть так, но все-таки в языке имеется и явный синтаксис объявления переменной.
SR>>Сами же образцы для сопоставления отличаются несущественно. WH>На игрушечных примерах.
Как показывать преимущества Scala над Java так примеры нормальные, а как выяснится, что преимущества и нет, так примеры игрушечные.
WH>Полный код в студию. WH>В чем проблема?
С моей точки зрения код тривиален. С точки зрения моих противников код не может существовать.
Так как мои противники люди нетривиальные (это похвала) вероятно мой код весьма интересен.
Поэтому может быть мне стоит его представить в более широковещательном виде, например в виде статьи в журнале и статьи на какой-либо конкурс.
Re[23]: Действительно ли ML языки хороши в компиляторописани
Здравствуйте, SmbdRsdn, Вы писали:
SR>>>Что же не привели образец для сопоставления? Уверен я легко мог бы сделать такой и на Java. C>>Нельзя. Точнее, можно, но совершенно непрактично. SR>Так нельзя или можно?
Нельзя.
SR>Если можно, то в чем будет непрактичность?
Тонны кода.
M>>>>Сколько перегруженых операторов equals придется писать для каждого отдельного случая? SR>>>0. equals пишется для вариантов, но при поддержке компилятора и среды его можно и не писать. C>>?? equals можно автоматически сгенерировать с помощью IDE. SR>Это был вопрос? Если да, то что удивляет? Чего только сейчас IDE не генерируют.
Нет, это было удивление. Я прекрасно знаю как сейчас работают Java IDE (чай не зря 8 лет на Java пишу...).
SR>Сами понимаете, что добавить еще и equals не сложно.
Ага. Только и получаются тонны ненужного кода в результате.
Sapienti sat!
Re[21]: Действительно ли ML языки хороши в компиляторописани
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, FR, Вы писали:
FR>>Вообще классно пишешь, и главное так хитро и тонко, я вот почитал и практическм перестал сомневатся в преимуществах ML образных WH>Давай-давай. WH>У нас конкурентов меньше будет.
Халва, халва, халва
Re[24]: Действительно ли ML языки хороши в компиляторописани
Здравствуйте, Cyberax, Вы писали:
SR>>Сами понимаете, что добавить еще и equals не сложно. C>Ага. Только и получаются тонны ненужного кода в результате.
Вообще у меня дежавью, помню спорил лет восемь назад с закоренелым сишником о пользе и необходимости классов, в общем аргументы практически один к одному и главный "все можно сделать".
Re[25]: Действительно ли ML языки хороши в компиляторописани
Здравствуйте, FR, Вы писали:
C>>Ага. Только и получаются тонны ненужного кода в результате. FR>Вообще у меня дежавью, помню спорил лет восемь назад с закоренелым сишником о пользе и необходимости классов, в общем аргументы практически один к одному и главный "все можно сделать".
Классы — это ещё фигня. Их, действительно, совсем не так уж сложно сделать.
А вот pattern matching — это вещь уже совсем другого уровня сложности.
Sapienti sat!
Re[26]: Действительно ли ML языки хороши в компиляторописани
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, FR, Вы писали:
C>>>Ага. Только и получаются тонны ненужного кода в результате. FR>>Вообще у меня дежавью, помню спорил лет восемь назад с закоренелым сишником о пользе и необходимости классов, в общем аргументы практически один к одному и главный "все можно сделать". C>Классы — это ещё фигня. Их, действительно, совсем не так уж сложно сделать.
Вопрос только, какие именно классы
Хотя, конечно, можно для каждой задачи свой вариант классов ваять
Re[23]: Действительно ли ML языки хороши в компиляторописани
Здравствуйте, SmbdRsdn, Вы писали:
SR>Будем считать частным случаем нетипизированного списка, у которого в качестве элемента может быть другой список.
Кортежи не списки.
Это совсем другие зверьки.
WH>>Теоритически все можно сделать... особенно на словах... SR>Теоретически и опровергнуть можно, особенно на словах.
Опровергать то чему нет никаких подтверждений не имеет смысла.
Оно опровергнуто по умолчанию.
WH>>Покажи код увидишь. SR>Может быть покажете свою мощь на уже выложенных мной примерах?
Примеры без того что их исполняет не имеют смысла ибо это не болие чем псевдокод и работать они не могут.
WH>>Вот еще за тебя делать твою работу. SR>Что значит за меня, я ее уже проделал.
Вот и покажи раз проделал.
Иначе придется сделать вывод что все это пустой треп.
SR>Про интеллект компиляторов тоже отвечал. Могу только повторить.
Да хоть заповторяйся умнее они не станут.
SR>Да, собственно в теме уже приводился пример, который развертывает сопоставление с образцом в набор if'ов на lua. Компилятор действовал в условиях полной определенности.
SR>Все-таки это вопрос стиля конкретного языка. Есть в которых объявляют, а есть в которых нет.
А тут переменные объявляют.
Это не бейсик какойнибуть где переменные объявляются при первом обращении.
Тут объявление явное.
SR>Пусть так, но все-таки в языке имеется и явный синтаксис объявления переменной.
Синтаксис дело десятое.
Главное что переменные всегда объявляются явно.
SR>С моей точки зрения код тривиален. С точки зрения моих противников код не может существовать.
Я могу придумать сотни вариантов того что делает вид что работает.
Так что код в студию.
SR>Так как мои противники люди нетривиальные (это похвала) вероятно мой код весьма интересен. SR>Поэтому может быть мне стоит его представить в более широковещательном виде, например в виде статьи в журнале и статьи на какой-либо конкурс.
Да ты хотябы тут покажи.
Или таки все это пустой треп?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Действительно ли ML языки хороши в компиляторописани
Здравствуйте, Mamut, Вы писали:
M>Птаница в незнакомом синтаксисе просто произошла
Кортеж или список это примерно одно и тоже, с точки зрения сопоставления с образцом.
M>Таким образом, M>
M>match({a, b, c})
M>
M>это сопоставление с экземпляром класса типа
Кортеж, я так понимаю, отдельный тип, а не любой класс с полями. M>
M>class Elem {
M> a;
M> b;
M> c;
M>}
M>
И сопоставлять должно что-то в духе — match(Elem(a,b,c))
Иначе возникает очевидная путаница между классами у которых одинаковые внутренние типы, например Add и Sum.
M>где a, b, c — это поля произвольного типа
M>поэтому все остальное поскипано, потому что мы возвращаемся к коду из первого примера:
Зачем возвращаемся не понятно. Код сопоставления к этому примеру я уже приводил.
Re[24]: Действительно ли ML языки хороши в компиляторописани
Здравствуйте, Mamut, Вы писали:
M>Потом кто-то это будет редактировать под vi через ssh
Гм, это какой-то каменный век хотя может быть в erlang исходный код хранится рядом с бинарным?
В Java же ни на тестовом, ни на производственном сервере никаких java файлов и не будет — нечего редактировать.
Я уж молчу, что как правило у разработчиков отсутствует доступ к развертыванию не то что на производственный, но даже и на тестовый сервер.
Re[24]: Действительно ли ML языки хороши в компиляторописани
Здравствуйте, Cyberax, Вы писали:
C>Нельзя.
То нельзя, то можно.
C>Тонны кода.
Если под тонной понимать тысячу строк, то это в современных условиях ерунда.
Вот если бы речь шла о мегатоннах.
Да и то, достоточно посчитать количество строк в JDK, а люди, тем не менее его легко используют.
C>Нет, это было удивление. Я прекрасно знаю как сейчас работают Java IDE (чай не зря 8 лет на Java пишу...).
И что же вас удивило в генерации кода на IDE?
C>Ага. Только и получаются тонны ненужного кода в результате.
Если ненужного зачем генерировать?
Re[23]: Действительно ли ML языки хороши в компиляторописани
M>>Птаница в незнакомом синтаксисе просто произошла SR>Кортеж или список это примерно одно и тоже, с точки зрения сопоставления с образцом.
Ту хум хао, как говорится
M>>Таким образом, M>>
M>>match({a, b, c})
M>>
M>>это сопоставление с экземпляром класса типа SR>Кортеж, я так понимаю, отдельный тип, а не любой класс с полями.
Чем класс не тип?
M>>
M>>class Elem {
M>> a;
M>> b;
M>> c;
M>>}
M>>
SR>И сопоставлять должно что-то в духе — match(Elem(a,b,c)) SR>Иначе возникает очевидная путаница между классами у которых одинаковые внутренние типы, например Add и Sum.
Что-то в духе? Что будет сопоставлять? Кто будет писать эту функцию match?
M>>где a, b, c — это поля произвольного типа
M>>поэтому все остальное поскипано, потому что мы возвращаемся к коду из первого примера: SR>Зачем возвращаемся не понятно. Код сопоставления к этому примеру я уже приводил.
Еще раз.
На пример
def simplify(term: Term) = term match {
case Mul(Num(0), x) => Num(0)
case Mul(Num(1), x) => x
case _ => term
}
Был приведен псевдо код с неким term.equals, причем кто будет писать этот equals — непонятно. Предполагается, что IDE
будет приведена совсем третья функция, разбирающая эту структуру.
И каждй раз программисту (особенно новому) придется разбираться — что делает тот или иной цикл, те десять функций equals, тот десяток методов matches и т.п.
Давай таки по чесному сравним не только два этих отрывка кода, но и то, что за ними стоит
Мелкий ликбез по Erlang-у:
Атомы всегда начинаются с маленькой буквы — это просто имена. Больше всего похожи на перечисления в С++
Переменные начинаются с большой буквы.
Запись [H|T] означает: список из головы H и хвоста T, где T может быть любым списком, в том числе и пустым.
Для кортежей {...} такой синтаксис не возможен.
Запись [H] означает список из одного элемента H
M>>
M>>case input_data of
M>> [{elem1, elem2}|T] -> сделаем что-то одно
M>> [[L]|T] -> разбираем вложенный список
M>> {a, b} -> а ждесь вообще не список, оппаньки
M>> {[H|T], [H2|T2]} -> и здесь не список передали. но внутри список
M>> {a, {b, {c, d}}} -> здесь списком даже и не пахнет, но все разобрали
M>> {_, _, _, _, x} -> нам важен только 5-й параметр, хотя струкутра может быть такой:
M>> {{a, b, c}, [H|T], {[H2|T2]}, d, e} -> и все равно мы ее сможем разобрать
M>>end
M>>
Это вполне законченный кусок кода.
Т.е. вместо русских комментариев после -> можно написать любое допустимое выражение Erlang-а
Кроме того, можно дописать сколько угодно условий, с какими угодно образцами.
Можно дописать условие, которое будет совпадать в том случае, если ни один другой образец не совпал.
И input_data и совпавшие литералы и забинденные переменные могут быть любого допустимого в Erlang-е типа: числом, сторокой, атомом, кортежем, списком, записью и т.д.
Т.о. код не накладывает никаких требований на типы элементов, с которыми мы тут работаем.
SR>
Какого здесь типа будет data — у него как минимум должна быть реализована matches. Т.е. сразу ограничение в сравнении с вариантом Erlang-а
Ладно, давай предположим, что у нас есть некоторый класс PMatcher с функцией matches, которая, принимает 2 параметра, данные и паттерн, в результате выдаёт совпало/несовпало и биндит переменные указанные в шаблоне.
Данные понятно — Оbject — чтобы можно было любой тип подавать.
Отрывок под это дело переписывается элементарно.
Мы не будем придираться, что этот класс и его функцию matches нужно как-то реализовывать и это точно займёт не 2-3 строки. Ведь и в Erlang-е PM не по волшебству берётся.
Лучше посмотрим во что выливаются остальные требования.
Ну про данные понятно — они должны быть любые.
Теперь про шаблон — как его можно записать?
Попробуем создавать структуры-шаблоны. Причём, мы хотим от шаблонов как можно большей естественности — т.е. чтобы они как можно меньше отличались от кода, который мы пишем создавая наши структуры.
С константами вроде проблем нет.
А вот с массивами уже есть: предположим мы хотим нарисовать такой шаблон для массива целых, из 3х элементов, где первый нам не важен (_), второй всегда равен 2 а третий сбиндить в указанную переменную...
Кажется придётся отказатся от массивов, всё равно нормальные пацаны используют коллекции...
Едем дальше — Классы.
Значит как минимум одно требование у нас есть — в классе должен быть реализован некий метод equals который, как я понимаю, осушествляет глубокое сравнение с учётом биндинга и пропусков (_).
Ок. Расширяем Эклипс или НетБинс чтоб она за нас его рисовала.
Но этот код уже таки нужно учитывать — т.к. нам таки приходится изменять классы под PM.
Опять же, пусть есть класс:
class Elem {
public int a;
public double b;
public string c;
Elem(int aa, double bb, string cc) {a = aa; b = bb; c = cc;}
}
Хотим написать шпблон, где поле a нас не интересует, поле b должно быть 3.14, а поле c сбиндить в указанную переменную...
Если мы хотим, чтобы шаблон создавался таким же кодом, как и обычные структуры, то очевидно, здесь нужно менять типы, т.е. вместо int, double, string ставить Object.
Очевидно, что с таким классом будет изрядно неудобно работать в остальных местах.
Кроме того, в этом случае нельзя будет работать с классами, написанными не нами...
Значит такой способ задания шаблона не катит. Попробуем по другому: для каждого интересующего нас класса можно создать PM-двойника, который бы мы использовали при задании шаблонов. Этим кстати можно даже обойти проблему с массивами.
Наверное тоже можно нагнуть Эклипс и несколькими щелчками получить двойника заданного класса. Правда остаётся неприятная проблема с типизацией. Да и код от этих двойников раздувается...
Получается, что общий код для поддержки твоего псевдокода по объёму его сильно превосходит, без учёта самого движка сопоставления.
И объявления каких-то переменных, которые в псевдокоде мелькали — действительно можно не учитывать на этом фоне.
Кстати, а куда будем учитывать плагины которые тоже нужно писать и поддерживать?
P.S. С Java разбирался довольно давно. Поэтому, если кто-нибудь расскажет как обойти эти проблемы, с кодом, за которым понятно что стоит, буду признателен.
Только почему-то кажется, что таки легче скалу взять.
P.P.S. А ты правда правда считаешь что куски эквивклетны по понятности/объёму, или просто отстаиваешь любимый язык?
Несколько месяцев назад я примерно с такими же доводами выступал. Правда в качестве псевдокода использовал С++.
... << RSDN@Home 1.2.0 alpha 4 rev. 1065>>
Re[24]: Действительно ли ML языки хороши в компиляторописани
Здравствуйте, WolfHound, Вы писали:
SR>>Может быть покажете свою мощь на уже выложенных мной примерах? WH>Примеры без того что их исполняет не имеют смысла ибо это не болие чем псевдокод и работать они не могут.
Определение псевдокода в студию! Или это всего лишь треп?
Большинство остальных оппонентов скорее согласны, что код работать может, но будет много кода илл он его применение будет сильно рассогласовано.
WH>Компилятор действовал в условиях полной определенности.
Что мешает компилятору и тут действовать в условиях полной определенности?
WH>А тут переменные объявляют. WH>Это не бейсик какойнибуть где переменные объявляются при первом обращении. WH>Тут объявление явное. WH>Главное что переменные всегда объявляются явно.
Вот-вот — явно. А не в середине или в конце набора скобок, групповых символов, имен классов, строковых, числовых и логических литералов.
WH>Синтаксис дело десятое.
Может быть для Lisp так и есть.
WH>Или таки все это пустой треп?
Конечно пустой, странно, что вы это так долго до этого доходили.
Re[24]: Действительно ли ML языки хороши в компиляторописани
Здравствуйте, Mamut, Вы писали:
M>Чем класс не тип?
Тип конечно. Но кортеж это отдельный тип, такой же как например какой-нибудь другой — String, например.
То есть всякий кортеж класс, но не всякий класс кортеж.
M>Что-то в духе? Что будет сопоставлять?
Это такие выражения в русском языке.
M>Кто будет писать эту функцию match?
А кто до этого писал? Имя match у вас же возникает, я просто заменил образец, то есть параметр функции.
Если бы я приводил пример на Java, то использовал бы new Elem(a, b, c).
M>Еще раз.
M>На пример M>
M>def simplify(term: Term) = term match {
M> case Mul(Num(0), x) => Num(0)
M> case Mul(Num(1), x) => x
M> case _ => term
M>}
M>
M>Был приведен псевдо код с неким term.equals, причем кто будет писать этот equals — непонятно. Предполагается, что IDE.
M>был приведен совсем другой код, разбирающи списки
Обращаю внимание, что вы в этих двух примерах непринужденно перешли с одного языка на другой, насколько я понимаю.
M>На пример M>
M>будет приведена совсем третья функция, разбирающая эту структуру.
Для второго и третьего примера функция одна как я уже писал. validate и проход по циклу использовался для уточнения условий задачи.
M>И каждй раз программисту (особенно новому) придется разбираться — что делает тот или иной цикл, те десять функций equals, тот десяток методов matches и т.п.
Гм, зачем разбираться? Цикла вообще нет, функции equals тривиальны и многократно описаны до какого-бы-то-нибыло сопоставления с образцом, метод matches тоже один. Странно, что вы не видите, что все это можно легко привести к одному виду.
M>Это мы еще про байндинг переменных не упомянули.
Почему, кстати? Связывание я приводил со своего первого примера.
Re[25]: Действительно ли ML языки хороши в компиляторописани
M>>И каждй раз программисту (особенно новому) придется разбираться — что делает тот или иной цикл, те десять функций equals, тот десяток методов matches и т.п. SR>Гм, зачем разбираться? Цикла вообще нет, функции equals тривиальны и многократно описаны до какого-бы-то-нибыло сопоставления с образцом, метод matches тоже один. Странно, что вы не видите, что все это можно легко привести к одному виду.
Пока этого одного вида пока никто так и не увидел
M>>Это мы еще про байндинг переменных не упомянули. SR>Почему, кстати? Связывание я приводил со своего первого примера.
Где он был не совсем корректным и не соответствовал условиям задачи.
Кстати, насчет связывания переменных.
[{elem1, elem2}|T]
data.matches(list(elem1, elem2), T)
Что такое T в примере на Java, и откуда оно взялось?
Здравствуйте, Tonal-, Вы писали:
T>Давай таки по чесному сравним не только два этих отрывка кода, но и то, что за ними стоит
T>Мелкий ликбез по Erlang-у:
Замечу все-таки, что начинал я сравнение не с erlang'ом, а со Scala.
Конечно, мне бы хотелось и продолжать сравнивать со Scala, но возражающие мне в основном используют erlang.
А вникать в отдельный язык ФП с его тонкостями желания нет, поэтому думаю, что непонимания с обеих сторон будет еще немало.
T>Атомы всегда начинаются с маленькой буквы — это просто имена. Больше всего похожи на перечисления в С++ T>Переменные начинаются с большой буквы. T>Запись [H|T] означает: список из головы H и хвоста T, где T может быть любым списком, в том числе и пустым. T>Для кортежей {...} такой синтаксис не возможен. T>Запись [H] означает список из одного элемента H
M>>>
M>>>case input_data of
M>>> [{elem1, elem2}|T] -> сделаем что-то одно
M>>> [[L]|T] -> разбираем вложенный список
M>>> {a, b} -> а ждесь вообще не список, оппаньки
M>>> {[H|T], [H2|T2]} -> и здесь не список передали. но внутри список
M>>> {a, {b, {c, d}}} -> здесь списком даже и не пахнет, но все разобрали
M>>> {_, _, _, _, x} -> нам важен только 5-й параметр, хотя струкутра может быть такой:
M>>> {{a, b, c}, [H|T], {[H2|T2]}, d, e} -> и все равно мы ее сможем разобрать
M>>>end
M>>>
T>Это вполне законченный кусок кода. T>Т.е. вместо русских комментариев после -> можно написать любое допустимое выражение Erlang-а T>Кроме того, можно дописать сколько угодно условий, с какими угодно образцами. T>Можно дописать условие, которое будет совпадать в том случае, если ни один другой образец не совпал. T>И input_data и совпавшие литералы и забинденные переменные могут быть любого допустимого в Erlang-е типа: числом, сторокой, атомом, кортежем, списком, записью и т.д. T>Т.о. код не накладывает никаких требований на типы элементов, с которыми мы тут работаем.
SR>>
T>Какого здесь типа будет data — у него как минимум должна быть реализована matches. Т.е. сразу ограничение в сравнении с вариантом Erlang-а
Смешное возражение, data должна иметь matches только для более понятной инфиксной записи, в противном случае можно записать if (matches(data, pattern)).
T>Ладно, давай предположим, что у нас есть некоторый класс PMatcher с функцией matches, которая, принимает 2 параметра, данные и паттерн, в результате выдаёт совпало/несовпало и биндит переменные указанные в шаблоне. T>Данные понятно — Оbject — чтобы можно было любой тип подавать. T>Отрывок под это дело переписывается элементарно. T>Мы не будем придираться, что этот класс и его функцию matches нужно как-то реализовывать и это точно займёт не 2-3 строки. Ведь и в Erlang-е PM не по волшебству берётся. T>Лучше посмотрим во что выливаются остальные требования. T>Ну про данные понятно — они должны быть любые. T>Теперь про шаблон — как его можно записать? T>Попробуем создавать структуры-шаблоны. Причём, мы хотим от шаблонов как можно большей естественности — т.е. чтобы они как можно меньше отличались от кода, который мы пишем создавая наши структуры. T>С константами вроде проблем нет. T>А вот с массивами уже есть: предположим мы хотим нарисовать такой шаблон для массива целых, из 3х элементов, где первый нам не важен (_), второй всегда равен 2 а третий сбиндить в указанную переменную...
new Object[] {_, 2, x}
T>Кажется придётся отказатся от массивов, всё равно нормальные пацаны используют коллекции...
Отказ от массивов не понятен. T>Едем дальше — Классы. T>Значит как минимум одно требование у нас есть — в классе должен быть реализован некий метод equals который, как я понимаю, осушествляет глубокое сравнение с учётом биндинга и пропусков (_). T>Ок. Расширяем Эклипс или НетБинс чтоб она за нас его рисовала. T>Но этот код уже таки нужно учитывать — т.к. нам таки приходится изменять классы под PM.
Код можно и не писать, я уже приводил пример, вполне можно расширить компилятор.
abstract class Term {};
final class Num extends Term {};
final class Var extends Term {};
@PatternMatching
Term simplify(Term term) {
if (term.equals(new Num(1))) {
}
}
И этот компилятор может например добавить необходимый equals в классы, либо переписать simplify на if (term instanceof Num) и т.д.
T>Значит такой способ задания шаблона не катит. Попробуем по другому: для каждого интересующего нас класса можно создать PM-двойника, который бы мы использовали при задании шаблонов. Этим кстати можно даже обойти проблему с массивами.
Я как раз и приводил код с созданием двойников _Term, _Num и .т.д. Но это для кода работающего здесь и сейчас.
T>Наверное тоже можно нагнуть Эклипс и несколькими щелчками получить двойника заданного класса. Правда остаётся неприятная проблема с типизацией. Да и код от этих двойников раздувается...
Не очень понятно, почему беспокоит раздутие кода, если это отдельные классы. Они могут даже отсутствовать в проекте в виде java файлов, сразу в виде class на какой-либо из стадий сборки. Например по WSDL создается весьма объемный код, который не замедляет восприятие всего проекта отдельным разработчиком.
T>Получается, что общий код для поддержки твоего псевдокода по объёму его сильно превосходит, без учёта самого движка сопоставления.
В случае equals и движка-то никакого не надо.
А в случае списков, кортежей нет и общего кода для поддержки.
T>Кстати, а куда будем учитывать плагины которые тоже нужно писать и поддерживать?
А куда будем учитывать код затраченный на поддержку PM в Scala?
T>P.P.S. А ты правда правда считаешь что куски эквивклетны по понятности/объёму, или просто отстаиваешь любимый язык?
Куски очевидно не равны по объему и по понятности, но близки, правда это в коде, который приводил я.
А вот в первом сообщении на которое я отвечал, объемы различались чуть ли не в десятки раз.
Язык Java не является моим любимым. T>Несколько месяцев назад я примерно с такими же доводами выступал. Правда в качестве псевдокода использовал С++.
Это не псевдокод, повторяю в который раз.
Re[25]: Действительно ли ML языки хороши в компиляторописани
Здравствуйте, SmbdRsdn, Вы писали:
C>>Тонны кода. SR>Если под тонной понимать тысячу строк, то это в современных условиях ерунда. SR>Вот если бы речь шла о мегатоннах. SR>Да и то, достоточно посчитать количество строк в JDK, а люди, тем не менее его легко используют.
Мне плевать сколько кода в JDK. Я его не отлаживаю.
Но мне совсем не плевать, сколько кода придётся читать лично мне.
C>>Нет, это было удивление. Я прекрасно знаю как сейчас работают Java IDE (чай не зря 8 лет на Java пишу...). SR>И что же вас удивило в генерации кода на IDE?
Меня удивило, что это считается большим плюсом...
C>>Ага. Только и получаются тонны ненужного кода в результате. SR>Если ненужного зачем генерировать?
Так как в языке нет средств, чтобы этого избежать.
