🚀 go-pugleaf

ENGR@GSSI.MV.COM (Michael Furman) writes:
	...
>  1. Memory (default): regular C/C++ variable that will be mapped to some 
>memory.
>  2. Emitter: in this case you must specify access function to call when 
>somebody
>     will read value of this "variable".
>  3. Collector: in this case you must specify access function to call when 
>     somebody will write value of this "variable".
	...
>I think it does not break any existent code (but needs two or even three 
>extra reserved words).

>Any comments?

Sather simplifies this sort of approach, in its "syntactic sugar
expression" syntax production, by mapping syntactic sugar to fixed
names.  For example, "a[row,col] := b;" always maps to "a.aset(row,col,b)",
just as "a/b" always maps to "a.div(b)", etc.  In particular, in Sather,
"a:=b" maps to "a(b)", and a plain identifier "b" maps to "b()".

A mapping to fixed names seem to me to be a superior approach to the
extra complications of a user-definable mapping, for something
ultimately as minor as syntactic sugar.  Note that the fixed names are
not reserved words -- they're plain old identifiers of methods that the
class author will have to declare and define normally, they are subject
to normal overload resolution, etc etc.  If the user would like
"a=b" to actually call "a.set(b.get())", while the fixed mapping
would give "a(b())", nothing stops him or her from coding two simple
inline forwarding functions in the appropriate classes:
	(in a's class) bar operator()(foo X) {return set(X);}
	(in b's class) foo operator()() {return get();}

You could implement this as an upwards-compatible extension to C++ (no
chance that it will make it into the standard -- but nothing stops you
from taking GNU C++ and hacking this extension into it, just as it
already has several extensions to both ANSI C, and proposed-ANSI
C++...  if you make it popular enough, it will have a chance to get in
by the time the _next_ round of the standardization process rolls in,
early next century).  To avoid breaking any existing code, just have
the sugar-mapping extension kick in only when, without it, the code
would be ill-formed by present C++ language rules -- in particular, you
will have to decide whether this is worth breaking the
visibility-vs-access rule of C++ -- I suggest you don't, but rather
treat it as one more candidate for function-call overloading (with
priority lower than existing forms, so as to make sure existing correct
programs stay the same).


Could we move this discussion to comp.LANG.c++...?  It really has
little or nothing to do with the language _standard_, per se...


Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it                            Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: +39 (51) 597120

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]