[REBOL] A FORMAL REBOL SPECIFICATION Re:
From: bobr:dprc at: 1-Oct-2000 15:39
I would prefer to see a specification of
what is available now and also make sure it clearly
covers what is in /core first.
It is fine if the elements are hyperlinked
(IE the document does not have to be linear - we are after all
citizens of the web ;)
Publishing it to this list is ok
but putting it out as a true website that others can
reference is better.
It is also fine (AFIK) for the document to be in nearly constant flux
and never quite complete. So long as people can use it as a reference
for -WHAT IS-. Lets leave forward looking statements to carl and dan.
where to start?
here is a shopping list, some of it is more
guidelines for what to pick from:
- anything already available via 'help *
is either copyright or a duplication of effort.
- at the end of the formal specification for the language elements
one should be able to write a parser
(resist, if you can, writing it in rebol for as long as you can)
which can at least tell the difference between a
syntactically well formed script and a badly formed one.
This will be based on a set of start-conditions since, with dialecting,
you can define a whole new environment for performing a parse.
- you will eventually [need to] settle on a terminology set to
describe things. Draw from standard sources when you can
(such as RFCs) and as a second use other on-web references.
If you like I will explain why but I bet you can figure it out.
- There will be multiple perspectives and meta perspectives where
terms in one family can be matched up with terms from another.
Things like "structure" and "field" vs "block" and "/word".
In some cases RT will have coined a term that is more precise
but less well known. Decide what your audience will be
and stick with that target. Trying to explain terms using both
families is analogous to translating a Russian dictionary
to French and Japanese in the same document.
It is very distracting to see the juxtaposition
of terms from separate term-families.
Consider that the document instead could have "modes" or "lingua"
which will use terms all from the same family.
Let others who are good at language translation provide the content
for those other modes.
- A formal specification usually starts with a few lowest level or
foundation terms, ones that a parser would be most immediately checking for
... like comments in code vs code in comments.
"not a ; half comment" ; but this is a comment "and this is not unclosed
- You are not out to make another users guide. How to use something
is not a goal of a formal specification.
- After syntax is done, you can go on to semantics or the coupling
and logistics of putting one thing before/after another and what
behavior will be implied by the result. Fair warning: describing all
possible behaviors is a infinite task. The only behaviors that
must be covered are ones which as a result of their execution, modify
future syntax [and semantics].
At 07:24 AM 9/30/00 +1200, [Al--Bri--xtra--co--nz] wrote:
>Mark Dickson wrote:
> > For my own interests I require to write a formal specification for REBOL
>as a language & technology.
>
>Will this be a description of the way Rebol is now? Or will be more
>descriptive of what Rebol will be, once bugs are fixed?
> I'm in favour of the latter.
>
>Andrew Martin
>ICQ: 26227169
>http://members.nbci.com/AndrewMartin/
>http://members.xoom.com/AndrewMartin/
>-><-
;# mailto: [bobr--dprc--net]
