Repository navigation
Make Entity serializable #323
Description
Activity
@Happypig375 the fact that
Entitywill be serializable doesn't imply by default what exact framework or technique we will use for it. Probably, it will be similar to ToString and return a base64 format. And aMathS.Deserializewill create anEntityback from a serialized one.That's my thoughts, but there should be serialization, so that you could save your formulas, or send somewhere, etc. Remember, that we don't guarantee
a.ToString().ToEntity()be parsable and equal toa.So why not an existing and widespread format like JSON, XML, YML, etc.?
Or not just Parse/ToString?
Maybe we will take JSON, I don't know. I just thought that maybe we want a compressed and fast format
Just Stringize/Parse should be compressed enough, right? I don't know about fast though, but shouldn't be much slower.
Like I said,
a.ToString().ToEntity()!=a. Say, is1 + 2 + 3same as(1 + 2) + 3or1 + (2 + 3)? For this one we haveExplicitOutputsetting, but in general, it might be not parsable back. Also, we need to check how slower it is to parse than to convert from a binary expression.- added a commit that references this issue
on Aug 23, 2026 #1031 does the serialization half, as JSON through
System.Text.Json, with the printed form as the
format — soParse/ToString, which is what @Happypig375 asked twice, wrapped so that anEntity
works as a member of a serializable type without the caller doing anything.Measured before changing anything, on v2.3.0:
JsonSerializer.Serialize(entity)threw for every
entity,(Entity)3included —Nodesis a node's enumeration of itself, so the reflecting converter
walked it until it reported an object cycle.DataContractSerializerrefused the types and
typeof(Entity).IsSerializablewasfalse. So there was no way to serialize an expression at all,
which is the concrete thing this issue names.On the "compressed and fast" thought: reading a 43-node textbook expression costs about 430 us and
0.8 MB through the parser, against 6.5 us and 25 kB to build the same tree from constructors. That
gap is real, and the PR argues it is a case for a faster parser rather than for a second
representation that only serialization uses and that can drift from the printed one.@WhiteBlackGoose your objection has narrowed rather than gone.
StringizeRoundTripTestand
EveryNodeSurvivesEveryPipelineTestdo enforcea.Stringize()parsing back toafor every node
type now — but your own example still stands:1 + (2 + 3)prints as1 + 2 + 3and reads back as
(1 + 2) + 3, because a right operand of equal priority is not bracketed. Shape and not value for
every associative operator; forimpliesit is value, and that is #1032.Codomainis never
printed at all, which is #1022.Two things before this closes, neither of which I have touched:
- the second half of this issue, "and make FieldCache non-serializable", names a type that no
longer exists — the memoisation isLazyPropertyA<T>fields now, and nothing reads a field of a
node any more because the expression is written as text. The reason for it is gone rather than
answered, and that is a maintainer's call. netstandard2.0is not covered: it has noSystem.Text.Jsonin the box and the csproj takes no
package reference for it.
- the second half of this issue, "and make FieldCache non-serializable", names a type that no
- added a commit that references this issue
on Aug 23, 2026 Let's drop netstandard2.0 for v3 and have .NET 10 as the baseline for v3 - JsonSerializer support will then be implicitly available. Note this down for #1019
Let's attempt to make Stringize and parsing as fast as possible with as little memory as possible before deciding that we need a whole new format
And make FieldCache non-serializable