Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты

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

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

P.S. Я допускаю, что теоркатщики могут себе придумывать проблемы с параметризированностью типов, но на практике, паттерн матчинг делает код чище. Достаточно пописать на Typescript с его кастрированным паттерн матчингом и Rust/ML/Ваш вариант, и увидеть насколько все проще выглядит на практике. Я уже не говорю про С с union/enum парами.

Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты

1. Почему нет? Любой тип может возвращать константное значение паттерна.
2. Я не против

Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты

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

Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты

Например так:

trait PatternProducer {
    fn pattern(&self) -> &'static str;
}

struct Class {
    producer_fn: Box<dyn Fn() -> &'static str>
}

impl Class {
    pub fn new(pattern: &'static str) -> Self {
        Class {
            producer_fn: Box::new(move || pattern)
        }
    }
}

impl PatternProducer for Class {
    fn pattern(&self) -> &'static str {
        (self.producer_fn)()
    }
}

fn print_pattern(class: &dyn PatternProducer) {
    match class.pattern() {
        "a" => println!("Match A"),
        "b" => println!("Match B"),
        _ => println!("Unknown pattern")
    }
}

fn main() {
    print_pattern(&Class::new("a"));
    print_pattern(&Class::new("b"));
    print_pattern(&Class::new("c"));
}

На самом деле, информация о типах — это такие же данные, как и все остальное.
На эти данные навешен какой-то функционал в рантайме, который поддерживается языком.

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

Что такое Spring Framework? От внедрения зависимостей до Web MVC

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

1. «Изменения» байт-кода выглядит подходящим словом.
2. Spring Boot наверное «альтернативная версия»

Оригинальность конечно будет терятся, но новичкам это будет намного понятней. Они и так страдают с этими всеми фреймворками.

Что такое Spring Framework? От внедрения зависимостей до Web MVC

Как насчет реального плетения байт-кода?

— в этом месте сильно задумался как фраза звучала в оригинале.

Spring Boot — это самоуверенная версия Spring Framework

— тут сдался и полез в оригинал.

val6852, спасибо конечно за труд, но текст неплохо было бы хотя бы перечитывать после машинного перевода, а то местами очень похоже на GTA San Andreas.

Теория программирования: Вариантность

К сожалению, не являюсь достаточным специалистом в Скале, что бы реализовывать. Боюсь попасть под немилость скалистов )

Теория программирования: Вариантность

Вот здесь пример с животными.

Выглядит примерно так

class Foo[+A] // A covariant class
class Bar[-A] // A contravariant class
class Baz[A]  // An invariant class

Плюс там есть ограничения варинтности до определенного типа (не уверен в правильности определения. В оригинале type bounds):

trait Node[+B] {
  def prepend[U >: B](elem: U): Node[U]
}

case class ListNode[+B](h: B, t: Node[B]) extends Node[B] {
  def prepend[U >: B](elem: U): ListNode[U] = ListNode(elem, this)
  def head: B = h
  def tail: Node[B] = t
}

case class Nil[+B]() extends Node[B] {
  def prepend[U >: B](elem: U): ListNode[U] = ListNode(elem, this)
}

Теория программирования: Вариантность

vintage, а в Scala смотрели? Там, насколько я знаю, с этим должно быть все хорошо.

Указатели в Python: в чём суть?

Здесь переменная x имеет фальшивый адрес 0x7f1 и значение 2337

Почему интересно фальшивый? В крайнем случае «виртуальный». У людей может создаться впечатление, что в С там тоже какае-то непонятная адресация.

Пишем на Rust + CUDA C

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

Качество кода

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

• Написать комментарий с описанием логики работы функции с полученным значением;
• Сделать функцию-обертку для интерфейсной функции с другим именем;
• Сделать временную переменную с именем, которое отражает смысловую нагрузку полученного значения применительно к алгоритму функции;

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

ООП мертво, да здравствует ООП

Джентльмены, а посоветуйте хорошую книгу по OOD, если такова имеется.

Удивительная производительность параллельных алгоритмов C++17. Миф или Реальность?

А почему OpenMP может себя так плохо показывать в случае с тригонометрическими функциями?

Компания LG объявила о выпуске открытой платформы WebOS Open Source Edition

Это не зоопарк окололинуксовых технологий, а обычный линукс дистрибутив. Дистрибутив удобен прежде всего из-за Javascript фреймворков и LS2 API, которые довольно сильно упрощают разработку. На самом деле там довольно много времени было вложено в разработку ОСи. Назвать ее зоопарком технологий нельзя. Там свой композитор, мультимедиа движок и т.п.
Говорю обоснованно, так-как когда то был одним из разработчиков.
WebOS уже довольно давно и успешно работает на телеках. Сравнивать с FirefoxOS некорректно, т.к. у Мозиллы не было устройств с ее операционкой.
Но шанс умереть есть. Они в свое сделали большую ошибку — закрыли исходный код. Это во времена, когда были люди, которые реально контрибютили в OpenWebOS. Как мне кажется, хотели выстрелить и отожрать много рынка. Сейчас, по всей видимости, испугались Андроида и открыли. Но сегодня вероятность того, что кто-то опять возмется за разработку под эту операционку очень мала.

LL(*) парсер с использованием Rust макросов

Немного поискал и нашел cargo-expand. Он позволяет выводить сгенерированный макросами код. При желании, можно сначала разворачивать, а потом включать в проект и отлаживать.

LL(*) парсер с использованием Rust макросов

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

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

Я знаю один действенный вариант отладки анализатора — покрывать все правила тестами. Во всех других случаях отладчик помогает очень слабо.

LL(*) парсер с использованием Rust макросов

А можно ли таким образом выполнять нужный код в зависимости от типа параметра? Например иметь разный код для stat и для expr:

macro_rule! fancy_macro => {
  [$arg: expr, $($ex: expr),? $($st:stat),?] => {
    $($expr($arg)),?
    $(
        $st;
        $arg
     ),?
  }
}

LL(*) парсер с использованием Rust макросов

Поправил, спасибо.

LL(*) парсер с использованием Rust макросов

Пожалуйста.

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