Re: [ Attn: Randy ] Ad-hoc Parsing?

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

Date: Sun, 12 Dec 2004 21:43:46 GMT

The \\o//annabee wrote:
> This looks a little better than what I'd feared.
> What plans for Right-clicks and similar niceessities ?

Plans for right-clicks? Ummm, the answer is "yes"...yes, we will have
right-clicks (and probably, in fact, "tooltips" and other such navigational
aids too :)...the exact details? Yet to be decided...

Though, one aspect is that LuxAsm has these "property" things (in short, as
every label can have "child" labels in this scheme...so then constants,
equates and such can also be "local" to labels and blocks too, by being
child "properties" of any label...do you get me? There are "local #defines
/ equates" (which can be attached to blocks and individual labels) as well
as "global #defines / equates" (like those found in other assemblers /
programming languages...these, in fact, are the same thing, really, as the
"local" ones but are just "children" of the "root" of the tree, which is
"global"), so to speak :)...

Anyway, as well as the fact that you can use these "properties" yourself
for programming (set up constants, equates and things...note, as these can
also be "local" too, you can, for instance, create those "flags" used in a
structure to be "local" to that structure...taking Windows - because you
know that best, I think - you can create CS_HREDRAW, CS_VREDRAW,
CS_SAVEBITS constants and such as "local" to WNDCLASS structures...so,
really, you don't need that "CS_" thing at the start anymore...well, except
just to keep to the "standard names" :)...there are also "standard
properties"...

These "standard properties" all start with a "#" prefix...well, actually,
this prefix character might be "$" or something, in the end...the exact
character is being debated but there'll be a "prefix" to all these
"standard properties" to 1. make them visually obvious 2. "reserve for
future use" (as only "standard" properties have the prefix but user ones
don't then more "standard properties" could be added in future with no
danger of "clash" with user properties :)...

Anyway, the "trick" with these "standard properties" is that they are
understood and recognised by the assembler and / or IDE to denote special
things...a means to "communicate" things from the source code to the
assembler and IDE to do things (often replacing the need for "directives"
for various things :)...

The most obvious one we're going to have is a "#type" property...simply,
this is just a string that can be attached to any label...by default, the
string is effectively blank..."not set" / "no type"...whenever the
assembler is processing the source code, it, in fact, checks the "#type"
properties (if they exist)...if types are being mixed - literally as simple
as a string compare between the two "#type" properties to see if they match
or not (note, if no "#type" is set, they default to blank...blank compared
with blank is a "match"...if you don't ever set any "#type" properties,
then types always match up and you effectively have no "data typing" at
all, as per NASM ;) - then the assembler issues a warning: "type mismatch"
or whatever (note also that I said _WARNING_, not error...this is not
really an error and HLLs misclassify it treating it as an error, really)...

So, with the "#type" property (optional), you can specify _selectively_
"data typing" from none at all to very strict (indeed, the "#type" is just
a string...so, you can stick with simple, basic types like "integer",
"float", etc....or something stricter like "array index integer", "count
integer" to get any type of "types" you like...meaning this can get _more_
"strict" with data types than HLLs :)..."selectively" meaning you can add
"#types" to some things but not to others, as you like (so, perhaps you
might normally not use "data types" but you can add a few to help with
"debugging" without meaning you have to give everything a "#type"...leave
'em in, delete them later on...whatever...as I suggest is the "LuxAsm way"
of doing things, we're not telling anyone how they should program but
trying to offer support for all types of programming and then the
programmer chooses what they want...so, for instance, there is this
"selective data typing" available but, by default, the "#type" property is
blank (indeed, implementation-wise, it'll only be allocated if it's ever
set so it doesn't take up RAM to do nothing...not that, on the user end,
you'll be able to tell the difference and you can logically treat it as if
there is a "#type" property there but it's just not set to anything ;)...if
you want data types, then just set the "#type" properties for all your
variables and you've got it (selectively, to whatever level of "strictness"
you like from the choice of strings you use :)...so, as I say, it's up to
the programmer what they want to do...LuxAsm just tries to provide the
facilities but there's no compulsion to actually use them...or, possibly,
don't bother with "types" for something small but do bother with them for a
big, complicated project where they might be useful...so you can also
choose to sometimes use a facility or sometimes not...it's not always
appropriate or useful...indeed, many reject "data types" wholesale exactly
because they are so often "non-optional" and _must_ be applied to
everything, like it or not...well, you don't have to reject it outright
with LuxAsm because it's optional and it's _selective_...so, for instance,
you could just add them to just a few variables to help with "debugging" in
a problematic area (use them to just "double-check" you've not made any
silly obvious mistakes :) and not bother elsewhere :)...

