Re: "Unified model" for beginners

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 12/12/04 

Date: Sun, 12 Dec 2004 10:11:13 GMT

Percival wrote:
> Beth wrote:
> [stuff that took .5 seconds to highlight because you type so ****ing
> much Beth :)]

[ Just doing some "quality assurance" testing on your newsreader that it's
about to deal with such a quantity without crashing ;) ]

> I hate to burst your bubble, but ... this sounds alot like Lisp. I mean,
> ALOT like lisp.

No bubbles burst...there have also been comparisons made to Forth
too...comparisons to C as well...

Good; Proves I've done the job _exactly as intended_...this idea is, by the
way, jokingly called "the Unified Model"...now, if you know about the
original "unified model" and the concepts of a "grand unified force" in
physics and that this is where the "joke" name comes from (though a "joke"
name, it is still meant to convey the basic concept accurately...the "joke"
being the comparison to something so bold as "the theory of everything",
not a "joke" that it isn't about the same kind of "unification" concepts
:), then you can appreciate that I find such comparisons to anything and
everything no kind of "insult" whatsoever...indeed, if I've done it right,
then it can be compared to anything and everything...

I mean, how are comparisons to all these great, working, tried-and-tested
languages an insult? On the contrary, this bursts no bubbles...you've just
confirmed exactly what I intended all along: To "unify" many different
aspects from all over the place into one place...

What insult would it be to say "hey, it can do something like what LISP
does...and it can do something like what Forth does...and it can do
something like what C++ does...and it can do something like what XXX
does...what YYY does...what ZZZ does"...Wow! Excellent! That's no
insult...quite the contrary, exactly what was intended:

To grab the "essential essence" - what's common - between so many different
languages and implementations, reduce it to that "essential essence" only
(remove the "fluff" ;) and then _implement that_...so that, indeed, you can
use it like using LISP, like using C++, like using plain old NASM, like
using HLA, like using all these things...

Indeed, per the name, to stop having "weak nuclear force" (LISP) in its own
little "bubble"...and "strong nuclear force" (Forth) in another
incompatible "bubble"...and "electromagnetism" (C++) over in some other
incompatible "bubble"...to stop seeing things as "space" and "time" but to
see them as "spacetime"...to change our "paradigm" to see _what's the
same_, not what's different...

To, as per the name: "Unify"...a "grand unified force"...the point isn't
that this "grand unified force" is something "new"...not at all...it's
essentially the same old "weak nuclear force", "strong nuclear force",
"electromagnetism", "gravity", "space" and "time" as always...nothing "new"
in that regard...the "new" part is the "paradigm" of seeing these things as
NOT being "separate" and "different" anymore...

That is the whole intention (so, nice to hear that I'm succeeding, to some
degree, to do that...impressive, really, considering I've NEVER used LISP
and have no idea how it works...but it surprises me not to hear this...as I
say, the "essential essence" running through it all...take away all the
"fluff" of the specifics and the details to the "minimal", reduced
"essence" and implement that...which isn't that complicated either:
"groups"...that's it...putting things into "groups" is what nearly every
single "abstraction" boils down to, in the end...time is just the fourth
dimension...it's not a difficult concept in itself...though, the
ramifications - what you're able to do with this new "paradigm" of looking
at things - can be large)...

Originality isn't the point...let Pythagoras play with triangles and
Archimedes play with his rubber ducky in the bath...I'm rather doing what
Euclid did: Putting the whole thing _together_ into one thing called
"mathematics"...not really inventing anything myself but trying to put
everyone's inventions together into a consistent, seamless whole...to take
traditionally "separate" ideas and form them into a "whole"...Euclid's name
may never be remembered quite so fondly as Pythagoras or Archimedes but
what he did was just as important...Pythagoras and Archimedes and such
people worked out "concepts"...but Euclid did something as equally
important...he put them all together to create "mathematics"...one seamless
"theory" for the whole lot...

