Предлагаю синтаксис языка Haskell! Конечно же, измененный под наши нужды. На самом деле я серьезно: в Haskell есть и enum (ADT), и trait (type-class), и closure (lambda), и async/await (do-notation). Он и так уже повлиял на Rust, но все же было бы здорово еще выкинуть хотя бы лишние скобки и точки с запятой. На функциональности это точно никак не сказалось бы. А пока работаем с тем, что имеем.
UPD. Если из-за инверсии код выглядит сильно по-другому, то на Haskell его можно переписать, используя "pipe-оператор", например.
-- pipe
($>) :: a -> (a -> b) -> b
($>) = flip ($)
-- аннотацию типа можно не писать
calculate :: Int -> Int -> Int
calculate bottom top = [bottom..top] $> (filter even) $> sum
Да, в современном английском языке у существительных действительно (почти) полностью отсутствует категория рода. Важно понимать, что речь идет именно о грамматической, но никак не семантической, категории рода.
В эсперанто вы имеете ровно такую же ситуацию, просто для обозначения "сестринства" вам сначала потребуется образовать слово "сестра" от слова "брат", добавив суффикс, сигнализирующий о принадлежности к женскому полу.
Брат - a broth'er - frat'o, сестра - a sist'er - frat'in'o, братство - a broth'er'hood - frat'ec'o, сестринство - a sist'er'hood - frat'in'ec'o. Апострофами отмечены границы морфем. В этом плане английский и эсперанто невероятно схожи и оба используют агглютинацию для словообразования.
Думаю, автор не подменял определения, а говорил об этом же подходе, но с другой стороны. Например, у нас есть функция с сигнатурой f : {a : Type} -> (a, a) -> a. Она принимает кортеж (a, a), который является лишь одним аргументом, ведь это всего-то терм типа (a, a). И если вместо него там будет гетерогенный список или любая другая структура данных, все равно ничто не изменится. Таким образом, обычно мы используем две операции, одна из которых отображает тип (a, a) в тип a -> a, а вторая делает обратное.
Прошу прощения, но рациональное число — пара таких чисел m и n, что m — целое число, n — натуральное число, которое > 0. Если же мы говорим про множество несократимых рациональных чисел, то добавляем условие того, что наибольший общий делитель m и n = 1.
Извиняюсь, я глупость написал. Не флективный, а аналитический. Почти противоположные подходы (но часто совмещаются).
Так, отсутствие союзов сильно увеличивает вероятность моей неправоты.
Я вас понял. Немного жаль, конечно. Во всяком случае, всегда буду рад снова увидеть ваши оригинальные статьи на любую другую тему. Удачи с вашим проектом!
Я понимаю, о чем вы говорите. Но я искренне не понимаю, зачем писать такой код в JS. Может, человек ожидал наличие кортежей (сарказм), может еще что-то, конечно, но все же. Ни в одном языке не нужно использовать конструкции, с которыми ты не знаком. И о типах, да, я согласен, что здешняя система типов местами отвратительна, но ее действительно нужно знать. В C++ типизация тоже не на высоте, но никто в здравом уме не будет отрицать, что этот язык очень важен во многих сферах, и нужно знать о некоторых нюансах его реализации, чтобы его использовать.
Но как рофл — статья действительно хороша. xd
P.S. Как поживает ваш компилятор LENS? Будут ли новые статьи на тему компиляции?
Я как раз пытаюсь до вас донести, что веб-воркеры появились по другим причинам. Использование DOM API однопоточное и потребности делать его многопоточным нет. Веб-воркеры решают другую проблему — они нужны для вычислений. Не нужно использовать их для рендеринга.
Ответ на ваш вопрос содержится в одном из комментариев выше.
В JS изначально была возможность работать только с одним потоком по той причине, что нельзя работать с API DOM с разу из нескольких потоков.
Этой мой первый серьезный компилятор, так что это, своего рода, проба пера. Я хочу, чтобы получился максимально строгий и понятный язык, очень много думаю над синтаксисом.
Он, к сожалению, пока только в стадии зарождения. На данный момент есть только переменные, а из типов данных только числа и хлипкая реализация массивов. Все компилируется в простой ассемблерный код, синтаксис NASM. Так как опыта довольно мало в этой сфере, приходилось несколько раз начинать сначала, сейчас чувствую, что на верном пути. Нет, этап не пройденный, сейчас дочитываю Креншоу, на работы Вирта ни разу не смотрел, как ни странно. Спасибо большое за литературу!
Мне очень понравилась статья. Сейчас и сам пишу язык, чтобы прокачать навыки. Был бы очень рад, если бы вы поделились своим опытом в этом деле и написали статью на эту тему. Спасибо!
Прекрасная статья! Да, она большая, но очень интересная, так ещё и понятная... Даже тем, кто не в теме. Пишите ещё! Буду рекомендовать друзьям.
Наконец-то кто-то об этом заговорил
Предлагаю синтаксис языка Haskell! Конечно же, измененный под наши нужды. На самом деле я серьезно: в Haskell есть и enum (ADT), и trait (type-class), и closure (lambda), и async/await (do-notation). Он и так уже повлиял на Rust, но все же было бы здорово еще выкинуть хотя бы лишние скобки и точки с запятой. На функциональности это точно никак не сказалось бы. А пока работаем с тем, что имеем.
UPD. Есть даже картинка по теме:
UPD. Если из-за инверсии код выглядит сильно по-другому, то на Haskell его можно переписать, используя "pipe-оператор", например.
Настоятельно рекомендую ознакомиться с данным видео.
Да, в современном английском языке у существительных действительно (почти) полностью отсутствует категория рода. Важно понимать, что речь идет именно о грамматической, но никак не семантической, категории рода.
В эсперанто вы имеете ровно такую же ситуацию, просто для обозначения "сестринства" вам сначала потребуется образовать слово "сестра" от слова "брат", добавив суффикс, сигнализирующий о принадлежности к женскому полу.
Брат - a broth'er - frat'o, сестра - a sist'er - frat'in'o, братство - a broth'er'hood - frat'ec'o, сестринство - a sist'er'hood - frat'in'ec'o. Апострофами отмечены границы морфем. В этом плане английский и эсперанто невероятно схожи и оба используют агглютинацию для словообразования.
Рекомендую к просмотру:
https://youtu.be/Ku-3ySghWgA
https://youtu.be/3AnG3tbwlIw
https://youtu.be/7kV_bLrfUxs
Думаю, автор не подменял определения, а говорил об этом же подходе, но с другой стороны. Например, у нас есть функция с сигнатурой
f : {a : Type} -> (a, a) -> a. Она принимает кортеж(a, a), который является лишь одним аргументом, ведь это всего-то терм типа(a, a). И если вместо него там будет гетерогенный список или любая другая структура данных, все равно ничто не изменится. Таким образом, обычно мы используем две операции, одна из которых отображает тип(a, a)в типa -> a, а вторая делает обратное.Так, отсутствие союзов сильно увеличивает вероятность моей неправоты.
Как всегда — очень интересно!
Но меня все еще волнует вопрос — что за тему вы используете? :)
Но как рофл — статья действительно хороша. xd
P.S. Как поживает ваш компилятор LENS? Будут ли новые статьи на тему компиляции?
Или даже цикл статей :)
Я как раз пытаюсь до вас донести, что веб-воркеры появились по другим причинам. Использование DOM API однопоточное и потребности делать его многопоточным нет. Веб-воркеры решают другую проблему — они нужны для вычислений. Не нужно использовать их для рендеринга.
В JS изначально была возможность работать только с одним потоком по той причине, что нельзя работать с API DOM с разу из нескольких потоков.
Этой мой первый серьезный компилятор, так что это, своего рода, проба пера. Я хочу, чтобы получился максимально строгий и понятный язык, очень много думаю над синтаксисом.
Он, к сожалению, пока только в стадии зарождения. На данный момент есть только переменные, а из типов данных только числа и хлипкая реализация массивов. Все компилируется в простой ассемблерный код, синтаксис NASM. Так как опыта довольно мало в этой сфере, приходилось несколько раз начинать сначала, сейчас чувствую, что на верном пути. Нет, этап не пройденный, сейчас дочитываю Креншоу, на работы Вирта ни разу не смотрел, как ни странно. Спасибо большое за литературу!