That's a good one, too. I'm all in favor of eliminating noise, by which I mean parts of the program that are required but not directly related to what you're trying to do.
But on the other hand, I wonder what kind of code I'd want to generate from A + B if I don't know if B is 2 or 2.1. Realistically, I'd need to store at least a value and a type for each variable, and for any variable that may be bound to multiple types, I'd have to allocate storage for every different type of value. That's not a problem in an interpreted language, but it gets interesting when you stsart thinking about how you;d handle compiled code. That being said, it is entirely reasonable to say that these are details the user shouldn't need to know or care about, and that it's a problem for the compiler writer. --- Gary Monger <[EMAIL PROTECTED]> wrote: > No strong typing. > > I think of a variable as a name for something. I am not interested > in the > underlying implementation of that something. MUMPS allows me to > focus on my > algorithm, not how many bytes I need to represent an integer. > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Greg > Woodhouse > Sent: Tuesday, August 16, 2005 4:51 PM > To: [email protected] > Subject: Re: [Hardhats-members] MUMPS features > > Hmm...I hesitate to do this, for fear of forgetting something, but my > MUMPS "greatest hits" list, includes at least > > 1. Global arrays > 2. Hierarchical arrays in general, and especially the ability to > store > values at non-leaf nodes. > 3. An integrated JOB command and the $J special variable > 4. Patterns > 5. The MERGE command > 6. Built in string handling functions > 7. Incremental locks (but see below) > 8. Indirection and the XECUTE command (again with some caveats) > 9. Simplicity > > By contrast, my "biggest gripes" list includes > > 1. Default global scope for variables > 2. No static scoping > 3. No interprocess communication or asynchronous signaling > 4. Weak support for I/O > 5. I'm sorry, but 2 + 3 * 4 is NOT 20 > 6. Unintuitive (and not clearly useful) semantics for reference > parameters > 7. Incremental locks don't block (like semaphores) > 8. No distinction between read and write locks > 9. No support for namespaces or packages > 10. No flexibility with regard to character sets > > > --- Chris Richardson <[EMAIL PROTECTED]> wrote: > > > I don't have much easy association with baseball, but; > > > > 1) the polymorphic Data Representation (for SET X="12 Cats"); > > A) a string, WRITE X > > B) an expression, WRITE X+"15 Dogs" > > C) a Truth Value, IF X WRITE "True" > > D) has properties, WRITE > > %DATA(X)_":"_$LENGTH(X)_":"_$LENGTH(X," ") > > (and a lot more) > > E) has substrings, WRITE $PIECE(X," ",2) > > F) extensible, SET X=X_" and kittens" > > G) malible, FOR I=$LENGTH(X):-1:1 WRITE $EXTRACT(X,I) > > H thru ZZZ) Lots more > > 2) data clustering, for the data created by FOR I=1:1:10 SET > > X($R(100))=I > > A) Evaluated, WRITE $DATA(X) > > B) Walked, SET Y="" FOR S J=$ORDER(X($G(J)) QUIT:J="" WRITE > > X(J)_":"_J,! > > C) Copied, MERGE Z=X > > D) Trimmed, SET J=$ORDER(X("")) KILL:J X(J) > > E) Killed, KILL X > > > > More later. > > > > ----- Original Message ----- > > From: "Gregory Woodhouse" <[EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Tuesday, August 16, 2005 7:09 AM > > Subject: [Hardhats-members] MUMPS features > > > > > > > I've been thinking about the use of strings as a uniform data > > > representation in MUMPS and, to draw an analogy with baseball, it > > is > > > easy to come up with a hit (such as the ability to use the same > > > idioms, e.g., $G(X)="" for different kinds of data), or a double > > > (such as being able to intermix numbers and strings as subscripts > > to > > > the same array), but I can't think of a real home run. Thoughts? > > > > > > === > > > Gregory Woodhouse > > > [EMAIL PROTECTED] > > > > > > "Perfection is achieved, not when there is nothing more to add, > but > > > when there is nothing left to take away." > > > -- Antoine de Saint-Exupery > > > > > > > > > > > > ------------------------------------------------------- > > > SF.Net email is Sponsored by the Better Software Conference & > EXPO > > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > > Practices > > > Agile & Plan-Driven Development * Managing Projects & Teams * > > Testing & QA > > > Security * Process Improvement & Measurement * > > http://www.sqe.com/bsce5sf > > > _______________________________________________ > > > Hardhats-members mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > > > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing > > & QA > > Security * Process Improvement & Measurement * > > http://www.sqe.com/bsce5sf > > _______________________________________________ > > Hardhats-members mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > > === > Gregory Woodhouse <[EMAIL PROTECTED]> > > "Design quality doesn't ensure success, but design failure can ensure > failure." > > --Kent Beck > > > > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > === Gregory Woodhouse <[EMAIL PROTECTED]> "Design quality doesn't ensure success, but design failure can ensure failure." --Kent Beck ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