Or, similarly, Einstein's basic "as simple as possible" to stop seeing
"space" and "time" as separate..."the theory of everything", in a sense,
was his idea...his dream...he started it off by changing the paradigm to
"spacetime" - one "unified" thing - not separate "space" and "time"...doing
so, it started a "chain reaction" which is "unifying" weak, strong,
electromagnetism (the fourth "eludes" unification at the moment :)...the
"grand unifying force", of which, basically, _EVERYTHING_ is made of...the
idea being that of there being _ONE_ set of "laws" that governs
_everything_...the _real_ "laws of the universe"...

"All of these endeavours are based on the belief that existence should have
a completely harmonious structure. Today, we have LESS ground than ever
before for allowing ourselves to be forced away from this wonderful belief"
[ Albert Einstein ]

And, of course, you might be thinking "what's this got to do with
programming?"...but that's the whole point, isn't it? The "divisions" are
only _fabrications_ of our own minds but don't actually exist...programming
is based on Turing principles...Turing principles interplay with things
like "game theory" / "information theory"...information theory is directly
relevent to physics...if you like, the "walls" between "disciplines" are
only human inventions..."terrible illusions" we regularly fool ourselves
into believing are real...but there don't actually exist...

For instance, take your hand...five fingers...you can use your "digits" to
count out numbers and do mathematics...hold it out and we'll put a
microscope to it...on normal magnification, we just see your hand, as
normal...well, that's "biology"...zoom in a little more and we see "cells"
(okay, still "biology") but what's that inside the cell? It's DNA! That's
"evolution" there...okay, turn the dial some more...what do we see now?
Molecules and atoms (okay, we don't actually "see" atoms, this is a
hypothetical microscope that "sees" concepts, not actually based on light
;)...well, that's "chemistry" and periodic tables...but, wait, what's that
inside the atom? Spin the dial some more...protons, neutrons and
electrons...we're in "physics" now...but what's that further down?
"Quarks", eh? We're entering the weird world of "quantum physics"
now...keep going...BANG! Oops, the microscope has stopped working...bloody
"uncertainty principle"!!! Can never get any concepts into focus because of
it!! Oh, well...end of journey but we caught a glimpse of nothing but
"probabilities" floating around, just before it stopped working...so, turns
out your hand is made of "statistics"...oh well, at least you can use the
fingers on your hand to count out numbers to help work out those
statistics, eh? Full circle ;)...

But where were these "brick walls" between things? They weren't really
there, were they? Indeed, here's something to ponder...a carbon atom?
That's inanimate...not alive...but, yet, your hand is alive and animate,
composed of exactly those carbon atoms...ummm, at which point did we cross
the "brick wall" dividing the "alive" bits and the "not alive" bits? Clue:
If you go to biology and evolution newsgroup, then you know how we're
always asking "What is an assembler?" / "The definition of an assembler"
and such? Their recurring topic is "what's the definition of life?" (or
"what is biology?")...take your pick of newsgroups...the "deeply ironic"
thing? They almost all (all the ones that deal with sciences and things
like that...the "Madonna fan club" newsgroup may be different, I don't
know...go ask Laura ;) have these "recurring topics" and the hilarious
thing is that if it's about assembly language, then the topic is "what is
an assembler?" (or "what is assembly language?" phrased differently ;)...if
the newsgroup is about biology, then the topic is "what is the definition
of life?" (or "what is biology, anyway?" phrased in a different way)...

The hilarious thing is this constant pattern everywhere that once someone
becomes "expert" in a topic, they inevitably end up questioning if their
"expert topic" even exists in the first place...essentially, you're hitting
an inherently "human" thing...our brains work by "categories",
"classifications", "nouns, verbs", "divisions", "pigeon-holes", etc.,
etc....to be able to think of anything, the way our brains work is to
_divide_ things..."this is this and that is that", so to speak...so, he's a
"biologist", she's a "mathematician", him over there is a "computer
programmer" (but when the "biologist" talks to the "computer programmer",
we have "AI"...when the "biologist" talks to the "mathematician", we get
population figures and "evolution" (sort of)...when the "mathematician"
talks to the "computer programmer", we have a long discussion about Turing
and such...are these _REALLY_ separate subjects at all? Are we really
creating new subjects by "unifying" them together or is there, in fact,
only _ONE_ subject...and all these "topics" and "subjects" we invent are
just the little "windows" of our mind we place over this one unified
subject, simply because our minds are, to be honest, a touch "puny" and
can't deal with the complete picture but only small "subsets" of it at any
one time?)...

