Naive newbie question. 
Author Message
 Naive newbie question.

By convention class names in Dylan are <>-wrapped (e.g. <class>).  All the
docs I'm reading, in fact, go so far as to say that having classes not named
with this convention is a Bad Thing.  While I understand (and even agree
with) the convention, I'm interested in why the language definition doesn't
mandate this?


Fri, 31 Aug 2001 03:00:00 GMT  
 Naive newbie question.

Quote:

> By convention class names in Dylan are <>-wrapped (e.g. <class>).  All
> the docs I'm reading, in fact, go so far as to say that having classes
> not named with this convention is a Bad Thing.  While I understand (and
> even agree with) the convention, I'm interested in why the language
> definition doesn't mandate this?

No particular reason; it's just a (highly recommended) naming convention.

You should also note that Dylan allows more legal name characters than most
languages. In particular, you could name a class ">>**!?234foo%$<>*<" and
Dylan would not complain.

However, other Dylan programmers *would* complain. ;-) Quite loudly, too.

Perl attempts to make "different things look different". Dylan does the
same thing, but it does so on an informal basis. This keeps the language
very simple.

Cheers,
Eric



Fri, 31 Aug 2001 03:00:00 GMT  
 Naive newbie question.

Quote:

>Perl attempts to make "different things look different". Dylan does the
>same thing, but it does so on an informal basis. This keeps the language
>very simple.

So this is an implementation issue -- making it an informal guideline
simplifies the compiler front-end?


Fri, 31 Aug 2001 03:00:00 GMT  
 Naive newbie question.


    Date: Mon, 15 Mar 1999 18:26:39 GMT


    >Perl attempts to make "different things look different". Dylan does the
    >same thing, but it does so on an informal basis. This keeps the language
    >very simple.

    So this is an implementation issue -- making it an informal guideline
    simplifies the compiler front-end?

I think that Eric is saying that it's a specification issue.  Making
this a guideline means that the core language specification is simpler.

On the whole, I think that languages should specify things very
closely, making conventions official where possible.  However, in the
case of naming conventions, I think you can't really do this.  The
goal of naming conventions is readability, and it's trivial to
construct thoroughly unreadable names even with good conventions.
So there's no point cluttering up the language specification with
something that's completely unenforceable.



Fri, 31 Aug 2001 03:00:00 GMT  
 Naive newbie question.

Quote:

>I think that Eric is saying that it's a specification issue.  Making
>this a guideline means that the core language specification is simpler.

Which is in and of itself a noble goal.  One of the reasons that Modula-3
and Dylan both made it on my list of C++ replacement candidates was that
both were very simple languages.  Eiffel only made it because it was very
powerful and still simple in comparison to C++.

Quote:
>On the whole, I think that languages should specify things very
>closely, making conventions official where possible.  However, in the
>case of naming conventions, I think you can't really do this.  The
>goal of naming conventions is readability, and it's trivial to
>construct thoroughly unreadable names even with good conventions.
>So there's no point cluttering up the language specification with
>something that's completely unenforceable.

I'm kind of internally divided on this issue myself.  I lean more toward the
"close specification" side, but I can see how in this case close
specification would needlessly muddy the waters with no perceivable gain.


Fri, 31 Aug 2001 03:00:00 GMT  
 Naive newbie question.


Quote:

>>Perl attempts to make "different things look different". Dylan does the
>>same thing, but it does so on an informal basis. This keeps the language
>>very simple.

>So this is an implementation issue -- making it an informal guideline
>simplifies the compiler front-end?

No, it's not really an implementation issue.  It's a philosophical issue
about the nature of names, variables, and objects.  It would be "unnatural"
for Dylan to tie the specific characters in a name to the semantics of the
object that happen to be stored in the variable that happens to be referenced
at compile time by that name.

I'm not sure if I can say precisely why this is so.  It may be because
in Dylan variables are fundamentally untyped.  It takes extra work to
give a type to a variable.  By default variables can hold any type of
object.  This is very different from more static languages, where declaring
the variable actually allocates storage for a particular type of object.
In Dylan, when you create a variable all you're doing is creating a way
to refer to a location which can point to any object at all.  (Of course,
there are optimizations that come into play when you have something
that's declared as a constant, etc, but we're talking basic model here.)

There are other places where this model shows up.  For example, you may
not know at compile time whether the result of a certain expression will
be a class or some other kind of object.  You may not know at run time
what name was used for the variable in the program source code.  How do
you handle that situation?

And if you wanted to enforce the <> convention, would you also try
to enforce the ? convention (by automatically declaring methods
with such names to return a <boolean>)?  And how would you enforce
the ! convention?

It all comes back to the fact that names, in Dylan, don't have any
semantic meaning beyond their uniqueness as an identifier.  You can
replace any name with any other, and as long as it's done consistently,
the meaning of your program won't change.

Not sure if this ramble has made any sense at all.  I hope it has.

  -Andrew



