Prism criticism

[Jim Little]

Maneesh Yadav wrote:
> 
> You're goals seem clearer to me now, and I agree with them for the most
> part.  However I really don't see what you are trying to sya here.  Is the
> meaning part just a part of the code?

I'm not sure if I understand your question, but I'll try to answer it
anyway.

Source code is a model of a program.  It has an intrinsic meaning: the
program it represents -- and an extrinsic meaning: the program you think
it represents.

The purpose of a metamodel is to define the meaning of a set of models
so that when you look at the model, the extrinsic meaning (what you
think it is) is the same as the intrinsic meaning (what it really is).

To put it another way, a metamodel is a language specification.


> How is this different than writing out a c struct and a comment
> beside it?

It's not really any different.  I could have used C's basic data types
to model programs, but I chose not to.  C isn't really that well suited
for the purpose -- the basic types already have an intrinsic meaning (an
'int' is a number, a 'char' is a character), and they're fairly limited
(no collections).  C++ has collections, but now we're talking code, and
it just makes things messy.  As it stands, the Prism meta-metamodel is
fairly pure, almost orthogonal, and (most importantly) small and simple.

 
> Jim give me a clear example on how using Prism's methods provides more
> elegance/usefullness whatever, than doing it in C++....that's all that you
> need to prove your case.

I can't give you any useful examples at this time.  Prism is done, but
the infrastructure required be more useful than C++ (mixing several
models into one) has yet to be started.  The best I can do is give you a
concept.  It's a fabricated problem, but I'm trying to mix together
multiple issues just like a real program does:


Imagine writing a GUI program to find all lines beginning with "//" in a
file.  Instead of struggling with regular expressions in C++, or visual
development in Perl, you use multiple Prism languages.  One just for
visual layout.  One just for regular expressions.  And one just for file
access.  You glue them altogether with an event-driven messaging
language. 

We're not assuming you've ever used any of these things before,
either... just that you're familiar with the basics of Prism, C++, and
Perl.  Rather than thumbing through massive tomes trying to figure out
how to write a regular expression parser (for C++) or how to layout
GUI's (for Perl), you find just the metamodels you're interested in,
scan their five page specifications, spend a bit more time understanding
their related (and minimal) languages, and get the entire project done
in a couple hours.  It looks something like this:

# This is a comment
** USE Prism/Event **   # 'use' tells compiler what language
SearchMain {
   AT START {
      TELL SearchGui start;
   }
   EVERY (1) SECOND {
      # Just showing some event metamodel possibilities, hee hee
   }
}
   
** USE Prism/Event **
** EMBED Prism/Gui **
SearchGui {
   WINDOW frameWindow CONTAINS {
      LISTBOX resultsList BELOW {
         TEXTFIELD filenameField LEFTOF
         BUTTON processButton
      }
   }
   WHEN TOLD start {
      TELL frameWindow display;
   }
   WHEN processButton PRESSED {
      TELL SearchEngine match(GET FilenameField contents);
   }
   WHEN TOLD displayResults(results) {
      ** EMBED Prism/Loop **
      ** EMBED Prism/Collection **
      TELL resultsList clear;
      ITERATE i = results;
      WHILE (results.HASMORE) {
         TELL resultsList display(results.NEXT);
      }
   }
}

** USE Prism/Event **
** EMBED Prism/File **
** EMBED Prism/Regex **
SearchEngine {
   WHEN TOLD match(filename) {
      ** EMBED Prism/Loop **
      ** EMBED Prism/Conditional **
      ** EMBED Prism/Collection **
      ** EMBED Prism/String **
      TEXTFILE file = filename;
      NEW LIST result;
      UNTIL (file.EOF) {
         STRING line = file.GETNEXTLINE;
         if (line MATCHES [^\w*//]) {
            APPEND result(s);
         }
      TELL SearchGui displayResults(result);
      }
   }
}

Anyway, that's an example.  Not the best one in the world, and I think
real programming in Prism will be different, but it's the best one I can
give at this stage.

If you're wondering why you don't see any _Bits, _Streams, or _Maps in
the above code, it's because atoms are the infrastructure, not the
goal.  I'm still building the infrastructure, so naturally that's what I
focus on.  When I'm done, normal programmers won't see the
infrastructure; they'll just deal with languages.  Only expert
programmers will deal with the Prism infrastructure, and only when they
make new metamodels and languages for ordinary programmers to use. 
(Sort of like library developers and application developers today.  Most
people don't create template classes in C++, they just use the ones that
expert library programmers have created.  Same concept for Prism
programmers and metamodels.)

Jim

Prism is at http://www.teleport.com/~sphere