The answer - though forever no-one has accepted this when I've put it
forward - is that there is NO "definition of an assembler"...there is also
NO "definition of life"...at least, there is no physical reality to these
"divisions" and "barriers"...they are just figments of our mind and
imagination...go outside...there are no "rooms", no "walls" but those which
humankind has invented to _cage himself in_...if you head up into the sky,
there is no "point" at which you cease to be "on Earth" and "in space",
really...oh, humans - always insisting on classifications and words and
divisions - will invent "official definitions" that such-and-such miles
counts as the "point" where it changes over...but, up there, there is no
"point"...down here it's Earth, up there it's space...there is no "point"
at which the "division" exists...it's all "fuzzy"...where do atoms stop and
cells start? Where do cells stop and your hand start? Where do you stop and
society begin? Where does _anything_ stop for something else to start?

Einstein's real dream...what Euclid started, so to speak, by inventing
mathematics (and we all know where that little invention got us...is there
anything no "outside" Euclid's unified dream of "mathematics"? ;)...the
"grand unified force"...the "theory of everything" (now you kind of see why
it was given such a grandiose name, eh? Not really because of what it would
be but becomes of what it aspires to do...to finish off what Euclid
started...although, of course, scientists were saying "we're near the end"
at the end of the 19th century...look what happened since...you can always
depend on Murphy's Law to throw in something "new" you weren't expecting
just before the point you thought was "the end of it all" ;)...

And look at mathematics, as the "pure" example...it has one "feature"
that's very important...numbers have no "types" (you can add "units" at the
end to bring meaning back to the numbers, if you like...but numbers
themselves are "typeless" ;)...there are just a set of basic mathematical
operators that you can apply to them, as you like (though, it's "poor show"
that these aren't really "minimal"...you don't need "subtraction", if
you've got addition and negative numbers (or, better, if negative numbers
are just subtractions themselves then you don't need anything but
subtraction and kick out addition instead ;)...multiplication is just a
"HLLism" for "lots of addition"..."to the power of" the same but one
"level" higher again as "lots of multipication"...these operators aren't
properly "minimal"...could we, in fact, kind of do it all with just
"subtraction" and then lots of "HLLism macros" to create all the other
operators as "shorthand"? Ah, don't ask me...ask a "mathematician"...my
"mental window" doesn't extend that far ;)...

"Intertwingularity is not generally acknowledged:

People keep pretending they can make things deeply hierarchical,
categorizable and sequential when they can't.

Everything is deeply intertwingled."

[ Ted Nelson ]

> Lemme explain. Lisp is built on the concept that everything is either an
> atom, or a list. A list BTW, is a list of lists or atoms. Code, Data,
> even jumps, loop constructs, even macros and so forth are all just
> lists. If you are wondering, these "lists" are linked lists.
>
> In essence, a list is a program. In fact, the whole program in Lisp is
> just a list.

Yup, that's a "unified" approach, alright...

Forth has something similar in that you make "words" (that's "word" in its
Plain English meaning, not 16-bits ;) and build up a "vocabulary"..."words"
may be defined in terms of other "words" (somewhat axiomatically...but not
completely so, as Forth does have "keywords" and "operators" that are just
"built-in" ;)...and you build up your "vocabulary" until you have one
"word" which represents your program...you type that "word" in to execute
it and it calls other "words" and other "words" from there and so on and so
forth...

I had this kind of thing totally in mind when I was formulating
"blocks"...indeed, I'm trying to stop C adding in "keywords" and
"differences" and things which would be like LISP having "lists" and
"atoms" but, ummm, some lists are different to others and can't contain
certain types of "atom" and...and...well, it defeats the whole original
purpose, yes? You know what I'm getting at from LISP...perhaps at least you
can appreciate the importance I'm attaching to it being 100% "generic" and
absolutely no "types" of "lists and atoms" (or "blocks" in this case :)...

