Squeak and Namespaces

>From: Andreas Raab <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Squeak and Namespaces
>Date: Wed, 29 Nov 2006 00:14:11 -0800
>
>Bert Freudenberg wrote:
>>Actually, that is the beauty of the proposal. Colons are already allowed
>>unquoted in a symbol. #My::Class is valid right now. In this proposal, the
>>compiler knows *nothing* about namespaces. It just permits a colon in a
>>global identifier. It's the only syntax change.
>
>Is that really true? I haven't looked at the code in a while but Goran used
>code that I had originally written and that code most certainly wasn't just
>permitting colons in a global identifier.  What it did do was introducing
>explicitly scoped variables and the result of Foo::Bar would depend on what
>is stored in Foo's scope under the name of #Bar and not on what is stored
>under Smalltalk at: #'Foo::Bar'. Of course, these two can be made the same
>by using the same association but that's still quite a bit different from
>just permitting colons in global names.
>
>Generally speaking, I'm -1 on the proposal, mostly because what the
>proposal doesn't achieve is to make a real step towards enabling
>scalability of development (which to me is really what we're after). That's
>because the *author* of some code still needs to find unique names
>(prefixes) that do not conflict with the rest of the world and that a
>"change of prefix" becomes very, very expensive because it's literally like
>renaming all of the classes at once (and consequently breaking all of the
>code that uses any name from that "prefix space").
>
>So basically you're trading the probability of conflicts (reduced due to
>the increased length in names) with the severity of conflicts (increased
>since changing the prefix is more expensive). It's an incremental approach
>that shifts tradeoffs but doesn't do anything to address the problem on a
>more fundamental basis (in all fairness, Goran never claimed it did but
>it's important in this discussion to understand what this proposal does and
>doesn't do to assess the impact of a change).
>
>But since it's "only" an incremental shift in tradeoffs I wonder if a
>language change (with significant costs for compatibility) is really
>justified. It seems to me that the practical gain is fairly minor and there
>is little motivation that I can see for anyone with a "serious" project to
>adopt this solution given that it will neither be portable nor
>backward-compatible. Put on top that the proposal deliberately doesn't take
>a stand on any general modularity issues (visibility, dependencies), then
>what exactly does one gain?
>
>To me the basic question here is: Is the prefix pattern so pervasive (and
>so problematic) that it deserves a special syntactic representation?
>Without taking a stab at the "real" problem (scalability of development) my
>answer is: No. It's a clever hack but nothing that I would loose sleep over
>if it weren't there (and I won't loose sleep over it being there either but
>I'd like us to be clear about what we're trying to achieve with adopting
>it).
>
>Cheers,
>   - Andreas
>

>From: Howard Stearns <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Squeak and Namespaces
>Date: Wed, 29 Nov 2006 09:32:41 -0600
>
>There's a heuristic that says incremental wins are good, but there are
>cases that don't apply. ("The world is better off without Saddam Hussein in
>power, no?") How do we know that this isn't leading the kind of "half a
>loaf" (non-)solution that I tend to worry about?
>
>Guy Steele once told me that the first thing he tries to get right about a
>language is the namespace. "Get that wrong and you'll never recover."
>
>I like Andreas' way of comparing what the proposal does to the cost of
>programmer changes. Determining whether his analysis is correct depends, I
>think, on what the proposal is actually doing, no?  I think it's possible
>to implement it in such a way that changes scale appropriately, but it is
>not yet clear to me that the code actually does things that way.
>-Howard
>
>Hernan Tylim wrote:
>>+1
>>
>>I like Goran solution. Its true that only  fixes the "prefix" problem  and
>>not the "namespace" problem, as Andreas pointed out. But to me that is not
>>a bad thing. its one step further to make Squeak a little more
>>comfortable.
>>
>>Regards,
>>Hernán
>>
>>On 29 Nov 2006 15:59:41 +0100, *Lex Spoon* <[hidden email]
>><mailto:[hidden email]>> wrote:
>>
>>     Andreas Raab <[hidden email] <mailto:[hidden email]>>
>>writes:
>>      > Generally speaking, I'm -1 on the proposal, mostly because what
>>the
>>      > proposal doesn't achieve is to make a real step towards enabling
>>      > scalability of development (which to me is really what we're
>>      > after). That's because the *author* of some code still needs to
>>find
>>      > unique names (prefixes) that do not conflict with the rest of the
>>      > world and that a "change of prefix" becomes very, very expensive
>>      > because it's literally like renaming all of the classes at once
>>(and
>>      > consequently breaking all of the code that uses any name from that
>>      > "prefix space").
>>
>>     It's a good observation.  Nonetheless, a hierarchical global
>>namespace
>>     seems a good step forward over a flat global namespace.  I do not
>>know
>>     about *this* system, but in general I would love if global variables
>>     and classes had long hierarchical names.  Using the existing class
>>     categories would seem great for that.
>>
>>     Right now, responsible programmers already fake a hierarchical
>>     namespace by putting prefixes in front of all their global names.  At
>>     the very least, it would be nice to support this practice in the
>>     programming language.  Ideally, you can even use long names
>>     ("Monticello") instead of short prefixes ("MC") and thus greatly
>>     reduce the chance of conflicts.
>>
>>     In practice, I bet it's not so hard to pick prefixes that are unique
>>     in the contexts the package will be used in.  Most of the time, you
>>     can just use the name of the project, which you have surely already
>>     gone to some efforts to try and make unique.  If nothing else, all
>>the
>>     open-source projects would benefit!
>>
>>
>>     Finally, keep in mind what the great naming systems you describe for
>>     the future would look like.  They will probably still have path-based
>>     identifiers!  The only difference from hierarchical names would
>>likely
>>     be that the path can start from somewhere other than a single global
>>     root.  Thus, a flexible hierarchical-naming system would seem like a
>>     good basis for the kind of naming system you are thinking about.  (In
>>     particular, you would want Foo::Bar to really mean "Bar" within
>>     "Foo"....)
>>
>>
>>
>>     -Lex
>>
>>
>>
>>
>>
>>--
>>Saludos,
>>Hernán
>>
>>
>>------------------------------------------------------------------------
>>
>>
>
>--
>Howard Stearns
>University of Wisconsin - Madison
>Division of Information Technology
>mailto:[hidden email]
>jabber:[hidden email]
>voice:+1-608-262-3724
>

