LINUX.ORG.RU
ФорумTalks

Яр для Js - есть ли смысл?

 


1

4

Ну вот, теперь стало ясно, что идею русскоязычного ЯП массы не подхватили. Т.е. конечно, Ланит-Терком пилит свой «РуСи» и, наверное, найдёт кому его запродать, а Нуралиев успешно продаёт реализации языка 1С, но это большие дяди, а я - пусть и дядя, но маленький, так что ресурсов впарить кому-то целый ЯП, да ещё и на уровне прототипа, у меня нет. Нет за спиной ни гугла, ни фейсбука.

И кроме того я не хочу лить воду на мельницу искусственного интеллекта. Я не исключаю, что лисп разбомбили именно из-за того, что он мог сделать людей слишком уж могущественными и это было осознано правителями мира (можете смеяться над моей паранойей и конспирологией - я на это отвечу - вы просто уткнулись носом в компьютер и ничего не видите дальше его экрана, а значит, являетесь клиентами иллюминатов. Мозг-то надо использовать по-назначению, а назначение мозга, способного понимать компьютер - в том, чтобы понимать мир. Компьютер слишком скучен, поверьте. Если он вам ещё не надоел, то через 10 лет точно надоест. Или, может быть, вы являетесь персонажем анекдота про курицу и мафию и отрицаете мировой заговор только по той причине, что сами в нём участвуете. Дальше я не буду касаться этого вопроса).

Так вот, я никоим образом не хочу помогать ни искусственному интеллекту, ни автономным боевым роботам. Вот когда америка, или, что более вероятно, Япония, сделает этих роботов, они засветятся в войнах и станет ясно, что они представляют явную угрозу России - тогда поговорим. А так - ну, слили Украину, Молдавию, Казахстан и вот Армения на очереди. Всё это ещё не повод делать автономных боевых роботов. Велика Россия, отступать есть куда.

И ещё конечно, меня подвело высказывание из книги «несвятые святые», о том, что телевидение - это лишь инструмент, а использовать его можно и во благо. Можно ли использовать во благо автономные боевые роботы? Ядерное оружие - можно. Автономных боевых роботов - сомневаюсь.

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

Например, взять ФПИ. Наверное, там сидят молодые придурки, которые делают автономных боевых роботов, хотя смотрели «Терминатор-3». Должно ли у меня было получиться с ними сотрудничать? Очевидно, не должно было.

Так вот, мировое правительство посмотрело Терминатор-3 и постановило: создавать больше мусорных ЯП, и вообще устроить чехарду технологий, всячески проводить дебилизацию ИТ-шников, дискредитировать волнами хайпа саму идею ИТ-инноваций - лишь бы люди не добрались до «дерева безсмертия», упомянутого ещё в самом начале «бытия». Я не буду мешать этим светлым планам, да и даже если пытаться мешать, то всё равно ничего не выйдет. Глупо противостоять мировому правительству.

Поэтому масштаб задач нужно снизить до сравнимых с масштабом моих ресурсов и ограничиться тем, что решает этичные задачи. Например, задачу повышения моего личного благосостояния :)

И приступим к делу. Вот например, JS. Я посмотрел на разные языки, которые транслируются в JS. И что-то мне ни один не понравился. Мне нужно совсем немного:

  • многострочные строковые литералы
  • необязательная статическая типизация
  • при этом «тип» может говорить о том, что «у объекта, к-рый придёт таким-то параметром, должны быть такие-то поля, и больше никаких». И при нарушении типа должна возникать ошибка во время компиляции (когда это возможно) или в рантайме (в противном случае)
  • нормальная числовая башня
  • вменяемые операции, а не 1+1=11
  • полная поддержка sourcemaps
  • работа в браузере и в ноде
  • вменяемые сигнатуры функций с именованными необязательными параметрами и значениями по умолчанию, а не такая помойка, как в JS. Естественно, с проверкой во время компиляции, когда это возможно
  • макросы хотя бы как в Си или m4
  • модули как в Паскале, но с возможностью асинхронной загрузки
  • естественно, лямбды, async и промисы должны быть доступны

Но я такого не встретил. Или плохо смотрел? Соответственно, два вопроса к ЛОРу:

  • что взять за основу такого языка?

Перемещено tailgunner из development

★★★★★

Последнее исправление: den73 (всего исправлений: 4)
Ответ на: комментарий от tailgunner