> Now, this can be applied to Unified model. Everything is either a Block
> or an "atom".

Correct; But there's one _crucial_ little difference...this is assembly
language...and that makes all the difference in the world...the "atoms"
here are the _TRUE_ "atoms" of the CPU itself, not HLL "illusions" of code
and data but the real deal...starting to see where I'm going here?

With LISP, you're creating "lists" of "atoms"...in Forth, you're creating
these "words"...but it's a HLL...the "atoms" are, in fact, not really
"atomic" at all...it's a false name, in fact...but applying this concept to
_ASSEMBLY LANGUAGE_ with "blocks", the machine instructions truly _ARE_ the
"atoms" of the CPU...they are, indeed, _ACTUALLY_ "atomic" (a point of
importance in concurrent programming often :)...

So, now do you see where I'm heading? The assembler is otherwise
NASM-like...the basic machine instructions, no "HLLisms", no fuss or
bother..."no red tape", as NASM likes to call it...

Of course, if you want, then you can just use "atoms" all the way
through...stick with "global variables"...code it "monofile"...a valid use
of blocks will delibrately include "no use of blocks at all" (that covers
all possibilities...none to (theoretical) infinity...in practice, until
your RAM and disk space runs out ;)...

Then we throw "blocks" into the mix...and, yes, the concept is essentially
similar to "lists" (LISP) or "words" (FORTH) or a number of other things
from other languages with a similar perspective...as these languages
demonstrate (indeed, I kind of _need_ these languages as "proof of concept"
that I'm not insane...these languages are _exclusively based_ on the
concept, so, yes, you can have this and nothing else and that _IS_ good
enough to cover all eventualities ;), you can then use these simple,
"generic" mechanisms to build all manner of constructs...all constructs,
really...

In doing so, we can add "blocks" and, as can already be seen by some of the
examples given, we then don't need "structure" keywords or "namespace"
keywords or "class" keywords or special "operators" or any such
thing...just "blocks", the ability to make "macros", of course (though, of
course, macros themselves are just more of the same "block" and "label"
stuff all over again ;) and the machine instructions...the CPU instructions
which _ARE_ the true "atoms" of the CPU itself...

And the "unification" is complete...basing on the _REAL_ "atoms" of the CPU
itself (and you can leave out all "blocks"), then it starts at the lowest
possible level...using blocks and macros and such, you can build up nearly
any construct you like (not just to HLL levels but beyond, if you really
want to do all the work :)...from no abstraction to (theoretical)
infinity...the whole gamut - the complete spectrum - of
possibilities...true, complete Liberty...

[ Well, not quite...one further concept is to even eradicate "machine
instructions" too...instead, there's "DB", so to speak and you can use
"macros" for the mnemonics which produce the correct "DB" sequences for the
machine encodings...now that _really_ is lowest level (and even wolfgang
begins to approve ;)...unfortunately, this is one "contraversy" and
"heresy" too far...even I can't twist people's arms that far...a shame
because you could, of course, use this to create your own
syntaxes...Herbert's syntax could be accomodated as a set of
"macros"...prefer RosAsm or HLA? A different bunch of macros...oh, you can
get really "insane"...a bunch of macros that use 68K mnemonics but generate
(awfully complex macros, though ;) x86 machine encodings...would really be
a "HLL" at that point but it's "cross-assembling" for you there...if we
could "free up" and devise a means to define labels like "+=" or ":=" then,
theoretically, we could consider implementing _any_ programming language as
simply a set of "macros"...this, of course, is highly "advanced material"
here...extending the idea beyond where most people feel comfortable...but
you catch a glimpse of the overall concept: Complete "unification"...true
"anything you can do, I can do better" for assembly language without
compromise...this is the "new" part...the rest, yeah, has all been done
before, no question :) ]

> Thus, I learn more about this, I hope to be able to relate things from
> Lisp so that we could improve the Unified model to do what Lisp fails to
> do. Unfortunatly, i only have moderate experiance in Lisp, and never
> done anything real in it. Perhaps you could learn lisp to see what i mean
:)

