Open effectfully opened 1 month ago
@effectfully will the let
node allow for multiple variables?
eg
(let a b c d
body
)
instead of
(let a
(let b
(let c
(let d
body
)
)
)
)
Otherwise case
and constr
are only 2 nodes of difference
(case
(constr 0 a b c d)
(lam a
(lam b
(lam c
(lam d
body
)
)
)
)
)
will the
let
node allow for multiple variables?
I'm not sure if that'll buy us much (or even anything at all) in terms of size or performance. Or can you think of something?
Otherwise case and
constr
are only 2 nodes of difference
The issue with constr
is that you need those arguments to get fed into lambdas one by one and it's just less efficient to evaluate applied lambdas than it is to evaluate let
nodes, especially in the current Haskell VM. Plus let
s are more readable and I'd rather make UPLC readable if I can help it.
the cost of nodes evaluation will be the same right?
the number of lambdas is the same of the number of let
I'm not sure if that'll buy us much (or even anything at all) in terms of size or performance
Why this is not a problem for case
and constr
, which both have unbounded number of children?
the cost of nodes evaluation will be the same right?
the number of lambdas is the same of the number of let
You're asking an interesting question, I'll bring it up to the team.
Why this is not a problem for
case
andconstr
, which both have unbounded number of children?
Those have to have them, it wouldn't make much sense to only allow constructors with a single argument. Single let
s on the other hand are perfectly reasonable.
@nau reported some stats and they suggest that evaluating AST nodes consumes 96.66% of MEM, which is an absurdly huge amount compared to the 3.34% that builtins consume. Does it really have to be that way? And if it does, should we prioritize working on solutions making MEM consumption lower by evaluating fewer AST nodes or producing fewer evaluation frames? For example by adding
fix
(issue) orlet
(issue) to the AST.