ты не захотел пожертвовать пальцами для науки

«А ты не путай мои личные пальцы со своими. Жертвовать пальцами в то время, когда российская промышленность не рассчиталась с государством по процессорам и компьютерам!» © :)

quickquest ★★★★★
()
Ответ на: комментарий от LjubaSherif

Да и вообще, а кто тебе сказал, что кол-во потребителей - критерий качества и успеха?

Ты можешь выбирать какие угодно критерии качества и успеха. Потому что это субъективно.

Люди понимают, что ширпотреб всегда дерьмо, но почему-то на этом уровне всегда ратуют за ширпотребное дерьмо.

Ты не шаришь. То, что ты называешь «ширпотребное дерьмо» — это часто тщательно выверенный продукт по соотношению «цена/качество». И на нём очень хорошие деньги делают.

Немногие могут создать то, что ты называешь «ширпотребное дерьмо». Перефразирую: создать дерьмо может каждый, но лишь единицы могут сделать такое дерьмо, чтобы его массово покупали.

Wizard_ ★★★★★
()
Ответ на: комментарий от Wizard_

Ты можешь выбирать какие угодно критерии качества и успеха. Потому что это субъективно.

Неверно, нищебродные оправдания. Критерии качества и успеха - объективны, особенно в этом мире.

Ты не шаришь. То, что ты называешь «ширпотребное дерьмо» — это часто тщательно выверенный продукт по соотношению «цена/качество». И на нём очень хорошие деньги делают.

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

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

Немногие могут создать то, что ты называешь «ширпотребное дерьмо». Перефразирую: создать дерьмо может каждый, но лишь единицы могут сделать такое дерьмо, чтобы его массово покупали.

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

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

Ты же определил один критерий, один приоритет - не пытайся с него слиться.

LjubaSherif
()
Ответ на: комментарий от LjubaSherif

Ширпортребное дерьмо - дерьмо, по определению. Выверено оно только в твоих фантазиях.

Ясно. Желания продолжать дискуссию дальше нет.

Wizard_ ★★★★★
()
Ответ на: комментарий от Unununij

Ну дак ответить мне что-то, вперёд. Опровергни мою шизофрению, опровергни мои тезисы, скажи мне хоть что-то.

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

Шизофрения - помоги ему, ты же можешь.

LjubaSherif
()

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

Заговора нет. Есть лишь общие цели человечества. Одновременно и высокие, и эгоистичные. Каждый человек хочет комфортной и безопасной среды обитания (как минимум для себя и своих прямых потомков). Этим, как мне кажется, обуславливается то, что правительства развитых стран, транснациональные корпорации и прочие «сильные» действуют «за одно».

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

Бгг. Мировое правительство, как ни странно, мегаломаньяки по сути своей. Его консервативность обусловлена лишь осторожностью. И вот до них дошло, что ИИ это вовсе не обязательно Скайнет, вполне возможно, что это Валли, Юмэми или Дэвид. И попёрли нейросети от гугла с фейсбуком.

Глупо противостоять мировому правительству.

Правильные вещи говоришь. Ведь кроме тебя (и возможно твоих ближайших друзей/родственников) только «мировое правительство» заинтересовано в том, чтобы _лично_ты_ не жил в дерьме XD

необязательная статическая типизация

Чем обязательная не угодила?

Яр для Js - есть ли смысл?

Нет. Есть LLVM, который умеет транслировать почти что угодно в WebAssembly.

robus ★★★★★
()
Ответ на: комментарий от mimimimi

Ты точно на все посмотрел?

Ура, ответ по существу :) Наверное, не на все, но я же для того и написал, чтобы кто-то сразу слёту подсказал. Этот список я видел вроде. Возможно, нужно ещё раз посмотреть. Спасибо в любом случае.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от robus

Есть LLVM, который умеет транслировать почти что угодно в WebAssembly.

Просто для проверки своего понимания: JS входит ли в «почти что угодно»?

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от robus

Чем обязательная не угодила?

Да она просто не всегда нужна. Там, где не нужна, становится обузой. Пример: список любых объектов.

den73 ★★★★★
() автор топика
Ответ на: комментарий от stevejobs

Помню, было такое лет 20 назад, называлось «Ява апплеты». Но я не люблю Яву.

den73 ★★★★★
() автор топика
Ответ на: комментарий от mimimimi

