Re: [ Attn: Randy ] Ad-hoc Parsing?
From: C (blackmarlin_at_asean-mail.com)
Date: 12/11/04
- Next message: Bob McConnell: "Re: Is Microsoft anti-GPL ?"
- Previous message: Randall Hyde: "Verbs for Adventure Game Engine"
- In reply to: Betov: "Re: [ Attn: Randy ] Ad-hoc Parsing?"
- Next in thread: Betov: "Re: [ Attn: Randy ] Ad-hoc Parsing?"
- Reply: Betov: "Re: [ Attn: Randy ] Ad-hoc Parsing?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 11 Dec 2004 13:42:41 -0800
Betov wrote:
> "C" <blackmarlin@asean-mail.com> écrivait
news:1102788666.667037.262110
> @f14g2000cwb.googlegroups.com:
> > No, ':' is defined to mean 'a defininition' of something,
> > this something could be either a label, a macro, an equate.
>
> In other words... a _Symbol_.
>
> Admitting this, what would be:
>
> Agaga
> {
> ;...
> }
>
> "Syntax error" on "Agaga"?
Yes, unless 'Agaga' is defined as a macro elsewhere.
> It seems to me a flat evidence, that, if a char is
> meaning "anything", it is meaning "nothing". So,
> here, you are doing the same thing as with wasting
> the so precious "[]" for nope: Wasting the so precious
> ":" for nope.
No, you need the ":" to differentiate a define and
an access to an enclosing block. Such apparent
redundancy is necessary to implement a context-free
grammer, which is very useful for an incremental
assembler.
> >> A Label, in Assembly, must be the Symbol of a
> >> Physical "Location:". A Macro cannot have any.
> >
> > Yes.
>
> ? Does your "yes" mean "_Yes_, a Macro can have
> a Location:"... ?
No, I advise you do not phrase your questions in the
negitive if you are prone to this confusion. To
reiterate, I agree with you: macros (or equates) do
not have a corresponding address in the output file,
unlike labels.
[snip]
> >> Unifying may make some sense, but unifying for
> >> nothing but the intellectual pleasure of Monotheism
> >> is absurd.
> >
> > We're not taking a religious view of Luxasm :-)
>
> _Yes_, you are. The "unified" thingie is a typical
> childish attitude, that wants to simplify a world
> too complex to be understood and masterize. So,
> a Mono-God is a good alternative to study.
?
'Explaining' things by postulating the existance of a
God or Gods actually increases the complexity to be
understood, not to mention failing to solve the problem
of how that/those God(s) came to be in the first place.
Especially as _any_ argument of how that/those God(s)
came into existance can be applied to how the universe
itself came into existance, thus creating a simpler
explaination. (Applying Occam's Razor would then
imply that explaintion to be the one we should use.)
We are actually trying to avoid such unnecessary
complexity, therefore we are attepting to both
eliminate all unnecessary redundancy and maintain a
consistant syntax. Beth's 'unified' idea merges a
number of concepts which are not normally thought as
connected, indeed it when a little further than I would
like, ie. I recommended a different syntax for equates
than was initialilly proposed.
> What an individual think about how an ideal programming
> Tool should be counts for nope, if we consider the
> real facts. This is one reason why the HLLs exist.
I'm not sure what your point is here.
> >> This is exactely a part of what we should call
> >> "The HLL Tempation": "My dreams first, the reality last".
> >
> > Yes, though I would refuse _any_ syntax which prevented
> > me from using Luxasm as an assembler. But this syntax
> > does not, it only reengineers how the labeling system
> > works. Therefore, in my book, it is acceptable.
>
> I don't yet know enough about the final LuxAsm
> Syntax for making any opinion.
Well in summary, the main syntax is like NASM with
the labels and directives reengineered.
> Just, what i see here, in matter of discussion makes me
> think that 1) you do not know where you are going to,
We have had a bit of a change in direction, that is true.
> 2) you have not define the minimum ethic requirements
I fail to see how ethics applied to a tool, though I can
see how ethics would apply to use of a tool. As we are
not forcing anyone to use Luxasm, by in large ethics do
not apply.
> 3) there does not seem to be any real leader in your
> group, applying the absolutely required _dictatorship_,
> for implementing _his_ views.
We're all somewhat anarchists, I for one cannot abide
either following or leading. I do not command nor obey,
instead I prefer to reach decisions by logic and
concensus. This may take longer and risk a commitee
like standard, but I believe that there are sufficiently
few members of the main Luxasm group and we each have
somewhat similar aims, so we are likely to end up with
something workable and hopefully nice looking.
Having said this, it may be a good idea to state the
objectives for the language design more clearly, as they
are currently rather fuzzy at the mement.
> At this last point of view, such a project can go
> nowhere but to hell, with the usual "democratic"
> attitudes. There must be some leader who says
> where are the limits of the discussion, what things
> can be done and what things can not be done.
Some anarchist you are! :-)
> Of course, this has the inconvenient that, usually,
> the Assemblers Project are "one man's Project"s.
Well, I could implement Luxasm myself, but I'd prefer
to end up with a tool others would like, this would
be more useful in the long run.
> But once the things have grown to some extend, the
> volonteers have the advantage of engaging on defined
> road map, with some consistency and some logic of
> the overall Project, that is guaranted. This can
> not be achieved since day one by the democratic
> ways.
Yes, democratic decision making does seem to result
in 'lowest common denominator' decisions. Hopefully
this can be avoided. So far we have been lucky in
that we have people who will discuss a point (even
when we don't agree) instead of just insulting anyone
who may express a differing viewpoint.
C
2004-12-11
- Next message: Bob McConnell: "Re: Is Microsoft anti-GPL ?"
- Previous message: Randall Hyde: "Verbs for Adventure Game Engine"
- In reply to: Betov: "Re: [ Attn: Randy ] Ad-hoc Parsing?"
- Next in thread: Betov: "Re: [ Attn: Randy ] Ad-hoc Parsing?"
- Reply: Betov: "Re: [ Attn: Randy ] Ad-hoc Parsing?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
