RTS graph and "temporal formulas"

RTS graph and "temporal formulas"

[Emanuel Berg]

I have an exam the 30th on RTS and there is one problem I cannot
solve, because there is nothing on this in the material, and the
teacher doesn't answer mails with questions.

I turn to you, not to solve the problem, but to explain what it
means - once there, I hope to solve it myself.

The problem involves a graph.

- there are states: circles with names (e.g., "B") and conditions
  (x <= 10) (sometimes, the states do not have conditions)

- one state has a double circle: is this the initial state?

- there are edges between the states, that are directed: those
  edges are tagged: sometimes with conditions (x < 5), sometimes
  with assignments (x := 0), and sometimes with both (y < 0 and y
  := 0)

- the variables (x and y are "clocks")

What does it all mean?

Check out the graph here:

http://user.it.uu.se/~embe8573/2011.pdf

(Problem 7, the last one.)

They also mention "temporal formulas" to describe properties of
the system, that the graph is a model of. Do you know of a
resource, that describes the syntax and semantics of such
formulas?

Thanks :)

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: RTS graph and "temporal formulas"

[dukeofpurl]

On Wednesday, August 21, 2013 2:04:00 PM UTC-6, Emanuel Berg wrote:

https://duckduckgo.com/?q=temporal%20formulas&d=1

Re: RTS graph and "temporal formulas"

[Emanuel Berg]

dukeofpurl <sidney.reilley.ii@gmail.com> writes:

> https://duckduckgo.com/?q=temporal%20formulas&d=1

Yes... I know how to search.

Do *you* know anything about this way of modelling RTSs?

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: RTS graph and "temporal formulas"

[optikos]

On Wednesday, August 21, 2013 3:04:00 PM UTC-5, Emanuel Berg wrote:
> I have an exam the 30th on RTS and there is one problem I cannot
> solve, because there is nothing on this in the material, and the
> teacher doesn't answer mails with questions.
>
> I turn to you

  You turn to the Ada-language Usenet group for a question about 1950s mathematics-nomenclature?  Oh well.  Instead of "get off my lawn", I will point you in the right direction, which generally leads away from here. :-)

>, not to solve the problem, but to explain what it
> means - once there, I hope to solve it myself.
> 
> The problem involves a graph.

Apparently, your instructor is assuming that you already know Mealy finite-state machines and their canonical notation (as opposed to Moore finite-state machines).  Most of your question is answered by http://en.wikipedia.org/wiki/Mealy_machine (as opposed to http://en.wikipedia.org/wiki/Moore_machine, which utilizes the same stimulus/response notation but on the states=vertexes instead of on the transitions=edges).  I will utilize the initialism FSA (for finite-state automaton) below.

> - there are states: circles with names (e.g., "B") and conditions
>   (x <= 10) (sometimes, the states do not have conditions)


> - one state has a double circle: is this the initial state?

 yes.  If there were a terminal state, it would be solid black, instead of white with a black perimeter.

> - there are edges

  Here you are utilizing graph-theoretic terminology.  Edges are known as transitions in Mealy & Moore FSAs (and depending on context, either transitions or arcs in Petri networks).

> between the states

  Here you revert to Mealy & Moore FSA terminology.  States are known as vertexes or vertices in graph-theoretic terminology.

> , that are directed

  All transitions in Mealy & Moore FSAs are directed.  There is only traversal as "go to" running forward in time, not untraversal as "come from" running backward in time.

> : those
>   edges are tagged: sometimes with conditions (x < 5)

  In Mealy's FSA notation, each edge may be labeled by a stimulus/response. [Note the slash; it is part of the notation.]  The Mealy FSA stays in its current state v until one of the transitions egressing v has a stimulus-constraint that matches an actual stimulus in the FSA's environmental context.  Hence, your "condition" is a stimulus.

> , sometimes
> 
>   with assignments (x := 0)

  And your "assignment" is a response actualized by traversing that transition e, proceeding to the state into e ingresses.

> , and sometimes with both (y < 0 and y
> 
>   := 0)

  Your professor should have his hand smacked for abuse of notation firmly established in the 1950s and still widely utilized in electrical engineering (and deriving from Petri nets in chemical-manufacturing plants in the 1930s).  Your professor's logical comparisons are Mealy's "leftward of the slash" for stimulus.  Your professor's ":=" is Mealy's "rightward of the slash" for response.  Apparently your professor's exposure to FSAs is 2nd hand from C-language source-code in imperative-instruction sequential software, not from seminal references in the 1950s (or the 1930s).

