By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,290 Members | 1,363 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,290 IT Pros & Developers. It's quick & easy.

Named argument view for IDE and more

P: n/a
I've seen lots of discussions on the proposed inclusion of "function
call with named arguments" to C/C++ on these newsgroups. My proposal
is slightly different in that:

* No ANSI approval is needed
* No conflicts with existing language features such as function
overloading
* No need to modify the language spec or the compiler
* No need to modify your source code

As you may have guessed, I think it possible to make this a feature of
the IDE.

A first thought was to keep the argument order as specified by the
function declaration, but allow the editing and viewing of function
arguments in a named manner. That is to say, the argument list is
displayed as a closeable table immediately after every function call.
The table include argument names and fields where you can view or fill
the value or expression for each argument. But the tables are just
visual effects of the code editor window, and the source code is
stored in the original format in memory and on disk.

If you also want customized argument order, the order information can
be saved by the IDE as special comments in the source file, or as a
seperate non-source file included by your project file.

Another idea of mine is also about programming language design,
although a bit theoretical. It's about a freer syntax. The idea comes
from my research on controlled language design and translation (the
BabelCode methodology); controlled natural languages and programming
languages have something in common that is they're both formal
languages. We know modern programming language design is evolving
toward a goal of "programming like speaking a natural language"; OOP
has unleashed the most of the semantic potential of programming
languages, but the syntactic freedom still has room to improve.

A typical C function call (enhanced by the "named argument" feature)
is like this:

myfunc(arg1 value1, arg2 value2, ...);

Compared to English syntax, myfunc is like the main verb of a
sentence, and argvalues are the subject, the objects (dierct and
indirect, argument name omitted unless in passive voice),
prepositional phrases (argument names are the preposition, values are
the prepositional objects), adverbials (presence of argument name is a
flag delivering a boolean value) and nonfinite verb phrases (passing
function pointers). This is like the freeform case-based natural
languages such as Russian and German. In OOP programming languages
like C++, the "subject" or "object" argument is isolated and put
before the "main verb", the other arguments being remained in the
argument list:

subject.myfunc(arg2 value2, arg3 value3, ...);

This way it's more like how we form a natural language sentence. But
note that this is only in favor of English-like syntax. Many natural
languages even including English prefer to place some prepostional
phrases before the main verb. The Chinese language prefer:

subject.(arg2 value2, arg3, value3, ..., myfunc objvalue, ...);

Russian and German prefer the "good old C function call" style:

.(arg2 value2, subjvalue, arg3 value3, myfunc, ..., OBJ objvalue,
....);

What's worse, many Chinese monolingual speakers can't distinguish the
v.t. part-of-speech from the prep part-of-speech. In their eyes, these
are both "relational words with an object and belonging to a
predicate" so they're likely to take a PP (viewed from English) such
as "with" for the main verb. This makes me to try break the POS
difference between prep and vt and treat them as equal entities. So
Chinese speakers may prefer this syntax:

subject.argx(valuex, arg1 value1, arg2 value2, ..., myfunc objvalue,
....);

Some programming languages are promoting the idea of "everything is an
object", and here "argument names" also become objects, at least with
equal syntactic status to that of the function name.

The above discussion shows that:

1. The SUBJECT argument may not necessarily come first;
2. Virtually any argument can play the role of "main verb" (function
name);
3. There may not necessarily be a distinct place for "main verb", in
languages that sometimes don't distinguish verbs from preps.
4. The order of arguments should be able to vary.

Handling such function call syntax is technically possible as long as
the real "main verb" identifier can be found.

Although this syntatic freedom is more significant to my controlled
language authoring and translation project, it does have some use in
programming languages. Take an example from the C library function
memcpy:

void *memcpy(
void *dest,
const void *src,
size_t count
);

We would be able to call it in these ways:

memcpy(to p2; from p1; amount count); // the original order
memcpy(amount count; from p1; to p2); // the english order
(from p1; memcpy amout count; to p2); // the chinese order
....

Yao Ziyuan
Nov 14 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Booted Cat <co********@hotmail.com> spoke thus:
* No ANSI approval is needed
If it isn't ANSI(/ISO)-approved, it isn't standard and isn't discussed
here. If you're suggesting additions to the Standard, take them to
comp.std.c.
* No conflicts with existing language features such as function
overloading
You posted this to comp.lang.c. C doesn't have function overloading.
* No need to modify the language spec or the compiler
Then how are you going to support this feature? Magic?
As you may have guessed, I think it possible to make this a feature of
the IDE.


IDE? Surely you jest.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #2

P: n/a
In article <news:7a**************************@posting.google. com>
Booted Cat <co********@hotmail.com> writes:

[a bunch of interesting stuff, but alas, all -- or almost all --
off-topic in comp.lang.c.]

This really belongs over in comp.programming.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 14 '05 #3

P: n/a
Booted Cat wrote:
I've seen lots of discussions on the proposed inclusion of "function
call with named arguments" to C/C++ on these newsgroups.
No you haven't. We discuss only the actually existing language, C, not
some fiction in your head called C/C++. Anything you assert about "lots
of discussion ... of C/C++" is, on its face, a lie.
My proposal
is slightly different in that:


Who the hell cares?

Nov 14 '05 #4

P: n/a
Your post is very interesting.
I am working in exactly a similar solution to the problem
of type composition in C.

To implement type composition I have developed an IDE based solution first.

jacob

http://www.cs.virginia.edu/~lcc-win32
Nov 14 '05 #5

P: n/a
Hi,

I have tried your IDE. I only found that it could prompt me the
argument list as a tooltip (Visual C++ IDE also implemented this).
What i proposed as my first idea was viewing and editing named
arguments in graphical tables which are visually "embedded" in the
code editor window. Like this:

r = myfunc(
-------------------------------------
| argname1: ____argvalue1 here____ |
| argname2: ____argvalue2 here____ |
| argname3: ____argvalue3 here____ |
| ... |
-------------------------------------
)

Each argname leads a field where the programmer can edit the argument
expression.

Best Regards,
Yao
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message news:<c6**********@news-reader5.wanadoo.fr>...
Your post is very interesting.
I am working in exactly a similar solution to the problem
of type composition in C.

To implement type composition I have developed an IDE based solution first.

jacob

http://www.cs.virginia.edu/~lcc-win32

Nov 14 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.