А кстати, мне вот уже понравился GorillaScript - один из первых, в котором есть слово types. Чувствуется, что люди имеют склонность к лиспу. Правда, нужно кое-что выкинуть и я ещё не всё посмотрел. Жаль, конечно, что оно сдохло.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

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

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Вот читаю https://nim-lang.org/docs/coro.html#CoroutineRef и не вижу интерфейса к async в JavaScript, а ведь это примерно из той же оперы. Его нет?

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

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

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Задача «переход к определению» в Typescript всё ещё не решена. Обещали к версии 2.8, но обманули. Версия вышла, а этой фичи так и нет. https://github.com/Microsoft/TypeScript/issues/6209 . О чём думают эти люди?

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Итак, пытаемся исключить Nim путём придирок.

  • Транслируется в С++. Eval не обнаружен
  • Нет интеграции корутин с async
  • Платформо-зависимый int
  • Однобайтный char
  • Слишком большой

Вывод: закопать.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Eval не обнаружен

macro eval(s: string): expr =
  result = parseStmt($s)

Нет интеграции корутин с async

А зачем, если в C++ async нету, а в JS он умеет намного меньше, чем корутины в Nim?

Платформо-зависимый int

Есть int8, int16, int32.

Однобайтный char

Юникодный char в Nim называется Rune

Слишком большой

ЩИТО?

$ aptitude show nim
Пакет: nim
Версия: 0.18.0-2
...
Размер в распакованном виде: 11,7 M
...

$ aptitude show sbcl
Пакет: sbcl
Версия: 2:1.4.7-1
...
Размер в распакованном виде: 47,2 M
...

$ aptitude show nodejs
Пакет: nodejs
Версия: 8.11.1~dfsg-2
...
Размер в распакованном виде: 18,4 M
...
monk ★★★★★
()
Ответ на: комментарий от monk

О, спасибо, что пришёл!

macro eval(s: string)

Разве это настоящий eval? Я так понял, parseStmt генерирует AST. Где средство исполнить AST, существующий в рантайме?

А зачем, если в C++ async нету, а в JS он умеет намного меньше, чем корутины в Nim?

Моя стратегия и идеология на данный момент состоит в примыкании к силе. За силу принят JS. Что он позволяет как платформа - то и нужно. Остальное не нужно. Соответственно, если C++ может больше, чем JS, то это игнорируется, а если меньше, то это повод отбросить С++.

Есть int8 ... Юникодный char

Вопрос в том, что используется в стандартной библиотеке и примерах. Если используются rune и конкретные int, то вопроса нет. Но для моего спокойствия названия этих типов должны быть bad_char_dont_use и bad_int_dont_use.

Насчёт размера - я имел в виду не байты, а фичастость. Я рассчитываю на себя. Даже если, допустим, ты станешь мне помогать, нас будет всего двое. В команде Kotlin якобы работает 40 человек. Нужно здраво оценивать свои возможности. Язык должен быть по размеру как Оберон или 1С 7.7, тогда его можно будет ворочать маленькой командой.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

За силу принят JS. Что он позволяет как платформа - то и нужно.

Тогда согласен, что Nim не подходит. Не боишься дойти до края платформы JS как у тебя случилось с платформой CL?

Насчёт размера - я имел в виду не байты, а фичастость.

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

А вот если в твоём языке фича нужна, а в базовом её нет, то начинаются шаманские пляски вокруг костра.

P.S. Судя по https://github.com/nim-lang/Nim/blob/master/lib/pure/coro.nim, при компиляции Nim в JS корутины вообще не работают.

monk ★★★★★
()
Ответ на: комментарий от den73

Разве это настоящий eval? Я так понял, parseStmt генерирует AST. Где средство исполнить AST, существующий в рантайме?

compiler/nimeval.nim экспортирует execute*(program: string)

Пакет compiler.

monk ★★★★★
()
Ответ на: комментарий от monk

Не боишься дойти до края платформы JS как у тебя случилось с платформой CL?

Боюсь, а что делать... Мир как-то на ней живёт же, во всяком случае, получится не хуже, чем у остальных...

А вот если в твоём языке фича нужна, а в базовом её нет, то начинаются шаманские пляски вокруг костра.

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

Т.е. никогда не планировалось Яр->SBCL, а планировалось переплавить SBCL в Яр. И сейчас, если речь идёт об условном Nim, то не Яр->Nim, а переплавить Nim в Яр. Для этой задачи «Nim» должен быть маленьким, иначе получится болото.