> - the variables (x and y are "clocks")

  Progress of monotonically-increasing measured realtime is merely yet another "sensor" from which the Mealy FSA is hooked up to the contextual environment to receive stimuli (much as your brain acquires stimuli from its five senses as sensors).  [In electrical engineering, often the sensors are merely digital-logic lines.]  Out of the potentially vast avalanche of incoming stimuli from the sensors, only the stimulus-constraints that are actionable (to progress to a different state and/or to evoke a response) at each particular transition egressing from each state (when it is the current state) are overtly stated.  When the multitude of stimulus-constraints are not actionable, that multitude is unmentioned at that transition.  Likewise, out of the multitude of responses not effected by a transition, that multitude is unmentioned at that transition.

> What does it all mean?

  It means either that you are missing a prerequisite for this class or (if this is the course of first exposure to FSAs and their brethren) that your professor has failed to introduce you to Mealy FSAs, Moore FSAs, Petri nets, Viterbi dynamic-programming algorithm, and Markov chains.  (Only the first of these 5 related concepts is utilized in Problem 7, but you should, at your leisure, study the other 4 sometime too.)

> Check out the graph here:
> http://user.it.uu.se/~embe8573/2011.pdf
> (Problem 7, the last one.)

> They also mention "temporal formulas" to describe properties of
> the system, that the graph is a model of. Do you know of a
> resource, that describes the syntax and semantics of such
> formulas?

  Formulae from temporal logic: https://en.wikipedia.org/wiki/Temporal_logic

  a branch of symbolic logic:  https://en.wikipedia.org/wiki/Symbolic_logic

> Thanks :)
> 
> 
> 
> -- 
> 
> Emanuel Berg - programmer (hire me! CV below)
> computer projects: http://user.it.uu.se/~embe8573
> internet activity: http://home.student.uu.se/embe8573

Re: RTS graph and "temporal formulas"

[Emanuel Berg]

optikos@verizon.net writes:

> You turn to the Ada-language Usenet group for a question about
> 1950s mathematics-nomenclature?  Oh well.  Instead of "get off
> my lawn", I will point you in the right direction, which
> generally leads away from here. :-)

The reason I posted here is that we had Ada in the course.

Thanks for the tutorial, very helpful. I will read those pages,
only: the "x := 0" response transition doesn't have a stimuli. The
state it comes from has one, so perhaps that should be used?

But then, the "A" state has a stimuli (x <= 10), and two outgoing
transitions *with* stimuli (x < 5 and x > 11) - how should this be
interpreted?

Last: the clocks - do they start at 0?

Making a transition, that doesn't take any time, does it?

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: RTS graph and "temporal formulas"

[optikos]

On Wednesday, August 21, 2013 5:50:55 PM UTC-5, Emanuel Berg wrote:
> opt...@verizon.net writes:
> 
> > You turn to the Ada-language Usenet group for a question about
> > 1950s mathematics-nomenclature?  Oh well.  Instead of "get off
> > my lawn", I will point you in the right direction, which
> > generally leads away from here. :-)
> 
> The reason I posted here is that we had Ada in the course.

  But your professor utilized C-language's == as the logical comparison in the E->D transition's stimulus-constraint in 7b, not Ada's =.  :-)

> Thanks for the tutorial, very helpful. I will read those pages,
> only: the "x := 0" response transition doesn't have a stimuli.

  Transitions which lack a stimulus are always traversed.  The lack of stimulus is notated overtly as epsilon.  2 or more epsilon transitions egressing from the same state is an ambiguous type of FSA called an NFA.  But when there exists only one epsilon transition as the sole transition egressing from a state, then determinism is effectively preserved.

http://en.wikipedia.org/wiki/Nondeterministic_finite_automaton_with_%CE%B5-moves

> The state it comes from has one, so perhaps that should be used?

  Yes.  Epsilon in this idiomatic usage means always traverse this C->A transition when in state C.