Anyway, what's this have to do with the IDE and "right-click"? Well, I had
to explain these "standard properties" more generally (and the "#type" is a
good example, plus, yes, a nice "advert" at the same time ;)...but the
point is that another idea for a "standard property" we're thinking about
is a "#comment" standard property...

In this case, the "#comment" standard property is for the benefit of the
IDE...another string that can be set by the user to anything they
like...and the basic idea is that if you roll the mouse over any label that
has a "#comment" property then that text is just echoed back in a
"tooltip"...optional, of course, as always...but a rather simple but
effective little device...you can define your variable and then add a
"#comment" in the source code to say: "This variable keeps track of the
current customer record in the database; -1 means 'no record'; Added by
Beth on 12-12-2004" (put this next to the variable declaration and, of
course, it doubles up as a comment of the usual variety, explaining what
something is :)...or, of course, _ANY_ string that you reckon would be
useful to see...

And then anywhere in the source code that this variable is referred to, you
might forget what it is...roll the mouse over it and the IDE brings up a
"tooltip" which lists information about it...the "#type" property, if it
has one...and the "#comment" property, if one is set too...just "echoes"
back whatever you wrote...the simple idea being that these are much the
same "comments" that you might add to your source code to explain what a
variable is for or what parameters a routine takes or whatever...but you
can actually _attach_ them to those labels and the IDE can then call back
the "#comment" in a "tooltip" when you hover the mouse over the label,
anywhere in the source code...

This way, the "#comment" comes to you, instead of you trying to go find the
comment in the declaration section of the source code somewhere...other
"standard properties" could do other things like this...for example, for a
group of constants or a structure, then a useful display is not only the
information on just the one constant or member of the structure but to list
out the whole "block"...so, another "standard property" could be used to
set things like this...blah-blah-blah...

So, in addition to RosAsm-like "right-click" navigation, these "standard
properties" can also bring extra features, like these roll-over "#comments"
(so, rather than jumping to the declaration, you can just look at the
"tooltip" instead...saves time if you only want to know, say, what value a
constant is but nothing else...don't actually need to "jump" around the
source code to pull up information...though a "jump to" feature will be
included too, of course...as, of course, you might want to change it, not
just read some information about it :)...

Nothing has been exactly decided...for example, I'd rather a right-click
menu appears and that "jump to..." is the top option but that there are
other options like "cut, copy, paste" or "back, forward" navigation and the
like on this menu too...yes, this means it would be "two click" rather than
RosAsm "one click" but, well, I'm thinking that the extra click is a price
worth paying to be able to put other features at easy reach too...also,
it's more "standard" - how other applications work - for a menu to appear
on right-click (with "cut", "copy", "paste" when clicking over something
with text...and "back" and "forward" for things that have "history" and
"navigation" :)...as I say, this has not been decided firmly or
anything...but this is how I personally see it working (but maybe everyone
else will "override" me and insist it's "one click" like RosAsm, not "two
click" with a "context menu"...just my personal opinion that we should
really do this because you can then pack more features onto the right-click
menu besides just simple navigation and this is more "familiar" to what
right-click does in other applications...I think that the extra click, so
to speak, is a minor thing in comparison...and, indeed, "jump to..." can be
the top option that it's only fractionally more effort...this way, the
"back" and "forward" options could also be put on the menu and not require
going up to some "toolbar" all the time...you know, "swings and
roundabouts"...the extra click and a "menu" might make "jump to..."
slightly more complex but it makes other things - "back", "forward", "cut",
"copy", "paste" (and anything else I can think up ;) - easier...I think
that's worth the extra click myself :)...

And, of course, the "incremental" brings up the "type time feedback" stuff
with the IDE too...the assembler and IDE are, in a sense, "in constant
communication" and send information back and forth ("deep integration", as
I like to call it :)...so, as you type, the IDE sends the changes to the
assembler, as you know...BUT what might not be so obvious is that, by the
same token, the assembler can also send back information to the IDE in
response...and that's where the "nice-essities" appear...

