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?


On Sun, Jul 30, 2000 at 11:37:36PM +0200, Marius Vollmer wrote:
> 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.

Hmmm... maybe {{ }} would work, though I don't know what someone
who didn't know what it meant would think.  I'd like for someone
to be able to create code in this language with only a previous
knowledge of C and working code to work as a template.

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

Well, that's kind of already taken.  I suppose `lambda' is better than
making something up, but this is the one place where I'd rather not
have a keyword.

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

Yes, I just noticed this too.  I think it's a bit weird to overload '
in this way.  Maybe just ` would be useful, with a small optimization
that if , (or whatever the unquote was) wasn't found it would be a
simple quote.

> > > 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 don't like having lots of symbols all over the place.  Keywords are
nice because they mostly explain themselves.  And the standard C 
operators make sense because people have gotten used to them.  Besides
these, I'd like to use keywords as much as possible.

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

I'd like to avoid making scheme escapes necessary.  Of course, they
will be necessary, but they shouldn't be typical.  So I don't think it
should be too necessary to make the syntax easy for inserting Scheme
expressions.  use-modules should have a native form.  Any special
syntax that GOOPS uses should have a native form.  I don't know of
a whole lot of other places where you'd need to do Scheme escapes.

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

Beats me, I haven't used C++ in years.  I think the namespace stuff
wasn't entirely standardized when I was using it.

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

I think it would be for C programmers.  I'd expect them to do:

  function my_map(func, l) {
    var new_l=make_list(10), i;
    for (i=0; i<length(l); i++) {
      new_l[i]=func(l[i]);
    }
    return new_l;
  }

car and cdr are not very C-style.

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

That seems reasonable to me too.  It mostly matches C, and it should
be pretty easy for people to understand what it means.  And the error
message when they leave out arg_rest could give hints.

Ellipses fit with variable arguments quite well, too.

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

Yes, this sounds better.

So we have:

argument_list ::= "(" normal_arguments optional_arguments
                  keyword_arguments ("..." variable_name)? ")"
normal_arguments ::= variable_name ("," variable_name)* | <empty>
optional_arguments ::= ("," variable_name "=" expression)*
keyword_arguments ::= ("," "keyword" variable_name ("=" expression)?)*

Except the commas don't quite work out... but that's just an annoyance.


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