> But then, the "A" state has a stimuli (x <= 10), and two outgoing
> transitions *with* stimuli (x < 5 and x > 11) - how should this be
> interpreted?

  Upon second look, your professor has utilized both Mealy stimulus-constraint nomenclature (with green logical comparisons as stimulus-constraints on the transitions of 7a) and Moore response-triggered nomenclature (with purple logical comparisons as characterizations of execution time of the software which executes upon entering a state).

  Please be very careful with your wording, because sloppy terminology is a major component in your confusion.  The contextual environment has stimuli; the FSA does not.  The FSA has Mealy-nomenclature stimulus-***constraints*** (i.e., green logical comparisons on transitions) against which incoming stimuli from the sensors are matched.  State A does not have a stimulus; state A has a Moore-nomenclature response (i.e., purple logical predicate as a characterization of the execution time of software executed upon entrance to State A).

  Decoder ring that your professor should have provided in the text of Problem 7 or in the class:
   green:  stimulus-constraint (input)
  purple:  [characterization of] response (output)
    blue:  [imperative instruction that implements] response (output)

> Last: the clocks - do they start at 0?

  Yes.  In a well designed FSA, there would be an overt pre-A initial state with epsilon transition whose response is x:=0 initialization-to-zero, analogous to the C->A transition reset-to-zero.

> Making a transition, that doesn't take any time, does it?

  That is where I am supplementing my prior posting (where I was hand-wavingly oblivious to your current situation at hand).  "Taking time" in a state is precisely what the purple logical comparisons are.  The usage of nearly the same nomenclature 1) for characterization of execution time of the software executed upon entry to a state [as output] and 2) for the stimulus-constraint [related to comparisons against input] differed only by color is an especially cryptic and unwise nomenclature that is inferior to the nomenclature of Mealy, Moore, or the modern math utilized in the Wikipedia articles to which I directed you.

Your professor appears to lump the time it takes to make a transition in with the purple execution-time chararterizations of the state into which the transition ingresses.  Conversely, your professor appears to assume that failed attempts to match the sensors' stimuli to each not-traversed transition egressing from the current state takes zero time (which is incorrect, because it does take time, unless the clock ticks relatively huge compared to the overhead of operating the FSA).

> -- 
> Emanuel Berg - programmer (hire me! CV below)
> computer projects: http://user.it.uu.se/~embe8573
> internet activity: http://home.student.uu.se/embe8573

Re: RTS graph and "temporal formulas"

[Emanuel Berg]

optikos@verizon.net writes:

> ... in the Wikipedia articles to which I directed you.

Yes, I will read it.

Only one more thing, for A, the "Moore-nomenclature response" is x
<= 10, but transitions from A are at x < 5 and x > 11. Does this
mean that the x < 5 transition is never made, because until x =
11, there is computation at A? Or does the A condition *hold* when
it is OK to make transitions? Or doesn't the A condition impact
flow, it just tells something about the system at state A?  Or
does computation "fork" so there are numerous processes all around
the graph?

/The Hairdresser

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: RTS graph and "temporal formulas"

