NetRexx enhancements -- reply

classic Classic list List threaded Threaded
104 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

Thomas.Schneider.Wien
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:
Yes, the general case of a+=expression is what I meant, where + is any operator.
 
And I still like:  a+expression  (in general:  symbol operation expression) as a shorter way of saying the same thing (does not work in classic or oo Rexx, of course, because a clause that is an expression is a command).
 
Mike
 


From: [hidden email] [[hidden email]] On Behalf Of George Hovey
Sent: 24 September 2010 12:53
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] NetRexx enhancements -- reply

Not a+=expression ?  It's true 'expression = 1' is the commonest case, but the latter is also common and equally inconvenient if 'a' is complicated.

On Fri, Sep 24, 2010 at 6:25 AM, Mike Cowlishaw <[hidden email]> wrote:

> But when I read that [snip] 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

Yes, the a+=1 shorthand is definitely the best candidate of Tom's list.

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]


_______________________________________________ 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)
Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

Thomas.Schneider.Wien
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)
Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

George Hovey-2
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:
If we are going to change these symbols, lets not just plump for some other random symbol.   Using ∧ for exclusive OR would be as crazy as using = for not equals, since ∧ is the mathematical symbol for AND!   

If we change the symbols, lets be consistent and virtuous and use the proper mathematical ones.   They may seem arbitrary to someone who does not know them, but the same could be said of any mathematical symbol; if we went down that route it would be a license to use all sorts of random symbols due only to personal preference, and some one would come up with a different sort of OR and we'd have ||| or &&& or &&| or something terrible.   

If, for consistency with our mathematics mates, we use = for equals, + for addition, then lets also use ∧ for AND, ∨ for OR, and ⊕ for EXCLUSIVE OR.   It turns out that they are just as easy to remember as any other symbol and actually look nicer in expressions I think since they don't get mistaken for anything else.

After all | does not really mean OR any more than any other symbol, and EXCLUSIVE OR is neither OR OR (||) or AND AND (&&).   If we use the proper mathematics symbols, we'll not end up having to invent new compound symbols every time we include a new operation. 

I think some of the confusion stems from the words used, and not using the correct words when talking about the operators.   When we say AND, what we really mean is BOTH.   When we say OR, what we really mean is EITHER, and when we say EXCLUSIVE OR, what we really mean is ONE OF.   When we think of it like this, the temptation to use & for BOTH is less attractive, and using the established mathematical symbols is easier to accept.   In todays world, there is no difficulty in using the correct symbols; they have been provided by fellow human beings so that we can use them, lets not insult these good people by ignoring their efforts while making do with something far less adequate.

If there is not much appetite for NetRexx to evolve, then this is the wrong forum to discuss these things.   If the approach taken by Tebetha (which has no qualms about using the most appropriate symbols, or moving on from what other languages have done) makes sense to anyone, and they want to learn more about Tabetha (which has syntactic elegance for human usability as one of its key aims), I'd be happy to contribute to a separate forum (when I'm not so busy).   Let me know, Connor at JoinedUpBusiness dot com.

Connor.

  
On 24 Sep 2010, at 17:37, Mike Cowlishaw wrote:



   What would be the logical symbol/character for XOR?  
   '⊕' would be
   just as incomprehensible to the average programmer...

Cool!  Where'd you find that glyph, Mike?  The Wiccan 
codepage?  The Double-Byte Vampire Character Set?  ;-))

Google (for example): HTML exclusive or

   [but yes,
   '||' would be what I might have chosen, had that not 
   been widely in
   use for 'concatenate'].

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.

I'm not sure, either (see post of a few minutes ago).  There was precedent for
&&, I'm sure, so I followed that.

Mike


_______________________________________________
Ibm-netrexx mailing list
[hidden email]


_______________________________________________
Ibm-netrexx mailing list
[hidden email]




_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

David Requena
In reply to this post by Mike Cowlishaw

El 24/09/2010 14:51, Mike Cowlishaw escribió:
And I still like:  a+expression  (in general:  symbol operation expression) as a shorter way of saying the same thing (does not work in classic or oo Rexx, of course, because a clause that is an expression is a command).

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]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