при компиляции Nim в JS корутины вообще не работают.

Спасибо!

compiler/nimeval.nim экспортирует execute*(program: string)

https://forum.nim-lang.org/t/1319 - судя по всему, это интерпретатор. Бьюсь об заклад, что v8 порвёт его как тузик грелку. Он ведь заточен именно на генерацию быстрого машкода в рантайме.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

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

Так можно же просто не использовать

Т.е. никогда не планировалось Яр->SBCL, а планировалось переплавить SBCL в Яр.

Разве? В Яре вроде CLOS c defmethod и MOP не предполагался.

то не Яр->Nim, а переплавить Nim в Яр

А смысл? Тогда если брать нормальный язык за основу, то «получится болото», а если «должен быть маленьким», то будет непрактичным. Попробуй на том же Обероне писать в функциональной парадигме (например, написать функцию compose).

Реально требуется интероперабельность между языком-бэкендом и Яром (чтобы можно было смешивать библиотеки). И в этом случае лишние фичи языка-бэкенда не мешают.

Бьюсь об заклад, что v8 порвёт его как тузик грелку. Он ведь заточен именно на генерацию быстрого машкода в рантайме.

На выполнении eval? Сомневаюсь. Байткод почти всегда быстрее однократно выполнить, чем скомпилировать в оптимизированный машкод. А если нужен именно машкод, то и полнофункциональный компилятор в том же пакете (этот пакет, собственно, и есть то, из чего бинарник nim компилируется)

monk ★★★★★
()
Ответ на: комментарий от monk

полнофункциональный компилятор в том же пакете

Разве это будет работать без gcc?

Байткод почти всегда быстрее однократно выполнить

Если тебе всё ещё интересно участие, можно приватно обсудить.

Разве? В Яре вроде CLOS c defmethod и MOP не предполагался.

Там многое менялось. Но вообще он рассматривался как «Не мешающая фича», как минимум, а то и как опора для каких-то вещей. Когда стало ясно, что всё плохо с качеством, он стал мешать, как фактор, увеличивающий общий объём кода SBCL. Чем больше SBCL - тем дороже его всё время латать.

а если «должен быть маленьким», то будет непрактичным

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

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Разве это будет работать без gcc?

Нет конечно. Без binutils тоже не будет. Если нужен компилятор, он должен быть в системе. Но это логичней, чем дублировать компилятор в каждом бинарнике.

Если тебе всё ещё интересно участие, можно приватно обсудить.

Интересно, но пока (точнее уже) непонятно, какая цель. В смысле каков ожидается результат и какое ожидается использование результата. На начальном этапе я предполагал, что будет нечто, похожее на 1С по синтаксису и интероперабельное с Common Lisp.

Когда стало ясно, что всё плохо с качеством, он стал мешать, как фактор, увеличивающий общий объём кода SBCL. Чем больше SBCL - тем дороже его всё время латать.

Идея латать язык основы вообще ущербная. Если появилась такая потребность, значит либо язык основы выбран неверно, либо та фича, которой нет в языке основы быть не должно и в Яре. Поэтому язык основы должен быть достаточно фичастый, чтобы позволять реализовать все фичи Яра через свой интерфейс. Для этого надо как минимум определить все необходимые фичи до выбора языка основы.

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

Ещё раз: отталкиваться нужно от задачи. Надо определить потенциальную нишу Яра и его семантику. Пусть минимально возможную семантику (на КуМире тоже кто-то пишет).

monk ★★★★★
()
Ответ на: комментарий от monk

Но это логичней, чем дублировать компилятор в каждом бинарнике.

Не соглашусь.

отталкиваться нужно от задачи

Да по сути задача - «сделать, чтобы было красиво». Если же спуститься с небес на землю и рассматривать практически осмысленные задачи, то, видимо, придётся дальше так или иначе иметь дело с вебом. Нужен нормальный язык для этого. А такого языка пока не наблюдается.

Надо определить потенциальную нишу

Делать то же, что делают на JS, но удобнее.

Идея латать язык основы вообще ущербная.

Ты здесь исходишь из того, что существующие языки достаточно хороши. Возможно, тебе больше повезло, т.к. ты работал с Racket или просто более положительно настроен. Не «латать язык основы», а «взять язык, максимально приближенный к нужному, форкнуть его и переплавить в нужный». В случае JS речь не идёт о латании JS.

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

