Re: seperation of function namespace

Ron Garret <rNOSPAMon@xxxxxxxxxxx> writes:

In article <yfs4pzopany.fsf@xxxxxxxxxxx>,
Alexander Schmolck <a.schmolck@xxxxxxxxx> wrote:

(For that matter, Lisp-2
avoids certain name clashes everywhere, not just in macros.)

Like what?

Types vs values; block labels -- all sorts of things.

I presume you mean something like:

(let ((list ...))
(block list ... (return-from list (coerce (foo list) 'list)) ...))

It isn't really Lisp-2 avoiding name collision here, it is, as you say,
Lisp-inf. The merits of having each of these name spaces built in to
the language is a separate, orthogonal discussion which would lead us
far afield. I'll just point out a couple of things:

1. In Python, types are (mostly) opaque first-class objects, and that
seems to work reasonably well.

Yes, but name clashes still happen (cls, l or lst etc.) and idiotic naming
conventions still exist as a result of the lack of namespaces
(ClassesAreCapitalized, haphazardly, some of the time).

I would say that these naming conventions are by and large to make the
code easier to read, not to avoid name clashes. It is very rare that
there is a class named FooBaz and a potentially conflicting variable
named foobaz (and in most of those cases it's an indication of bad
design).

It certainly happens to me at times. And the "bad design" is silly -- although
English is quite rich in synomys there are plenty of cases where one and the
same spelling names quite different but about equally useful concepts in
different namespaces that are awkward to express differently in order to
prevent nameclashes (e.g. record). One reason that it's a dumb idea to make
'end' a reserved keyword is that it's something you'd almost certainly like to
call a parameter and there's a darth of viable synonyms. Even if it doesn't
happen often it sucks when it happens, and is ugly to work around, especially
when several languages (or automatic mappings from identifiers to english
words for UIs) are involved.

Custom may exert influence, but by itself it can never PREVENT anyone
from doing anything (much to the consternation of reactionaries the
world over).

I'm not interested in metaphysical arguments, I'm interested in predicting
whether something will happen or not and for all practical purposes custom is
the supreme preventer, often far more effective than legal sanctions or other
coercive measures.

4. Why stop where CL did? Why not e.g. a separate name space for every
data type? Why shouldn't I be able to do:

(list-let ((x '(1 2 3)))
(vector-let ((x #(a b c)))
(integer-let ((x 1))
(cons (car x) (aref x x))) --> (1 . b)

Because the way the English language graphemically conflates verbs and nouns
and platonic with concrete objects does not provide a rationale for it.

Oh, so if my native language isn't English then separate name spaces for
different types might be good design?

No. Read it again (or did you forget a "not"?).

1. Obviously *your* native language is utterly irrelevant. The natural
language the programming language is based on is what matters.

2. What *is not* rationalized is the seperate namespace for every datatype,
what *is* rationalized is the seperate namespace for "verbs" and "nouns"
viz. functions and values.

Your tone suggests surprise that an arbitrary natural language should have
anything to do with programming language design decisions, but did you ever
consider the possibility that the messy type of syntax that's currently most
popular (and most elegantly embodied by python), viz. a jumble of prefix
functions, infix methods and operators and largely prefix control constructs
is likely an artifact of US, and hence English predominance in the programming
world?

English is SVO ("I eat cake"), whereas most languages are SOV (I cake eat).

I'd bet that if programming had historically been dominated by say the
Japanese, a (likely more regular and nicer) Smalltalk-like syntax would be
standard. I certainly doubt very much that C++/python style syntax would be
the most popular choice.

Have a look at all the bizarre naming conventions in
PLT scheme and related publications).

I'm not sure which bizarre naming conventions you're referring to, but a
lot of Scheme's naming conventions are there to make the code easier to
read, not to avoid name clashes.

Scheme isn't a real programming language[1]

I'm going to insert your footnote here:

[1] Confining oneself to any of the scheme standards when programming (i.e.
writing practical software) is just nuts. Scheme is more (an academic
tool and toy that spawned) a family of languages.

The ANSI standard is also quite constraining, as it has nothing to say
about networking, multithreading, graphics, foreign functions, database
connectivity.

True.

In fact, the number of things that both CL and Scheme lack is much larger
than the number of things that CL has that Scheme lacks. So by your metric,
CL is a little more "real" than Scheme, but not much.

Nonsense. People do write non-trivial applications and libraries that work on
multiple CL implementations, whereas writing cross-implementation scheme code
is so painful that the only real program that I've ever seen to do it also
threw in common lisp compatibility (!). Scheme doesn't even supply
error-handling or a way to organize code into units and any number of other
things that occur pervasively in any kind of real code and are not trivially
relegated to some relatively small compatibility layer.

That's not to say the situation in CL is satisfactory and indeed some scheme
dialects are far more complete than individual CL implementations. You might
want to have a closer look at PLT scheme, for example, maybe it'd make you
happier than CL (this is not meant as one of these "bug someone else"
suggestions -- PLT scheme certainly seems a better match to a number of your
requirements than CL. Also be sure to check out swindle).

I was talking of PLT scheme, which is a real programming language and as
result of the concomittant complexity-increase does suffer from strange
conventions brought about at least in part by a lack of separate namespaces.

Sorry, I still have no idea what you're talking about. I'm not familiar
with PLT scheme, but a quick browse of the PLT documentation reveals
nothing out of the ordinary.

From the class docs:

(define stack<%> (interface () push! pop! none?))

(define stack%
(class* object% (stack<%>)
; Declare public methods that can be overridden:
(public push! pop! none?)
; Declare a public method that can be augmented, only:
(pubment print-name)
(define stack null) ; A private field

Eli Barzilay's swindle (also part of PLT scheme) used a different
<dylan>-style convention, last time I looked. I happen to find the jumble of
<stack> stack<%> stack% and stack visually offensive.

For an egregious and slightly unfair example look at PLAI (which does have
other things going for it, though) -- or grep the PLT source for [^a-z-].+
identifiers.

What does the PLT source have to do with anything?

PLAI is a book, not plt source. It employs a wild mixture of CamelCase,
camelCase, ALLCAPS, lowercaseonly and hypen-seperated words, plus hybrids
(I guess that might also be for "readability"'s sake, but certainly there
are names in it which are only distinguished by such typographic
presentation and one does thankfully not see much similar code in CL land).

Just because there may be cruft in an implementation that says nothing at
all about the LANGUAGE.

Sure it does, especially if the implementation is written by the guys who
hashed out the language. But also see above.

IMO the comparatively sane naming conventions in CL are one of CL's few
distinguishing usability (as opposed to expressiveness) features and I see
them as partly associated with the lisp-inf-ness.

I'm still waiting for an actual example to support your view.

See above (I hope you won't deny that identifiers in CL code tend to have
comparatively good names?). It is of course difficult to pin-point the exact
causes, because there are different peculiarities relating to identifiers in
CL (apart from the 2 namespace there is the nutty readtable case behaviour, a
long cultural tradition, the large character set for identifiers that can be
used even without escaping and the ability to escape any character in an
identifier and the idiosyncratic syntax).

Another thing is that the lisp-inf approach has other repercussions -- CLers
don't mind dealing with names (and manage code units via a namespace
management) whereas schemers would abhor the idea of exporting names, rather
than values. I have no well-considered opinion on this.

'as
.

Relevant Pages

  • Re: Is there a Scheme standard?
    ... I did not mean to suggest that PLT Scheme is *the* Scheme standard. ... - R5RS is not a language in a meaningful, ... It is therefore not a fair comparison to something like Python. ...
    (comp.lang.scheme)
  • Dissecting the electorate
    ... Scheme needs *no* additional modularization ... would be quite a bit more painful to use than the language we ... Now, getting the module system *right* is not necessarily easy, ... from the core semantics and into the library - the C stdio libraries ...
    (comp.lang.scheme)
  • Re: Batch conversion of files
    ... tried writing those other languages in Scheme. ... one would want to do in GIMP is a procedural task. ... cleaner code that would have been written in another language more ... Let's take that simple batch mode script that caused all the fuss to ...
    (comp.graphics.apps.gimp)
  • Re: Scheme went one direction, Haskell went another: Why?
    ... these sorts of language features, ... Scheme, the current Haskell situation may be considered an anti-goal. ... a feature of the Glasgow Haskell Compiler ...
    (comp.lang.scheme)
  • Re: R6RS mail archives, formal comments, next r6rs draft
    ... R5RS Scheme an excellent language for learning programming and has ... Should Scheme stop at that? ... useful features are not in R6RS. ... Now R6RS is structured into two parts: the language and the standard ...
    (comp.lang.scheme)