For example, the assembler can send back _accurate_ and "fine grained"
syntax highlighting information directly from its "parsing" phase...you
know, rather than the IDE just looking over the text and trying to work out
how to colour it, the IDE sends the source code to the assembler, which
sends back exactly the information about what the assembler parsed when it
was assembling ("incrementally" :)...and, thus, the colours for the "syntax
highlighting" comes "straight from the horse's mouth"...it is _guaranteed_
to be exactly accurate to how the assembler really is looking at the source
code because it _IS_ what the assembler made of the source code...and it
can be more "fine-grained" too than most syntax highlighting because, of
course, the assembler's parser _REALLY_ reads the source code and
understands it all...

Plus, implementation-wise, this is a nice idea from the perspective that
you're "re-using" the assembler's parser rather than writing a simple one
for the IDE and another one for the assembler (two things doing much the
same job? No, one thing can do it and then "re-use" its information
:)...the assembler _already_ does this job when it process source code...so
the IDE just "borrows" the information that the assembler determined doing
that for "syntax highlighting" and "tooltips" and such...meaning instant
"feedback", which is always guaranteed _accurate_ (because it literally
_IS_ what the assembler is seeing, not just a "guess" ;)...

As well as the other "incremental" benefits...no "assemble"
button...because it's always doing this in the background as you type
(instead, a "save" button...the idea being that it assembles into RAM as
you go along and when you're satisfied, hit "save" and that "flushes" it
out to the files (note, also, as it's working in RAM mostly then, sorry
Rene, all the "file-based" assemblers are no way going to catch up with a
totally RAM-based assembly process...5ns versus 1700rpm? No contest! Plus,
"incremental" happens in parallel _AND_ it guarantees "once only"
assembling...if you're still thinking you'll compare to this, Rene, then
you have _NO IDEA_ what you're dealing with here...okay, the odd "bad
cascade" could slow it down but, generally, the term "instant" will mostly
apply...and the most important point is that, whatever the speed in the
end, you're NOT WAITING and that changes things around radically...it's not
about "assemble speed" anymore, really ;)...of course, this shouldn't be in
any way an "unfamiliar" way of doing things...this is what you're doing
when you load up a file into Notepad or Word or Excel, right? The file is
loaded into RAM, you edit it (in RAM) and then hit "save" to write the
changes to the file...the way this "incremental" stuff will work will be
broadly similar (again, "exact details to be announced" ;)...load the
project into the IDE, edit it, hit "save" to "commit" your changes to your
files...if you screw things up then a "revert" command can be included
too...just gives up on the RAM copy and re-loads it back from the file to
"start again"...again, something you've probably already seen on your GUI
applications, anyway...this isn't "new", of course...as I say, the idea is
to make it work much like most other GUI applications already work...the
"new" bit is having this happening with a programming language, as that's
not "usual" :)...

