This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: C-like identity?
- To: ianb at colorstudy dot com
- Subject: Re: C-like identity?
- From: Marius Vollmer <mvo at zagadka dot ping dot de>
- Date: 30 Jul 2000 23:37:36 +0200
- Cc: guile at sourceware dot cygnus dot com
- References: <20000730123732.C401@lothlorien>
ianb@colorstudy.com writes:
> > Yep. But as you say, for for-each you might want to provide something
> > more concise. Maybe simply
> >
> > { arg_list: body ... }
> >
> > (see definition of arg_list below) However, this would maybe clash
> > with list constructors that might also want to use `{' and '}'.
>
> This looks kind of nice
But you have to watch out for ambiguities. For example, the colon
might cause confusion when you allow labels. And, after looking at it
a little bit longer, it looks a bit too `unspectactular' for such a
unexpected thing in a C like language. Maybe use double braces
{{ arg_list: body ... }}
The double braces would be a single token like ++. However, they
could clash with nested lists or nested initializers.
> -- I really don't like the word "lambda" at all. One mathematician
> chose an arbitrary greek letter, and then it became syntax...
But it's very widely recognized already. You could use a different
keyword, of course, like "function".
> > Hmm, I agree that 'asymbol will probably not fit into the rest of the
> > grammar.
Ok, I have noe checked the original CTAX documentation (which I should
have done muich earlier). They did use the 'asymbol form and
something was treated as a character constant when it looked like one.
They also have quasi-quotation using ` and constant lists using '.
Maybe we can just support quasi-quotation and `abuse' it for the rest.
After all, `asymbol is the same as 'asymbol and `(a b c) is the same
as '(a b c).
> > There should be a general purpose way of escaping to Scheme
> > and something like
> >
> > #.any-scheme-expr
CTAX used #any-scheme-expr. However, as you say, it might be good to
use `#' in the same way as Scheme, as a generic back-door into the
reader. We could define `#(' in an expression context to read a list
until the closing `)'. Other extension could then done by using some
other character as `('.
> I wonder if #scheme any-scheme-expr might be better, as it's much
> easier to read.
Yes, but I think it would be a nice feature to be able to just write
#(use-modules (ice-9 format))
> Then there could be other # expressions (like include). (What
> syntax does C++ use for modules...? #include still, right?)
Hmm, yes and no. C++ still uses the preprocessor (#include, #define,
#ifdef, ...) but it also has explicit name space management via
`namespace' and `using' (right? Im not sure about these keywords).
> Symbols should really have some representation, though, because they
> get used a lot.
What about using only ` and quasi-quotation?
> > My first try would be to have
> >
> > ( e1, e2, ... )
> >
> > [...]
>
> Well, list(1, 2, 3) already works fine and looks fine syntactically.
Yes, I thought about that. You are right that we don't need special
syntax for the `list' and `vector' functions.
> I think they are more comfortable with vectors because they are easier
> in C. I definately want x[10] to work if x is a vector *or* a list.
> Lists are called for more often in Scheme than vectors, and even in
> a C-like language people are going to be constructing more lists than
> vectors.
Yes, but accessing list via list-ref is not very common, I think.
> > > Functions that take variable number of arguments:
> > > function foo(arg1, arg_rest*) ...
> >
> > What about
> >
> > foo (arg1, arg2; arg_rest)
> > {
> > // arg_rest is a list of all rest arguments here
> > }
CTAX uses
foo (arg1, arg2, ... arg_rest)
which looks OK to me. I shortly toyed with (arg1, arg_rest ...) but I
thought that people used to C could get confused by this because
varargs in C work differently (via va_list, et al). But the CTAX form
seems to be significantly less confusing because it looks different
enough.
Together with keyword and optional arguments and your suggestions,
this could be expressed as
arg_list ::= <empty
| arg { ',' arg } *
arg ::= identifier [ '=' expression ]
| 'keyword' identifier '=' expression
| '...' identifier
Or, we could replace '...' with 'rest'.
> It seems like it would be clearer to make people use `key' for each
> keyword. I'd probably also use `keyword' instead of `key', since I
> don't want to steal the use of `key' as a variable name.
Yep, agreed.
> The other thing is that it is potentially unambiguous if it was just
>
> function foo(x, y, bar=10) {...}
> foo(10, 20, bar: 10)
Hmm, what about optional arguments? This are arguments at the end of
a argument list, that get default values when the caller does not
specify a value for them. "bar" should be a optional argument I'd
say, not a keyword argument.
> This is what Python does. OTOH, unlike Python the call on the function
> has to include the keyword arguments with a `:' (as opposed to
> foo(10, 20, bar=10)) because assignment is a proper expression. This
> detracts from the value of this syntax significantly.
What about a different token from `=' and `:'? ADA uses `=>', I
think.
> A mysterious part of the C syntax I found was `...', which apparently
> can come at the end of a function definition, as in:
>
> int foo(x, y, ...) {...}
>
> I've never seen this used, so I don't know what it is. Maybe something
> like `rest'...?
Yes, it's they way C implement a variable number of arguments. You
use it with the macros `va_start', `va_arg' and `va_end'. Like this:
#include <stdarg.h>
void
foo (int x, int y, ...)
{
int z;
va_list ap;
va_start (ap, y);
...
z = va_arg (ap, int); /* z == 3 in the call below */
...
va_end (ap);
}
...
foo (1, 2, 3);
There are a lot of drawbacks to this way of doing rest arguments. For
example, you can't tell when you have reached the end of the argument
list, you can not portably copy a va_list object, you always need at
least one proper argument, and the mechanism undermines the type
system of C. You should not model the CTAX rest arguments on this.
> > When the last part is just a single identifier, and there are more
> > than one part, that last part is treated as a `rest' part.
>
> I'm not clear what you mean here.
This was supposed to allow
foo (a; r)
as an abbreviation to
foo (a; rest r)
but "foo (a)" would not mean "foo (rest a)".