Да вроде в Js всё есть. Не богато (т.е убого), но в принципе жить можно. Ну, может быть, нету слабых хеш-таблиц. Но это уже вопрос эффективности, т.к. можно их имитировать. Вообще думаю, что можно рассмотреть две целевые платформы - Js и Golang. Обе вроде выглядят годными. Вот из минимума от возможностей этих платформ и можно исходить.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Делать то же, что делают на JS, но удобнее.

А что тебе в TypeScript не хватило?

В случае JS речь не идёт о латании JS.

Надеюсь. Хотя если планируешь язык для запуска в браузере, то выбора нет.

Ты здесь исходишь из того, что существующие языки достаточно хороши.

Так надо выбрать такой, который достаточно хорош. С учётом того, что нужны только необходимые примитивы, то для 99% всего, что возможно вообразить достаточно, например, Chez Scheme или C++. Если от JS надо только запуск в браузере, а не использование jQuery, то есть WebAssembly, в который компилируется LLVM (а значит почти всё от C++ до Rust).

Ну, может быть, нету слабых хеш-таблиц.

WeakMap в ECMA2015 появился.

Нету (насколько я знаю) того, из-за чего ты SBCL насиловал: возможности перехватывать аксессоры, сделать свой readtable, отладчик и контекстно-зависимое дополнение.

monk ★★★★★
()
Ответ на: комментарий от monk

Если от JS надо только запуск в браузере, а не использование jQuery, то есть WebAssembly

А как ты это себе представляешь? wasm это же по идее черный ящик с «неонкой» который общается с браузером исключительно бинарными массивами. Прелестно для портирования С-шного 7-zip'а, но вот для пинг-понга dom<=>логика ... будет не очень.

WebAssembly, в который компилируется LLVM

Уровнем повыше есть binaryen, schism и AssemblyScript

antares0 ★★★★
()
Ответ на: комментарий от den73

Хорошо, я тебе даю список объектов, любых. Твои действия, опиши мне алгоритм их обработки. После неудачи ты поймёшь почему твой пример - бред.

LjubaSherif
()
Ответ на: комментарий от LjubaSherif

Хорошо, я тебе даю список объектов, любых. Твои действия, опиши мне алгоритм их обработки.

Например, функция apply. Какой у неё должен быть тип второго аргумента?

monk ★★★★★
()
Ответ на: комментарий от den73

JS входит ли в «почти что угодно»

В смысле, можно ли скомпилировать JS в WebAssembly? Можно.

Или «можно ли именно через LLVM»? Компилятор JS в LLVM я не знаю.

monk ★★★★★
()
Ответ на: комментарий от monk

Например, функция apply. Какой у неё должен быть тип второго аргумента?

Ничего не понял. К чему это? Это типа попытка доказать нужность динтипизации? Слабо.

Во-первых, у тебя возникла логическая ошибка - если ты не знаешь типа параметра, то ты не знаешь тип аргумента. Что ты будешь передавать в apply? Каким образом ты соотнесёшь на рантайме тип аргумента и параметра, ожидаемого функцией?

Во-вторых - существует генерики и иже с ним.

LjubaSherif
()
Ответ на: комментарий от LjubaSherif

Что ты будешь передавать в apply?

Ты же сам писал «список объектов, любых». Если в языке обязательная статическая типизация, то apply становится невозможным. Ещё есть функция read, когда тип результата определяется тем, что написал пользователь.

Во-вторых - существует генерики и иже с ним.

Они каким боком?

Каким образом ты соотнесёшь на рантайме тип аргумента и параметра, ожидаемого функцией?

В момент вызова функции будет проверено соответствие имени функции и её типов аргументов фактически переданному списку параметров.

monk ★★★★★
()
Ответ на: комментарий от monk

В смысле, можно ли скомпилировать JS в WebAssembly?

Пока не доказал: https://github.com/AssemblyScript/assemblyscript/wiki/Limitations

А что тебе в TypeScript не хватило?

https://github.com/Microsoft/TypeScript/issues/6209 Вроде это излечимо, но подождём. Удивляет, что они это не сделали за столько времени - может быть, это неспроста? К тому же, нет смысла расширять плохой язык, каковым является JavaScript. Из ложки дёгтя добавлением мёда бочку мёда никак не получится сделать. За вычетом этих оговорок, действительно был вариант форкнуть ts и выкинуть из него лишнее.

