160 lines
4.9 KiB
Plaintext
160 lines
4.9 KiB
Plaintext
|
|
taking expressions and parsing them later down?
|
|
that seems slightly stupid.
|
|
really, an expression is sort of a tree that
|
|
hasn't been dealt with yet.
|
|
is it really wise to keep passing them down as
|
|
just that expression?
|
|
otherwise it would have to be evaluated in the later
|
|
scope.
|
|
it makes more sense to sort of evaluate things
|
|
as we go along.
|
|
at the very least, every expression will always end
|
|
up being 'something'.
|
|
it just means that we need to execute different
|
|
expressions in different contexts
|
|
i guess.
|
|
so 'meaning' becomes slightly more interesting here.
|
|
i guess this would be where the macros fit.
|
|
we could use a macro, which literally replaces
|
|
a particular expression with another one, somehow, or
|
|
maybe pass in some other sort of context to evaluate
|
|
these things under. but that would evaluate everything
|
|
that way.
|
|
it would be nice if we could somehow refer to an
|
|
expression as what it is expressed as, but also
|
|
what it will be.
|
|
|
|
i mean: let (render (elements)) mean (... do stuff ...)
|
|
is great and all because i can now do:
|
|
render (
|
|
box()
|
|
)
|
|
but then how about
|
|
let (view) mean (box())
|
|
and then render(view)
|
|
|
|
that clearly does not work, but absolutely should be
|
|
valid nel code.
|
|
|
|
with equal pertinence, on the other hand we have:
|
|
|
|
let (sum) mean (math (5 + 2))
|
|
where math ()...
|
|
|
|
hold on. i think i know why this is actually confusing
|
|
me. it also connects quite well with how source code
|
|
works.
|
|
|
|
'mean' means 'copy the expression in place'
|
|
somehow preserving the scope.
|
|
but
|
|
'be' means 'the literal value we want'
|
|
|
|
which is, definitely rather odd. very odd.
|
|
how is each one useful in their own right?
|
|
|
|
i think, my issue is that im really struggling
|
|
to see the direct separation between what we have
|
|
defined in nel and what the compiled bits should be!
|
|
|
|
code {
|
|
(number) means (int)
|
|
let (x) is a (number)
|
|
let (y) is a (number)
|
|
let (sum) is a (number), is (x + y)
|
|
}
|
|
|
|
i mean its weird. very weird.
|
|
since the 'let' bits should really be interpreted by
|
|
the 'code' expression to represent some local variables
|
|
in source code!
|
|
but then the 'means' bit quite literally breaks that idea
|
|
in two because that isn't source code at all it's just
|
|
doing its own thing really.
|
|
we ideally want 'means' to be available everywhere?
|
|
are there any situations where it is bad?
|
|
and again, what about macros?
|
|
so maybe back to html as a weird example
|
|
|
|
ui {
|
|
|
|
box()
|
|
}
|
|
|
|
i think i get it now.
|
|
when you use 'means' you are creating a new binding in
|
|
the scope that forces NEL to create a 'value' which
|
|
is more a wrapper (or even a trap!) that calls that
|
|
particular expression again in the parent scope.
|
|
this IS that macro, and i think it is quite deadly.
|
|
which makes me wonder, is this a good idea to have
|
|
around? well, i'm not sure!
|
|
|
|
in a lot of cases, this is actually very nice, because
|
|
we can literally just functionally expand our ENTIRE
|
|
program out as we please without any function overhead.
|
|
note that this is bad for maintainability and code bloat.
|
|
we also still have the power of a general routine, so this
|
|
isn't all doom and gloom really.
|
|
|
|
how weird.
|
|
i think i am sort of ok knowing this now, even though
|
|
i am now very much more confused than even before.
|
|
|
|
however, this turns out to be very nice.
|
|
|
|
so:
|
|
(doeth (code)) means (do (code))
|
|
|
|
right, crap. effectively here that entire idea doesn't
|
|
really hold water simply because i need the candid
|
|
expression to be able to execute the nellie effectively.
|
|
that's not entirely great is it now.
|
|
|
|
'means' and 'do' operations themselves work over abstract
|
|
nel anyways. this sum foolery indeed.
|
|
so effectively, abstract nel doesnt like abstract nel,
|
|
yes yes yes that makes complete sense actually.
|
|
because with doubly abstract nel we cannot just say
|
|
(action) means (print (text (fart)))
|
|
and then literally
|
|
do {
|
|
action;
|
|
action;
|
|
action;
|
|
}
|
|
or even worse have some sort of multiplicative expression.
|
|
it's just not feasible you see!
|
|
however, i now think i have a sort of idea.
|
|
you see, with bindings, we can have values
|
|
|
|
i have been thinking for a while and i am not sure if
|
|
i can easily find some sort of solution to all of this.
|
|
it's quite concerning really.
|
|
|
|
do {}
|
|
represents a list of expressions, how can we define this,
|
|
just in pure NEL, to execute each statement.
|
|
because, and i need to keep saying it, NEL should compile
|
|
NEL, no?
|
|
if EVERYTHING is written in NEL, then i surely should be
|
|
allowed to write nel that can interpret expressions this
|
|
way. it just feels incredibly stupid to not be able to.
|
|
like what?
|
|
all while being simple to understand. completely insane.
|
|
COMPLETELY, insane.
|
|
|
|
unless... just about unless.
|
|
all expressions were functions.
|
|
that promised to give back an expression.
|
|
|
|
i realise now that my mind is very very weak.
|
|
there is something missing from it. it's not about all the
|
|
puzzles. it seems definition is trivial to everything.
|
|
but this algorithm seems to me like a knot.
|
|
its not a knot, i know there is a very clean solution,
|
|
i just cant see it right now.
|
|
i need to actually break things down into what i want first
|
|
so i can see things as clearly as i possibly can
|