Still working on standards.

archive/note1.txt

@@ -0,0 +1,159 @@
+
+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