[Dan'l Miller]

On Wednesday, August 21, 2013 7:19:19 PM UTC-5, Emanuel Berg wrote:
> I wrote:
>
> Only one more thing, for A, the "Moore-nomenclature response" is x
> <= 10, but transitions from A are at x < 5 and x > 11. Does this
> mean that the x < 5 transition is never made,

  You cross the line of answering the test question for you when you ask whether a transition will be made or not.

> because until x = 11, there is computation at A?

  Upon traversal of a transition that ingress into A (and only upon such traversal), there exists computation that consumes at most 10 clock ticks.  It is ambiguous in your professor's sloppy nomenclature whether that State-A computation is evoked upon start-up of the 7a FSA, such as we discussed above by traversal of an epsilon transition that initializes x to zero.  As stated, I would assume that the initialization of x is magic and that the State-A computation is not evoked upon start-up of the 7a FSA.

> Or does the A condition *hold* when
> it is OK to make transitions?

  Your terminology of "hold" is ambiguous.  If your "hold" means logically hold, then yes, the purple characterizations are absolute truth and always hold without exception:  upon every entry into a state in the 7a FSA that has a purple execution-time characterization, that characterization is never false.  I.e., the software always runs exactly as characterized, when so triggered.

  If your "hold" means pause, then no.  The purple characterizations of execution-time are ***not*** criteria that govern whether the entry-into-state computation executes or not, nor that govern when the entry-into-state computation executes.  Upon entry, that state's computation commences immediately and always executes to completion (as characterized).

> Or doesn't the A condition

  As I have said before, your confusion is because you are sloppy with your terminology.  The purple logical relations are not _a priori_ conditions (i.e., not criteria, not constraints governing a decision).  The purple logical relations are _a posteriori_ reports of how long the entry-into-state computation took to complete.

> impact flow,

  The purple characterizations do not directly affect a decision-making capability within the machinery that operates the FSA.  The purple characterizations may cause factual cascading ramifications (e.g., the passage of time as measured by clock ticks expended by the entry-into-state computation), where those cascading ramifications that are picked us by a sensor (e.g., reading the clock), where those sensor readings in turn affect whether a transition is traversed, as governed by the green stimulus-constraints on (some) transitions.  Impact flow?  Directly, no.  Indirectly, perhaps, and analysis thereof is what your professor is requesting in the exam questions 7.1 and 7.2 and subbullets thereof.

> it just tells something about the system at state A?

  Yes, as I have been saying, the green logical relations are _a posteriori_ reports of how the entry-into-state computation turned out.

> Or does computation "fork" so there are numerous processes all around
> the graph?

  No.  FSAs are DFAs (deterministic nonforkingly, despite the possibility of single epsilon transitions borrowed from NFAs, as we discussed above).  FSAs are not a GLR parser, which does in fact have the exploratoration-of-hypotheticals forking behavior that you (incorrectly for FSAs) devise.

Re: RTS graph and "temporal formulas"

[Emanuel Berg]

"Dan'l Miller" <optikos@verizon.net> writes:

> You cross the line of answering the test question for you when
> you ask whether a transition will be made or not.

Oh, that was by mistake. Actually, I don't think those questions
are difficult at all once you understand the machine.

And, I always make an effort to use correct terminology. If it is
sloppy, it is not because my attitude is sloppy.

Is this correct:

You should always move from one state to another if the stimulus
of a transition holds.

The postconditions of the states does not influence this: they
express what holds for the timers if computation is at that state,
less the system is broke (inconsistent).

Question: if the timer is say 5, and transition is at "timer =
10", does that mean you "pause" (compute) at the current state,
while incrementing the timer? timer = 5, 6, 7, 8, 9, 10 - OK, the
stimulus holds, and the transition is made?

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: RTS graph and "temporal formulas"

[Dan'l Miller]

On Thursday, August 22, 2013 4:04:33 PM UTC-5, Emanuel Berg wrote:
> You should always move from one state to another if the stimulus
> of a transition holds.

  Yes.

> Question: if the timer is say 5, and transition is at "timer =
> 10", does that mean you "pause" (compute)

  Yes, pause, which means "don't compute in this FSA" = "go compute something else that takes less than 5 clock ticks".  If this is a multitasking operating system or emulation thereof, schedule something other than this FSA to execute.

> at the current state, while incrementing the timer?

  Remember that the timer is a sensor of reality.  God increments real-time's timer for you.  The sensor merely reads the progression of God's real-time.  I would reword as "while time naturally passes" during other computations outside of this FSA.

> timer = 5, 6, 7, 8, 9, 10 - OK, the stimulus holds, and the transition is made?

  Yes, then evoking any Mealy response side-effects of traversing that transition, then evoking any Moore response upon entry into the state into which that transition ingresses.

Re: RTS graph and "temporal formulas"

[Emanuel Berg]

"Dan'l Miller" <optikos@verizon.net> writes:

> Yes, then evoking any Mealy response side-effects of traversing
> that transition, then evoking any Moore response upon entry into
> the state into which that transition ingresses.

OK, I got it! :) Thanks a lot.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: RTS graph and "temporal formulas"

[Dan'l Miller]

On Thursday, August 22, 2013 4:35:03 PM UTC-5, Emanuel Berg wrote:
> OK, I got it! :) Thanks a lot.

  Good luck on the exam.  I am glad to have been of help.

Re: RTS graph and "temporal formulas"

[Adam Beneschan]

On Wednesday, August 21, 2013 4:33:23 PM UTC-7, Dan'l Miller wrote:

>   But your professor utilized C-language's == as the logical comparison in the E->D transition's stimulus-constraint in 7b, not Ada's =.  :-)

Yeah, but he also used ":=" for assignment.  I guess he wanted to avoid a simple "=" in every case.  Not a bad idea where it could lead to confusion.

                             -- Adam

Re: RTS graph and "temporal formulas"

[Georg Bauhaus]

On 22.08.13 02:59, Adam Beneschan wrote:
> On Wednesday, August 21, 2013 4:33:23 PM UTC-7, Dan'l Miller wrote:
>
>>    But your professor utilized C-language's == as the logical comparison in the E->D transition's stimulus-constraint in 7b, not Ada's =.  :-)
>
> Yeah, but he also used ":=" for assignment.  I guess he wanted to avoid a simple "=" in every case.  Not a bad idea where it could lead to confusion.
>

Microsoft could stop the confusion by finally including a key with an
assignment symbol on their new keyboards. Its lack is simply an oversight
of years of computer design, maybe a blind spot, and too embarrassing to
be fixed.

Re: RTS graph and "temporal formulas"

[Adam Beneschan]

On Thursday, August 22, 2013 1:51:09 AM UTC-7, Georg Bauhaus wrote:

> Microsoft could stop the confusion by finally including a key with an
> assignment symbol on their new keyboards. Its lack is simply an oversight
> of years of computer design, maybe a blind spot, and too embarrassing to
> be fixed.

Which assignment symbol?  The left arrow (as in APL)?  I could go for that, except that you know everyone would confuse it with the other left arrows already on the keyboard that are used for cursor movement.

                               -- Adam

Re: RTS graph and "temporal formulas"

[Alan Jump]

On Thursday, August 22, 2013 8:42:29 AM UTC-7, Adam Beneschan wrote:
 
> Which assignment symbol?  The left arrow (as in APL)?  I could go for that, except that you know everyone would confuse it with the other left arrows already on the keyboard that are used for cursor movement.

Wow. APL. I haven't seen any APL code in over 30 years.

+1, old school.

- -
73 de N5ILN
Alan

Re: RTS graph and "temporal formulas"

[Georg Bauhaus]

On 22.08.13 17:42, Adam Beneschan wrote:
> On Thursday, August 22, 2013 1:51:09 AM UTC-7, Georg Bauhaus wrote:
>
>> Microsoft could stop the confusion by finally including a key with an
>> assignment symbol on their new keyboards. Its lack is simply an oversight
>> of years of computer design, maybe a blind spot, and too embarrassing to
>> be fixed.
>
> Which assignment symbol?  The left arrow (as in APL)?  I could go for that, except that you know everyone would confuse it with the other left arrows already on the keyboard that are used for cursor movement.

Yes. A left arrow could take the position of the CAPS LOCK key
when the keyboard is switched to programmer mode. Programmers
should not find it confusing, then. They are used to overloading.

Re: RTS graph and "temporal formulas"

[Adam Beneschan]

On Thursday, August 22, 2013 11:34:06 AM UTC-7, Georg Bauhaus wrote:

> Programmers should not find it confusing, then. They are used to overloading.

Well, yeah, but mostly overloading on caffeine and extra work.  :)

