[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Var-free programming (slightly off-topic)

At 12:49 PM 12/5/01, Dan Sugalski wrote:
>At 12:00 PM 12/5/2001 -0500, Scott McKay wrote:
>>At 11:13 PM 12/4/01, Dan Weinreb wrote:
>>>    From: Scott McKay <swm@hotdispatch.com>
>>>      (1) It should have a small, reasonably orthogonal core that has 
>>> extensibility
>>>           built in from the start.
>>>What counts as extensibility?  Does this mean macros in the sense of
>>>Lisp, Dylan, Jonathan's JSE?
>>Extensibility includes being able to extend classes, functions, and syntax.
>Why small and orthogonal, though? That would seem to be as much an 
>implementation issue as anything else. (And it's not really likely in 
>domain-specific languages, which I'd expect would have odd protruberances 
>matching their problem domain)

Because "small and reasonably orthogonal" makes the core of the
language easy to use, and "extensible" makes it easy to add "odd
protuberances" to match the domain.  The core should not require
any sort of domain-specific bits.

>>>      (3) Highly layered approach to adding functionality.
>>>I honestly don't know what you're getting at here.
>>It means that it should be easy to add "libraries" that integrate well
>>with the rest of the language.  It means that the core language should
>>not be cluttered with things that belong in libraries.  This, as I said,
>>is partly a matter of good expository writing.
>The distinction between core and libraries is a blurry one. I don't think 
>it ought be made as part of an evaluation of the language either--what 
>would you do with a language that, for example, stuck all its socket stuff 
>in a library, but automagically yanked in the library if the parser saw 
>you were using functions from it?

I don't think the distinction between core and libraries is particularly
blurry.  And I don't think the language should automagically yank
libraries, but it seems completely reasonable for this to be provided
by a development environment.  Note that the notion of a "development
environment" is also susceptible to light-weight-think: it might be
nothing more than a shell that evaluates scripts, and sucks in
libraries as needed.