WeakMap в ECMA2015 появился.

Интересно, как его реализует Babel. Может, я и зря сказал, что его можно имитировать.

den73 ★★★★★
() автор топика
Ответ на: комментарий от monk

Ты же сам писал «список объектов, любых». Если в языке обязательная статическая типизация, то apply становится невозможным.

std::invoke.

Они каким боком?

Обыкновенным.

В момент вызова функции будет проверено соответствие имени функции и её типов аргументов фактически переданному списку параметров.

Неверно. Аргументы передаются как есть, никакие типы не учитываются. А теперь ответь на вопрос:

У меня есть функция f(x) {x.ya_balabol = true;}, есть apply, а теперь ты мне расскажешь, каким образом ты передашь туда «любой тип».

LjubaSherif
()
Ответ на: комментарий от LjubaSherif

std::invoke.

Это не apply, это funcall.

Или покажи, как на нём сделать

function f(fun, numbers)
{
  if(fun = "min") { return Math.min.apply(null, numbers); }
  if(fun = "max") { return Math.max.apply(null, numbers); }
}
, где Math.min и Math.max — функции, принимающие произвольное количество аргументов-чисел.

У меня есть функция f(x) {x.ya_balabol = true;}, есть apply, а теперь ты мне расскажешь, каким образом ты передашь туда «любой тип».

Если f определена именно так, то она принимает любой тип (предполагаю, что язык — JS). Соответственно, f.apply(null, [«ok»]) — успешно отработает.

Если же предположить, что для x пропущен некий тип с нужным булевым полем, то при выполнении apply произойдёт проверка на соответствие аргумента этому типу. И при несоответствии будет TypeError.

monk ★★★★★
()
Ответ на: комментарий от monk

fun = «min»

Я теперь понимаю для кого := и === делают.

struct Math {
  struct max {
    template<typename ... args> auto operator()(args ... arg) {
      using common = std::common_type_t<args...>;
      return std::max({common(arg)...});        
    }
  };
  struct min {
    template<typename ... args> auto operator()(args ... arg) {
      using common = std::common_type_t<args...>;
      return std::min({common(arg)...});        
    }
  };
};

template<typename ... args> auto f(std::string_view fun, args ... arg) {
  if(fun == "max") return std::invoke(Math::max(), arg...);
  if(fun == "min") return std::invoke(Math::min(), arg...);
}



