C# is not Dylan (was: Re: C# : The new language from M$)
Rob Myers
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.
Bruce Hoult wrote:
> In article <kpamlscdjl89ihfhs...@4ax.com>, Jason Trenouth
> <ja...@harlequin.com> wrote:
>
> >Unfortunately,
> > from the point of view of promulgating the language, Dylan's syntax
> > looks very alien to many C programmers.
--
Rob Myers - ro...@h2g2.com H2G2 - http://www.h2g2.com/
"Don't talk to sociologists. Social practice has no sociological
content."A&L
http://www.robmyers.org/ http://www.gwydiondylan.org/
Lyman Taylor
...
> This was, of course, in the days before Java, Perl, and C#.
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
Lyman Taylor
...
> .... but the
> semantics are pretty similar.
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
Rob Myers
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.
> From: Lyman Taylor <lyman....@mindspring.com>
> Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
>
> Rob Myers wrote:
> ...
>> .... but the
>> semantics are pretty similar.
>
> Huh???
>
Bruce Hoult
> Well, Dylan really isn't C-ish syntax. No braces (except in macro
> definitions), no casting, postfix type declarations, and very
> different (Lisp/Scheme-like) identifier conventions. Unfortunately,
> from the point of view of promulgating the language, Dylan's syntax
> looks very alien to many C programmers.
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
Simon Brooke
> In article <kpamlscdjl89ihfhs...@4ax.com>, Jason Trenouth
> <ja...@harlequin.com> wrote:
>
> > Well, Dylan really isn't C-ish syntax. No braces (except in macro
> > definitions), no casting, postfix type declarations, and very
> > different (Lisp/Scheme-like) identifier conventions. Unfortunately,
> > from the point of view of promulgating the language, Dylan's syntax
> > looks very alien to many C programmers.
>
> 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.
Isn't there also an (alternative) prefix syntax for Dylan? That must
be even more lisp-like (says Simon, never having tried it).
--
si...@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
' ' <------- this blank intentionally spaced left
Jason Trenouth
> Isn't there also an (alternative) prefix syntax for Dylan? That must
> be even more lisp-like (says Simon, never having tried it).
No. That was ditched a long time ago.
__Jason
Bruce Hoult
Brooke <si...@jasmine.org.uk> wrote:
> Bruce Hoult <br...@hoult.org> writes:
>
> > In article <kpamlscdjl89ihfhs...@4ax.com>, Jason Trenouth
> > <ja...@harlequin.com> wrote:
> >
> > > Well, Dylan really isn't C-ish syntax. No braces (except in macro
> > > definitions), no casting, postfix type declarations, and very
> > > different (Lisp/Scheme-like) identifier conventions. Unfortunately,
> > > from the point of view of promulgating the language, Dylan's syntax
> > > looks very alien to many C programmers.
> >
> > 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.
>
> Isn't there also an (alternative) prefix syntax for Dylan? That must
> be even more lisp-like (says Simon, never having tried it).
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
Erik Naggum
| 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.
Scott McKay
Erik Naggum wrote in message <31713540...@naggum.no>...
>* Jason Trenouth <ja...@harlequin.com>
>| No. That was ditched a long time ago.
>
> Yet, curiously, that was about the same time I decided Dylan was a
> waste of time.
>
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.
Jason Trenouth
> * Jason Trenouth <ja...@harlequin.com>
> | No. That was ditched a long time ago.
>
> Yet, curiously, that was about the same time I decided Dylan was a
> waste of time.
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
Erik Naggum
| 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".
David Bakhash
> 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.
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
Carl L. Gay
>
> * "Scott McKay" <s...@mediaone.net>
> | If infix syntax was not what you expected, please alter your expectations.
>
> Oh, please.
>
> | I worked on Dylan for 5 years. I'm back to using Lisp again. Guess
> | what? I like Dylan better, syntax and all.
>
>
> 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".
It's pointless to spend any effort selling to 1% of the market.
Reality sucks.
Rob Myers
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.
> From: Erik Naggum <er...@naggum.no>
> Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
>
Jeff Dalton
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?
I'm tempted to say "irrelevant", because I don't use Dylan and
because it's unlikely that I ever will. The syntax is largely
to blame for that, though not in the way most people reading this
probably expect.
(Actually, I think Dylan is a good language, and despite being a
"Lisper", I don't much mind the syntax, though it is a bit odd, as
"infix" syntaxes go.)
But ... things may have seemed different to people on the "inside",
working on Dylan design and implementation, but from my point of
view things went though something like the following phases:
1. I start hearing about Dylan from other Lisp folk. It sounds
interesting. Soon the first book appears, and at the Lisp and
FP conference there's a lot of interest. Dylan people are handing
out copies. The books says Dylan is a small dialect of Lisp,
and all the code examples have a Lisp-like syntax. Some
implementations appear.
2. It's emphasised that there are supposed to be two syntaxes.
It sounds like implementations will support both, and all the
implementations available to me support only the Lisp-like syntax.
Indeed, we don't know what the other syntax is yet.
3. We're told that there will be only one syntax. We still don't
know what it is. Some Dylan people are by now treating "old
Lispers" with considerable hostility. Quoting the Dylan book
on Dylan's relationship to Lisp gets one flamed, even though
the the issue ought to be largely *semantic* and even though
Dylan is very close to Scheme+a-CLOS-subset in "language
space". It seems like there's been an essentially political
decision to distance Dylan from "Lisp".
4. Time passes. We still don't know what the syntax is.
I therefore can't write any Dylan programs.
5. Eventually the new syntax appears. There's an implementation
from CMU (not their main effort) that supports the new syntax,
so I try it out a bit, but it's not something I could use for
my work. There's much discussion of Dylan macros, with more
hostility towards "Lisp".
6. Time passes. Eventually we find out about macros. There
still doesn't seem to be a serious Dylan implementation I
can use.
7. There's at least one serious implementation, but ...
Ok. I put in the stuff about hostility because, even though it was
annoying, I still retained an interest in Dylan. I was hoping Dylan
might save me from having to work in C++.
Unfortunately, so much time passed that Java came along, and Netscape
decided to support it, before I could ever seriously consider using
Dylan.
It's all very well to have a syntax that will appeal to "mainstream"
programmers, or whatever was supposed to happen, but all the syntax-
related stuff (which includes macros, because otherwise Dylan could
have followed Scheme) just took too long.
Dylan might be better than "Lisp" (by which people seemed to really
mean something more like "typical Common Lisp implementations") -
or not - it no longer matters. I use Common Lisp when I can, Java
when I must, and Dylan never enters the picture.
-- jeff
Erik Naggum
| It's pointless to spend any effort selling to 1% of the market.
Then it's clearly even more pointless to spend any effort "selling"
anything to you, only one in 6 _billion_ people, such as a much
better attitude towards "reality" than you currently have, both in
terms of suckiness and in terms of this mythological _one_ market.
#:Erik
--
If this is not what you expected, please alter your expectations.
Tim Bradshaw
> It's pointless to spend any effort selling to 1% of the market.
> Reality sucks.
I wonder how big Dylan's market is compared to Lisp's (not a
rhetorical question, I'd like to know).
--tim
Phil Stubblefield
> | I worked on Dylan for 5 years. I'm back to using Lisp again. Guess
> | what? I like Dylan better, syntax and all.
>
And the alternative is... impersonal ad brochures?
Seriously, I'd love to hear Lisp vs. Dylan comparisons from someone
with Scott's amount of Lisp experience. I just browsed the subject
tree at Amazon.com, and of the three books listed within "Dylan
Programming," one was a tutorial, one a reference manual, and the
third had the comment, "Incomplete and riddled with errors." I'd
rather trust the judgement of someone like Scott, who I know *gets*
Lisp.
Scott, I second David Bakhash's interest in more details from you.
Phil Stubblefield
Rockwell Palo Alto Laboratory 206/655-3204
http://www.rpal.rockwell.com/~phil ph...@rpal.rockwell.com
Scott Ribe
>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.
I think Dylan syntax is "more sensible" ONLY in practical/political
terms. Personally, I don't mind either. But here's my own take:
- C/C++ programmers work in a mode of thought that is dominated by gnarly
syntax issues and many (in my experience most) do not have enough
experience with other languages or enough education to see beyond the
surface syntax issues.
- Lisp programmers don't think about syntax too much (because Lisp has
almost none), and they tend to have a much deeper understanding of the
semantics of languages and their expression through syntax.
So, given that you must make a choice, and given that you'd like Dylan to
become popular, which group do you deprive of their comfortable syntax?
The group that is terrified of anything that looks too different? Or the
group that can see beyond the surface and understand what a language
really offers?
Of course, that presumes that even WITH infix notation that you could (or
would want to) appeal to C/C++ programmers, and the onslaught of Java has
made that a much more difficult thing to do. With Sun marketing cranking
out lies, backed by millions of $, faster than they can be debunked,
Dylan is left in the position of appealing only to those who can see
through to the underlying semantics.
Scott Ribe
scott...@killerbytes.com
http://www.scott.net/~sribe
(303) 665-7007 voice
Erik Naggum
| And the alternative is... impersonal ad brochures?
Someone just getting the point would be a worthwhile alternative.
Jon S Anthony
>
> On Fri, Jun 30, 2000, David Bakhash <ca...@alum.mit.edu> wrote:
>
> So, given that you must make a choice, and given that you'd like Dylan to
> become popular, which group do you deprive of their comfortable syntax?
> The group that is terrified of anything that looks too different? Or the
> group that can see beyond the surface and understand what a language
> really offers?
The oddest thing about this is that "you" ended up "depriving" _both_.
A C/C++ hack is _never_ going to go with "pascal-ish" syntax. Never.
And the Lisp folks won't go for it because, frankly, it is
fundamentally broken with respect to macros.
> made that a much more difficult thing to do. With Sun marketing cranking
> out lies, backed by millions of $, faster than they can be debunked,
True. But they also understood if you are going after popularity you
need to cozy up to the same broken, butt/bug-ugly syntax that caters
to the infantilism of the C crowd.
/Jon
--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
Scott Ribe
>The oddest thing about this is that "you" ended up "depriving" _both_.
>A C/C++ hack is _never_ going to go with "pascal-ish" syntax. Never.
>And the Lisp folks won't go for it because, frankly, it is
>fundamentally broken with respect to macros.
>
>> made that a much more difficult thing to do. With Sun marketing cranking
>> out lies, backed by millions of $, faster than they can be debunked,
>
>True. But they also understood if you are going after popularity you
>need to cozy up to the same broken, butt/bug-ugly syntax that caters
>to the infantilism of the C crowd.
Sadly, I have to agree with everything you say.
Dylan will only ever appeal to a small portion of all developers, period.
But not all those of us working with C/C++ are immune to better ideas. So
there ARE some who will look at Dylan, along with Eiffel, Clean, CLOS,
Smalltalk and so on; and even some who will choose Dylan ;-)
The challenge is not to displave Java. (Who would want to have the idiots
of the world join us?) The challenge is to grow a community large enough
for Dylan to prosper.
As for your last comment about the "infantilism" of many developers, I've
long been saying the following:
Like everything else, the talent, education, and dedication of developers
is distributed with a big hump in the middle where the average is. If you
set out to design a language to appeal to the largest number of
developers, you would aim squarely for the average schlepps, and you'd
design Visual BASIC. If you want to actually advance the state of the
art, you have to figure out how to make a go of it when your market is
automatically restricted to the thin slice at the far right edge ;-)
Bruce Hoult
McKay" <s...@mediaone.net> wrote:
> Erik Naggum wrote in message <31713540...@naggum.no>...
> >* Jason Trenouth <ja...@harlequin.com>
> >| No. That was ditched a long time ago.
> >
> > Yet, curiously, that was about the same time I decided Dylan was a
> > waste of time.
> >
>
> 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.
Hark! The voice of experience!
But could you clarify that?
1) you hate Dylan syntax, but still prefer Dylan over CL for other
reasons
2) you prefer Dylan syntax
-- Bruce
Christopher Browne
>>
>>
>> | 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.
>>
>>
>> pretty darn stupid considering it was a selling point towards a
>> community that was told "you fine people don't matter, anymore".
>
>Reality sucks.
Ah, but when you're trying to sell _Dylan_, when it has _no_ market,
having a community of Lisp adopters might have been a Good Thing, and
might well have represented a lot more than 1% of the market _for
Dylan_.
--
cbbr...@hex.net - <http://www.ntlug.org/~cbbrowne/lisp.html>
I'M SORRY, LUSER, I CAN'T LET YOU DO THAT. WHY DON'T YOU LIE DOWN AND TAKE
A STRESS PILL? MY NAME IS LM1. I WAS MADE AT THE LISP MACHINE FACTORY IN
MASSACHUSETTS ON DECEMBER 12, 1992. MY TEACHER WAS MR. WINSTON. HE
TAUGHT ME A PROGRAM. WOULD YOU LIKE TO SEE IT? HERE IT IS:
Bruce Hoult
<j...@synquiry.com> wrote:
> The oddest thing about this is that "you" ended up "depriving" _both_.
> A C/C++ hack is _never_ going to go with "pascal-ish" syntax. Never.
> And the Lisp folks won't go for it because, frankly, it is
> fundamentally broken with respect to macros.
And the Pascal/Modula-2/Ada guys like me say "what the heck are those ()
doing around all the conditions?". And absolutely no one is pleased.
I don't know what to do about this. My ideal Dylan would lose the ()
and use then/do type keywords instead.
But when it comes down to it I really don't care *what* syntax is used
as long as its consistent. And infix. I've written significant
programs in at least:
infix:
- (Object) Pascal
- dylan
- C/C++
- java
- perl
not infix:
- assembler
- postscript // bracketless postfix
- logo // bracketles prefix
- scheme // bracketed prefix
I can use anything. I *definitely* prefer an infix syntax. I slightly
prefer Pascal-ish syntax, but *all* the most common languages today --
C++, Java and Perl (and C#) -- use essentially the same syntax. A
broken one, IMHO, but one familiar to a great many people. And one that
now has a number of different semantics.
-- Bruce
Rob Myers
> Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
>
> having a community of Lisp adopters might have been a Good Thing, and
> might well have represented a lot more than 1% of the market _for
> Dylan_.
Attempting to cannibalize a small and entrenched user base is never a good
idea.
If Dylan was a language that looked and acted exactly like Lisp, I can't
help but feel there's an already established language that people would use
instead.
Languages can come from no market to global domination *if* they
differentiate themselves. J**a, Perl and (for the moment) Rebol and PHP
prove this. "Dylan is almost as good as Lisp but doesn't have it's 'purity
of syntax' " is not going to convince anyone.
Reading some of the Fun-O white papers will give a feel for what makes Dylan
special. Bemoaning its lack of information-destroying syntax won't.
- Rob.
Rainer Joswig
<je...@aiai.ed.ac.uk> wrote:
> Dylan is very close to Scheme+a-CLOS-subset in "language
Hmm, personally I'd say Dylan is a stripped down Common Lisp.
Dylan has much more from Common Lisp than from Scheme.
And this is not only the object system.
Dylan has:
- keyword parameters
- multiple values
- types
- multiple defines
- conditions
- blocks with cleanup clause
- loop (called "for")
- ...
But then, "The Dylan Reference Manual" does not
mention Lisp, Common Lisp or Scheme with a single word.
Thanks.
--
Rainer Joswig, BU Partner,
ISION Internet AG, Steinhöft 9, 20459 Hamburg, Germany
Tel: +49 40 3070 2950, Fax: +49 40 3070 2999
Email: mailto:rainer...@ision.net WWW: http://www.ision.net/
Rainer Joswig
<scott...@killerbytes.com> wrote:
>- Lisp programmers don't think about syntax too much (because Lisp has
> almost none), and they tend to have a much deeper understanding of the
> semantics of languages and their expression through syntax.
Hmm? I think this is simply not true. Common Lisp has a lot of syntax.
Compare for example Dylan's "define class" with Common Lisp's
"DEFCLASS". For DEFCLASS see:
http://www.xanalys.com/software_tools/reference/HyperSpec/Body/mac_defclass.html#defclass
Despite that Common Lisp groups certain source objects as lists via
parentheses, it has a ***lot*** of syntax:
- a lot of surface syntax to describe external representations of Lisp objects
(characters, symbols, strings, numbers, arrays, lists, ...) and
read macros with macro characters
- function application syntax with a complicated version of arglists
(rest, key, optional, ...)
- special forms
- tons of macros which implement a lot of syntax (look at the LOOP macro)
- ...
Erik Naggum
| Apart from the syntax, want do you think of the semantics and
| the feature set?
I thought I said that: I concluded that Dylan was a waste of time.
What kept me interested in it for a while was the Lisp-like syntax.
I didn't find the semantics and the "feature set" sufficiently
attractive on their own, and knowing how fixed-grammer languages
evolve (rampant keyworditis and logorrhea), didn't appear to be
something worth investing in at the time. However, it has been six
years, so I ordered a couple books on Dylan from Functional Objects
to see if there are any good ideas I am more likely to pick up now.
(Incidentally, I didn't see any non-Windows offerings, which means
I'm not inclinced to investigate further, as I simply don't deal
with criminals, such as Microsoft.)
#:Erik
--
If this is not what you expected, please alter your expectations.
Scott McKay
>
>Ah, but when you're trying to sell _Dylan_, when it has _no_ market,
>having a community of Lisp adopters might have been a Good Thing, and
>might well have represented a lot more than 1% of the market _for
>Dylan_.
Hey, look, if the only thing that Lispers care about is having
Lisp syntax, then they are as closed-minded as the C and Java
communities. Syntax is trivial. Get over it.
Scott McKay
Phil Stubblefield wrote in message <395D0225...@rpal.rockwell.com>...
>> | 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.
>
>
>with Scott's amount of Lisp experience. I just browsed the subject
>tree at Amazon.com, and of the three books listed within "Dylan
>Programming," one was a tutorial, one a reference manual, and the
>third had the comment, "Incomplete and riddled with errors." I'd
>rather trust the judgement of someone like Scott, who I know *gets*
>Lisp.
>
>Scott, I second David Bakhash's interest in more details from you.
OK, I'll tell you some of the things I like about Dylan, and some
of the things I like better in Lisp. First the likes:
- I like Dylan's type system. I like that the "built-in" types fix into
the type system in a clean and consistent way. I like that you
can use it "typeless" but can then clamp down the types to get
better code, and more importantly, better compile-time error
detection. Going back to Lisp makes me fell butt-naked on the
type safety front; as the static-type people have been saying
for years, a lot of errors really are type errors, and Dylan does
a good job catching these.
- I am surprised to say that I have come to like the infix syntax.
For one, using type decls in Dylan is a lot easier than in Lisp,
and a lot more readable, too. Don't delude yourself into thinking
Lisp has "no syntax" (as many people claim); it does, but it's
just harder to see.
- I like Dylan's hygienic macro system. If we adopted Keith
Playford's work on procedural macros, Dylan's macros would
be very nearly as powerful as Lisp's, and many of Lisp's
pitfalls would fall away.
- I like that Dylan has a library compilation model. I like being
able to ship reusable components. I like Dylan's library and
module system.
- I like that Dylan is smaller than Common Lisp. I don't miss most
of the fat.
- Believe it or not, I now prefer the simpler method combination
in Dylan. It forces you to get your class hierarchy correct, and
not to patch it up with kludgy method combination. If you think
you haven't used kludgy method combination, I bet you're wrong.
I prided myself on how little I resorted to such kludges, but my
Dylan experiences truly showed that my pride wenteth before
a fall. (I confess that I miss the "namespace" provided by
daemon method combination, but you get used to it.)
- I like that all primitive operations are defined as generic functions,
too, unlike in Lisp.
- It's partly parental pride, but I like using HD/FD better than almost
any other programming environment I've used. Yeah, it's not as
mature or solid, but it's really good.
Now some dislikes:
- I don't like that Dylan doesn't have first-class interfaces like Java.
- I wish Dylan hadn't thrown out so much of the CLOS MOP. I would
like some of the introspection reinstated (slot descriptors, e.g.),
but could live with only compile-time MOP for doing extensions.
Obviously, I like that Dylan is truly a dialect of Lisp (closest to Eulisp,
I think) with all that Lisp gives you: dynamic types, keyword args,
higher order functions, etc.
Scott McKay
David Bakhash wrote in message ...
>"Scott McKay" <s...@mediaone.net> writes:
>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.
I don't actually think CL syntax is more expressive or more uniform.
The *basic* syntax of lists certainly is, but once you start adding in
all the macros and special forms, the nice uniformity goes right
down the tubes. Think of if, cond, do, defclass, ...
It's certainly more malleable, and it's certainly easier to write read
and print. There are some things for which that is a real benefit.
In fact, the slightly less malleable syntax actually makes most Dylan
macros easier to read, in my opinion, because there isn't so much
flexibility that you can do any awful thing.
Carl L. Gay
>
> * Carl L Gay wrote:
>
> > Reality sucks.
>
> rhetorical question, I'd like to know).
I guess it's a good sign that you don't think it's obvious. :-)
It's a small percentage of the size of the Lisp community, I'm sure.
Johan Kullstam
it's not. i like the lisp syntax because of its clean look. more
importantly, the syntax is what lets lisp have such powerful and
useful macros. with a less regular or less simple syntax you could
never do it as easily nor to such great effect. it has nothing to do
with being closed minded. sometimes certain things really are better;
this is such a case.
--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
Don't Fear the Penguin!
Michael T. Richter
news:m2og4ha...@euler.axel.nom...
>> Syntax is trivial. Get over it.
> it's not. i like the lisp syntax because of its clean look.
That's the first time I've seen someone describe a profusion of parentheses
as "clean".
Erik Naggum
| Hey, look, if the only thing that Lispers care about is having
| Lisp syntax, then they are as closed-minded as the C and Java
Wow, so much _passion_ against somebody caring about something! But
why reduce somebody else's concerns to "only thing that they care
about"? How rewarding can it be to beat those strawman arguments?
You may dislike that some people care about syntax and even think
they are idiots for it, but at least have the honesty and decency to
judge them for what they think, not for some moronic attitude _you_
attribute to them out of malice, OK?
Syntax _is_ important to some people. So, too, is spelling and
grammar in natural languages. Some _always_ "disagree" with this,
however and it is usually coupled with a hostile "get over it" to
whoever points out a mistake. One could psychologize endlessly over
the causes of such intolerant hostility.
Syntax evidently forms the ways our languages develop and evolve, if
the history of programming languages is at all useful to consider,
which would imply that syntax itself in no small part shapes the way
we _think_ in our languages, especially when so much of programming
is all about making our own thoughts expressible _in_ a language, by
extending it in various ways. I therefore find it a sign of general
lack of insight into languages and human use of them to make such an
unfounded and overly broad claim as "syntax is trivial", especially
after having complained about Lisp's syntax. What was that "get
over it"? It surely does not apply _only_ to others, does it?
On the other hand, my chief gripe with fixed-grammer syntaxes is
that they enforce this artificial separation between the language
and any expression in the language, but some people never get past
the level where they only "use" a language. as opposed to be able to
_live_ with the language. [A weak reference to Richard Gabriel's
"Patterns of Software" and _inhabitable_ software.]
Finally, a twist on the old "beware of programmers with screwdrivers":
Beware of programming language designers who show disdain for syntax.
Neel Krishnaswami
>
> 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.
I don't want to disparage your (or anyone else's) taste, but
for me, syntax rarely matters except when it is designed to maximize
confusion. (Eg: Perl and Python -- the two languages have nearly
identical semantics, but Perl is awk on PCP and Python isn't, so
I use Python for sysadminy things.)
But Dylan and Lisp are both clean enough; I can judge between the two
based on their feature sets. I chose Dylan, but there are features
that you might need (such as the MOP) that Dylan (deliberately)
doesn't have.
> 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.
Actually, I'd say that Dylan is simpler and more uniform than Common
Lisp. There are single features of CL (such as LOOP and the FORMAT
sublanguage) that are nearly as complex as all of Dylan.
But Common Lisp has a set of powerful features Dylan doesn't. Reader
macros, compiler macros, and the ability to do computation at macro
expansion time. Dylan's macros are very close to Scheme's; they are a
hygienic pattern-expansion mechanism (plus a feature to deliberately
break hygiene).
Since I do need a comprehensive object system but don't usually need
the MOP, make frequent use of higher-order functions, and naturally
tend to write only the sorts of macros easily written with a hygienic
system, I prefer Dylan.
Neel
Erik Naggum
| That's the first time I've seen someone describe a profusion of
| parentheses as "clean".
Congratulations! That's means you have finally opened your eyes to
the _existence_ of people who don't share your closed-minded view on
syntax. That's no small feat for a man in this day and age! I hear
tolerance is such a virtue over in the Dylan camp, so you must feel
almost like a white supremacist who saw the first black in his life,
or the uptight puritan who first discovered gays and lesbians on his
own -- such wild and unbridled expansion of your consciousness is so
seldom achieved without drugs these days. Man, you are _so_ lucky.
No wonder Dylan dropped its clean, attractive syntax -- had it
retained it, the Dylan community would have had to deal with so much
hostility in their own ranks -- as always, it's _so_ much better to
find an external "enemy" to ridicule and denigrate, especially when
it's someone you think you're competing with because you might have
been friends if you were any smart, but if you choose infix, being
smart is just _not_ an option.
Paul F. Dietz
> But Common Lisp has a set of powerful features Dylan doesn't. Reader
> macros, compiler macros, and the ability to do computation at macro
> expansion time. Dylan's macros are very close to Scheme's; they are a
> hygienic pattern-expansion mechanism (plus a feature to deliberately
> break hygiene).
I was interested in Dylan, but this makes me much less interested.
I use the power of CL's macros all the time.
Paul
Neel Krishnaswami
> > compiler macros, and the ability to do computation at macro
> > expansion time. Dylan's macros are very close to Scheme's; they are
> > a hygienic pattern-expansion mechanism (plus a feature to
> > deliberately break hygiene).
>
> I was interested in Dylan, but this makes me much less interested.
> I use the power of CL's macros all the time.
There's no shame in not liking Dylan, of course, but I still think
it's very much worth trying out.
Personally, I think much of the use of macros in Lisp is to avoid
using higher-order functions, or to work around non-generic functions
in the CL spec. These are both more natural in Dylan. I don't want to
over-sell, though: if you are writing something like Screamer, then CL
is the only thing that can do it.
Neel
Rob Myers
> Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
Having worked with the source to d2c, the Dylan core libraries and the
public DUIM code, as well as writing an OS interface and an application
shell in Dylan, I am convinced of Dylan's elegance and power. :-)
> Now some dislikes:
>
> - I don't like that Dylan doesn't have first-class interfaces like Java.
Java's interfaces are broken, IMHO! Anything that allows naming clashes
whilst disallowing code reuse is a real worst of both worlds solution.
Protocols are used in Dylan instead, aren't they?
> - I wish Dylan hadn't thrown out so much of the CLOS MOP. I would
> like some of the introspection reinstated (slot descriptors, e.g.),
> but could live with only compile-time MOP for doing extensions.
I like the way Java lets you work with objects and methods by name, and
resolve things at runtime. I used this throughout 3 years of real-world
Java programming. I'm assuming MOP transcends this, and I'd like to see it
in Dylan, although Dylan's efficiency shouldn't be compromised.
> Obviously, I like that Dylan is truly a dialect of Lisp (closest to Eulisp,
> I think) with all that Lisp gives you: dynamic types, keyword args,
> higher order functions, etc.
I'm learning Common Lisp at the moment, after working with Dylan for 2 years
(I don't intend to switch, but I feel Lisp is very important to know). In
the same way that all modern Operating Systems want to be UNIX, all modern
programming languages want to be Lisp. Dylan can be regarded as the MacOS X
or Gnome of Lisp. This is a good thing.
- Rob.
Rob Myers
plans, and then try http://www.gwydiondylan.org/ . If you want to provide
an AmigaDOS or Playstation 2 port of d2c, just say.
Also, please don't post offensive nonsense attempting to conflate dislike of
fully-bracketed prefix syntax with homophobic and racial intolerance on this
list. It is singularly offensive and unproductive, and has no place anywhere
in the comp.* hierachy.
- Rob.
> From: Erik Naggum <er...@naggum.net>
> Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
>
Scott McKay
Johan Kullstam wrote in message ...
>it's not. i like the lisp syntax because of its clean look. more
>importantly, the syntax is what lets lisp have such powerful and
>useful macros
This is simply wrong. What makes DRM Dylan macros less
powerful than Lisp macros is that they can call general procedures
at compile-time. The syntax has nothing to do with it, except that
Lisp macros at their worst are even more unreadable than Dylan
ones. As I have already said in this so-called conversation, the
adoption of Keith Playford's procedural macros for Dylan would
make them equally as powerful as Lisp's macros.
The confusion of macro power with infix is just that -- confusion.
Scott McKay
Erik Naggum wrote in message <31714603...@naggum.net>...
>* "Scott McKay" <s...@mediaone.net>
>| Hey, look, if the only thing that Lispers care about is having
>| Lisp syntax, then they are as closed-minded as the C and Java
>| communities. Syntax is trivial. Get over it.
>
> Wow, so much _passion_ against somebody caring about something! But
> why reduce somebody else's concerns to "only thing that they care
> about"? How rewarding can it be to beat those strawman arguments?
Perhaps you missed the "if" in that sentence?
> You may dislike that some people care about syntax and even think
> they are idiots for it, but at least have the honesty and decency to
> judge them for what they think, not for some moronic attitude _you_
> attribute to them out of malice, OK?
>
> Syntax _is_ important to some people. So, too, is spelling and
> grammar in natural languages. Some _always_ "disagree" with this,
> however and it is usually coupled with a hostile "get over it" to
> whoever points out a mistake. One could psychologize endlessly over
> the causes of such intolerant hostility.
>
> Syntax evidently forms the ways our languages develop and evolve, if
> the history of programming languages is at all useful to consider,
> which would imply that syntax itself in no small part shapes the way
> we _think_ in our languages, especially when so much of programming
> is all about making our own thoughts expressible _in_ a language, by
> extending it in various ways. I therefore find it a sign of general
> lack of insight into languages and human use of them to make such an
> unfounded and overly broad claim as "syntax is trivial", especially
> after having complained about Lisp's syntax. What was that "get
> over it"? It surely does not apply _only_ to others, does it?
If you took the time to actually learn something about modern
linguistic theory, you would see that people like Chomsky have
tried to show that surface syntax is a property derived from
much deeper underlying rules. Pinker's books are an excellent
introduction to this. I find it a sign of general lack of insight that
people think that syntax in most languages is the tough thing,
because it isn't.
> On the other hand, my chief gripe with fixed-grammer syntaxes is
> that they enforce this artificial separation between the language
> and any expression in the language, but some people never get past
> the level where they only "use" a language. as opposed to be able to
> _live_ with the language. [A weak reference to Richard Gabriel's
> "Patterns of Software" and _inhabitable_ software.]
>
> Finally, a twist on the old "beware of programmers with screwdrivers":
> Beware of programming language designers who show disdain for syntax.
I have seen evidence of "disdain for syntax". Well, except from
you, who evidently could not care less for the genuine effort
spent making Dylan's infix syntax reasonable.
Scott McKay
Rob Myers wrote in message ...
>> From: "Scott McKay" <s...@mediaone.net>
>> Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
>
>Having worked with the source to d2c, the Dylan core libraries and the
>public DUIM code, as well as writing an OS interface and an application
>shell in Dylan, I am convinced of Dylan's elegance and power. :-)
>
>> Now some dislikes:
>>
>> - I don't like that Dylan doesn't have first-class interfaces like Java.
>
>Java's interfaces are broken, IMHO! Anything that allows naming clashes
>whilst disallowing code reuse is a real worst of both worlds solution.
>Protocols are used in Dylan instead, aren't they?
Any of the 'define protocol' stuff you might have seen is
just simple macrology I wrote to collate things that I think
belong in a first-class interface...
But I didn't mean Dylan interfaces should be like Java.
I meant that Dylan needs an object -- let's just call it an
"interface" -- that collects sets of generic functions into
this interface. You can then say a class implements [some
part of] an interface, and some compile-time (or run-time)
error gets signalled when you try to make an objects whose
interfaces are not fully implemented.
In a language with multi-method dispatch, this has some
complications...
Paul F. Dietz
> Personally, I think much of the use of macros in Lisp is to avoid
> using higher-order functions, or to work around non-generic functions
> in the CL spec. These are both more natural in Dylan. I don't want to
> over-sell, though: if you are writing something like Screamer, then CL
> is the only thing that can do it.
My major use is in compiling sets of patterns. This involves
nontrivial computation at compile time.
Paul
Frank A. Adrian
news:B5843163.3C3F%robm...@cwcom.net...
> Also, please don't post offensive nonsense attempting to conflate dislike
of
> fully-bracketed prefix syntax with homophobic and racial intolerance on
this
> list. It is singularly offensive and unproductive, and has no place
anywhere
> in the comp.* hierachy.
Yes, but it makes about as much sense as citing Pinker's and Chomsky's works
as a defense of saying that syntactic choices don't matter when applied to
artificial languages. Besides, USENET is often about being "singularly
offensive and unproductive" to win an argument (or haven't you been around
this neck of the woods for long? :-). If you want rhetorical purity in
search of truth, stick to moderated mailing lists.
faa
Eric Gouriou
Erik Naggum wrote:
[Some character attack on Scott McKay]
Erik,
Please keep your comments to yourself if you cannot manage
a minimal level of civility. These are not advocacy newsgroups
and your flames are uncalled for.
I tried to make this point privately and politely a few hours ago,
but my mail bounced. Either there was a technical problem or the
mail address you provide when posting is invalid.
For the record, I do not remember any post from Scott McKay where
he failed to be professional and helpful. I was expecting at least
as much from a Lisp advocate - due to the respect I have for Lisp
and its users.
Regards - Eric
--
Eric Gouriou egou...@cup.hp.com
Neel Krishnaswami
> > clashes whilst disallowing code reuse is a real worst of both
> > worlds solution. Protocols are used in Dylan instead, aren't they?
>
> Any of the 'define protocol' stuff you might have seen is
> just simple macrology I wrote to collate things that I think
> belong in a first-class interface...
>
> But I didn't mean Dylan interfaces should be like Java.
> I meant that Dylan needs an object -- let's just call it an
> "interface" -- that collects sets of generic functions into
> this interface. You can then say a class implements [some
> part of] an interface, and some compile-time (or run-time)
> error gets signalled when you try to make an objects whose
> interfaces are not fully implemented.
ISTM you can get most of the way there with modules already.
Do something like
define module foo-interface
create
bar, baz;
end module;
To implement the interface, define a new module that uses the
interface:
define module foo-implementation
use foo-interface, export: all;
end module;
And then if you don't implement both bar and baz in the module
foo-implementation, then you get a compile time error. You can
implement as much of the default protocol as necessary in
foo-interface, too.
I think the only thing Dylan really needs to make this a complete
solution is a way to parametrize modules, a la Standard ML's system of
functors. (Matthias Felleisen's units system for DrScheme might also
be worth stealing^H^H^Hlooking at, since it's basically functors for
dynamically typed languages.)
If you want to add types to the interfaces, then I think you'd have to
add parametric types (like Cecil, Eiffel, or GJ) to keep the interface
from becoming a stratjacket that blocks reuse.
Neel
Scott McKay
Paul F. Dietz wrote in message <395E8386...@interaccess.com>...
FWIW, this is the kind of thing I probably would do in Lisp
because (1) you get to use a very simple representation
for patterns (lists that you call 'read' on), and (2) you really
do get all of Lisp's run-time at compile-time. For me, this
sort of thing happens 1% of the time; I'm sure there are
people for whom the occurrence is much higher, and they
should keep using Lisp.
Just my opinion.
Scott McKay
Neel Krishnaswami wrote in message ...
>ISTM you can get most of the way there with modules already.
>
>Do something like
>
> define module foo-interface
> create
> bar, baz;
> end module;
>
>To implement the interface, define a new module that uses the
>interface:
>
> define module foo-implementation
> use foo-interface, export: all;
> end module;
>
>And then if you don't implement both bar and baz in the module
>foo-implementation, then you get a compile time error. You can
>implement as much of the default protocol as necessary in
>foo-interface, too.
>
>I think the only thing Dylan really needs to make this a complete
>solution is a way to parametrize modules, a la Standard ML's system of
>functors. (Matthias Felleisen's units system for DrScheme might also
>be worth stealing^H^H^Hlooking at, since it's basically functors for
>dynamically typed languages.)
>
>If you want to add types to the interfaces, then I think you'd have to
>add parametric types (like Cecil, Eiffel, or GJ) to keep the interface
>from becoming a stratjacket that blocks reuse.
That's quite clever! Good one!
But the reason I don't like it, is that it's not really first class.
Dylan modules are compile-time objects, and you can't ask
anything about them at run-time. That is, you can ask a class
what methods or superclasses it has. You can ask a G.F.
what methods it has. But you can't ask this sort of an interface
what GFs are in it. I think this sort of introspection could be
useful in a number of ways in real-worl applications.
(But I still think your idea is clever.)
Erik Naggum
| Perhaps you missed the "if" in that sentence?
| If you took the time to actually learn something about ...
I don't really think I "miss" what you communicate with your "if"s.
I perceive your intentions _very_ well, actually: You're here to
show off your _personal_ superiority to anyone who dares criticize
Dylan, and especially its syntax. By the insulted tone of your
messages and your constant insults hurled towards me, it is clear
that you have failed to deal with public comments in a public way,
but instead prefer to make this a personal issue. Coupled with your
lack of observation skills is your inability to deal with what
people are actually saying in preference to arguing against
incredibly cheap strawman arguments. This imparts an impression of
a _stale_ intellect in need of self-defense at the slightest hint of
serious criticism. I don't understand what you think you could
possibly _gain_ by this, however, but I'm sure _you_ think Dylan
will go out of this stupid activity of yours as a clear-cut winner.
Maybe it's time to re-evaluate your strategy? Maybe you just ought
to deal with the fact that not everybody shares your pathetically
unenlightened (why else resort to the stupidity I have spared you
from quoting in its entirety above) view on syntax?
| I find it a sign of general lack of insight that people think that
| syntax in most languages is the tough thing, because it isn't.
I quite agree -- it isn't, but nobody ever said anything about it
being "the tough thing", dude, so where _did_ you get that cheap
straman argument? (Does it feel good to knock down strawman
arguments, or does it leave you with an empty feeling inside which
fits the sheer lack of intellectual accomplishment? Feel free to
elaborate on your arrogance and inability to read what people
actually write to defend yourself.) If you aren't bright enough to
understand that objection to or love of syntax is not even related
to the effort required to learn or use the language, I have no
resepct for the rest of your similarly shallow opinions.
_If_ you took the time to read what people say instead of believing
they said what you can most easily argue (such as it is) against,
you might actually learn something, including differences in what
people prioritize and value, but I get the impression that it's been
a while since you learned anything from anyone other than yourself,
and I certainly won't waste any more of my time on you when you are
so demonstrably devoid of ability to deal with criticism.
| > Finally, a twist on the old "beware of programmers with screwdrivers":
| > Beware of programming language designers who show disdain for syntax.
|
| I have seen evidence of "disdain for syntax".
Precisely. If you "missed" a "no" in there, perhaps you are going
to deny that you wrote "syntax is trivial, get over it", too?
| Well, except from you, who evidently could not care less for the
| genuine effort spent making Dylan's infix syntax reasonable.
So you really are _personally_ offended, now, huh? Geez, get over
yourself. If you can't deal with negative comments on your work in
public, it would be a good thing for you to try to avoid defending
_yourself_. But why spend so much _genuine effort_ at something
that you claim is _trivial_ towards those who _don't_ like it? Just
how do you propose that I reconcile your clear disdain for syntaxes
(other than your own) with that whining about respecting your work?
I don't judge your efforts, dude, I judge the results, from a number
of aspects and values and premises of my own. You do not seem to
have any respect for any such other than precisely _your_ own, which
means that communication with you is a waste of time, just like
Dylan is a waste of time, from my point of view. At this point, I
think I have to tell you that you are free to be personally insulted
by my opinion, as well as free to act _professionally_ about a
difference in opinion that does not concern you personally at all.
Good luck with you language and your syntax and your efforts. Let's
just hope you do a better job communicating with someone who cares
what you think, _professionally_.
Rob Myers
which of course isn't any sort of runtime introspection, but works well in
some, well-defined situations where arbitary interfaces would otherwise be
used.
You do still have a slight bootstrapping problem in finding the protocol
method in the first place, though. :-)
- Rob.
Rob Myers
> Date: Sat, 1 Jul 2000 22:30:03 -0400 (EDT)
> To: info-...@ai.mit.edu
> Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
>
> as a defense of saying that syntactic choices don't matter when applied to
> artificial languages.
Having read Pinker (if anyone hasn't then do, The Language Instinct is
inspirational), I'd say that his accessible explanation of Chomsky's syntax
trees, deep and surface structure, and the process of creolization are very
relevent both to the creation of artificial syntax and its socialized use. A
language's "artificiality" has nothing to do with how applicable this is, if
anything, artfificial languages are easier examples (apart from Fortran :-).
BNF and Chomsky trees come from the same period and are mirror images of
each other to a degree. The contrast between deep & surface structure is
important in deflating a debate (however nonsensical) about infix vs. prefix
syntax for languages with fundamentally similar underlying systems.
When considering a language whose readability is entirely up to the user,
the structures that programmers use to achieve this must be regarded as
external to, and a socialized appropriation of, the syntax of the original
language and therefore a form of creolization. Machine-generated Lisp looks
very different from the elegance of good human-generated Lisp.
I don't see how immature attempts at demonization are more relevant than
this. In my 3 years on this newsgroup this is the closest I've seen to a
flamewar, and comp.lang.dylan isn't moderated.
- Rob.
António Nunes
fad...@uswest.net wrote on 7/1/00 7:22 PM:
> Yes, but it makes about as much sense as citing Pinker's and Chomsky's works
> as a defense of saying that syntactic choices don't matter when applied to
> artificial languages.
At least it is not destructive, it is an attempt at being constructive. And
it is certainly not offensive.
>Besides, USENET is often about being "singularly
> offensive and unproductive" to win an argument (or haven't you been around
> this neck of the woods for long? :-).
"Being about"? How does this ever win an argument? It doesn't! Just because
people do it does not mean it is a good thing, or something to be adopted.
Why be out to _winning_ an argument anyway? Tell your truth. I.e., the truth
as you see it. If you are on the right track you will "win" anyway. Even if
(some) others won't acknowledge that.
Being respectful to others, even when you think they are in the wrong or
disrespectful themselves, will much likely get you a lot further.
If you find yourself in disagreement build your "enemy" a Golden Bridge over
which to retreat. He (she) is much more likely to use it.
Cheers,
António
-----------------------------------------------------------
What you have inside you expresses itself through both your
choice of words and the level of energy you assign to them.
The more healed, whole and connected you feel inside,
the more healing your words will be.
--Rita Goswami
-----------------------------------------------------------
Simon Brooke
> "Johan Kullstam" <kull...@ne.mediaone.net> wrote in message
> news:m2og4ha...@euler.axel.nom...
> >> Syntax is trivial. Get over it.
>
> > it's not. i like the lisp syntax because of its clean look.
>
> That's the first time I've seen someone describe a profusion of parentheses
> as "clean".
Well, then, look again. LISP syntax results from the fact that LISP as
printed is a very nearly direct representation of the structures that
are created in the machine as it is read.
The representation of LISP structures which you conventionally edit in
a file has a uniquely direct and simple mapping onto the
representation which is held in core - a representation much more
direct, much more consistent and much more perspicuous than in any
other high-level language in common use. Furthermore, these structures
which you edit can be interpreted directly, and one of the great
benefits of Common LISP over earlier LISPs is it strives very hard to
ensure that the semantics of code when it is compiled are identical to
the semantics of the same code when interpreted.
It's this cleanness which makes it so much easier to 'think yourself
into the machine' in LISP than in other high-level languages.
--
si...@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
;; If God does not write LISP, God writes some code so similar to
;; LISP as to make no difference.
Frank A. Adrian
Chomsky (even before he moved into using linguistic semantics as a method
for analyzing politics), I would be surprised if either of them would
automatically give a pass to applying their work to artificial, (and
especially) primarily non-verbal languages. If that were so, we would not
be designing languages that had routine calls deeper than about three or
four levels (the deepest recursion normally occurs in languages); we'd be
limiting structures to no more than about six or seven elements (else, we'd
not be able to remember them all), etc. In short, the argument about
artificial languages even mapping onto cognitive structures the same way as
natural languages do seems quite specious to me. You, of course, are
entitled to your own viewpoint.
faa
Rob Myers <robm...@cwcom.net> wrote in message
news:B584F881.3CDF%robm...@cwcom.net...
> > From: "Frank A. Adrian" <fad...@uswest.net>
> > Date: Sat, 1 Jul 2000 22:30:03 -0400 (EDT)
> > To: info-...@ai.mit.edu
> > Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
> >
> > Yes, but it makes about as much sense as citing Pinker's and Chomsky's
works
> > as a defense of saying that syntactic choices don't matter when applied
to
> > artificial languages.
>
Frank A. Adrian
faa
P.S. Your response might also be viewed as an attempt to __win__ an
argument, too. Get over it.
António Nunes <to...@euronet.nl> wrote in message
news:B584A1EA.218B%to...@euronet.nl...
> in article Osz75.876$XU2.4...@news.uswest.net, Frank A. Adrian at
> fad...@uswest.net wrote on 7/1/00 7:22 PM:
>
> > Yes, but it makes about as much sense as citing Pinker's and Chomsky's
works
> > as a defense of saying that syntactic choices don't matter when applied
to
> > artificial languages.
Erik Naggum
| [Some character attack on Scott McKay]
Really? Well, this just goes to show some people can't read
anything eyond what they already believe in.
| Please keep your comments to yourself if you cannot manage a minimal
| level of civility.
Sure, I'll make sure to ask you every time I conclude that I do, and
you probably don't.
| These are not advocacy newsgroups and your flames are uncalled for.
And here I was thinking that what I replied to was a nasty attack,
but, hey, this just goes to show that some people will excuse juat
about anything if it comes from one of their own.
| I tried to make this point privately and politely a few hours ago,
| but my mail bounced. Either there was a technical problem or the
| mail address you provide when posting is invalid.
And this shows me that you aren't interested in being helpful or
constructive. _Any_ programmer knows that having some user draw
his own conclusions about what might be the problem is useless; the
_only_ useful thing to do is to report the problem _accurately_, and
since you don't do that with something so simple as an error message
from SMTP (I got a useful message from somebody else who experienced
the same problem), there's now _some_ reason not to trust whatever
else you conclude, too.
| For the record, I do not remember any post from Scott McKay where
| he failed to be professional and helpful.
Probably true, but I didn't respond to your memory. I responded to
an actual message from Scott McKay where he acts incredibly insulted
and retorts in worse kind. Most people are nice when they are safe
and not challenged in any way. What's important is what it takes to
make them feel unsafe or challenged and what they do then. Many
people are nice only because they suppress feelings of being unsafe
or challenged, and then they turn into veritable psychopaths when
they feel they have a "right" to cease being nice, such as when they
feel that empathy can be withheld. Don't be misled by someone's
history as being nice once they are being pushed -- Scott McKay has
obviously never had to defend Dylan and its syntax before, and he
turned into a nutcase as soon as he had to. _That's_ important.
| I was expecting at least as much from a Lisp advocate - due to the
| respect I have for Lisp and its users.
I'm not responsible for your desire to think in group terms.
António Nunes
on 7/2/00 10:13 AM:
> Most people are nice when they are safe
> and not challenged in any way. What's important is what it takes to
> make them feel unsafe or challenged and what they do then. Many
> people are nice only because they suppress feelings of being unsafe
> or challenged, and then they turn into veritable psychopaths when
> they feel they have a "right" to cease being nice, such as when they
> feel that empathy can be withheld.
So from the tone of your writings I guess you're describing yourself here
then :-)
I'm sorry to read you have such a negative view of human nature. People can
be so nice when treated with respect. This effect tends to be amplified when
they realise you continue to be respectful even when they know they are
being disrespectful to you. That's when they will often start to respect you
at a deeper level. (That's my reality anyway, hope it will be yours too one
day!).
Live well,
António
----------------------------------------
Disapprove of sin but not of the sinner!
----------------------------------------
Janos Blazi
> then :-)
>
> I'm sorry to read you have such a negative view of human nature. People
can
> be so nice when treated with respect. This effect tends to be amplified
when
> they realise you continue to be respectful even when they know they are
> being disrespectful to you. That's when they will often start to respect
you
> at a deeper level. (That's my reality anyway, hope it will be yours too
one
> day!).
>
> Live well,
> António
Isn't it wonderful how we all teach each other how to behave? Maybe we
should consider changing the name of the NG (I hope the second 'we' is not
an insult to anybody).
J.B.
Brian Rogoff
On Sat, 1 Jul 2000, Scott McKay wrote:
> OK, I'll tell you some of the things I like about Dylan, and some
> of the things I like better in Lisp. First the likes:
>
> - I like Dylan's type system. I like that the "built-in" types fix into
> the type system in a clean and consistent way. I like that you
> can use it "typeless" but can then clamp down the types to get
> better code, and more importantly, better compile-time error
> detection. Going back to Lisp makes me fell butt-naked on the
> type safety front; as the static-type people have been saying
> for years, a lot of errors really are type errors, and Dylan does
> a good job catching these.
Interesting. I like statically typed languages too, just not the popular
ones
> - I am surprised to say that I have come to like the infix syntax.
> For one, using type decls in Dylan is a lot easier than in Lisp,
> and a lot more readable, too. Don't delude yourself into thinking
> Lisp has "no syntax" (as many people claim); it does, but it's
> just harder to see.
People like what they get used to. I even know people who like Perl! I
find Dylan syntax close enough to a language I use and like (Ada 95) that
I agree with you. If I were using Lisp or Scheme heavily I might be in the
other camp. In any case I agree with you that its not something to get
hung up on. I also agree with Frank Adrian that programming languages are
*NOT* like spoken (or signed :-) human languages. If you read Pinker, I'm
surprised you haven't reached the same conclusion.
> - I like Dylan's hygienic macro system. If we adopted Keith
> Playford's work on procedural macros, Dylan's macros would
> be very nearly as powerful as Lisp's, and many of Lisp's
> pitfalls would fall away.
Could you provide a pointer to more information on this? I haven't been
able to find documentation on it at all. Are either of the two
implementors considering adding this to their implementations?
... snip...
> - Believe it or not, I now prefer the simpler method combination
> in Dylan.
I recall reading some time ago about a slightly "better" system for
Dylan which is pretty close to what is there now. Maybe if there is a
new version of Dylan...
> Now some dislikes:
...snip...
My biggest gripe right now is the lack of implementations. The commercial
Dylan is for an OS I don't care about, and the free one is a bit too
heavyweight. I'd prefer a "tractable" Dylan implementation for
experimentation, even if the code it generated were an order of magnitude
slower than C. As an example of what I mean, consider the OCaml compiler,
which is relatively small, and compiles on every Unix out there with
minimal effort, and generates very good code! I'm not criticizing the
Gwydion developers here, its just that they have very different
priorities.
-- Brian
Erik Naggum
| So from the tone of your writings I guess you're describing yourself
| here then :-)
You need to guess less and think omre.
| I'm sorry to read you have such a negative view of human nature.
You need to guess less and think more.
| People can be so nice when treated with respect.
Now, how does that _really_ differ from what I said?
| This effect tends to be amplified when they realise you continue to
| be respectful even when they know they are being disrespectful to
| you.
Well, I think this is an excellent idea. However, in keeping with
the very simple concept of "puting your money where you mouth is", I
wait for those who proclaim a principle to apply it to themselves.
Anybody can expound on some principle he wants _others_ to apply,
but if you refrain from applying it to yourself, you communicate a
quality of the advice given that is extremely unflattering: If it
isn't good enough for yourself, why should anyone take your advice?
| That's when they will often start to respect you at a deeper level.
| (That's my reality anyway, hope it will be yours too one day!).
It amazes me that you start off your "respectful" message with a
disrespectful grin, instead of just _doing_ what you recommend.
Such hypocrisy is utterly _disgusting_ to watch. Just quit it.
Rob Myers
> Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
>
a bit too heavyweight.
If you have a Mac, there's a CodeWarrior plugin that makes life with d2c a
lot easier, and even on UNIX the biggest step to using d2c is installation.
If you use make-dylan-app and work with the generated code, you just need to
call make to compile.
Please don't be put off by how industrial-strength d2c has been designed to
be, it's really very easy to get started with. The Gwydion Maintainers are
very happy to answer queries and provide help, and always listen to
constructive suggestions (and offers of assistance :-).
- Rob
Gregory T. Sullivan
Neel> Scott McKay <s...@mediaone.net> wrote:
>> Rob Myers wrote in message ...
>> >
>> > Java's interfaces are broken, IMHO! Anything that allows naming
>> > clashes whilst disallowing code reuse is a real worst of both
>> > worlds solution. Protocols are used in Dylan instead, aren't they?
Neel> ISTM you can get most of the way there with modules already.
Neel> Do something like
Neel> define module foo-interface
Neel> create
Neel> bar, baz;
Neel> end module;
Neel> To implement the interface, define a new module that uses the
Neel> interface:
Neel> define module foo-implementation
Neel> use foo-interface, export: all;
Neel> end module;
One shortcoming of Dylan's module system is that you cannot be more
specific than names -- i.e. you can't specify the type signature of
methods or generic functions at the module level. At least Java
interfaces allow you to specify the names _and_ types of methods that
must be implemented.
Having type signatures as part of the module system would enable
better cross-module type checking and better optimization.
--
Greg gr...@ai.mit.edu (617)253-5807
Sullivan http://www.ai.mit.edu/~gregs/
Rob Myers
> Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
>
>
> | People can be so nice when treated with respect.
>
> Now, how does that _really_ differ from what I said?
Because he's not suggesting that the principle applies only to himself?
Please, please go away.
- Rob.
Scott McKay
I've trimmed all of Erik's lame attempts to hurl insults at to spare
everyone the trouble of re-reading them. Since Erik's return mail
address appears not to work, it's not actually possible to address
any of this in private.
>| Well, except from you, who evidently could not care less for the
>| genuine effort spent making Dylan's infix syntax reasonable.
>
> So you really are _personally_ offended, now, huh? Geez, get over
> yourself. If you can't deal with negative comments on your work in
> public, it would be a good thing for you to try to avoid defending
> _yourself_. But why spend so much _genuine effort_ at something
> that you claim is _trivial_ towards those who _don't_ like it? Just
> how do you propose that I reconcile your clear disdain for syntaxes
> (other than your own) with that whining about respecting your work?
For the record, I had no part in designing Dylan's infix syntax. It was
a fait accompli by the time I started doing any work on Dylan. I should
have thought that my comment earlier in this discussion about how I
was surprised to discover that I liked the infix syntax would have clued
people in to that fact. So I don't take any personal offense at all.
Erik Naggum
| Since Erik's return mail address appears not to work, it's not
| actually possible to address any of this in private.
This is really interesting. I have logged an attempt to send mail
from s...@mediaone.net via chmls06.mediaone.net [24.147.1.144] port
42508 at 2000-07-01 23:40:41.218 UTC, and your posted this silliness
2000-07-03 00:08:47 UTC, more than 24 hours later. This is quite
telling, actually, since you blithely assume that a problem properly
reported (which a Lisp user did to another address (which anyone who
knows about WHOIS would have found in no time), but another Dylan
user whined about it in a very useless way in public) would not get
fixed for 24 hours, even when it concerns such a terribly important
basic network service as e-mail.
With such an attitude towards software problems, nobody should care
what that person might have to say about programming _languages_.
Erik Naggum
| Please, please go away.
Is it common and accepted practice among Dylan users to engage in
back-stabbing by removing the newsgroups people read? Furrfu!
However, I won't rat on the Dylan users who informed me about this.
Who _knows_ that you guys might do to your own...
Tim Bradshaw
> Hey, look, if the only thing that Lispers care about is having
> Lisp syntax, then they are as closed-minded as the C and Java
> communities. Syntax is trivial. Get over it.
I kind of agree, but the world doesn't seem to: look at XML. One of
the great advantages of Lisp syntax, I think, is that it gives you
everything useful that XML does, without the nauseating complexity.
Of course Lisp somehow managed to fail to take advantage of this, so
people are now busy implementing XML interfaces to Lisp, but that's
just the usual Lisp `x, 4 years too late' syndrome.
--tim
Rob Myers
shows (amongst other things) Erik's backup email address as being:
> From: Erik Naggum <er...@naggum.net>
> Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
> Is it common and accepted practice among Dylan users to engage in
> back-stabbing by removing the newsgroups people read? Furrfu!
Removing the Lisp newsgroup was just a courtesy to your long suffering
audience there. The semantic drift neccessary to construe this as
backstabbing is PhD material.
> However, I won't rat on the Dylan users who informed me about this.
> Who _knows_ that you guys might do to your own...
Since you ask, we usually beat traitors with long wooden clubs whilst
force-feeding them olive oil. I don't think being able to read To: lines
quite qualifies, though.
- Rob.
Jens Kilian
> That's the first time I've seen someone describe a profusion of parentheses
> as "clean".
Hint: Write down a grammar for Lisp. Write down a grammar for Dylan (or C,
or C++, etc.). Compare their sizes.
HAND,
Jens.
(Oh, and good luck with the C++ grammar ;-)
--
mailto:j...@acm.org phone:+49-7031-464-7698 (HP TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-464-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
Rob Myers
> At least Java
> interfaces allow you to specify the names _and_ types of methods that
> must be implemented.
Note the "must be implemented". :-)
> Having type signatures as part of the module system would enable
> better cross-module type checking and better optimization.
Type and other information is exported and used "behind the scenes" by the
compiler, it's just hidden from the programmer. Information hiding can be
good.
The programmer knows from the name whether a given name is a $constant, a
$variable or a <class>, and the signature or layout of these can be
determinded from the documentation. And the compiler will tell you if a
method isn't congruent.
In Java, you still have to read the sources or the JavaDoc to find out about
a method. Dylan is no different, it just has a cleaner and higher-level
syntax for managing name import and export. And it allows code reuse. ;-)
- Rob.
--
Rob Myers - ro...@h2g2.com H2G2 - http://www.h2g2.com/
"Don't talk to sociologists. Social practice has no sociological
content."A&L
http://www.robmyers.org/ http://www.gwydiondylan.org/
Erik Naggum
| Also, please don't post offensive nonsense attempting to conflate
| dislike of fully-bracketed prefix syntax with homophobic and racial
| intolerance on this list. It is singularly offensive and
| unproductive, and has no place anywhere in the comp.* hierachy.
Please don't post your back-stabbing crap where your victim doesn't
read it. [And here I was probably missing which article one Dylan
user wanted to alert me to. Sorry about that -- but a quick scan of
your _friendly_ newsgroup revealed a _lot_ of crap from Rob Myers.]
Such is considered very bad behavior everywhere but comp.lang.dylan,
where I'm quickly learning about the very special rules which apply
only to what Dylan users are allowed to do to those who express any
opinion contrary to their own, and if they happen to like Lisp, no
holds are barred, fire at will. It's most amazing. PhD material,
I'm sure.
Dylan must be _such_ a pathetic loser language to have so many so
incredibly defensive people "fighting" for it. Furrfu!
I'm _so_ happy I didn't waste any time working with the Gwydion
project back in 1993/4, despite generous and interesting offers.
They just had "no future" written all over them, and I hate it when
I'm right about apparently good things that fail because of stupid
and destructive people.
Failed languages never die, however, they just attract bad people.
This "Dylan experience" sures shows what kind of people Dylan keeps
attracting.
Rob Myers
> Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
> [Regarding d2c]
> Surely dynamic linking should be able to reduce the size
> of the executables but this situation doesn't inspire confidence.
I think we have dynamic linking working on most platforms now. Some of us
are working on executable / library size at the moment, but the Dylan
runtime will always be larger than the C++ one. :-)
> I think its implementors were able to get there by going the route of
> bytecode compilation, and only later to build an optimizing native code
> compiler.
Gwydion Dylan started out with the Mindy bytecode system. You may like to
try this, I think it's in the standard distribution, but it doesn't have
Macro support. :-(
> Sure, I installed it easily on Linux as an RPM, and I can use it to play.
It's good to hear that.
> I wouldn't try to introduce it at work, even though I like the language.
At the moment we wouldn't expect you to, but I understand that real-world
projects have been completed in Gwydion Dylan.
We're improving the compiler constantly, and working on new features like
DUIM and an industrial-strength FFI. Try us again soon. :-)
- Rob.
Brian Rogoff
> > From: Brian Rogoff <b...@shell5.ba.best.com>
> > Subject: Re: C# is not Dylan (was: Re: C# : The new language from M$)
> >
> > My biggest gripe right now is the lack of implementations. ... the free one is
> a bit too heavyweight.
>
> If you have a Mac, there's a CodeWarrior plugin that makes life with d2c a
> lot easier, and even on UNIX the biggest step to using d2c is installation.
I think you misunderstand when I say "heavyweight". Even for small
programs d2c takes a relatively long time to run, and generates huge
executables. Surely dynamic linking should be able to reduce the size
of the executables but this situation doesn't inspire confidence.
I'm comparing with OCaml, which as I stated earlier, was a breeze to
install from source on Unix, and runs amazingly fast, even when generating
optimized code. I actually use OCaml at work for production code; this
ease-of-installation/speed-of-compilation/speed-and-size-of-generated-code
combination is what I mean by "lightweight".
I think its implementors were able to get there by going the route of
bytecode compilation, and only later to build an optimizing native code
compiler. The other compilers I have used which go the "compile to
C" route, Sather and Mercury, also seem to be rather heavyweight. Mercury
at least has an easy (but very slow) install and generates amazingly small
executables. I haven't used Gambit-C or Bigloo, maybe these do better.
> If you use make-dylan-app and work with the generated code, you just need to
> call make to compile.
> Please don't be put off by how industrial-strength d2c has been designed to
> be, it's really very easy to get started with. The Gwydion Maintainers are
> very happy to answer queries and provide help, and always listen to
> constructive suggestions (and offers of assistance :-).
Sure, I installed it easily on Linux as an RPM, and I can use it to play.
I wouldn't try to introduce it at work, even though I like the language.
-- Brian
Kim Barrett
>One shortcoming of Dylan's module system is that you cannot be more
>specific than names -- i.e. you can't specify the type signature of
>interfaces allow you to specify the names _and_ types of methods that
>must be implemented.
Speaking as one of the designers of the existing module system, I strongly
disagree with you on this. It was in fact completely intentional that Dylan
module definitions *don't* contain such information. Dave Moon explained
it well, in a long-ago (3/3/94) email discussion:
Dylan does not require programmers to make a textual copy of portions
of the definitions of items exported by a module, like a C header file
or an Ada package declaration. In my opinion Dylan modules still have
a well-defined interface; the difference is that we assume there will
be the obvious development tools for printing out that interface,
instead of requiring programmers to pretend to be tools and copy text
from one file to another. (Except of course Dylan still requires
programmers to copy the -names- of the exports from their definitions
into the define module statement. We haven't thought of a good way to
avoid that.)
As Rob Meyers (7/3/00) noted:
In Java, you still have to read the sources or the JavaDoc to find out
about a method. Dylan is no different ...
>Having type signatures as part of the module system would enable
>better cross-module type checking and better optimization.
Having type signatures as part of the module system should do nothing to
improve cross-module type checking and optimization. The development
environment and delivery model assumed by the existing specification of
module defining forms is that part of a library that one can compile code
wrto and link to is some information provided by the compiler when it
processed that library. One of the things that should be in that
information is the stuff needed to compile more efficiently references
to the library's bindings. Type information is only one of many bits that
ought to be placed there, including such things as inlining information,
sealing, expected code size (might be used for automatic inlining
decisions), expected runtime cost (again useful for inlining), and so on.
Much of that can't reasonably be generated by the programmer, and really
needs to be done by the compiler. Given the existence of this repository,
it seems pretty silly to make the programmer maintain two independent
copies of the type information when the compiler could just as easily
generate the needed information by processing the definitions instead of
comparing the two copies and complaining about the occasional mismatch.
Gregory T. Sullivan
newsgroup, and who are not familiar with the "open" nature of usenet,
I thought it might be timely to post a few remarks:
(1) info-dylan is NOT moderated. Anyone has the right to post
anything they want. Posting to info-dylan _is_ restricted to
subscribers, but there is no analogy w.r.t. posting to
comp.lang.dylan. Also, though posting to info-dylan is restricted
to subscribers, the content is not restricted.
(2) it is inevitable, given the openness of usenet, that there will be
posts that are off topic, objectionable, insulting, etc.
Sometimes the offense is by a well-meaning but naive poster who
will respond to constructive coaching on "netiquette". Often,
however, that is not the case. In that case, there are two
strategies that I find useful:
(a) ignore -- usually the best policy is to simply ignore the
offensive poster. Since attention is what they crave, they
will usually move on after a while.
(b) kill files -- most decent newsreaders (I use the gnus
package under emacs) provide a "kill file" capability.
Adding an address to your kill file will conveniently shield
you from future rantings by the specified user.
Welcome to the future!
Hugh Greene
saying "Dylan's module system should (not) do X", I like to see people
(including me ;-) say "Here's something interesting you could do, X, and
here's why you'd want to do it." We might find we have requirements best
satisfied by more than one thing, for example. I hope I remember to
stick to my own suggestion; others are free to ignore it, of course ;-)]
On Mon, 3 Jul 2000, Kim Barrett wrote:
> Greg Sullivan (7/2/00) said:
> >One shortcoming of Dylan's module system is that you cannot be more
> >specific than names -- i.e. you can't specify the type signature of
> >methods or generic functions at the module level. ...
Why, specifically (and if possible with example scenarios), would you want
to do this? (I'm not suggesting there's no reason -- I give one below --
I just wonder what ones you have.)
> Speaking as one of the designers of the existing module system, I
> strongly disagree with you on this. It was in fact completely
> intentional that Dylan module definitions *don't* contain such
> information. Dave Moon explained it well ...
>
> Dylan does not require programmers to make a textual copy of portions
> of the definitions of items exported by a module, like a C header file
> or an Ada package declaration. In my opinion Dylan modules still have
> a well-defined interface; the difference is that we assume there will
> be the obvious development tools for printing out that interface,
> instead of requiring programmers to pretend to be tools and copy text
> from one file to another. (Except of course Dylan still requires
> programmers to copy the -names- of the exports from their definitions
> into the define module statement. We haven't thought of a good way to
> avoid that.)
Avoiding duplication is a very good principle, I agree. It occured to me
that one way to avoid repeating names in module definitions might be to
allow an "exported" modifier on definition macros. The problem I saw with
this is that:
- these definitions would presumably be in a source record in some
module, "foo", from which you want them exported;
- the module definition for "foo" has to be in a source record in some
*other* module;
- code produced by macro expansion will be in the same module as the
macro call, so there's no way to create or add to a module definition
for some defining form from the expansion of that form.
I suppose one way round this, for future consideration, would be to have
some "special form" like "export(name, from-module)" which would be
effectively used by the built-in defining macros and could be used by
user-defined defining macros.
The existing module defining form might still exist in a modified form
which was mostly/only for listing imported (and re-exported?) modules and
names.
Problems ...
- I'm omitting consideration of the "create" clause, so this might be
unworkable if you looked more closely.
- I can imagine confusions (for a human reader, not for the compiler)
arising from "exported" being applied to some methods of an implicit
generic but not others. My interpretation for this would be that a
generic is exported if any of its methods is; but then a casual reader
might see an "unexported" method and jump to the wrong conclusion. An
alternative would be to require explicit generics if you want to
export things, but that would be a real pain.
- I also think it's a bit ugly :-(
> As Rob Meyers (7/3/00) noted:
>
> In Java, you still have to read the sources or the JavaDoc to find out
> about a method. Dylan is no different ...
>
> >Having type signatures as part of the module system would enable
> >better cross-module type checking and better optimization.
>
> Having type signatures as part of the module system should do nothing to
> improve cross-module type checking and optimization. The development
> environment and delivery model assumed by the existing specification of
> module defining forms is that part of a library that one can compile code
> wrto and link to is some information provided by the compiler when it
> processed that library. ...
Right. So far, the Fun-O compiler (IIRC, and not all of this may be
user-visible) allows you to assume as much as possible (i.e., the exact
type) or as little as possible (i.e., everything is assumed to be <object>
at compile time and only checked at runtime), both within and across
module (or just library?) boundaries.
Something else you might want to do would be to provide type (and other)
information more specific than just "<object>" but less specific than
what's actually in the source you're compiling against. A reason I can
imagine for this is if you want to be able to swap implementations between
runs without recompiling (assuming dynamic library linking or similar) but
without the efficiency penalties of deferring all type-checking to
runtime.
I think most of this goal can be accomplished by having an interface
library (assuming OS-specific dynamic libraries contain one or more
complete Dylan libraries). This would define a number of open (abstract,
uninstantiable) classes, open generics (with no methods) and variables
(with some dummy initial value) and a client library would be compiled
against it in some mode assuming as much type information as possible.
Each of several (mutually exclusive) implementation libraries would be
similarly compiled against it and would add concrete subclasses (probably
sealed and possibly with "down-delegating" make methods for the abstract
classes), methods (covering the whole GF domain and probably sealing
everything) and assignments to the module variables. (The sealing may not
affect efficiency from client to implementation but should at least help
within the implementation library.)
In this setup the implementation can't offer the client "swappable"
"define function"s and "define constant"s -- but I can't think what a
compilation of the client could do with those knowing their signature
(respectively, type) but not their value. (Maybe someone else can?)
(If you want several implementation libraries to be loaded *together* you
probably need to use the Bridge design pattern -- more details available
on request.)
I wondered whether a bit more efficiency could be gained if there were
some way to do sealing in Dylan such that it came into effect at "dynamic
link time" or, in Dylan terms, at the point where all top-level
definitions have come into effect but before any top-level expressions are
evaluated. I imagine this hypothetical ability allowing one to add
sealing definitions to the interface library, enabling the client to do
more optimisation. However, I can't think what it could do, if it knows
domains / class trees are sealed but doesn't know what's in them. (Then
again, I'm no compiler guru, so maybe someone else can ;-) Also, the DRM
already carefully defins the point in time at which definitions come into
effect, with respect to top-level forms, and not all textual orderings may
be acceptable on any given implementation; this makes me suspect that
"sealing at load time" would be even trickier than I imagine :-) So, this
doesn't seem all that useful after all.
Problems ...
- Current Dylan implementations don't make it easy for (non-guru) users
to deliver these combinations of Dylan libraries in different packages
of OS-specific dynamic libraries which suit everyone ;-)
- We might need/want some utility macros to make the sealing and
down-delegating in implementation libraries textually concise.
(Shouldn't be a problem, really, just a "to do".)
- There may be more undesirable repetition of information if the
different implementations don't differ "much" in type, e.g., if most
GF methods added differ between implementations mostly in their
bodies, not their signatures. However, my instinct (not thinking too
hard, at this time of night ;-) is that this is just the trade-off you
risk for having a flexible framework. (And if the signatures don't
differ at all, and you have some way to prevent inlining, you could
probably just get away with several swappable implementations and no
separate interface library.)
> .... Given the existence of this repository, it seems pretty silly to
> make the programmer maintain two independent copies of the type
> information when the compiler could just as easily generate the needed
> information by processing the definitions instead of comparing the two
> copies and complaining about the occasional mismatch.
Right. Dylan is a powerful language but it assumes some of the complexity
is transferred to a fairly clever development environment, in terms of the
information it can provide to the user. However, this doesn't have to be
a spangly GUI; it could mostly be a Dylan analogue of javadoc and dump
documentary summaries to text/html files, as an optional part of
compilation.
So, despite having argued in favour of this idea of "interfaces as
type-annotated module export lists" in the past, I'm tempted to conclude
that it doesn't buy one that much. I still think "interfaces as
type-parameterised groups of arbitrary Dylan objects" could be very
useful, but that's a ramble for another day ... %-) (And, as ever, I
could be persuaded otherwise.)
Hugh
Jon S Anthony
>
> - I like Dylan's type system. I like that the "built-in" types fix into
> the type system in a clean and consistent way. I like that you
> can use it "typeless" but can then clamp down the types to get
> better code,
Up to here, I don't believe there is any real difference to CL. Not
that you are comparing...
> and more importantly, better compile-time error
> detection. Going back to Lisp makes me fell butt-naked on the
> type safety front; as the static-type people have been saying
> for years, a lot of errors really are type errors, and Dylan does
> a good job catching these.
This I simply no longer agree with. Well, for all I know _you_ do
feel "butt-naked" w/o static typing, but I don't believe there is any
significant objective reality to the proposition that it really helps
find errors or helps clear up design issues, or whatever.
I used to believe that it _did_ help a lot with errors (well, more or
less), and it is certainly true that you can give some pretty good
arguments that static typing _should_ make a difference here, but in
practice it turns out to mean more or less nothing. At least in our
experience. Having built some large (and more importantly, _complex_)
stuff in statically typed languages (Ada95, Java) as well as Common
Lisp, Common Lisp turns out to be significantly better wrt catching
and eliminating errors. This is even more true wrt "real" bugs -
logic errors. I actually kept a log on the number of errors that a
statically typed language would have saved me from at runtime (note:
this is the only real difference - it is important to realize that the
error _will_ be caught with dynamic typing just as well as with static
typing).. This currently amounts to 3 simple typos in 2MB of source.
If you are working on true safety critical and/or mission critical
control software, then the very small potential advantage of static
typing preventing a runtime error is clearly still worth it. However,
in anything else it is more than made up for by the true dynamicism,
flexibility, and inherently easier to test (and thus more likely to be
fully tested) approach provided by environments like Common Lisp.
> - I am surprised to say that I have come to like the infix syntax.
> For one, using type decls in Dylan is a lot easier than in Lisp,
I don't think this has anything to do with "infix syntax".
> - I like Dylan's hygienic macro system. If we adopted Keith
> Playford's work on procedural macros, Dylan's macros would
> be very nearly as powerful as Lisp's,
Presumably this means these would allow complete use of the entire
language and any user defined functions and macros for processing at
compile time. However, that didn't happen and (even though you try to
claim otherwise) it is likely that the effort to make this all work
smoothly with the significantly more difficult syntax had a lot to do
with this.
> not to patch it up with kludgy method combination. If you think
> you haven't used kludgy method combination, I bet you're wrong.
I haven't, and you'd be wrong. If there is any inherent problem here
it is that people use OO for things for which it shouldn't be.
/Jon
--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
Johan Kullstam
> "Johan Kullstam" <kull...@ne.mediaone.net> wrote in message
> news:m2og4ha...@euler.axel.nom...
> >> Syntax is trivial. Get over it.
>
> > it's not. i like the lisp syntax because of its clean look.
>
> That's the first time I've seen someone describe a profusion of parentheses
> as "clean".
lisp only looks longwinded and confusing on the surface.
gareth mccaughan had an excellent post about this
http://x71.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=578557750&CONTEXT=962663586.1539506178&hitnum=0
the parens take up very little room and don't get in your way. notice
how much more descriptive words lisp allows compared to the required
boilerplate of C/C++. with-open-file only looks long compared to
fopen, but the former does *so much more*.
in general, i find that lisp programs are *much* shorter and more
concise than in other languages. this is least apparent with short
program stumps like in the above post. the gap is very wide once you
program anything of even modest size.
i admit that the boilerplate mishmash of parens, braces and semicolons
can help a human find their way, e.g., i think C's for (;;){} is
easier than lisp's (do ()()()). however, C's semi-random assortment
of statement seperators comes at a very high cost. look how feeble
C's macros are compared to lisp. do not be penny wise and pound
foolish.
imho the simple syntax of lisp is a *huge* advantage for lisp.
--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
Don't Fear the Penguin!
vsync
> http://x71.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=578557750&CONTEXT=962663586.1539506178&hitnum=0
Just FYI, this can be shortened to:
http://www.deja.com/=dnc/getdoc.xp?AN=578557750
--
vsync
http://quadium.net/ - last updated Fri Jun 30 22:55:16 MDT 2000
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil)))
vsync
> the parens take up very little room and don't get in your way. notice
> how much more descriptive words lisp allows compared to the required
> boilerplate of C/C++. with-open-file only looks long compared to
> fopen, but the former does *so much more*.
>
> in general, i find that lisp programs are *much* shorter and more
> concise than in other languages. this is least apparent with short
> program stumps like in the above post. the gap is very wide once you
> program anything of even modest size.
This example is especially good. My main programming language for
some time was (and still is, but not by choice) Java, and although its
exception handling does help localize errors and error checking, I
always hated its verbosity and seeming kludginess. Often, it seemed
like every tenth line was either a try or a catch.
Things such as with-open-file almost frightened me at first; they
seemed too good to be true. And then I needed to use unwind-protect
in some of my own code. Wow. I suspect I haven't even scratched the
surface yet, but Lisp's way of doing things is so much nicer to work
with.
David Hanley
Scott McKay wrote:
> Christopher Browne wrote in message ...
>
> >
> >Ah, but when you're trying to sell _Dylan_, when it has _no_ market,
> >having a community of Lisp adopters might have been a Good Thing, and
> >might well have represented a lot more than 1% of the market _for
> >Dylan_.
>
> Hey, look, if the only thing that Lispers care about is having
> Lisp syntax, then they are as closed-minded as the C and Java
> communities. Syntax is trivial. Get over it.
Actually, I thought that the simple, regular syntax greatly assists in
creation
of source-code transforming macros, which is one of the big plusses
of LISP.
dave
Timothy Guimond
"Erik Naggum" <er...@naggum.net> wrote in message
news:31716338...@naggum.net...
Rainer Joswig
<j...@synquiry.com> wrote:
> This I simply no longer agree with. Well, for all I know _you_ do
> feel "butt-naked" w/o static typing, but I don't believe there is any
> significant objective reality to the proposition that it really helps
> find errors or helps clear up design issues, or whatever.
It might be interesting to compare this with "Extreme Programming"
(XP), which originated in the Smalltalk camp and describes
how you achieve high productivity and quality using a dynamic
development "environment".
--
Rainer Joswig, BU Partner,
ISION Internet AG, Steinhöft 9, 20459 Hamburg, Germany
Tel: +49 40 3070 2950, Fax: +49 40 3070 2999
Email: mailto:rainer...@ision.net WWW: http://www.ision.net/
Erik Naggum
| Are you a typical representative of the lisp community?
No, of course not. Are _you_ typical of _any_ groups you might be
associated with accidentally or on purpose? Do you ask the same
question of somebody whom you don't like and who happens to be of a
particular sex or gay or black or from a particular country? Rob
Myers, probably typical of the Dylan community in your eyes, has
even said such moronic (rhetorical) questions as yours have no place
here, since they _are_ exactly what racism is based upon.
I guess the best commonality among vocal Dylan newsgroup members is
a sheer lack of a working brain, but other than that, I hope you are
just as unique and diverse as any other group. However, it amazes
me how some of you choose to portray yourself as so utterly devoid
of intelligence as the quoted question clearly indicates.
Neel Krishnaswami
>
> Are you a typical representative of the lisp community?
>
Erik is exceptional both in terms of technical competence and the
poisonous strength of his bile. You could do much worse than to
ignore his flames utterly and carefully read everything else by him.
If this discourages you, consider that this is an improvement over
real life: on Usenet you can in fact totally compartmentalize your
relationships with people. IOW, take the good and killfile the bad,
selectively.
Neel
Neel Krishnaswami
> "Michael T. Richter" <m...@ottawa.com> writes:
> > That's the first time I've seen someone describe a profusion of parentheses
> > as "clean".
>
> or C++, etc.). Compare their sizes.
FTR, I disagree with Michael, but your response doesn't have the
answer you apparently think it does: Dylan is the smallest of all of
these -- Dylan plus its special forms is substantially less complex
than Common Lisp and its special forms.
Now to profit maximally from this observation, I recommend comparing
the two with a critical eye, keeping in mind that both languages were
designed by smart and knowledgeable people. I learned a lot from this
very exercise; the two languages are close enough in design space that
their differences reveal a lot about the fine structure of language
design. (Haskell vs. ML is another good pairing. I haven't found
anything to compare Smalltalk to yet, though.)
Neel
Scott McKay
Kim Barrett wrote in message <2000070319...@life.ai.mit.edu>...
[Quote from Moon]
> Dylan does not require programmers to make a textual copy of portions
> of the definitions of items exported by a module, like a C header file
> or an Ada package declaration. In my opinion Dylan modules still have
> a well-defined interface; the difference is that we assume there will
> be the obvious development tools for printing out that interface,
> instead of requiring programmers to pretend to be tools and copy text
> from one file to another. (Except of course Dylan still requires
> programmers to copy the -names- of the exports from their definitions
> into the define module statement. We haven't thought of a good way to
> avoid that.)
If you want to declare an "interface" in Dylan right now, you copy the
names of functions into a module definition, and you copy the signature
from some set of methods into a 'define generic' form. So Dylan does,
in fact, require you to make "a textual copy of portions of the definitions
of items exported by a module" if you want to collate this into an
"interface".
And you get to copy a little bit into one place, and another bigger bit
into another place. So I find Moon's argument less than persuasive...
I have in the past proposed deprecating 'define generic' and augmenting
'define module' to take its place. I haven't thought about this for a year,
and I haven't written a real proposal, so don't bother to quiz me on it.
Reini Urban
>Johan Kullstam <kull...@ne.mediaone.net> writes:
>> http://x71.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=578557750&CONTEXT=962663586.1539506178&hitnum=0
>
>Just FYI, this can be shortened to:
> http://www.deja.com/=dnc/getdoc.xp?AN=578557750
I'd prefer: http://www.deja.com/=sr/getdoc.xp?AN=578557750&fmt=text
=sr has the threaded format template, =dnc the search stuff below.
(as text format both do the same of course)
--
Reini
Christopher Browne
>Jens Kilian <Jens_...@agilent.com> wrote:
>> "Michael T. Richter" <m...@ottawa.com> writes:
>> > That's the first time I've seen someone describe a profusion of parentheses
>> > as "clean".
>>
>> Hint: Write down a grammar for Lisp. Write down a grammar for Dylan (or C,
>> or C++, etc.). Compare their sizes.
>
>FTR, I disagree with Michael, but your response doesn't have the
>answer you apparently think it does: Dylan is the smallest of all of
>these -- Dylan plus its special forms is substantially less complex
>than Common Lisp and its special forms.
That's an interesting claim; I suspect that down that road lies some
unfortunately impressive flame wars, to go alongside whatever insights
come up.
>Now to profit maximally from this observation, I recommend comparing
>the two with a critical eye, keeping in mind that both languages were
>designed by smart and knowledgeable people. I learned a lot from this
>very exercise; the two languages are close enough in design space that
>their differences reveal a lot about the fine structure of language
>design. (Haskell vs. ML is another good pairing. I haven't found
>anything to compare Smalltalk to yet, though.)
Unfortunately, "comparative programming languages" tends towards
threads that resemble "capitalism versus communism." While there
are probably some useful insights in such discussions, it is unlikely
that the discussion will remain grounded in any common understandings,
as there are _dramatically_ different attitudes towards them. There
are enough "bigots" out there, whether relating to political systems
or to programming languages, that the discussion is likely to go down
in flames...
--
aa...@freenet.carleton.ca - <http://www.ntlug.org/~cbbrowne/linux.html>
Flashlights are cases for holding dead batteries.
Janos Blazi
Johan Kullstam <kull...@ne.mediaone.net> schrieb in im Newsbeitrag:
> [...]
> lisp only looks longwinded and confusing on the surface.
>
Well, wjen I started learning Lisp last year I thought than the parentheses
will become a nightmare but now I see that this is not the case. But there
is one example when I still think that infix syntax would be preferable: In
long mathematical formulae:
(/ (+ (- b) (sqrt ( - (* b b) (* 4 (* a c))))) (* 2 a))
ot something like that (I have not checked if the formula is correct) still
looks messy and I wonder if practicing would help. I can see immediately if
the infix form is correct, though.
J.B.
Raymond Wiker
It helps if you break this up over several lines and indent it
properly:
(/ (+ (- b)
(sqrt ( - (* b b)
(* 4 (* a c)))))
(* 2 a))
--
Raymond Wiker
Tim Bradshaw
> (/ (+ (- b) (sqrt ( - (* b b) (* 4 (* a c))))) (* 2 a))
> ot something like that (I have not checked if the formula is
> correct) still looks messy and I wonder if practicing would help. I
> can see immediately if the infix form is correct, though.
Mathematical expressions are the only place where I find infix better,
certainly.
--tim
Michael T. Richter
Goodbye.
"Erik Naggum" <er...@naggum.net> wrote in message
news:31714721...@naggum.net...
> * "Michael T. Richter" <m...@ottawa.com>
> | That's the first time I've seen someone describe a profusion of
> | parentheses as "clean".
>
> Congratulations! That's means you have finally opened your eyes to
> the _existence_ of people who don't share your closed-minded view on
> syntax. That's no small feat for a man in this day and age! I hear
> tolerance is such a virtue over in the Dylan camp, so you must feel
> almost like a white supremacist who saw the first black in his life,
> or the uptight puritan who first discovered gays and lesbians on his
> own -- such wild and unbridled expansion of your consciousness is so
> seldom achieved without drugs these days. Man, you are _so_ lucky.
>
> No wonder Dylan dropped its clean, attractive syntax -- had it
> retained it, the Dylan community would have had to deal with so much
> hostility in their own ranks -- as always, it's _so_ much better to
> find an external "enemy" to ridicule and denigrate, especially when
> it's someone you think you're competing with because you might have
> been friends if you were any smart, but if you choose infix, being
> smart is just _not_ an option.
Michael T. Richter
news:m2zoo0y...@gododdin.internal.jasmine.org.uk...
>> That's the first time I've seen someone describe a profusion of
>> parentheses as "clean".
> Well, then, look again. LISP syntax results from the fact that LISP as
> printed is a very nearly direct representation of the structures that
> are created in the machine as it is read.
But, silly me, I've always thought the point of automation was to make *MY*
life easier, not the machine's.
Michael T. Richter
>> parentheses as "clean".
> lisp only looks longwinded and confusing on the surface.
If something looks confusing, it likely is.
> i admit that the boilerplate mishmash of parens, braces and semicolons
> can help a human find their way, e.g., i think C's for (;;){} is
> easier than lisp's (do ()()()).
Yes. Finally I've met someone in the Lisp camp who recognizes this feature.
> however, C's semi-random assortment
> of statement seperators comes at a very high cost. look how feeble
> C's macros are compared to lisp. do not be penny wise and pound
> foolish.
Why is it that when I criticise Lisp's profusion of parentheses, the Lispers
always assume that this is a defense of C/C++?
Look at the newsgroups above. Point me to where it says "comp.lang.c" or
"comp.lang.c++".
> imho the simple syntax of lisp is a *huge* advantage for lisp.
If unreadability is supposed to be an advantage, I guess I'm all for it.
Michael T. Richter
> By the insulted tone of your messages and your constant insults
> hurled towards me, it is clear that you have failed to deal with
> public comments in a public way, but instead prefer to make this
> a personal issue.
Hey fuckhead: the person who invokes white supremacists in a trivial
disagreement over syntax really has nothing to complain about insults-wise.
> Maybe it's time to re-evaluate your strategy?
Maybe it is time for you hypocrites to read your own messages and follow
your own advice?