h
универсального варианта нет. точнее, можно его сделать, но даже парсер-генераторы в итоге дают набор нод, как отдельные типы/классы.
Identifier ноду с отдельным типов Identifier. Он не будет абсолютно всё делать как Node {NodeList children}Size: a a a
2021 May 26
h
Вот я и пишу, что ANTLR вам всё равно выдаст для
ВМ
Это можно представить на C# в виде
public interface Expr {}
public sealed class Value : Expr { public readonly int x; }
public sealed class PlusOperator : Expr { public readonly Expr lhs; public readonly Expr rhs; }РС
хмм, а почему?
опять же в книге дракона какие-то отдельные конструкции для построения дерева разбора не упоминаются
опять же в книге дракона какие-то отдельные конструкции для построения дерева разбора не упоминаются
h
с этим очень неудобно будет работать, так как придется для каждой ноды ещё тэг
kind делать, и потом приводить её к типу. А чтобы не было type-slicing'а (простите за мой плюсовый, есть ли он в шарпах не знаю), надо будет поинтеры хранитьВМ
При этом можно делать паттерн матчинг с этим в новых версиях шарпов через те же Expression switch выражения
РС
а если "арность" выражения будет динамической?:)
ВМ
А, в новых шарпах же ещё data классы появились
h
Потому что вам всё равно в какой-то момент надо будет узнать является ли абстрактный инстанс класса
Node Identifier типа. И для этого вам придется записывать тэг вроде NodeKind::Identifier, и потом приводить эту Node к типу Identifier. И если вдруг, там будет не Identifier... 🔥ВМ
Ну будет список экспров лежать у нужного класса
h
для этого есть
vector)РС
вы про записи (record)?
DP
Там все классы это reference типы, там таких проблем нет
h
а... не знал. И dynamic dispatch будет?
DP
РС
так нет, боксинг-анбоксинг будет, это тоже самое же почти
h
хотя стойте. ну да. не будет проблем с type-slicing, но
тут я скорее хочу сказать, что следовало бы избегать
kind всё равно надо будет хранить. его хранить придется в любой случае кстати, так как иногда нужно статически проверять тип ноды при парсинге.тут я скорее хочу сказать, что следовало бы избегать
switch'и повсюду на этот kindРС
не знаю, теоретически это все проблемы семантического анализатора, в моем случае он же будет заполнять таблицу идентификаторов и вычислять выражения
h
а зачем самому себе создавать проблемы?
вы пишете на ООП языке, и для вас же будет удобнее сделать пару десятков крохатных классов для каждой ноды, чем возиться потом с проверками вроде "Нода идентификатора не может содержать в себе функцию" 😊
вы пишете на ООП языке, и для вас же будет удобнее сделать пару десятков крохатных классов для каждой ноды, чем возиться потом с проверками вроде "Нода идентификатора не может содержать в себе функцию" 😊