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

SR>Определение псевдокода в студию!
Хрень похожая на код но которую нельзя запустить на исполнение.
И пока ты не приведешь тот код который может может оживить твои примерчики они останутся псевдокодом.

SR>Большинство остальных оппонентов скорее согласны, что код работать может, но будет много кода илл он его применение будет сильно рассогласовано.
Еще раз. Я могу придумать сотни вариантов того что делает вид что работает.

SR>Что мешает компилятору и тут действовать в условиях полной определенности?
То что ее нет.

SR>Вот-вот — явно. А не в середине или в конце набора скобок, групповых символов, имен классов, строковых, числовых и логических литералов.
Я думаю умные люди уже поняли чем отличается явное объявление переменной внутри match'а от неявного объявления переменной в какомнибудь позорном васике.

SR>Может быть для Lisp так и есть.
Причем тут лисп? Не меняй тему.

SR>Конечно пустой, странно, что вы это так долго до этого доходили.
Я понял это с первого поста.
Просто ты тут развел кучу демагогии на которую могли повестись мение опытные люди.

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

M>Пока этого одного вида пока никто так и не увидел
Так и общего кода на одном языке (желательно на Scala) тоже не приводилось.

M>Где он был не совсем корректным и не соответствовал условиям задачи.
Не припоминаю особых некорректностей, также как и несоответствия условиям задачи.

M>Кстати, насчет связывания переменных.

M>

M>[{elem1, elem2}|T]
M>

M>

M>data.matches(list(elem1, elem2), T)
M>

M>Что такое T в примере на Java, и откуда оно взялось?

Tail T = new Tail();
class Tail {
  public object[] value;
}

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

C>Мне плевать сколько кода в JDK. Я его не отлаживаю.
8 лет, говорите и не приходилось отлаживать по JDK? Кхм, кхм.
Ну всякое, конечно, бывает.

C>Меня удивило, что это считается большим плюсом...
По вашему большим плюсом было бы отсутствие кодогенерации в IDE?

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

SR>По вашему большим плюсом было бы отсутствие кодогенерации в IDE?
Несомненно.
Это не дело IDE код генерировать.
Это работа компилятора.

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

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

SR>>Большинство остальных оппонентов скорее согласны, что код работать может, но будет много кода илл он его применение будет сильно рассогласовано.
WH>Еще раз. Я могу придумать сотни вариантов того что делает вид что работает.
Если нечто выглядит как утка, крякает как утка и ходит как утка — наверное утка и есть.

SR>>Что мешает компилятору и тут действовать в условиях полной определенности?
WH>То что ее нет.
Подскажем аннотоцией недостающую определенность, делов-то.

WH>Я думаю умные люди уже поняли чем отличается явное объявление переменной внутри match'а от неявного объявления переменной в какомнибудь позорном васике.
Понять-то поняли, явность объявления под вопросом.

function a
  x = 1 * 2 * 3
  a = x * 2
end function

vs

Mul(Mul(Num(1), Num(2)), Num(x)) -> 2 * x

SR>>Может быть для Lisp так и есть.
WH>Причем тут лисп? Не меняй тему.
Притом что:
WH>Синтаксис дело десятое.
Говорят, что синтаксис не имеет значения для Lisp.
Возможно поэтому этот язык программироания не является достаточно понятным.

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

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

WH>Просто ты тут развел кучу демагогии на которую могли повестись мение опытные люди.

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

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

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

SR>>По вашему большим плюсом было бы отсутствие кодогенерации в IDE?
WH>Несомненно.
WH>Это не дело IDE код генерировать.
WH>Это работа компилятора.
Как думаете Eclipse само код генерит или при помощи компилятора?

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

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

WH>>Просто ты тут развел кучу демагогии на которую могли повестись мение опытные люди.

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

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

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

SR>Навыки начинающего Java программиста действительно непросто передать через форум.
Ой какие мы важные.

SR>А именно такой опыт, на мой взгляд, достаточен чтобы дописать оставшийся код.
Если все так просто то что же ты так и не привел код?
Он же простой и уже написан.

SR>Если нечто выглядит как утка, крякает как утка и ходит как утка — наверное утка и есть.
Не разводи демагогию.
Тут у нас не утки, а программная система которая должна работать четко и устойчиво.
И если то что есть у тебя (если вобще есть) ломается с пол пинка то в качестве инструмента для создания промышленных систем оно ну никак не годится.
А мы ведь тут говорим не о игрушках. Или как?