>From: [hidden email]
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Squeak and Namespaces
>Date: Wed, 29 Nov 2006 19:23:10 +0200
>
>Hi!
>
>Bert Freudenberg <[hidden email]> wrote:
> > On Nov 29, 2006, at 19:14 , J J wrote:
> >
> > > Once you get namespaces in, it's going to be pretty hard to take
> > > them out again if research shows a better way.
> >
> > Is that so? Did you read the proposal? It does not look hard at all
> > to back out again.
> >
> > - Bert -
>
>It would be trivial to back this out. But I guess most people arguing in
>this thread haven't read either the article nor have they actually
>looked at how it works or on the code itself. That is of course no
>crime, but it would be easier to discuss it if people actually looked at
>it. ;) ;)
>
>But now I guess people are waiting for that walkthrough instead. :)
>
>regards, Göran
>

> Hi!
>
> Howard Stearns <[hidden email]> wrote:
>> I like Andreas' way of comparing what the proposal does to the cost of
>> programmer changes. Determining whether his analysis is correct depends,
>
> I agree that this is a trade off that we need to look at closely.
>
>> I think, on what the proposal is actually doing, no?  I think it's
>> possible to implement it in such a way that changes scale appropriately,
>> but it is not yet clear to me that the code actually does things that way.
>> -Howard
>
> Ok, the code is small and it has class comments. If you (and or anyone
> else) is serious about looking at it for such an analysis I can offer a
> detailed writeup of EXACTLY what it does and how it works. After all, I
> have spent enough hours on this that I do not wish to see it all wasted.
> :)
>
> Say "please do" and I will do it. :)
>
> regards, Göran
>

> Göran Krampe wrote:
>> Foo::Bar == (Smalltalk at: #'Foo::Bar')
>> In fact, I believe it was you Andreas that strongly suggested I  
>> should do
>> it this way or take on a world of hurt. :)
>
> Right, because it's the only way to make it so that the tools would  
> continue to work (since none of them is namespace aware).
>
>>> So basically you're trading the probability of conflicts (reduced  
>>> due to
>>> the increased length in names) with the severity of conflicts  
>>> (increased
>>> since changing the prefix is more expensive).
>> Ehm, how can it be more expensive? You mean compared to changing a  
>> single
>> clashing class name?
>
> Yes.
>
>> And it *does* enable experimentation with prefix hiding (as I do  
>> in the
>> tools part) or even experimenting with explicit imports (which I  
>> detest -
>> and even Stephane now seems to think is a bad idea - but hey, feel  
>> free to
>> play around).
>
> Interesting. I'm just the other way around - I detest the idea of  
> tools rewriting source code under my feet and have code in the  
> morning look different from the same code in the afternoon, and  
> have code that would perfectly compile in the morning not compile  
> in the same way in the afternoon. And, I think imports are critical  
> for scalability - because they a) declare dependencies explicitly  
> and b) allow the *user* of a package/global to decide under which  
> name to use them. The Python module system works that way and it  
> works great.
>
>>> But since it's "only" an incremental shift in tradeoffs I wonder  
>>> if a
>>> language change (with significant costs for compatibility) is really
>>> justified.
>> Is the "language change" really of that kind? You can already have  
>> global
>> names with : in them (which is funny) but if you try using that for a
>> class you will get into trouble - a bug IIRC. So the small changes  
>> could
>> even be considered to be a bug fix. :)
>
> Hardly so. Code that doesn't work in any previous Squeak version  
> and doesn't work in any other dialect cannot be called a bug fix.  
> It's a significant syntax change.
>
>> I agree that it deliberately does not involve dependencies, and  
>> only a
>> little bit about visibility (the tool extensions I did have some
>> visibility mechanisms) - because I think we can first add the *basic*
>> notion of "named buckets" (=Namespace) and the *basic* syntax -  
>> without
>> blending those two issues into the pot.
>> If someone then would want to tie these Namespaces into dependencies,
>> imports, modularity etc - then that is IMHO a "next step".
>
> Yes, and that's the major reason why I'm not violently against  
> it ;-) It *may* be a step that needs to be taken now but I'm still  
> wondering if we won't be stuck forever at this point because even  
> between the two of us we can't agree on some very basic notions  
> (imports or not). That's why I'm judging this independently of the  
> follow-on steps (which may or may not happen) and that's why I'm  
> wondering if changing the syntax at this point is really worthwhile.
>
>> BUT... if we intend to try to tackle those two beasts on the language
>> level (instead of say SM or MC level), then perhaps a Namespace  
>> "notion"
>> is a first step.
>> And it doesn't seem to be a dangerous step either. But it will enable
>> experimentation.
>
> Experimentation is already enabled by having it loadable from  
> SqueakMap. And there are quite some risks associated with it most  
> importantly that of inventing an esoteric construct that nobody  
> wants and nobody needs because we may not understand the needed  
> semantics well enough to make it work out in the long term.
>
>> To summarise - it reifies prefixes and makes them concrete and  
>> easy to
>> manipulate, and easy to spot. That is all, and since we *have* these
>> things already (prefixes) - then making them tangible, concrete, real
>> objects seems like a useful thing to do.
>
> I agree with all of that. What I'm not sure about is whether that  
> (on its own) is reason enough for a change in syntax. The trouble  
> with syntax is that once it's chosen and once a semantics is chosen  
> we're essentially set with it. So are we certain, are we  
> *absolutely* certain that we understand the semantics of that  
> change well enough to say that "yes this is the semantics we need  
> for the follow-on steps and it is extremely unlikely that we'll  
> need anything but that"? I'm not.
>
> Cheers,
>   - Andreas
>
>
>