int main() {
  std::cerr << f("min", 10.123, 20, 30, 40) << std::endl;
  std::cerr << f("max", 10, 20, 30, 40) << std::endl;
  

принимающие произвольное количество аргументов-чисел.

Ты явно не в теме, но я тебе поясню. В жс нет такого понятия.

Если f определена именно так, то она принимает любой тип (предполагаю, что язык — JS).

Тебе задали просто вопрос - передай сюда любой тип.

Соответственно, f.apply(null, [«ok»]) — успешно отработает.

Нет.

Если же предположить, что для x пропущен некий тип с нужным булевым полем, то при выполнении apply произойдёт проверка на соответствие аргумента этому типу.

Ладно, если ты не способен понять логическую ошибку - добавим туда: f(x) {x.ya_balabol.da = true;}

И при несоответствии будет TypeError.

Что из этого следует? То, что любой тип передать нельзя. Оно упадёт. А почему? Давай я тебе сообщу новость, хоть ты и решил играть в дурака и нести мне херню.

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

Поэтому, все твои глупые рассуждения на тему apply, «любой тип» - это лишь глупые потуги непонимающего нихрена трепача.

Да что там далеко ходить, ты даже сам на этом засыпался:

Если f определена именно так, то она принимает любой тип

Ошибки номер один - f всегда принимает любой тип. Но ладно, спишем это.

принимающие произвольное количество аргументов-чисел.

Тут такая же херня, функция всегда принимает произвольное кол-во аргументов. Спишем это тот же. Но вот то, что мы списать не можем - это «аргументов-чисел».

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

Я не знаю, откуда вы такие нулёвые вылезаете, но это же элементарные вещи.

LjubaSherif
()
Ответ на: комментарий от LjubaSherif

f(«min», 10.123, 20, 30, 40)

нет. Тип у f не такой. Должен принимать два аргумента. То есть должно быть так:

int f(string s, vector<int> v)
{
   ...
}
...
  vector<int> v = {5, 3, 1, 3, 5, 2, 5};
  f("min", v);

Нет.

Проверь. В js ошибки нет.

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

В типизированных языках тоже можно устроить падение. Например,

void f(int *x)
{
  *x = 1;
}

f(NULL);
прекрасно проходит типизацию и падает при выполнении. Если же под типизацией ты подразумеваешь полную гарантию, что входные данные корректны для данного алгоритма, то в общем случае задаче эквивалентна задаче останова и неразрешима за конечное время.

Тут такая же херня, функция всегда принимает произвольное кол-во аргументов. Спишем это тот же. Но вот то, что мы списать не можем - это «аргументов-чисел».

Зависит от системы типов. Например, в Racket легко описывается

> min
- : (-> Real * Real)
то есть min принимает 0 до бесконечности аргументов типа Real и возвращает Real.

monk ★★★★★
()
Ответ на: комментарий от monk

О боже, как с вами сложно. Эта невероятная тупость, заспам ахиней, инорирование вопросов.

нет. Тип у f не такой. Должен принимать два аргумента. То есть должно быть так:

Я понимаю, что ты альтернативно одарённый, но всё же:

принимающие произвольное количество аргументов-чисел.
произвольное
количество
аргументов

Должен принимать два аргумента
два
произвольное

Ты в словарик давно заглядывал?

Проверь. В js ошибки нет.

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

В типизированных языках тоже можно устроить падение. Например,

К чему ты написал эту ахинею? Тебе кто-то говорил про падение? Нет. Тебе говорили о падении в контексте логической типизации. Упасть из-за этого кресты не могут.

прекрасно проходит типизацию и падает при выполнении.

Клоун, к типизации это не имеет никакого отношения.

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

Меня не интересуют твои потуги. Тебе сообщили о том, что такого понятия как «любой тип» - нету, не существует. В любом языке существует типизация на уровне логики. Именно поэтому типы будут ВСЕГДА.

Зависит от системы типов. Например, в Racket легко описывается

Меня не интересуют твои сливы на какое-то дерьмо для идиотов.

В конечном итоге, что мы имеем. С apply - обделался. С рассуждениями - обделался. Начал нести какую-то ахинею про «падения», начал игнорировать вопросы и изначальную тему.

LjubaSherif
()
Ответ на: комментарий от LjubaSherif

принимающие произвольное количество аргументов-чисел.

А теперь прочитай целиком то сообщение, которое цитируешь:

function f(fun, numbers)

Math.min и Math.max — функции, принимающие произвольное количество аргументов-чисел.

Тебе говорили о падении в контексте логической типизации. Упасть из-за этого кресты не могут.

Почему обращение к несуществующему полю — логическая типизация, а разыменование пустого указателя — нет?

Тебе сообщили о том, что такого понятия как «любой тип» - нету, не существует.

Сам же его используешь как аргумент шаблона. Но как элемент коллекции принимать отказываешься. Где логика?

Меня не интересуют твои сливы на какое-то дерьмо для идиотов.

То есть любая нормальная система типов для тебя дерьмо для идиотов? А единственно не-дерьмо — ущербная система типов Си++, в котором типы нужны не для безопасности кода, а для оптимизации скорости выполнения программы?

С apply - обделался. С рассуждениями - обделался. Начал нести какую-то ахинею про «падения», начал игнорировать вопросы и изначальную тему.

Это ты обделался. Из падения функции выводишь якобы неверный тип аргумента. Пишешь бред про «в любом языке существует типизация на уровне логики». При том, что типизировать многие функции просто невозможно. Например, какой тип аргумента функции is_boolean, которая принимает любой объект и возвращает истину, если объект равен true или false и ложь в противном случае?

Про apply всё переврал, написал бред и слился.

monk ★★★★★
()
Ответ на: комментарий от den73

Любой спор в Интернете имеет целью убедить не оппонента, а зрителей :-)

monk ★★★★★
()
Ответ на: комментарий от monk

А теперь прочитай целиком то сообщение, которое цитируешь:

После я того как я увидел = «max» я сделал резонный вывод - ты идиот, поэтому я даже не мог предположить, что настолько. Ты пытаешься слиться на тему преобразования массива в список аргументов. Первое - это не имеет никакого отношения к типизации, второе - есть std::apply, третье - даже в таком виде это можно наколхозить.

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