SR>Подскажем аннотоцией недостающую определенность, делов-то.
Полный код в студию.

WH>>Я думаю умные люди уже поняли чем отличается явное объявление переменной внутри match'а от неявного объявления переменной в какомнибудь позорном васике.
SR>Понять-то поняли, явность объявления под вопросом.
Ну если ты не в состоянии отличить объявление при первом использовании и объявление в паттерне то тебе ничем не помоч.
Разница меж тем существенна.
Если ты в васике в одном месте напишешь dashfgflodhbflkjzhxvcb, а в другом dashfgflodhblfkjzhxvcb васик и слова не скажет.
А если тоже самое сделать в скале то получишь по рукам от компилятора.

SR>Говорят, что синтаксис не имеет значения для Lisp.
Ну еще на заборе всякую фигню пишут.
В любом случае не меняй тему.

WH>>Просто ты тут развел кучу демагогии на которую могли повестись мение опытные люди.
SR>Чтобы пресечь подобное тут и находятся на дежурстве такие люди как вы.
Хочешь чтобы я удалил все твои сообщения и отправил в баню за попытку ввести людей в заблуждение?
Это можно устроить.

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

SR>Как думаете Eclipse само код генерит или при помощи компилятора?
Детали.
Главное чтобы код который я пишу был самодостаточным и не требовал помощи IDE для того чтобы он начал работать.

M>>Пока этого одного вида пока никто так и не увидел
SR>Так и общего кода на одном языке (желательно на Scala) тоже не приводилось.

Какой общий код? При поддержке ПМа языком, любой код, его использующий, будет более-менее общим

Если поддержки ПМа нет, то при


M>>Где он был не совсем корректным и не соответствовал условиям задачи.
SR>Не припоминаю особых некорректностей, также как и несоответствия условиям задачи.

Байндились ненужные переменные


M>>Кстати, насчет связывания переменных.

M>>

M>>[{elem1, elem2}|T]
M>>

M>>

M>>data.matches(list(elem1, elem2), T)
M>>

M>>Что такое T в примере на Java, и откуда оно взялось?
SR>

SR>Tail T = new Tail();
SR>class Tail {
SR>  public object[] value;
SR>}
SR>

чаво чаво? T у нас может быть любым объектом — списком, кортежем, классом, встроенным типом и т.п.

Более того, этот T мы можем сразу взять и использовать дальше — в последующих сопоставлениях или сразу по назначению:

match_list([H|T]) ->
    case T of 
        1 -> что-то делаем
        "text" -> делаем что-то еще
        какая-то_сложная_структура -> делаем что-то третье
        _ -> нас вообще T не интересует, работаем с H

Вот из примеров на Scala:

object MatchTest2 extends Application {
  def matchTest(x: Any): Any = x match {
    case 1 => "one"
    case "two" => 2
    case y: Int => "scala.Int"
  }
  println(matchTest("two"))
}

Ключевой момент — в выделенном. Тут мы создаи и заюзали переменную y встроенного типа Int. А могли бы дополнить:

    case z: MyClass => z.MyMethod(); z.field1 = 2;

И вообще — здесь, ответ на аргумент "Pattern matching is unnecessary" а также отсюда

Scala Pattern Matching = Visitor

Scala Pattern Matching from a Java perspective и особенно:

// The simple type match pattern

object MySingleton
val single = MySingleton
single match {case _:MySingleton.type => println("OK")}

Scala for Java Refugees Part 4: Pattern Matching and Exceptions, особенно

class Color(val red:Int, val green:Int, val blue:Int)
 
case class Red(r:Int) extends Color(r, 0, 0)
case class Green(g:Int) extends Color(0, g, 0)
case class Blue(b:Int) extends Color(0, 0, b)
 
def printColor(c:Color) = c match {
  // байндинг переменной
  case Red(v) => println("Red: " + v)
  case Green(v) => println("Green: " + v)
  case Blue(v) => println("Blue: " + v)
 
    // проверка на тип и байндинг переменной
  case col:Color => {
    print("R: " + col.red + ", ")
    print("G: " + col.green + ", ")
    println("B: " + col.blue)
  }
 
  case null => println("Invalid color")
}
 
printColor(Red(100))
printColor(Blue(220))
 
printColor(new Color(100, 200, 50))
printColor(null)

Ну и где же пресловутая всеобщая функция, которая:

— сможет разобрать тип передаваемых данных
— сами данные
— забайндить переменные по желанию программиста?


С ПМ'ом о таких мелочах не надо думать. Тебе нужно узнать структуру данных? Тип данных? Ты так и пишешь: "хочу структуру. хочу тип. хочу это все в куче переменных, чтобы сотни раз не писать var x = Elem.field1"

Здравствуйте, SmbdRsdn, Вы писали:
T>>Мелкий ликбез по Erlang-у:
SR>Замечу все-таки, что начинал я сравнение не с erlang'ом, а со Scala.
SR>Конечно, мне бы хотелось и продолжать сравнивать со Scala, но возражающие мне в основном используют erlang.
SR>А вникать в отдельный язык ФП с его тонкостями желания нет, поэтому думаю, что непонимания с обеих сторон будет еще немало.
В свою очередь не знаю скалы, а по erlang-у прочитал несколько статеек.
Но по ответам, мне показалось, что некоторые синтаксические конструкции не всем очивидны.

T>>А вот с массивами уже есть: предположим мы хотим нарисовать такой шаблон для массива целых, из 3х элементов, где первый нам не важен (_), второй всегда равен 2 а третий сбиндить в указанную переменную...
SR>

SR>new Object[] {_, 2, x}
SR>

Как будем различать массивы интов, даблов и собственно Object-ов?

T>>Но этот код уже таки нужно учитывать — т.к. нам таки приходится изменять классы под PM.
SR>Код можно и не писать, я уже приводил пример, вполне можно расширить компилятор.
SR>

SR>abstract class Term {};
SR>final class Num extends Term {};
SR>final class Var extends Term {};

SR>@PatternMatching
SR>Term simplify(Term term) {
SR>  if (term.equals(new Num(1))) {
SR>  }
SR>}
SR>

SR>И этот компилятор может например добавить необходимый equals в классы, либо переписать simplify на if (term instanceof Num) и т.д.
Вот про это тебе и говорят "псевдокод". То что можно построить некий тул, который будет переписывать АСД никто не сомнивается.
Но ведь его нет — стало быть и код нельзя ни выполнить ни проверить его корректность.
Кроме того, раз уж мы взялиcь перекраивать АСД, то можем выбрать и более явный код чем какскд if-ов, например switch/case:

@PatternMatching
void matches(data) {
  switch(data) {
    case list(elem1, elem2), T: {...};
    case list(L), T: {...};
    case a, b: {...};
    case list(H, T), list(H2, T2): {...};
    case a, list(b, list(c, d)): {...};
    case _, _, _, _, x: {...};
    case list(a, b, c), list(H, T), list(list(H2, T2), d, e): {...};
  }
}

При этом, PM-компилятор автоматом объявит все нужные для связывания переменные, и проведёт остальные нужные преобразования.

T>>Значит такой способ задания шаблона не катит. Попробуем по другому: для каждого интересующего нас класса можно создать PM-двойника, который бы мы использовали при задании шаблонов. Этим кстати можно даже обойти проблему с массивами.
SR>Я как раз и приводил код с созданием двойников _Term, _Num и .т.д. Но это для кода работающего здесь и сейчас.
T>>Наверное тоже можно нагнуть Эклипс и несколькими щелчками получить двойника заданного класса. Правда остаётся неприятная проблема с типизацией. Да и код от этих двойников раздувается...
SR>Не очень понятно, почему беспокоит раздутие кода, если это отдельные классы. Они могут даже отсутствовать в проекте в виде java файлов, сразу в виде class на какой-либо из стадий сборки. Например по WSDL создается весьма объемный код, который не замедляет восприятие всего проекта отдельным разработчиком.
Таки есть для такого решения несколько неочевидных вещей:
Где, в каком пакете, эти невидимые класс-файлы будут распологаться?
В том где мы решили использовать @PatternMatching? — тогда очевидно мы получим дублирование при использовании PM чужих классов.
Можно предварительно искать — есть ли уже сгенерённые двойники в пакетах используемых классов. Или в наших родительских.
Идеальное решение — сразу создавать вместе с классом их PM-двойников, а двойников стандартных типов запихать в библиотеки рантайма.
Кроме того, что с отладкой будем делать?