David Requena
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ó:
But David ....

El 24/09/2010 15:06, Mike Cowlishaw escribió:
Hey guys, we're talking about a language which incorporates (of all things!!) '&&' as a (i)logical 'XOR' operator.
 
What would be the logical symbol/character for XOR?  '' would be just as incomprehensible to the average programmer...  [but yes, '||' would be what I might have chosen, had that not been widely in use for 'concatenate'].

While I admit that *any* chosen symbol would be completely arbitrary, this particular case is specially unfortunate in my view.

- For any computer illiterate or novice programmer "&&" means "some form of 'AND'". That is because the symbol '&' has a very precise meaning in plain English (which happens to be 'AND'). 
 
Agreed.  But || was already taken by PL/I to mean concatenate, and && was already used in several languages for 'exclusive or'.   I wish I had chosen the PL/I ^ (possibly it wasn't using that then, or the character was not on keyboards, or other languages were using it for the power operator; I forget the reason).
 
- For any experienced programmer coming from C or C++ (and many others) '&&' is "logical AND". 
 
That wasn't an issue when Rexx was designed .. hardly anyone used C in 1979 (K&R was published in late 1978, and the other documents about C that I had seen all seemed very fluid -- in fact I chose the % operator from early C documents -- and then it changed (in C) to mean something different).
 
- For programmers coming from java '&&' is "short-circuiting logical AND". 
 
Quite.  So  NetRexx could add the ^ operator to mean XOR, and phase out &&, leaving it there just for old-timer Rexx folk. 

Given that 2nd and 3rd groups comprise a big chunk of the programmers population today, by choosing '&&' as an XOR operator NetRexx has gotten to alienate most of its actual and potential users. The problem is not alleviated by the fact that a single '&' means indeed "logical AND" in ´NetRexx.

A language may of course choose '=' as an non-equal logical operator (after all some arbitrary symbol needs to be chosen). The thing is that such an election would be very unintuitive for *most* people. 

Almost anything based on C is unintuitive for most people :-)).  That's why I did NetRexx.  However, basing it on Rexx did imply trying to stay as close to Rexx as possible -- including the operators.  But I entirely agree that && for XOR was not a good choice.  || would have been better.    History ...
 
Mike 
_______________________________________________ Ibm-netrexx mailing list [hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

David Requena
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]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

David Requena
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]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

David Requena
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]

Reply | Threaded
Open this post in threaded view
|

RE: NetRexx enhancements -- reply

Mike Cowlishaw
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


From: [hidden email] [mailto:[hidden email]] On Behalf Of David Requena
Sent: 25 September 2010 11:19
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] NetRexx enhancements -- reply


El 24/09/2010 14:51, Mike Cowlishaw escribió:
And I still like:  a+expression  (in general:  symbol operation expression) as a shorter way of saying the same thing (does not work in classic or oo Rexx, of course, because a clause that is an expression is a command).

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]

Reply | Threaded
Open this post in threaded view
|

RE: NetRexx enhancements -- reply

Mike Cowlishaw
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


From: [hidden email] [mailto:[hidden email]] On Behalf Of David Requena
Sent: 25 September 2010 11:46
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] NetRexx enhancements -- reply

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ó:
But David ....

El 24/09/2010 15:06, Mike Cowlishaw escribió:
Hey guys, we're talking about a language which incorporates (of all things!!) '&&' as a (i)logical 'XOR' operator.
 
What would be the logical symbol/character for XOR?  '' would be just as incomprehensible to the average programmer...  [but yes, '||' would be what I might have chosen, had that not been widely in use for 'concatenate'].

While I admit that *any* chosen symbol would be completely arbitrary, this particular case is specially unfortunate in my view.

- For any computer illiterate or novice programmer "&&" means "some form of 'AND'". That is because the symbol '&' has a very precise meaning in plain English (which happens to be 'AND'). 
 