Fri, 31 Aug 2001 03:00:00 GMT  
 Naive newbie question.


....

Quote:
>No, it's not really an implementation issue.  It's a philosophical issue
>about the nature of names, variables, and objects.  It would be "unnatural"
>for Dylan to tie the specific characters in a name to the semantics of the
>object that happen to be stored in the variable that happens to be referenced
>at compile time by that name.

 As perhaps a more concrete example.....

 The <*> is more of a explicit signification that this is a module/global
 constant ( or should be a constant) that is bound to a class/type instance.
 In Dylan, types are instances also.  For example:

  define method  foo (  obj :: <class>  )
     ...
  end method foo;

  define method bar  ( obj :: <class>  ) => (result :: <function> )
     method ( o :: obj ) ... end;
  end method bar;

 Personally, I think it would be "funny" to be required to place
 <*> around "obj" just because it is a parameter that can be bound to
 instances of <class>.  The parameter takes on various different
 bindings depending on the invocation site of the method.
 Where  <integer> always means the "class of integers". You can
 always go back to the site where <*> is defined and know what
 "type" it is based on and inference with that invariant.

 However, <type> instances are not any less "first class" than
 any other kind of object.

Quote:
>And if you wanted to enforce the <> convention, would you also try
>to enforce the ? convention (by automatically declaring methods
>with such names to return a <boolean>)?  And how would you enforce
>the ! convention?

 The $ convention would get kind of confusing also.
 "define class" and "define generic" define constants. But if
  all constants syntactically must begin with $ then.....  

 [ the ! could require a parameter to be used as an "lvalue" (or
   input to some othe ! method)  somewhere in the body.
   Semantically, that might not be the correct thing though. ]

--

Lyman S. Taylor           "Computers are too reliable to replace

                                Commander Nathan Spring, "Starcops"



Fri, 31 Aug 2001 03:00:00 GMT  
 Naive newbie question.


Quote:

...
>>On the whole, I think that languages should specify things very
>>closely, making conventions official where possible.  However, in the
>>case of naming conventions, I think you can't really do this.  The
>>goal of naming conventions is readability, and it's trivial to
>>construct thoroughly unreadable names even with good conventions.
>>So there's no point cluttering up the language specification with
>>something that's completely unenforceable.

>I'm kind of internally divided on this issue myself.  I lean more toward the
>"close specification" side, but I can see how in this case close
>specification would needlessly muddy the waters with no perceivable gain.

  I think it is better to have something that will  "bend but not break"
  for naming conventions.  A parametrized pendantic tool that examines code
  for "style" violations would allow for various senses of readability.
  It is not that the conventions can't be enforced. It is that
  casting the conventions in stone would make their enforcement rather
  draconian. [ all integer variables must begin with the letters
  'I' through 'N'. Easy to "enforce", but somewhat limiting. ]

  A Dylan coding inspector could examine various syntatical and semantic
  issues and issue missives that may or may not be followed (and can
  be suppressed once identified).  Something
  similiar to "lint" ( or gcc's   -Wall and -pedantic flags ),
  but more oriented to potential Dylan problems.  For instance, non
  complaince with a specified "interface" ( for a given class it should
  provide some list of methods ).  Something that would make it
  easier to check you have dotted all the i's and crossed all the t's. :-)
  Or as simple as making sure all names mentioned in "define class" are
  follow the <*> style.  

Lyman

--

Lyman S. Taylor           "Computers are too reliable to replace

                                Commander Nathan Spring, "Starcops"



Fri, 31 Aug 2001 03:00:00 GMT  
 Naive newbie question.

Quote:

> So this is an implementation issue -- making it an informal guideline
> simplifies the compiler front-end?

I agree with Scott McKay and the other posters from Harlequin--this is more
of a language-design issue than an implementation issue.

For some reason, it would feel very wrong to enforce these naming
conventions at the compiler level. My gut feeling is that it goes against
some part of the basic design, although I couldn't tell you which part. ;-)

Cheers,
Eric



Sat, 01 Sep 2001 03:00:00 GMT  
 Naive newbie question.


Quote:

>> So this is an implementation issue -- making it an informal guideline
>> simplifies the compiler front-end?

>I agree with Scott McKay and the other posters from Harlequin--this is more
>of a language-design issue than an implementation issue.

>For some reason, it would feel very wrong to enforce these naming
>conventions at the compiler level. My gut feeling is that it goes against
>some part of the basic design, although I couldn't tell you which part. ;-)

It goes against the part that says that type information is optional
at compile time, and is only absolutely required at run time.


Sat, 01 Sep 2001 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. naive type checking II (not so naive?)

2. Newbie Question (Was: Newbie Question...)

3. Questions from a naive user

4. Questions from a naive st programmer

5. Naive Forth questions

6. Extremely naive (and probably stupid) question

7. (Yet another) naive question

8. Naive question

9. Naive question

10. Another naive question

11. Naive Number Question

12. Naive Number Question

 

 
Powered by phpBB® Forum Software