T>>Получается, что общий код для поддержки твоего псевдокода по объёму его сильно превосходит, без учёта самого движка сопоставления.
SR>В случае equals и движка-то никакого не надо.
SR>А в случае списков, кортежей нет и общего кода для поддержки.
В erlang-е, проверяется непротиворечивость и полнота шаблонов. Думаю в скале тоже.
Кроме того, по шаблонам строится некий вычислитель (конечный автомат?) и собственно распознавание выполняется гораздо быстрее, чем последовательное тестирование каждого шаблона.

T>>Кстати, а куда будем учитывать плагины которые тоже нужно писать и поддерживать?
SR>А куда будем учитывать код затраченный на поддержку PM в Scala?
Ну, вот, мы уже и придумали некоторый кусок скалы.
Т.е. раз уж мы начали менять АСД и рантайм для работы с PM, почему не пойти дальше, и не включить например списковые дополнения или вывод типов?
К тому же оба нам всё равно понадобятся для нормального PM — мы ведь хотим удобства — значит типизация связываемых переменных — забота компилятора, да и возможность указывать только нужную часть массива или контейнера, какой бы он не был длинны — тоже очень удобная штука, особенно если мы хотим хвост сбиндить и тоже обработать.
Вполне возможно, для поддержки этого потребуется ещё что-то выносить на уровень рантайма...

Идём далее — у нас теперь получается язык с 2мя разными семантиками — одна, новая, работает в функциях отмеченных тагом @PatternMatching, другая, старая, во всех остальных местах.
Что не есть гуд — т.к. об этом надо постоянно помнить, и нельзя просто взять какой-то кусок кода — нужно указывать из какой он функции, отмеченной или нет.
Кроме того, все эти фичи довольно удобны — стало быть при работе с таким языком многие начнут просто сразу помечать все функции этим тегом а уж дальше разбираться нужен он реально или нет.
Стало быть проще сразу обрабатывать этим тулзом все функции и не париться.

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

Получился ответ на вопрос — зачем изобретать какой-то дополнительный язык, если на java всё это можно и так написать.
Ну и ответ на вопрос "в чём отличия" думаю тоже понятен — в удобстве использования и инфроструктуре.

T>>P.P.S. А ты правда правда считаешь что куски эквивклетны по понятности/объёму, или просто отстаиваешь любимый язык?
SR>Куски очевидно не равны по объему и по понятности, но близки, правда это в коде, который приводил я.
SR>А вот в первом сообщении на которое я отвечал, объемы различались чуть ли не в десятки раз.
SR>Язык Java не является моим любимым.
Мне кажется, что без учёта инфроструктуры и ограничений, код получается больше как минимум в 2-3 раза для простых случаев...

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

C>>Мне плевать сколько кода в JDK. Я его не отлаживаю.
SR>8 лет, говорите и не приходилось отлаживать по JDK? Кхм, кхм.
Попробуйте поставить брейкпоинт где-нибудь в java.util.collections. Запустите программу. Удивитесь.

А всё потому, что JDK в стандартной поставке не имеет отладочных символов. Их можно скачать дополнительно, но это отдельный разговор.

Так вот, код в JDK мне не приходилось отлаживать ни разу.

C>>Меня удивило, что это считается большим плюсом...
SR>По вашему большим плюсом было бы отсутствие кодогенерации в IDE?
Плюсом была бы ненужность кодогенерации.

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

SR>>А именно такой опыт, на мой взгляд, достаточен чтобы дописать оставшийся код.
WH>Если все так просто то что же ты так и не привел код?
WH>Он же простой и уже написан.
А, собственно, весь необходимый код уже и приведен. Просто разбит по нескольким сообщениям.

SR>>Если нечто выглядит как утка, крякает как утка и ходит как утка — наверное утка и есть.
WH>Не разводи демагогию.
WH>Тут у нас не утки, а программная система которая должна работать четко и устойчиво.
WH>И если то что есть у тебя (если вобще есть) ломается с пол пинка то в качестве инструмента для создания промышленных систем оно ну никак не годится.
WH>А мы ведь тут говорим не о игрушках. Или как?
Кому как. Зависит от уровня разработчика.

SR>>Подскажем аннотоцией недостающую определенность, делов-то.
WH>Полный код в студию.
Недостающие определенности в студию.

WH>>>Я думаю умные люди уже поняли чем отличается явное объявление переменной внутри match'а от неявного объявления переменной в какомнибудь позорном васике.
SR>>Понять-то поняли, явность объявления под вопросом.
WH>Ну если ты не в состоянии отличить объявление при первом использовании и объявление в паттерне то тебе ничем не помоч.
Я в состоянии. Вопрос именно в объявлении. Суть объявления именно в том, чтобы сделать нечно явным.
А явность в более-менее сложном образце отсутствует.

