It is currently Tue Jun 06, 2023 7:22 pm

All times are UTC - 8 hours [ DST ]

Post new topic Reply to topic  [ 2 posts ] 
Author Message
 Post subject: commands IF ELSE FOR DO
PostPosted: Tue Feb 25, 2014 8:42 pm 

Joined: Thu Feb 20, 2014 6:00 am
Posts: 12
Real Name: Michael Sharymov
Began Programming in MUMPS: 0- 0-1984
MUMPS language logically precise and well thought out. But part of the teams in it are not subject to the general rule.
The string contains one or more commands.
Teams do not comply with this rule:
IF, ELSE, FOR, DO without an argument.
This comes from the fact that by nature are block command. If we assume they start unit command and enter additional command END final block, then you can exclude specific behavior of these commands.

Offline Profile  
 Post subject: Re: commands IF ELSE FOR DO
PostPosted: Sat Mar 29, 2014 3:31 pm 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
The list of potentially argumentless commands includes: BREAK, DO, ELSE, FOR, HALT, IF, KILL, LOCK, NEW, QUIT, TCOMMIT, TRESTART, TROLLBACK, TSTART, and VIEW - that is, 15 of 27 commands, or 56% of the MUMPS commands. This means we can't treat the argumentless condition as any kind of exception, so the rule for MUMPS commands must be that they possess zero or more arguments.

This all dates back to MUMPS's origins as a language capable of being described as a finite-state machine, as evidenced by the state-transition diagrams included in MUMPS 1977 and MUMPS 1984. Following that model, it was important to MUMPS's designers that commands be atomic, which would tend to give preference to argumentless commands, say, over compound statements (which might include an END term) as a syntactic solution to semantic problems.

MUMPS's current state is more complex than that; indeed, the MDC had to drop the state-transition diagrams starting with the 1990 standard, because the system's semantics no longer lent themselves so readily to representation as state transitions. One of the topics I'd like to explore this year is whether we can prove that the state-transition diagrams could not be resurrected and updated, to clarify MUMPS's current formal semantic status. If the state-transition model truly can no longer elegantly describe MUMPS, then I'd like to pin down what semantic model can do so now. The ad hoc mathematical descriptions of MUMPS's semantics are adequate but not elegant, and a language (and its standard) should be elegant.

There have been interesting debates within the MUMPS community - including within the MDC - about creating a second-generation syntax for MUMPS, while preserving its underlying semantics. In the late 1990s, the MUMPS Development Coordinating Committee of Europe (MDCC-E) brought forward a proposal called "Taking M Beyond the Year 2000" that aimed to do just that, to modernize MUMPS's syntax while also making it easier to avoid errors. Such an overhaul would have to be outside the scope of the modest, practical goals we have for MUMPS 2015, but would make for a very interesting discussion after October of this year. What you are proposing seems to fit with the spirit of that MDCC-E proposal. We'll scan it in and post it here this year to reopen that discussion, which I hope you'll be interested in.

Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus

Offline Profile  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 posts ] 

All times are UTC - 8 hours [ DST ]

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created