But I don't know why you think a CAPS LOCK key could be dispensed with in "programmer mode".  Using all-caps for constant names is a convention in lots of programming languages.

                              -- Adam

Re: RTS graph and "temporal formulas"

[Georg Bauhaus]

On 22.08.13 20:56, Adam Beneschan wrote:
> On Thursday, August 22, 2013 11:34:06 AM UTC-7, Georg Bauhaus wrote:
>
>> Programmers should not find it confusing, then. They are used to overloading.
>
> Well, yeah, but mostly overloading on caffeine and extra work.  :)

+1. (Oh, wait, +1 . No.   +1! Ouch.  ++1 Nah.  +1? Argh!
+1,!!! +1,!!! +1    AHA!)                                   (*)

(Our espresso machine is simple but g- g- good.)

> But I don't know why you think a CAPS LOCK key could be dispensed with in "programmer mode".  Using all-caps for constant names is a convention in lots of programming languages.

We'd have to know whether or not programmers are actually using
CAPS LOCK for (frequently?) typing words in all upper case---I'm
still thinking that many use M-U (Emacs), or ~ (vi), or Ctl-Shift-X
(Eclipse), or Ctl-Shift-U (VS), ... And that's just typing them
for the first time, since language sensitive editing puts the words
in context menus near the cursor, ready for automatic placement.

(Also, Unix workstations' key mappings frequently had bindings
for CAPS LOCK that made the function disappear, IIRC.)

__
(*) printf("%d\n", <exp>);
  

Re: RTS graph and "temporal formulas"