> On Nov 29, 2006, at 9:42 AM, stephane ducasse wrote:
> > PS: I have been working with VW recently and I really found  
> > namespaces getting in my way all the time. Also the integration of  
> > namespaces
> > in VW is badly supported at the refactoring level and other tools.  
> > So this is often a pain.
>
> I agree with Andreas and Stef.
> Working with Seaside in VW right now, I can find 3 (three!)  
> "versions" of Date in VW (Core.Date, Squeak.Date and Seaside.Date)!
> It kind of sucks to have to extend Seaside.Date with date method  
> extensions already existing for Core.Date for this local shop.
>
> Maybe namespaces of VW helped to get seaside ported to VW at all, but  
> I'd prefer to have an ongoing desire to unify classes, which _are_  
> intended to work the same.

>
>
> On 11/29/06, Klaus D. Witzel <[hidden email]> wrote:
>        
>         Motivation for syntax: we say SmallInteger and LargeInteger to
>         subclasses
>         of Integer and obviously prefer the opposite direction for a
>         namespace
>         hierarchy. Let's replace the suggested :: by a legitimate
>         binary message
>        
>           Morphic >~ View
>           Tweak >~ View
>           System >~ Default >~ Compiler
>           My >~ Terrific >~ Compiler
>
> Implementing Namespaces like this would mean that your code runs
> slower. In order to refer to a class, you'll need to send a message to
> a Namespace every time you refer to it, rather than just refer to the
> class directly.
>
> Also, your message names are capitalised, which will have a negative
> affect on your karma.

> Il giorno gio, 30/11/2006 alle 12.07 +1300, Michael van der Gulik ha
> scritto:
> >
> >
> > On 11/29/06, Klaus D. Witzel <[hidden email]> wrote:
> >        
> >         Motivation for syntax: we say SmallInteger and LargeInteger to
> >         subclasses
> >         of Integer and obviously prefer the opposite direction for a
> >         namespace
> >         hierarchy. Let's replace the suggested :: by a legitimate
> >         binary message
> >        
> >           Morphic >~ View
> >           Tweak >~ View
> >           System >~ Default >~ Compiler
> >           My >~ Terrific >~ Compiler
> >
> > Implementing Namespaces like this would mean that your code runs
> > slower. In order to refer to a class, you'll need to send a message to
> > a Namespace every time you refer to it, rather than just refer to the
> > class directly.
> >
> > Also, your message names are capitalised, which will have a negative
> > affect on your karma.
>
> Isn't this what Henryk's Environments do?

> On 11/29/06, Klaus D. Witzel <[hidden email]> wrote:
>>
>> Motivation for syntax: we say SmallInteger and LargeInteger to  
>> subclasses
>> of Integer and obviously prefer the opposite direction for a namespace
>> hierarchy. Let's replace the suggested :: by a legitimate binary message
>>
>>   Morphic >~ View
>>   Tweak >~ View
>>   System >~ Default >~ Compiler
>>   My >~ Terrific >~ Compiler
>>
>
> Implementing Namespaces like this would mean that your code runs slower.