struct Math {
  struct max {
    template<typename ... args> auto operator()(args ... arg) {
      using common = std::common_type_t<args...>;
      return std::max({common(arg)...});        
    }
    template<typename T> auto operator()(T && c) {
      return *std::max_element(std::begin(c), std::end(c));
    }
  };
  struct min {
    template<typename ... args> auto operator()(args ... arg) {
      using common = std::common_type_t<args...>;
      return std::min({common(arg)...});        
    }
    template<typename T> auto operator()(T && c) {
      return *std::min_element(std::begin(c), std::end(c));
    }    
  };
};

template<typename ... args> auto f(std::string_view fun, args && ... arg) {
  if(fun == "max") return std::invoke(Math::max(), std::forward<args>(arg)...);
  if(fun == "min") return std::invoke(Math::min(), std::forward<args>(arg)...);
}


int main() {
  
  std::cerr << f("min", 10.123, 20, 30, 40) << std::endl;
  std::cerr << f("max", 60, 10, 20, 30, 40) << std::endl;
  std::cerr << f("max", (double[]){10., 20, 30, 40}) << std::endl;
  std::cerr << f("min", (double[]){10., 20, 30, 40}) << std::endl;
}

Это на тему типизации. И почему твои потуги нужны только в твоём детсаде.

Почему обращение к несуществующему полю — логическая типизация, а разыменование пустого указателя — нет?

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

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

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

Сам же его используешь как аргумент шаблона. Но как элемент коллекции принимать отказываешься. Где логика?

Твои потуги - бездарная клоунада. Ни в каком «как аргумент» шаблона никакой «любой тип» не используется. Любой тип используется в контексте передачи, а не в контексте использования.

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

То есть любая нормальная система типов для тебя дерьмо для идиотов? А единственно не-дерьмо — ущербная система типов Си++, в котором типы нужны не для безопасности кода, а для оптимизации скорости выполнения программы?

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

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

Это ты обделался.

Нет, ламерок.

Из падения функции выводишь якобы неверный тип аргумента.

Да, формат значения неверен, не тот, который предполагает функция. Тип неверен.

Пишешь бред про «в любом языке существует типизация на уровне логики».

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

При том, что типизировать многие функции просто невозможно.

Возможно, они итак всегда типизированы.

Например, какой тип аргумента функции is_boolean

Такой функции не существует, а ты клоун - несёшь ахинею.

которая принимает любой объект и возвращает истину, если объект равен true или false и ложь в противном случае?

Каким образом, клоун, ты узнаешь значения неизвестно чего? Как ты его сравнишь с «true или false».

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

Сравнить же непонятно что с непонятно чем - невозможно, в принципе. Любой сравнение типизировано.

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

Пиши в сишке f(void *) - и передавай туда всё, что угодно. А далее ты можешь уже дойти до своей рантайм типизации - добавив rtti. Заменяешь void * на base *, а далее вперёд - f(new Array()), f(new Number()) и всё что угодно.

LjubaSherif
()
Ответ на: комментарий от LjubaSherif

Первое - это не имеет никакого отношения к типизации,

Это имеет отношение к примеру «списка данных разного типа».

второе - есть std::apply

Вот на это я и намекал. Там есть тот самый «список данных разного типа» под названием std::tuple.

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

Существует, если вызываемые функции (min и max) являются частью библиотеки и тебе нельзя их менять.

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

Структура тоже полностью валидна. Невалидна операция записи в несуществующее поле.

Кстати, если f(x) {x.ya_balabol = true;} ошибка типизации, то есть ли ошибка типизации в полностью эквивалентном коде

void f(map<string,bool> x)
{
  x.at("ya_balabol") = true;
}
?

Типы существует только в момент интерпретации данных, т.е. их использования, где(естественно) все типы уже есть.

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

Такой функции не существует,

Существует

ты узнаешь значения неизвестно чего

Почему неизвестно чего? Если тип данных произволен, значит внутри данных есть тэг типа и его можно прочитать.

что сравнить разные типы нельзя

Можно. Просто значения разных типов будут всегда не равны, так как не совпадёт тэг типа. Внутри любые данные — массив битов. Часть этих битов могут описывать тип данных.

Пиши в сишке f(void *) - и передавай туда всё, что угодно.

Так den73 примерно про это и говорил. Что типизация должна быть необязательной. Тебе что-то не понравилось.

monk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.