Hi Mike,
1.) you might be philosophically right 2.) But using your proposal, you will -again- introduce a *new, unknown* notation to the majority of all current *programmers* I do *personally know* Hence please let us stick with *already known and wide-spread notations* as: a+=1 Remember, Mike: For (most probably historical) reasons, you did invent the 'stem' notation x= a.b.c -- for classic Rexx and you DID change that back to the more conventional x=a[b,c] -- for NetRexx Why not using the *common sense* at the first place ? Thomas. =========================================================== Am 24.09.2010 14:51, schrieb Mike Cowlishaw:
--
Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
In reply to this post by christel.u.w.pachl christel.u.w.pachl
... and therefore, to abbrevaite things, the a += b notation might be
helpful ...!!! Mike's suggestion of the even more compact a+1 notation is excellent, but *currenlty NOT common sense* for young programmers .... And as we all would like to spread the knowledge/usage of NetRexx, as a language, we should adhere to *common sense* (a bit), as method abc(a,b,c) returns d does (no ARG or PARSE arg needed/wanted anymore ....) Maybe the next release of ooRexx will even implement this common sense? Thomas Schneider. ============================================================ Am 24.09.2010 11:53, schrieb Walter Pachl: > ---- Connor Birch<[hidden email]> schrieb: > "Anyone who wants to save keystrokes could write a macro for their editor to turn their shorthand into the full statement." > > But when I read that bloody source I still have to see > this_is_the_name_of_a_very_important_variable=this_is_the_name_of_a_very_important_variable+1 > > and the have to change two tokensif there is a need to do so > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > -- Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
In reply to this post by FreeFall
It seems to me that we must limit NetRexx's character set (for all elements except identifiers and strings)
to ASCII which is a subset of at least CP1252, ISO-8859-1 and UTF8 encodings. Using other
characters, no matter how attractive, will get us into deep trouble with
respect to keyboard entry. Note that Java keywords limit themselves to
ASCII although identifiers may use Unicode characters. http://download.oracle.com/javase/1.3/docs/guide/intl/encoding.doc.html has some food for thought.
I support evolution for sound reasons, but not revolution. NetRexx isn't mostly wrong, it's hugely right. Your language Tabetha sounds very interesting, and I'd like to know more -- if only it had a spec! [MFC wrote his before the language. :-)] On Fri, Sep 24, 2010 at 2:14 PM, Connor Birch <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by Mike Cowlishaw
El 24/09/2010 14:51, Mike Cowlishaw escribió:
This particular one I don't like very much as 'a+1' is currently an expression yielding a result leaving 'a' unmodified. Would that new behaviour be only applied when that expression were to be found itself alone in a clause? What about b=a+1? Would that also increment 'a'? And how about 'a=1;a=a+1'? Would 'a' be assigned the value '2' or '3'? (OK, '2', but that is not evident at first sight) Admittedly those questions might be answered (for example if first question answer was 'yes'). But frankly it seems to me that such a syntax (having the very same expression resulting on different behaviour depending on context) would make the 'astonishing factor' to sky-rocket just to save *ONE* keystroke over 'a += 1' --- Saludos / Kind regards. David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by Mike Cowlishaw
Mike,
In general all my my remarks in this list have not been in any way criticisms about the language itself or your long time away taken design decisions. I may keep proposing enhancements but that is because the world kept revolving while NetRexx remained frozen in time (e.g. NetRexx is not fully compatible with the java library any more). That seems to be the wall we all are stumbling time and again. I'm not even complaining about '&&' which I went on using after a mild surprise when I saw it first time. My original point was that I don't see the '+=' operators family as such evil complexity risers given that we have things as && --> XOR no one seems to have an issue with. In general, I favour '+=' adoption as I try to always choose got variable names. Which in turn implies these get rather longish and that I often change variable names. Which in turn calls for 'search and replace'. 'search and replace' *IS TRUE EVIL* if you don't learn the particular regex flavour supported by your editor. Any regex flavour is abstruse by definition Under this light, any syntax which helps reducing the number of instances I need to change is welcome. --- Saludos / Kind regards. David Requena El 24/09/2010 18:34, Mike Cowlishaw escribió:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by billfen
Also on the 'a,b,c=int 5' thing it is not evident if you're defining 3 int variables with one initialiced to 5 or initialicing all of them to 5.
Different languages supporting this syntax choose either one of these meanings. What tends to be common among those languages is their discouraging of this particular idiom usage. - Saludos / Kind regards, David Requena -----Original Message----- From: "[hidden email]" <[hidden email]> Sender: [hidden email] Date: Fri, 24 Sep 2010 13:05:52 To: <[hidden email]> Reply-To: [hidden email], IBM Netrexx <[hidden email]> Subject: Re: [Ibm-netrexx] NetRexx enhancements -- reply I use the += and related operators, and think if anything is added, that should be the first candidate. I'm opposed to "a,b,c = x" although it is occasionally useful. Partially because it opens the door to: "Why didn't you do it like the other languages: "a=b=c=x" etc. I just don't think it is needed in a beautifully simple language like Rexx. Of course (IMHO) the ++ and -- operators are a couple of very bad features of C (along with the gratuitous break statements which have cost zillions of programming hours). It's such a shame that people let bad ideas become normal, and then expect them! Tinkering with a well designed language is a very slippery slope, and when different implementations support different syntax or capabilities there are always problems. Language evolution is fine, but it has to be carefully controlled. I think one of the strengths of Java is that Sun kept M$ from tinkering with it. There is an ANSI standard for Rexx and a single language definition for NetRexx, and it probably ought to stay that way. As for "NetRexx 3", maybe there should be community agreement well before anything is implemented? Mike owns the NetRexx name (philosophically if not legally), and it shouldn't be called NetRexx without his blessing. Of course everyone is free to invent their own language with any other name they choose :) I'm no fan of macro languages and preprocessors. Although they are occasionally useful, I think they tend to greatly muddy the water. The C preprocessor is a mess, and the PL/I preprocesssor doesn't have much to do with PL/I - it just sort of looks like it. That being said and from a language design standpoint, I've sometimes thought that a single token equivalence statement at the language level might not be a bad thing, at least in some cases. The "means" statement might help to get around keyboard and other clarity issues. It would be a restricted form of typical token substitution preprocessing, but limited to single tokens only. Over used though, it could really be a mess as well. For example, a BNF like equivalence token ("::=") or something more simple which is not a word could be used to specify the "means" statement. Then the statement "this ::= that" provides single token equivalence within a scope. A sequence of "means ::= ::= ; XOR means && ; " etc. allows some increased capability for clarity if used carefully. Obviously this has been done with various preprocessors, but I'm talking about token equivalence, not substitution. I think there is a bit of a difference between "this means that" and "#define this that", although in practice they are pretty much the same. The problem with something like this is knowing when to stop. It is much too easy to extend single token equivalence into "one for many" as in "flop means call that thing ; (i.e. #define flop call that thing )" etc. "because it is easy to do, it's just one string for another". Then comes "many to many" as in "do it means something else", and worse, the whole idea of "since we are substituting, why not add some parens, use $ for arguments, and maybe a conditional operator, etc. etc.". A very slippery slope indeed. Maybe not for NetRexx like languages though, since in effect it gives tokens specific meaning, and that is a bit counter to the idea that a word takes its meaning from the dynamic execution environment rather than from a fixed definition (i.e. reserved keyword) or a static definition (such as the "means" statement). And I definitely wouldn't like "++ means += 1" :-) Bill -------------------------------------------------------------------- mail2web.com - Microsoft® Exchange solutions from a leading provider - http://link.mail2web.com/Business/Exchange _______________________________________________ Ibm-netrexx mailing list [hidden email] _______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by FreeFall
Connor,
While not willing to debate on the underlying argument, if you're email shows something is that your proposed symbols are not universally supported on all systems. I'm not able to see them on my BlackBerry (which has a reasonable support for Unicode), much less enter them. I happen to program in NetRexx in some narrow charset environments like EPOC R5 with java 1.1.4. As Mike pointed out, the current mess of operator symbols is the result of universally available ones, not of personal preference. The pragmatic inside me will never support language features requiring specialised tools; be it special symbols, non-syntax-neutral indentation, or whatever. Anyone willing to suggest anything akin to C's trigraphs, please DO NOT!! PS: Do you've any online resources for Tabeta I could check? - Saludos / Kind regards, David Requena -----Original Message----- From: Connor Birch <[hidden email]> Sender: [hidden email] Date: Fri, 24 Sep 2010 19:14:30 To: IBM Netrexx<[hidden email]> Reply-To: IBM Netrexx <[hidden email]> Subject: Re: [Ibm-netrexx] NetRexx enhancements -- reply _______________________________________________ Ibm-netrexx mailing list [hidden email] _______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by Aviatrexx
Chip,
Such is the nature of written internet communication. Some times you (me!) introduce some small side argument to support tour reasoning but then... your main point gets lost and whole new discussion spins off. - Saludos / Kind regards, David Requena -----Original Message----- From: Chip Davis <[hidden email]> Sender: [hidden email] Date: Fri, 24 Sep 2010 19:54:37 To: IBM Netrexx<[hidden email]> Reply-To: IBM Netrexx <[hidden email]> Subject: Re: [Ibm-netrexx] NetRexx enhancements -- reply Frankly, if second-guessing Mike about his choice of glyph for an relatively obscure operator is the best we can do, I'd say there are better uses for our time. He was working with a 3270 keyboard and an expected initial programmer base familiar with EXEC2 and PL/I. And I suspect that when he started the design, he had no idea it was going to be publicly available in the first place. NetRexx inherited those choices honestly. Before long, we'll have voice-dictated programs and the whole keyboard/glyph problem evaporates. That will spawn a movement to make programming terms more euphonic (we can say "substring" now!). With the development of RMM technology, we'll find out how faulty our cognitive processes are, and people will wax nostalgic for the good old days of striking a specific key to get a specific character. As for adding syntactic sugar to NetRexx, I find it hard on my programming pancreas. There is an elegance in the conceptual simplicity of the Rexx design that such accretions mar. Sort of like putting spinner hubcaps on a Roll-Royce, imho. I wish I could look back at when I was his age and say that a sub-optimal choice for a mathematical symbol was one of my most enduring regrets... :-/ -Chip- _______________________________________________ Ibm-netrexx mailing list [hidden email] _______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by David Requena
Yes, this isn't an option now -- I was just saying it *was* a
nice idea.
And none of this is about 'saving keystrokes'.
What the A+=expression saves is the duplication of
the name, which is a source of errors when names are changed (forgetting to
change one or other of them). The same saving as not repeating
'BigDecimal' in:
foo=BigDecimal(5)
rather than:
BigDecimal foo=new BigDecimal(5);
[of course there is other unnecessary syntax that NetRexx
avoids, there. :-)]
Mike
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by David Requena
Sounds like everyone likes the += enhancement.
Looking forward to seeing it in NetRexx 3! When are you guys actually
going to ship that?
Mike
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by Thomas.Schneider.Wien
On 9/24/10 21:18 Thomas Schneider said:
> Hi Mike, > 1.) you might be philosophically right Which, IMNSHO, is much more important than C-ifying a language that was designed for humans. > 2.) But using your proposal, you will -again- introduce a *new, unknown* > notation to the majority of all current *programmers* I do *personally know* That depends on your cohort, doesn't it? Even so, does the world really need Yet Another C/C++ variant? If one wants to use a language with a philosophic emphasis on cryptic, terse, inconsistent expression, why not simply use Java in the first place? Or perl, or Python, or ... (ad infinitum, it seems). > Hence please let us stick with *already known and wide-spread notations* > as: > > a+=1 Why not stick with a=a+1? If, as has been asserted, "search and replace are evil" (with requisite apologies to Dijkstra) why not have a token that means "whatever is on the left of the '='"? Something like: aVeryLongAndComplicatedVariableName=~+1 > Remember, Mike: > > For (most probably historical) reasons, you did invent the 'stem' notation > > x= a.b.c -- for classic Rexx > > and you DID change that back to the more conventional > > x=a[b,c] -- for NetRexx because, as he just explained, the square brackets were not commonly available on the 3270 keyboard. The dotted stem notation was a reasonable accommodation to that, and reverting to the now more common usage made sense. Besides, a stem and an array are not the same thing in the first place. > Why not using the *common sense* at the first place ? I would assert that the design of Rexx and NetRexx are some of the best examples of common sense language design extant. "Common sense" being defined as "making sense to the common person" as opposed to "making sense to an already indoctrinated computer geek" (of which I am one). There are myriad programming languages that cater to the geek; how many could you teach to your mother-in-law? -Chip- _______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by George Hovey-2
On 25 Sep 2010, at 01:43, George Hovey wrote: It seems to me that we must limit NetRexx's character set (for all elements except identifiers and strings) to ASCII which is a subset of at least CP1252, ISO-8859-1 and UTF8 encodings. Using other characters, no matter how attractive, will get us into deep trouble with respect to keyboard entry Any 'problem' with entering the characters is more imagined that real. For at least a decade, people wanting to enter accents for roman letters have been able to use 'Dead Keys'. They press a Dead key that represents the family of accents (nothing appears to happen) then they press the roman letter, and the accented character appears. We could easily use a dead key (implemented in software), or even use an ALT key to allow programming symbols to be typed (A produces the AND symbol etc, very easy to remember). And there is an alternative to using the keyboard, in the same way as we add special symbols to a Word document for example, or into an email like this ↵ Can't see a problem at all, they are there for us to use. As an analogy, if we have all the correct sizes of screwdriver provided for us in our toolbox, who would choose not to use some of them? Kind regards, Connor. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by Aviatrexx
2010/9/24 Chip Davis <[hidden email]>:
> I always wondered why the compound operator '/|' wasn't chosen. > Visually it says "not-or" which isn't too big a conceptual leap to > 'exclusive-or' for most people. > > -Chip- +1 I vote for this... makes complete sense. FC _______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by FreeFall
On Sat, Sep 25, 2010 at 11:11 AM, Connor Birch
<[hidden email]> wrote: > Can't see a problem at all, they are there for us to use. I don´t want having to use a dead key to produce some strange character that a programming language might need. It´s a pain in the ... back end. Have you heard of the phrase "KISS - Keep it simple... Stup^B^B^B eriously!" ? > As an analogy, if we have all the correct sizes of screwdriver provided for > us in our toolbox, who would choose not to use some of them? What you are advocating here is not using one screwdriver from the standard set. That would be using the keys on the keyboard. What you are advocating here is using a new, strange screw. That would be akin to "security screws", that are likewise a pain in the ass. http://www.brycefastener.com/keyrexfeatures.jpg (Sorry, I said "ass", I ran out of metaphors). In short: Speaking of screws, I think you´re trying to get us screwed. :-P ;-)) FC PS: I have enough with the Latin American Spanish keyboard layout hiding the | and backslash \ characters in absurd "dead key" combinations, whereas on a US standard layout (that I used for decades) those characters are a simple keypress. _______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by David Requena
David,
To repeat a point I made to Connor: "It seems to me that we must limit NetRexx's character set (for all elements except identifiers and strings) to ASCII which is a subset of at least CP1252, ISO-8859-1 and UTF8 encodings. Using other characters, no matter how attractive, will get us into deep trouble with respect to keyboard entry. Note that Java keywords limit themselves to ASCII although identifiers may use Unicode characters. http://download.oracle.com/javase/1.3/docs/guide/intl/encoding.doc.html has some food for thought." On Sat, Sep 25, 2010 at 7:40 AM, David Requena <[hidden email]> wrote: Connor, _______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by FreeFall
But we don't have the correct tools in our toolbox. Your ideas on entering special characters strike me as horrific.
On Sat, Sep 25, 2010 at 10:11 AM, Connor Birch <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
PLEASE DON'T MESS WITH NETREXX OR TEXAS.
Bobh _______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by billfen
Bill,
I found you views on "tinkering" etc well judged. Just one comment. You remark 'As for "NetRexx 3", maybe there should be community agreement well before anything is implemented?' But it isn't exactly clear who the community is. RexxLA's homepage seems to suggest that they will become the proprietors of the NetRexx brand. How their development process works is a mystery since the bylaws section of their site seems to be permanently "under construction"; and it isn't clear that outsiders have any voice whatsoever. I find aspects of their operation disquieting. I see no sign of any interest in NetRexx at their site, except for the now famous notice of open sourcing. They have, as far as I can see, developed no libraries usable with NetRexx. Although this is currently the official NetRexx forum, I see little evidence of participation by RexxLA members other than Rene Jansen and Chip Davis (are there others?). This begs the questin "does RexxLA have the interest and expertise to develop NetRexx"? If/when the open sourcing takes place, this raucous but open forum could disappear in a blink. Should there be some plan for keeping it alive? On Fri, Sep 24, 2010 at 1:05 PM, [hidden email] <[hidden email]> wrote: I use the += and related operators, and think if anything is added, that _______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by David Requena
David,
Would you mind elaborating on your remark "NetRexx is not fully compatible with the java library any more"? On Sat, Sep 25, 2010 at 6:45 AM, David Requena <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by George Hovey-2
On Sat, Sep 25, 2010 at 1:26 PM, George Hovey <[hidden email]> wrote:
> But we don't have the correct tools in our toolbox. Your ideas on entering > special characters strike me as horrific. +1 indeed. In fact, I´ll vote twice against horror. +1+1 FC _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Free forum by Nabble | Edit this page |