Philosophical musings: interpreting models

[Jim Little]

(We were talking about portability and reusability.  I had said that I
thought the key was to use languages with semantics which allow you to
exactly express your desires.)

Laurent Martelli wrote:
> I think that the problem is often not in the language itself, but in
> the libraries, and the use of the language. OUTPUT should not be part
> of a language. If a library provides you with an OUTPUT(stream,string)
> you'll either use it and produce a non-portable program, or define a
> new function MYOUTPUT(string) and not reuse what already
> existed. That's why I think that it is not only a problem of language,
> but also a problem of design in libraries and software.

I agree that portable software will always be partly the responsibility
of the programmer.  The programmer has to think about what he codes and
use the most general solution he can.  But I think what you're saying
about library design applies equally well to language design. 
Furthermore, I think high-level languages are preferable to high-level
libraries.  The reason is that a compiler can't understand the semantics
of a library, but it CAN understand the semantics of a new keyword.  The
more a compiler understands, the more flexibility it has in producing
code, and that translates to optomization and portability.


>   Jim> The tricky part is finding languages with semantics which allow
>   Jim> you to exactly express your desires.  I think the key is
>   Jim> domain-specific languages rather than general-purpose
>   Jim> languages.
> 
> I don't agree. The problem with domain-specific languages, is that
> they often share some basic features, such as arithmetics and file
> accesses. So in the end you have to duplicate a lot of work in order
> to implement those features in all the domain-specific languages. 

I completely agree about the above disadvantages of DSLs.  I think the
solution is interoperable, tightly-focused DSLs.  So you have one DSL
which only does arithmetic, one which only does file access, etc.  Of
course, at this level of specialization, close interoperability is
crucial.  Such a level of specialization and interoperability is what
I'm working towards with Prism.

Once you have those very high-level languages, portability and
optomization aren't nearly as big of an issue as they are with other
languages.  The semantic granularity is so large that the compiler has a
lot of leeway in how it implements a particular feature.

> So I'd rather have one language (understand one semantic), and have
> the opportunity to change the syntax to make it more user-friendly for
> different domains. Take LISP. Most people think it has a very
> inconvenient syntax because of all the parenthesis. However, it has
> one of the cleanest semantic. What prevents us from wrting a special
> editor that would allow us to write (2+5)*3 instead of (* 3 (+ 2 5)) ?

LISP's semantics are very clean, but they're also very low-level.  Even
if LISP were compiled, it couldn't understand that it's allowed to
compile the program "DISPLAY 'Hello world'" into a windowed application
AS WELL AS a console application.  A very-high-level language's compiler
would have that knowledge.  In the case of something like TUNES, such a
language compiler could take into account the user's current situation
and decide how to display the greeting on the fly.  LISP could never do
that because its compiler couldn't know what DISPLAY means.


Jim Little
jiml@inconnect.com