On 28 Aug 2001 05:26:29 +0900, Hal E. Fulton wrote:
> ----- Original Message -----
> From: Sean Middleditch <elanthis / users.sourceforge.net>
> To: ruby-talk ML <ruby-talk / ruby-lang.org>
> Sent: Monday, August 27, 2001 3:09 PM
> Subject: [ruby-talk:20442] Re: Backwards language
> 
> 
> [snip]
> 
> > Ruby is a very dynamic language, which is really great, but isn't what I'm
> > looking for in my project.  I seem to have generated the wrong set of
> > reponses to my original query, which was merely what people though of
> > designing a backend before a syntax, for a syntax-neutal language, once
> > designed for it's power and speed of execution over it's gramatical and
> > syntactical features.
> 
> Sean,
> 
> My $0.02.
> 
> The reason a backend exists is so that it can be conceptually separate
> from the rest of the system. It can be maintained, tuned, documented --
> and yes, *designed* -- separately. But we all know that.
> 
> The question then (your question) is: Does it make sense to design the
> backend *first*? And I have to say: I see no problem with that.
> 
> But let me qualify that by saying: Once you design the rest, you may find
> yourself wanting to change the design of the backend somewhat. And
> that is just life in the programmers' world.
> 

Of course.  What doesn't one tune and change?  ^,^

> One of the few projects from grad school that I remember with fondness
> was a simple language I designed. Unlike some other people, I created
> three separate pieces: A compiler which generated fake assembly language;
> an assembler which assembled that into a relocatable object; and a binary
> interpreter acting as a virtual machine on which to run that object.
> 
> Testing the three of them could proceed in parallel, of course.
> 
> The relative ease with which the project was accomplished was not a tribute
> to my programming skill as such, but rather the consequence of a sensible
> design choice and a few good habits drilled into me by my instructors.
>

Understood.  I have, unfortunately, been bitten in the arse quite a few
times by poor design.  I didn't have the advantage of good habits
drilled in by instructors.  ~,^  Still, this is the first language
design I've ever done, so I'm supposing I'll be learning quite a bit
(heck, learned a lot today during research).  Seems everyone else agrees
with that statement, and I know they're most likely right.  ^,^
 
> So my opinion is: Separate the pieces well enough, and it's largely
> irrelevant
> which order you do them in.
> 

Never really thought of it like that.  I've usually seen people come up
with an idea for how a language should work, and what the features of
the language should be, then figure out a way to get the language
running with an interpreter/compiler.

I'll definitely think about what you say, though.  It might be
interesting to also come up with a language syntax completely
independent of the backend, and see how well they merge.  Might learn a
thing or two about both sides of a language.

Thanks.

> Hal
> 
> 
>