The syntax looks alien relative to  curly-bracket languages, but the
semantics are pretty similar. I find that as long as you admit that it
looks different, then explain how it's similar, you can get people to map
their C syntax to Dylan syntax pretty easily.

I got used to Dylan's syntax from a C background, I still haven't got used
to Lisp's.

int CPlusPlus()
{
    return 1;

(defun lisp (x)
    1
)

define method dylan() => ( result )
    1;
end method dylan;

- Rob.

--

"Don't talk to sociologists. Social practice has no sociological
content."A&L
http://www.*-*-*.com/ ;                 http://www.*-*-*.com/

...

  Err... C# certainly. :-)
  Work on Dylan probably predates Java (the language formerly know as Oak)    
    only by short amount of time, if at all. I seem to recall hearing about
    Oak and Dylan around the same time. However, the current infix
    syntax does not. (Dylan had  Lisp/Scheme like syntax at first).
  Perl (1987)... I don't think so.  At least "Perl" the replacement for "awk".
    (as opposed to Perl that caught the internet wave).

  I think it would more accurate that the Dylan syntax was likely more a
  direct "anti" reaction to the baroque language C++.  That language was
  in the "cures all ills" phase that Java is in now about that time. I
  don't think the designers wanted to take the herculean leap from
  "scheme like" to "c++ like".  Languages like Ada and Modula-3 had
  more compatible syntatical goals than C/C++.

  The commonality that C/Dylan share is along the respective
  Algol ancestory lines. Which for both is kind of far back. ;-)
  However, it is enough, with modest effort, for folks predisposed
  to C syntax to latch onto.

Lyman

...

 Huh???

       Dylan                                      C
   reference based semantics            value based semantics
   (never make a copy unless            ( always make copies)
     explicity asked for)

   operators are function calls         operators tend to map to opocodes

   most "statements" are expressions    statements don't return values.
   (e.g.
      1 ==  if test then a else b end; )

There are not totally unsimilar, but there are some definately some stuff
that can throw a C programmer into confusion.

The presented code fragments were almost entirely "syntax", IMHO.
The "last expression, function's value" sematics are matched in
dylan and lisp whereas the C requires explicit control change.

I will grant that people present their most negative visceral  reactions
to "alien" syntax. Second only to "alien" editors. :-)  They seem to
much more forgiving of difference as long as it malleable enough to
tweaked to what they want. (if necessary, a big enough hammer to
fit round peg into square hole.
         if test then temp := a else temp := b end;
         1 == temp;
Or the classic "fortran written in C". )

Lyman

Argh. Syntax semantics? Is that a valid phrase?

I meant that within the language syntax you have markers for beginning and
ending blocks, blocks are scopes, and lines generally end with an end of
line marker. I know this sounds trivial, but the fuss people make over
syntax tends to obscure this.

So, despite having each others' programmers reaching for their Red Books,
these are equivalent:

// C

void klin()
{
    if( true )
    {
        exit( 0 );
    }

// Dylan

define method blim()
    if( #t )
        exit( 0 );
    end if;
end method blim;

Whilst the Dylan takes more typing (in this hyper-correct form), you get
better documented code and you don't have to start blocks twice as you do in
curly-bracket langauges.

You are right that the examples were entirely syntax, this was what I meant.

- Rob.

I suspect that the guys tasked with coming up with the infix syntax were
concerned that if it looked *too* C-like then people would expect it to
have C semantics.

This was, of course, in the days before Java, Perl, and C#.

-- Bruce

Isn't there also an (alternative) prefix syntax for Dylan? That must
be even more lisp-like (says Simon, never having tried it).

--

        ' '     <-------  this blank intentionally spaced left

No. That was ditched a long time ago.

__Jason

Oh, absolutely.  A lot of simple Scheme textbook programs can be
converted into prefix Dylan simply by doing a global s/lambda/method/
e.g.

(define fact (lambda (n) (if (< n 1) 1 (* n (fact (- n 1))))))  // Scheme
(define fact (method (n) (if (< n 1) 1 (* n (fact (- n 1))))))  // Dylan

Then the differences start.  Scheme has a shortcut "(define (fact n) ...
)" whereas Dylan has "(define-method fact (n) ... )".  Dylan lets you
replace args in the argument list with (n <integer>) as a type
declaration.  Dylan has a built-in object system (and everything is an
object).  But they are very, very similar.

But neither current implementation of Dylan supports the prefix syntax.  
At all.  It's pining for the Fjords.  It's an ex-syntax.  It's bleedin'
snuffed it.

-- Bruce

| No. That was ditched a long time ago.

  Yet, curiously, that was about the same time I decided Dylan was a
  waste of time.

#:Erik
--
  If this is not what you expected, please alter your expectations.

If infix syntax was not what you expected, please alter your expectations.

Translation: I implemented Lisp and Lisp environments for 12 years.
I worked on Dylan for 5 years.  I'm back to using Lisp again.  Guess
what?  I like Dylan better, syntax and all.

I appreciate that Lispers may dislike Dylan's compromises and miss some of the
omitted features. Apart from the syntax, want do you think of the semantics and
the feature set?

__Jason

| If infix syntax was not what you expected, please alter your expectations.

  Oh, please.

| Translation: I implemented Lisp and Lisp environments for 12 years.
| I worked on Dylan for 5 years.  I'm back to using Lisp again.  Guess
| what?  I like Dylan better, syntax and all.

  Yeah, we need more personal testimonials.

  My point was that the decision to drop the Lisp-like syntax was
  pretty darn stupid considering it was a selling point towards a
  community that was told "you fine people don't matter, anymore".

#:Erik
--
  If this is not what you expected, please alter your expectations.

if it's okay, and you feel you can expound on this (i.e. if you can
point out things in the syntactic differences), plesae do. I know that I
was averse to Dylan's syntax.  But I also know the following:

when people know and love and understand something -- whatever that
something may be -- and then make a serious change (like Lisp->Dylan),
it's always hard to go back.  I think I wrote a post about his
phenomenon not too long ago.  Basically, it's always hard to go back to
something that breaking away from was work.  It's the same thing that
makes it hard for me to live in Long Island after growing up very
sheltered and struggling to live in my own in Boston.  

Of course, for me it was Pascal -> Common Lisp, and so going back to
that is hard for me.  It's really all about what you see and when you
see it.  I try to look at these things with as open a mind as I can, and
I simply cannot for the life of me see how the Dylan syntax is more
sensible.  I'm not counter-arguing; I just want to know details -- that
is, if you feel you can do it justice.  Admittedly, I have only a
cursory understanding of Dylan syntax, and so the best I can do is say
"I just don't like it as much" or something useless like that.  I do
think that Dylan syntax bites, at least for me.  Syntax is _extremely_
important to many programmers because there are many times when several
languages are "equivalent" in many respects, and so in the end it comes
down to which one's syntax one is most comfortable with.  

Since you have lots of experience with both languages, would you agree
that the CL syntax is more expressive?  more malleable?  More uniform?
I would, but if you feel otherwise, I'd like to know why.

dave

It's pointless to spend any effort selling to 1% of the market.
Reality sucks.

I came to Dylan post-syntax-change. I like the syntax, it's now my favourite
syntax over C++, Lisp, Java and AppleScript.

I appreciate that the object-pascal-style syntax may be offputting to people
who think they've got a career for life writing COM objects in VC++, but
it's less offputting to these people IMHO than Lisp syntax, and Dylan sorely
needed to differentiate itself from the incorrect common perception of Lisp
as an AI/research language.

- Rob.