Another IDE-based concept is a minor little "cosmetic" change that can
really make a difference to editing...there'll be a "project tree" window
(keeps track of your project files in their "tree"...oh, note, again, as
the IDE receives information from the assembler directly then another
"feature" is automatic "auto-dependency"...when you type "#include", the
assembler processes this and sends back information to the IDE, where the
include file is automatically appended to the "project tree" in the right
place...yes, appearing as you type the line and disappearing as you delete
the line, right in front of your eyes..and, again, "always guaranteed
accurate" because this _IS_ what the assembler sees when it processes the
changes that you're directly being shown on screen, "as it happens"...as I
say, "instant feedback"...indeed, perhaps the biggest problem with this is
that, at first, it might freak people out to be so well supported (an
actual _INTEGRATED_ development environment, not the "aggregated
development environments" elsewhere that falsely call themselves
"integrated"...the LuxAsm tools all work together with "tight
integration"...this is where the user sees the benefits of our "modular
architecture" internal structure)...but, Hopefully, you'll all get used to
it lickety-split and then it becomes working without such features (like
with RosAsm too :), which is what you can't handle too well anymore and
freaks you out ;)...

Anyway, yes...the "project tree"...another simple minor change I was
thinking (again, we're not on the IDE design yet, so all this is still
"ideas" yet to be decided or firmed up ;), is that, as normal, you can
double-click on a file in the "project tree" and the file appears...the
subtle little difference is this: When you close the file, it _returns_ to
the "project tree" (a little "*" appears next to the filename to denote
"modified" ;)...open up some more files from the "project tree", close
them...and then little "*" modified stars appear next to the changed
files...they _aren't_ saved unless you specifically hit "save" (or, to save
time, there will be a "save all" too :)...again, working in RAM...after
all, machines have plenty of RAM (and "virtual memory") that we can _stop_
working to the assumption that we've only got 8KB RAM and need to
constantly work sequentially from files / to files all the time...the
"traditional" methods are grounded in a situation that was true in
1973...4KB RAM, can't hold the source code, assembler and output all in RAM
at the same time...so, just feed the file one line at a time to the
assembler from a _file_ which sends the output straight back out to another
_file_...keep RAM free and empty...

Oh, come on, there's plenty to spare these days (especially when we're
dealing with assembly language, which brings about the smallest file
sizes...which will apply to LuxAsm too because it's coded in assembly
language too :)...and we're only talking plain ASCII text here...a couple
of GBs is sufficient enough to hold most, if not all, of the Library of
Congress in plain ASCII, for Pete's sake!! My longest post ever has never
made 128KB (and, as wolfgang noted, that's enough for two DOS-like
operating systems ;)...also, Linux doesn't eat RAM quite so greedily as
Windows does...and then there's the "swap file" or using temporary files,
for "virtual memory"...the file-based "load, edit, save, load, compile,
save, load, link, save, load, edit, save, load, compile, save, load, link,
save" development paradigm can _STAY_ in 1973, I think (actually, to be
fair, it's more to do with Microsoft, PCs, UNIX, DOS and such than
time...tools with better paradigms and such _did_ exist a long while ago
for other platforms but things "went backwards" and then got "stuck" back
in 1973...Randy's LISA assembler for the Apple ][, for example...not as
"ambitious" as some parts of LuxAsm, maybe, but considering the time and
hardware "gap" involved, that's not really suprising...indeed, really,
things should be better still by now...but we know who's the main name that
screwed up an entire industry from progressing for decades...clue: Starts
with "M" ends with "icrosoft"...but, of course, there is an "escape pod"
now...LuxAsm is a Linux assembler, after all ;)...