[Robert A Duff]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> Yes. A left arrow could take the position of the CAPS LOCK key

...and then the CAPS LOCK key can be moved to the far side of the moon,
where it belongs.

> when the keyboard is switched to programmer mode. Programmers
> should not find it confusing, then. They are used to overloading.

- Bob

Re: RTS graph and "temporal formulas"

[Shark8]

On Thursday, August 22, 2013 3:11:28 PM UTC-6, Robert A Duff wrote:
> Georg Bauhaus writes:
> > Yes. A left arrow could take the position of the CAPS LOCK key
> 
> ...and then the CAPS LOCK key can be moved to the far side of the moon,
> where it belongs.
> 
> > when the keyboard is switched to programmer mode. Programmers
> > should not find it confusing, then. They are used to overloading.


Come now, there's perfectly good uses for Caps-Lock, like writing section headers in your code:

----------------------------------------
--  CONSTANTS                         --
----------------------------------------

Re: RTS graph and "temporal formulas"

[Robert A Duff]

Shark8 <onewingedshark@gmail.com> writes:

> On Thursday, August 22, 2013 3:11:28 PM UTC-6, Robert A Duff wrote:
>> Georg Bauhaus writes:
>> > Yes. A left arrow could take the position of the CAPS LOCK key
>> 
>> ...and then the CAPS LOCK key can be moved to the far side of the moon,
>> where it belongs.
>> 
>> > when the keyboard is switched to programmer mode. Programmers
>> > should not find it confusing, then. They are used to overloading.
>
> Come now, there's perfectly good uses for Caps-Lock, like writing
> section headers in your code:
>
> ----------------------------------------
> --  CONSTANTS                         --
> ----------------------------------------

To each their own.  ;-)

The only time I EVER press caps-lock is by accident, and it's annoying.
And I didn't use caps-lock to type "I EVER" above.  In fact that key is
disabled on this computer, although I haven't gotten around to doing
that on my new laptop.

If I wanted to type "CONSTANTS", I'd type "constants", and then tell
my editor to convert to upper case.

I am a poor typist.  Probably close to 50% of my keystrokes are
"Backspace".  And too many are accidental caps-lock.  ;-)

- Bob

Re: RTS graph and "temporal formulas"

[Jeffrey Carter]

On 08/23/2013 06:52 AM, Shark8 wrote:
>
> Come now, there's perfectly good uses for Caps-Lock, like writing section headers in your code:
>
> ----------------------------------------
> --  CONSTANTS                         --
> ----------------------------------------

Since otherwise, no one could tell that declarations with the reserved word 
"constant" were constants.

-- 
Jeff Carter
"Clear? Why, a 4-yr-old child could understand this
report. Run out and find me a 4-yr-old child. I can't
make head or tail out of it."
Duck Soup
94

Re: RTS graph and "temporal formulas"

[AdaMagica]

On Friday, August 23, 2013 3:52:19 PM UTC+2, Shark8 wrote:

> Come now, there's perfectly good uses for Caps-Lock, like writing section headers in your code:
> 
> ----------------------------------------
> --  CONSTANTS                         --
> ----------------------------------------

Well, this isn't Pascal, or is it. You normally don't write first types, then constants, then variables.

Re: RTS graph and "temporal formulas"

[Adam Beneschan]

On Sunday, August 25, 2013 3:22:25 AM UTC-7, AdaMagica wrote:
> On Friday, August 23, 2013 3:52:19 PM UTC+2, Shark8 wrote:
> 
> 
> 
> > Come now, there's perfectly good uses for Caps-Lock, like writing section headers in your code:
> 
> > 
> 
> > ----------------------------------------
> 
> > --  CONSTANTS                         --
> 
> > ----------------------------------------
> 
> 
> 
> Well, this isn't Pascal, or is it. You normally don't write first types, then constants, then variables.

I know that there are (or have been) Ada shops with style requirements for things to be grouped together like this, where possible.  If you have an organization where people have to read each other's code, without an IDE or something like that, I can understand why it might be a good idea.

                                 -- Adam

Re: RTS graph and "temporal formulas"

[Stephen Leake]

Adam Beneschan <adambeneschan@aol.com> writes:

> If you
> have an organization where people have to read each other's code,
> without an IDE or something like that, 

Say what?

I would _never_ work for such an organization!

-- 
-- Stephe