SR>>Говорят, что синтаксис не имеет значения для Lisp.
WH>Ну еще на заборе всякую фигню пишут.
Стало быть синтаксис имеет значение даже для List?
WH>В любом случае не меняй тему.
Тема та же. С первого сравнения сопоставления с образцом в Scala и Java говорилось, что представление (синтаксис) образца имеет значение.

WH>>>Просто ты тут развел кучу демагогии на которую могли повестись мение опытные люди.
SR>>Чтобы пресечь подобное тут и находятся на дежурстве такие люди как вы.
WH>Хочешь чтобы я удалил все твои сообщения и отправил в баню за попытку ввести людей в заблуждение?
Начало проглядывать лицо садиста, которые часто общаются подобным образом:

В морду хочешь?

WH>Это можно устроить.
Впрочем, спасибо за предупреждение. На всякий случай сохранил все свои сообщения.

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

SR>>Как думаете Eclipse само код генерит или при помощи компилятора?
WH>Детали.
Важные. IDE именно потому и IDE, что integrated и включает в себя компилятор.
WH>Главное чтобы код который я пишу был самодостаточным и не требовал помощи IDE для того чтобы он начал работать.
С учетом, того что в IDE имеется компилятор и именно при его помощи и создается код.
При желании именно поддержку создания кода вполне можно вынести из IDE.

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

SR>>Так и общего кода на одном языке (желательно на Scala) тоже не приводилось.

M>Какой общий код? При поддержке ПМа языком, любой код, его использующий, будет более-менее общим
Такой общий код. Ранее сопоставление с вариантами и со списками приводилось на двух разных языках.

M>>>Где он был не совсем корректным и не соответствовал условиям задачи.
SR>>Не припоминаю особых некорректностей, также как и несоответствия условиям задачи.

M>Байндились ненужные переменные
Связывать ненужные переменные можно и в Scala, так что мимо.


M>>>Кстати, насчет связывания переменных.

M>>>

M>>>[{elem1, elem2}|T]
M>>>

M>>>

M>>>data.matches(list(elem1, elem2), T)
M>>>

M>>>Что такое T в примере на Java, и откуда оно взялось?
SR>>

SR>>Tail T = new Tail();
SR>>class Tail {
SR>>  public object[] value;
SR>>}
SR>>

M>чаво чаво? T у нас может быть любым объектом — списком, кортежем, классом, встроенным типом и т.п.
Стало быть это мне надо спрашивать?
M>>>Что такое T в примере на Scala, и откуда оно взялось?

M>Более того, этот T мы можем сразу взять и использовать дальше — в последующих сопоставлениях или сразу по назначению:
Так и в Java, неужели не видите, что раз term переменная и ее можно и использовать в соспоставлении с образцом, то и T переменная и ее тоже можно использовать далее как угодно, в том числе и при сопоставлении с образцом.

M>Ключевой момент — в выделенном. Тут мы создаи и заюзали переменную y встроенного типа Int. А могли бы дополнить:
Если нужна типизация, так в Java есть обобщенные классы. z = new Match<MyClass>().
M>

M>    case z: MyClass => z.MyMethod(); z.field1 = 2; 
M>

M>И вообще — здесь, ответ на аргумент "Pattern matching is unnecessary" а также отсюда
С обсуждения этого сообщения и началос обсуждение.

M>Scala Pattern Matching = Visitor
То же самое, что и у Одерски.

M>Scala Pattern Matching from a Java perspective и особенно:
Выше приводил пример на Java с типизацией.
M>

M>// The simple type match pattern

M>object MySingleton
M>val single = MySingleton
M>single match {case _:MySingleton.type => println("OK")}
M>

M>Scala for Java Refugees Part 4: Pattern Matching and Exceptions, особенно
Да все, примерно тоже самое.

M>Ну и где же пресловутая всеобщая функция, которая:
С чего вы взяли, что это будет одна и та же функция? Функции в Java поддерживают перегрузку параметров.
Применение функций будет выглядеть примерно одинаково.

M>- сможет разобрать тип передаваемых данных
Обобщенные классы.
M>- сами данные
Уже было.
M>- забайндить переменные по желанию программиста?
Связывание переменных уже тоже приводилось.

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