Agreed.  But || was already taken by PL/I to mean concatenate, and && was already used in several languages for 'exclusive or'.   I wish I had chosen the PL/I ^ (possibly it wasn't using that then, or the character was not on keyboards, or other languages were using it for the power operator; I forget the reason).

- For any experienced programmer coming from C or C++ (and many others) '&&' is "logical AND". 
 
That wasn't an issue when Rexx was designed .. hardly anyone used C in 1979 (K&R was published in late 1978, and the other documents about C that I had seen all seemed very fluid -- in fact I chose the % operator from early C documents -- and then it changed (in C) to mean something different).

- For programmers coming from java '&&' is "short-circuiting logical AND". 
 
Quite.  So  NetRexx could add the ^ operator to mean XOR, and phase out &&, leaving it there just for old-timer Rexx folk. 

Given that 2nd and 3rd groups comprise a big chunk of the programmers population today, by choosing '&&' as an XOR operator NetRexx has gotten to alienate most of its actual and potential users. The problem is not alleviated by the fact that a single '&' means indeed "logical AND" in ´NetRexx.

A language may of course choose '=' as an non-equal logical operator (after all some arbitrary symbol needs to be chosen). The thing is that such an election would be very unintuitive for *most* people. 

Almost anything based on C is unintuitive for most people :-)).  That's why I did NetRexx.  However, basing it on Rexx did imply trying to stay as close to Rexx as possible -- including the operators.  But I entirely agree that && for XOR was not a good choice.  || would have been better.    History ...
 
Mike 
_______________________________________________ Ibm-netrexx mailing list [hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

Aviatrexx
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]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

FreeFall
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]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

Fernando Cassia-2
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]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

Fernando Cassia-2
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]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

George Hovey-2
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,

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]



_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

George Hovey-2
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:

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]




_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

Robert L Hamilton
PLEASE DON'T MESS WITH NETREXX OR TEXAS.

Bobh

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

George Hovey-2
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
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]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

George Hovey-2
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:
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ó:
But David ....

El 24/09/2010 15:06, Mike Cowlishaw escribió:
Hey guys, we're talking about a language which incorporates (of all things!!) '&&' as a (i)logical 'XOR' operator.
 
What would be the logical symbol/character for XOR?  '' would be just as incomprehensible to the average programmer...  [but yes, '||' would be what I might have chosen, had that not been widely in use for 'concatenate'].

While I admit that *any* chosen symbol would be completely arbitrary, this particular case is specially unfortunate in my view.

- For any computer illiterate or novice programmer "&&" means "some form of 'AND'". That is because the symbol '&' has a very precise meaning in plain English (which happens to be 'AND'). 
 
Agreed.  But || was already taken by PL/I to mean concatenate, and && was already used in several languages for 'exclusive or'.   I wish I had chosen the PL/I ^ (possibly it wasn't using that then, or the character was not on keyboards, or other languages were using it for the power operator; I forget the reason).
 
- For any experienced programmer coming from C or C++ (and many others) '&&' is "logical AND". 
 
That wasn't an issue when Rexx was designed .. hardly anyone used C in 1979 (K&R was published in late 1978, and the other documents about C that I had seen all seemed very fluid -- in fact I chose the % operator from early C documents -- and then it changed (in C) to mean something different).
 
- For programmers coming from java '&&' is "short-circuiting logical AND". 
 
Quite.  So  NetRexx could add the ^ operator to mean XOR, and phase out &&, leaving it there just for old-timer Rexx folk. 

Given that 2nd and 3rd groups comprise a big chunk of the programmers population today, by choosing '&&' as an XOR operator NetRexx has gotten to alienate most of its actual and potential users. The problem is not alleviated by the fact that a single '&' means indeed "logical AND" in ´NetRexx.

A language may of course choose '=' as an non-equal logical operator (after all some arbitrary symbol needs to be chosen). The thing is that such an election would be very unintuitive for *most* people. 

Almost anything based on C is unintuitive for most people :-)).  That's why I did NetRexx.  However, basing it on Rexx did imply trying to stay as close to Rexx as possible -- including the operators.  But I entirely agree that && for XOR was not a good choice.  || would have been better.    History ...
 
Mike 
_______________________________________________ Ibm-netrexx mailing list

_______________________________________________
Ibm-netrexx mailing list
[hidden email]




_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

Fernando Cassia-2
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]

123456