As to what Rene was saying about Linux not being viable on desktops and
such...well, that's not altogether wrong...but it's "catch-22", ain't it,
Rene? If no developers support Linux and improve things there (it's "open
source"...it _invites_ help with improvements :) then it'll never reach
that level because no-one's improving it...only one cog in the wheel, of
course, but LuxAsm can make Linux a viable assembly language
platform...because, truth is, it's woefully unsupported at the moment...GAS
is just the GCC "back-end"...NASM works on Linux but then NASM is designed
to work on _anything_...HLA supports Linux and tried to keep Linux support
as equal to its Windows support (that's good)...not that this is bad - not
at all, that's great - but when you compare to MASM, RosAsm, NASM, HLA,
GoAsm, A(3)86, etc. and then it's the other means of "support"...for
instance, MASM32 provides Windows include files, RosAsm has the "equates
file", etc....where's the X support files for NASM? You know what I mean?
This is great stuff - I'm not knocking it - but the comparison to Windows
is poor...and, well, without Linux support, we _can't_ expect much assembly
development on Linux...

It's that "Field of Dreams" thing, isn't it? "Build it and they will
come"...because, logically enough, if you don't build it, then they can't
come because there's nothing to come to, even if they really, really wanted
to come...I signed up to LuxAsm because I always thought Linux had
"potential" but that it's not actually there yet, true enough...and,
simply, unless _SOMEONE_ does it, it'll never happen...

The only way out of a "catch-22" is to close your eyes and just march on
ahead regardless...you know: "there is no support"...right, we're just
going to have to _CREATE_ it, then..."it's not for desktops"...right, we're
just going to have to _MAKE_ it for desktops, then...you know what I mean?
If everyone sits around looking at everyone else to "do it first" then
nothing's going to happen at all..._someone_ has to "do it first" (even if
that will be more work...for example, no assembly header files for X...only
a little "syscall" documentation...so, nothing much to "translate" from or
"re-use"...just got to build it from scratch...when "doing it first" this
is unfortunately the case ;)...

Perhaps ReactOS may have a better chance of "destroying Microsoft"...but
I'm more interested in "competition" than destruction...break the monopoly
but, go on, let Microsoft continue...it's not like they'd stand a chance
against _real_ competition, if it were a fair fight with the crap they
produce...they only way they could succeed would be to "reform" and stop
producing crap...well, that would be a "new" Microsoft...if competiting
fairly, no more "monopoly" then why not give them a shot? It is their
_actions_ I can't abide, not the Microsoft people themselves...they are
ordinary working people (and a supposed "socialist" like you should
_ALWAYS_ stand by any and all "working people" everywhere...that is a
socialist principle: "Internationalism" and "worker's solidarity"...but,
then again, you're the strangest left-winger and anarchist I've ever
met...you seem to abide by neither...which, in an odd way, could be called
"anarchy" - in a "double bluff" kind of way - but it could also be called
"nonsense" too ;)...no reason why they shouldn't be allowed to put bread on
their tables for their families...the problem is _denying_ others the right
to do that too...that's "monopoly"..._THAT_ is the problem...indeed, if you
ain't worked it out, ReactOS isn't really trying to "destroy" Microsoft in
that sense...but trying to _FORCE_ "competition" onto them by "beating them
at their own game" / "using their own weapons against them"...ReactOS will
be, after all, a Windows clone and it will use Microsoft technologies...not
subverting their existence but subverting their "monopoly"...indeed, if you
"broke" Windows then Microsoft would just carry on with X-boxes and mice
and games and applications and "multimedia TV" and what-not...a "wound" but
not a moral one because the other things they do are more than sufficient
to keep them alive...but that's okay because they don't have "monopoly" in
these areas...so long as they don't have "monopoly", we can buy Nintendo
consoles, Logitech mouses and so forth (and they are probably better...the
Microsoft keyboard I bought broke within a week...admittedly, I put
keyboards through a lot of battering but just a week? That's very, very
shoddy workmanship...I have an IBM that's a decade old - no "Windows
keys"...yay! - and tough as old boots...you could put this IBM keyboard on
the outside of the space shuttle and fly into space and come back and it
would probably _STILL_ work...it's ugly and clunky but "robust" is an
understatement...I mean, a decade of the amount of the abuse I place on
keyboards? Not just the typing but I often drop cigarette ash between the
keys or tip Coke all over it...I know, I know...shouldn't be drinking or
smoking over a keyboard but I do it anyway...I've got quite a few keyboards
here, actually, because I tend to wear them out faster than most
people...so I always keep old keyboards from old machines as "spares" ;)...

Beth :)