SR>А, собственно, весь необходимый код уже и приведен. Просто разбит по нескольким сообщениям.
Так собери в кучу.
Причем так чтобы компилировалось и работало.
А то потом меня начнешь обвинять в том что я что-то не так собрал.

WH>>Тут у нас не утки, а программная система которая должна работать четко и устойчиво.
WH>>И если то что есть у тебя (если вобще есть) ломается с пол пинка то в качестве инструмента для создания промышленных систем оно ну никак не годится.
WH>>А мы ведь тут говорим не о игрушках. Или как?
SR>Кому как. Зависит от уровня разработчика.
Те ты в продакшен решениях используешь то что болтается на соплях и падает при любом не осторожном движении?
Хорошь же твой уровень.

SR>Я в состоянии.
Не похоже.

SR>Вопрос именно в объявлении. Суть объявления именно в том, чтобы сделать нечно явным.
Без объявление использовать переменные нельзя.
Место объявления четко определено.
Что еще надо?

SR>А явность в более-менее сложном образце отсутствует.
Да ладно.
Особенно если учесть что мы работаем в IDE и она вполне себе раскрашивает образци.

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

Или таки приведешь код?
Или засчитать тебе давно заслуженный слив?

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

SR>С учетом, того что в IDE имеется компилятор и именно при его помощи и создается код.
SR>При желании именно поддержку создания кода вполне можно вынести из IDE.
Те предлагаешь таки менять язык?

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

T>В свою очередь не знаю скалы, а по erlang-у прочитал несколько статеек.
T>Но по ответам, мне показалось, что некоторые синтаксические конструкции не всем очивидны.
Конечно не очевидны, что естественно.

T>>>А вот с массивами уже есть: предположим мы хотим нарисовать такой шаблон для массива целых, из 3х элементов, где первый нам не важен (_), второй всегда равен 2 а третий сбиндить в указанную переменную...
SR>>

SR>>new Object[] {_, 2, x}
SR>>

T>Как будем различать массивы интов, даблов и собственно Object-ов?
Трудности с различением не очевидны.

T>>>Но этот код уже таки нужно учитывать — т.к. нам таки приходится изменять классы под PM.
SR>>Код можно и не писать, я уже приводил пример, вполне можно расширить компилятор.
SR>>

SR>>abstract class Term {};
SR>>final class Num extends Term {};
SR>>final class Var extends Term {};

SR>>@PatternMatching
SR>>Term simplify(Term term) {
SR>>  if (term.equals(new Num(1))) {
SR>>  }
SR>>}
SR>>

SR>>И этот компилятор может например добавить необходимый equals в классы, либо переписать simplify на if (term instanceof Num) и т.д.
T>Вот про это тебе и говорят "псевдокод". То что можно построить некий тул, который будет переписывать АСД никто не сомнивается.
И где это говорят про псевдокод применительно к аннотоциям? Наоборот, мне предлагают привести, код раз он уже написан.
А про аннотации и про компилятор поддерживающий их я никогда не заявлял, что они готовы.
T>Но ведь его нет — стало быть и код нельзя ни выполнить ни проверить его корректность.
T>Кроме того, раз уж мы взялиcь перекраивать АСД, то можем выбрать и более явный код чем какскд if-ов, например switch/case:
Мы, в смысле я, не можем, так как код не компилируется Java компилятором.
И что такое АСД? Можеть быть AST?
T>

T>@PatternMatching
T>void matches(data) {
T>  switch(data) {
T>    case list(elem1, elem2), T: {...};
T>    case list(L), T: {...};
T>    case a, b: {...};
T>    case list(H, T), list(H2, T2): {...};
T>    case a, list(b, list(c, d)): {...};
T>    case _, _, _, _, x: {...};
T>    case list(a, b, c), list(H, T), list(list(H2, T2), d, e): {...};
T>  }
T>}
T>

T>При этом, PM-компилятор автоматом объявит все нужные для связывания переменные, и проведёт остальные нужные преобразования.
Зачем новый язык, когда и на старом все не сильно больше? Я как раз выступал против этого.

