Meta-Language Thread

Front page | perl.bootstrap | Postings from July 2000

From:

Clifford Hammerschmidt

Date:

July 21, 2000 14:57

Subject:

Meta-Language Thread

Message ID:

4.3.2.7.2.20000721133410.01d38008@mail.marketingtips.com

At 04:27 PM 7/20/2000 -0700, Brad Clawsie wrote:
> > I don't have a strong opinion about whether writing perl6 in perl,
> > in some other meta-language, yet to be invented, which might be
> > written in perl, or directly in a low-level language (I assume
> > that's what you meant by LLL, since you follow with:) like C.
>
>does anyone have any substantive or even anecdotal data regarding
>the feasability of using a "meta language" to generate code on this
>scale?

Not on this scale, but on a smaller scale and doing direct
interpretation rather than generating C code I've had great
success. Unfortunately I can't release the code (yet) as
my employer owns it. It has cut down development time for
building new applications enormously though, and the error
rate in those applications has dropped a few orders of
magnitude compared to doing adhoc development.

>it has a lot of "whiteboard" appeal, but it seems that in practice it
>might be extremely time-consuming and problematic, as opposed to just
>writing it in C.

The idea of building a new language that is specifically tailored
to writing the Perl6 engine with can only make things simpler, and
make it much easier for outside parties to contribute. The actual
language mechanics need to be kept simple, and the means of
extending the language must also be kept simple.

Take the argument made earlier that using C makes it easier for
people to add to the perl6 system because more people know C than
the CPP or marcos or a meta-language. I don't buy this. I've
seen some really bad C coding in my life (as I'm sure we all have)
but even assuming we do a great job of coding and documenting
the C code the shear volume of C code that will be generated, and
the level of complexity required will make the task of adding
anything to perl6 virtually equivalent to having to learn a whole
new language and still understand C.

If we abstract the language used to build the Perl6 engine we take
away the requirement that you have to know C. Instead you have to
learn a system that is well tailored to the task of building a
perl engine. This has the main benefit that you can't just hack
something into the system, you actually have to understand it to
make changes.

Let's look at it in terms of a web site system (the current
system I've developed is for web site development).

Let's say you have two files

---example.tmpl---
<table>
  <TMPL_LOOP NAME=mytable>
   <tr>
    <td><TMPL_VAR NAME=mydata></td>
   </tr>
  </TMPL_LOOP>
</table>
------------------

---example.rules---
db_selectall mytable
-------------------

I think almost everyone here right know can figure out what
the intended resulting web page might look like.

Now, the same in raw perl:

-----------------
use strict;
use DBI;

print "Content-type: text/html\n\n";

my $dbh = DBI->connect($DSN,$DBuser,$DBpasswd);

if (defined $dbh) {
   my $sth = $dbh->prepare('SELECT * from mytable');
   if (defined($sth) and $sth->execute) {
     my $row;
     print "<table>\n";
     while ($row = $sth->fetchrow_hashref()) {
        print "<tr><td>" . $row->{'mydata'} . "<\td><\tr>\n";
     }
     print "</table>\n";
     $sth->finish();
   } else {
     print "Error, problem getting data from database.";
   }
   $dbh->disconnect();
} else {
   print "Error, can't connect to database";
}
-----------------

Even though everyone on this list knows perl I think it's
safe to argue that the meta-language code is easier to read.

Not only that, but the meta language code is much easier
to debug, since it is much less complex than the perl code.
I tossed that perl code off and am almost sure it as an
error in it.

Now, I admit that the task of writing the perl6 engine in
a meta-language would require a much more complicated meta-
language than the one presented here, however since it
would be custom built for the purpose of making the perl6
engine you would still gain the shortened debugging time
and a raise in code clarity over doing it in pure C.

Also, this is not a whiteboard example, as I can take the
example.rules and example.tmpl files given above, drop them
on one of my web servers (and setup the database for it,
along with some .htaccess entries to hook up the mod_perl
module that does the meta-language interpreting) and have
it work right now.

Onto the next issue: Extendibility

The web system is based of a very simple language mechanics
mixed with custom build extensions written in Perl.

The 'db_selectall table_name' function is handled by a
DBI extension, functions like 'redirect someurl' are
handled by a CGI extension. The virtual machine that
executes the meta-language can dynamically load these
extensions to build up languages with only the functions
needed.

The largest advantage of taking this approach with the
Perl6 engine is that embedded system can tailor the
resulting Perl6 engine to only contain what they need,
and thus provide the smallest overhead for there system.

Also, if building extensions to the language is easy
then embedded system builders can provide extensions
that take advantage of the oddities of their system. For
example, someone building a system to play MP3 cds in
a car stereo system with an LCD display might want
to remove the standard IO system and replace it with
one that was already aware of the LCD screen. They
might also want to make getting a listing of MP3's
from the CD very easy and starting one playing as
simple as a single command.

I hope I'm made some headway in explaining this. It's
very difficult to describe the system I'm envisioning,
and I really don't have the time to build a prototype
that would effective convey how I would apply the
meta-language concept to the Perl6 engine development,
but I hope the example above at least conveys that
meta-language systems can make development easier
and more accessible to programming community, and
can result in more flexible systems.