This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: C-like identity?


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)".

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]