T>Таки есть для такого решения несколько неочевидных вещей:
T>Где, в каком пакете, эти невидимые класс-файлы будут распологаться?
Посмешили, какие трудности с выбором пакета?
T>В том где мы решили использовать @PatternMatching? — тогда очевидно мы получим дублирование при использовании PM чужих классов.
При правильной обработке аннотация и классы двойники не нужны.
T>Можно предварительно искать — есть ли уже сгенерённые двойники в пакетах используемых классов. Или в наших родительских.
Двойники, как раз нужны, чтобы сопоставление работало без изменения компилятора.
T>Идеальное решение — сразу создавать вместе с классом их PM-двойников, а двойников стандартных типов запихать в библиотеки рантайма.
T>Кроме того, что с отладкой будем делать?
А что сейчас-то с отладкой, все ровно тоже самое, например при заходе в методы, которые сделаны при помощи JNI.
Как, например, производится отладка веб-служб, классы которых доступны только во время выполнения?

T>В erlang-е, проверяется непротиворечивость и полнота шаблонов. Думаю в скале тоже.
Про exhaustive уже писал.
T>Кроме того, по шаблонам строится некий вычислитель (конечный автомат?) и собственно распознавание выполняется гораздо быстрее, чем последовательное тестирование каждого шаблона.
Это опять производительность. Доводы те же.

T>Ну, вот, мы уже и придумали некоторый кусок скалы.
Вы, но не я.
T>Т.е. раз уж мы начали менять АСД
Опять АСД.
T>и рантайм для работы с PM,
Что понимается под изменением рантайма? У меня ничего такого нет, что не вытекало бы из изменения AST.
T>почему не пойти дальше, и не включить например списковые дополнения или вывод типов?
Скорее надо бы объяснить почему надо включить.

T>К тому же оба нам всё равно понадобятся для нормального PM — мы ведь хотим удобства — значит типизация связываемых переменных — забота компилятора, да и возможность указывать только нужную часть массива или контейнера, какой бы он не был длинны — тоже очень удобная штука, особенно если мы хотим хвост сбиндить и тоже обработать.
Меня из нам вычеркивайте.

T>Вполне возможно, для поддержки этого потребуется ещё что-то выносить на уровень рантайма...
Что опять понимается под выносом на уровень рантайма?

T>Идём далее — у нас теперь получается язык с 2мя разными семантиками — одна, новая, работает в функциях отмеченных тагом @PatternMatching, другая, старая, во всех остальных местах.
Но-но, меня в эти с кем "идём" не записывайте. У меня никаких двух семантик нет.

T>Что не есть гуд — т.к. об этом надо постоянно помнить, и нельзя просто взять какой-то кусок кода — нужно указывать из какой он функции, отмеченной или нет.
У меня такой проблемы не возникает.

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

T>Стало быть проще сразу обрабатывать этим тулзом все функции и не париться.

T>Вот у нас и получился новый язык программирования, со своей семантикой и таким же как у java синтаксисом.
У вас, не у меня.
T>Но синтаксис нас всё же ограничивает.
Вас, не меня.
T>В java мы не можем работать с переменноё без объявления её типа, а хотелось бы, ведь у нас уже есть вывод типов.
Мне не хотелось бы.

T>Да и списковые дополнения хотелось бы использовать не только для описания шаблонов а и для конструирования массивов и других контейнеров.
Мне не хотелось бы.

T>Получился ответ на вопрос — зачем изобретать какой-то дополнительный язык, если на java всё это можно и так написать.
У меня такой ответ не получился.
T>Ну и ответ на вопрос "в чём отличия" думаю тоже понятен — в удобстве использования и инфроструктуре.
Мне не понятен, впрочем давно потерял суть ваших рассуждений. Одна из первых посылок, вероятно была неверной. Для меня по-крайней мере.

T>Мне кажется, что без учёта инфроструктуры и ограничений, код получается больше как минимум в 2-3 раза для простых случаев...
Но не в 30 раз по объему, если сравнивать с изначальным сообщением, что уже неплохо.
К тому же для сложных случаев, соотношение, как мне кажется будет даже уменьшаться.

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

SR>>8 лет, говорите и не приходилось отлаживать по JDK? Кхм, кхм.
C>Попробуйте поставить брейкпоинт где-нибудь в java.util.collections. Запустите программу. Удивитесь.
Ах вот оно что, отладка для вас означает установку точки останова.

C>А всё потому, что JDK в стандартной поставке не имеет отладочных символов. Их можно скачать дополнительно, но это отдельный разговор.
Скачиваете Eclipse, ставите точку останова, запускаете на отладку.

C>Так вот, код в JDK мне не приходилось отлаживать ни разу.
Ну раз 8 лет, значит так и надо.