"We"? You subscribed to our mailing-list already then? Well, we're "open
source", of course (you know, the real thing, not Rene's strange
"variation" ;)...the more, the merrier...

I would stress, though (because it may worry some), that it's not real
"unification" unless, at the "core", it remains essentially NASM-like...as
I'm trying to get across to C, that "atoms are _really_ atoms" thing is all
part of the "plan" so it should remain "low-level" and NASM-like (when
things like "blocks" are ignored)..."blocks" and "macros" and such are the
means to add on anything else (_IF_ you want to do that)...that is, if you
want some ":>" operator then we need to make the block semantics, label
naming scheme, directives and macro system applicable to _creating_ such an
operator...do that, stick it in the "standard macros" file (then anyone can
use these things by including the correct macros from the "standard macros"
provided with the LuxAsm package...there will be a "standard library" too,
of useful routines...again, don't want them? Don't use them...I'm
endeavouring to make sure, if I can, that these remain _external_ so that
you can _bring them in_ if you want them but they aren't actually
"built-in"...the "minimal" mentality of C / C++ there: Keep the I/O and
such _separate_ :)...

Oh, note, in fact, C, that this is one point about "built-in"...similar to
how we have to put in that "#" character (or whatever) for "standard
properties" to account for "future expansion", if we add in a ":>" operator
then aren't we potentially, in fact, screwing up the possibility of users
developing ">" or "->" or "::" operators and such? Though, this is a tricky
question, anyway...calling a macro "::"? We'd need to review how labels and
things work to do that...to get "total unification" - so that you could
implement Pascal as a "set of macros" or something bizarre like that - we'd
have to work out a way to allow, basically, _any_ name as permissible
(also, "prefix", "infix" and "postfix" parameters?!? ;)...

This, indeed, might be going too far...it's a tempting thought...but like
my "machine instructions are macros too" thing, this is another area of
"compromise"...you can, indeed, dream on forever...but, at some point, got
to draw a line and implement it...who'd want to implement Pascal as a set
of macros, anyway? Or "cross-assemble" to a 68K? Nice ideas, perhaps...but
a lot more effort for little less reward...yes, we can pull the "cut off"
further down than that...but, in a sense, I'm giving you the full "vision",
just so you know where the ideas head and then we can say "okay, that bit
is too much...that bit's going too far" and set the "cut off point" we
actually want for LuxAsm...I'm giving the "uncompromised vision" to lay out
all the ideas and possibilities but realise that, yes, in practice, we'll
have to have a "cut down" version...but when we know the full picture,
choosing the "cut off point" can be done in an "informed" way, so to speak
;)...

Beth :)

Relevant Pages

  • Re: a LISP raytracer
    ... > None of the free Lisp compilers come close to the capabilities of Stalin. ... > OCaml does has camlp4 macros. ... My languages professor right now is a huge fan ... on OCaML, and not so much with LISP. ...
    (comp.graphics.rendering.raytracing)
  • Re: Paul Grahams teaching style is bad
    ... > remaining distinctive features of lisp are a good thing. ... > languages have been picking up from lisp for so long was the big deal, ... > and that macros are only marginally important by comparison, ...
    (comp.lang.lisp)
  • Re: Is Lisp a Blub?
    ... collection is not feasible anymore. ... Why would he be looking toward providing Lisp-style macros ... referring to Gregor's move out of Lisp and into other languages with ... It is interesting that many old Lispers move away from Lisp and ...
    (comp.lang.lisp)
  • Re: Very poor Lisp performance
    ... What practical problems are easier to write in Lisp than in other languages? ... Lisp's macros are more powerful than OCaml's and Lisp programs are likely to be faster than Mathematica programs. ... The essence is that Lisp allows you to embed any kind of language, and mix Lisp and the various embedded languages in your programs. ...
    (comp.lang.lisp)
  • Re: atoms
    ... maths of Brwonian Motion pretty well putting atoms on a respectable ... variety of more detailed predictions which in some cases expand upon ... LISP programming language to refer to certain classes of immutable ...   In LISP dialects, the types of values in a language are often ...
    (comp.lang.scheme)