Re: High Level Assemblers vs. High Level Language Compilers

"Randall Hyde" <rhyde@cs.ucr.edu>
24 Mar 2002 00:15:41 -0500

          From comp.compilers

Related articles
High Level Assemblers vs. High Level Language Compilers whopkins@csd.uwm.edu (2002-03-19)
Re: High Level Assemblers vs. High Level Language Compilers rhyde@cs.ucr.edu (Randall Hyde) (2002-03-21)
Re: High Level Assemblers vs. High Level Language Compilers idbaxter@semdesigns.com (Ira D. Baxter) (2002-03-22)
Re: High Level Assemblers vs. High Level Language Compilers fjh@cs.mu.OZ.AU (2002-03-22)
Re: High Level Assemblers vs. High Level Language Compilers rhyde@cs.ucr.edu (Randall Hyde) (2002-03-24)
Re: High Level Assemblers vs. High Level Language Compilers rhyde@cs.ucr.edu (Randall Hyde) (2002-03-24)
Re: High Level Assemblers vs. High Level Language Compilers kgw-news@stiscan.com (2002-03-24)
Re: High Level Assemblers vs. High Level Language Compilers whopkins@alpha2.csd.uwm.edu (2002-03-31)
Re: High Level Assemblers vs. High Level Language Compilers rhyde@cs.ucr.edu (Randall Hyde) (2002-04-06)
Re: High Level Assemblers vs. High Level Language Compilers rhyde@cs.ucr.edu (Randall Hyde) (2002-04-06)
| List of all articles for this month |

From: "Randall Hyde" <rhyde@cs.ucr.edu>
Newsgroups: comp.compilers
Date: 24 Mar 2002 00:15:41 -0500
Organization: Prodigy Internet http://www.prodigy.com
References: 02-03-120 02-03-127 02-03-153
Keywords: assembler, design
Posted-Date: 24 Mar 2002 00:15:41 EST

Ira D. Baxter wrote in message 02-03-153...
>"Randall Hyde" <rhyde@cs.ucr.edu> wrote in message
>
>There's two reasons for a DSL: one, it encodes a problem domain
>situation in problem domain terms (C codes problem domain situations
>essentially in machine-level solution terms), *and* it gives a
>notation easily readable to a human designer familiar with that
>domain. Regular expressions (grep, sed, etc.) are a really good
>example that meet both criteria. You can probably code up a set of
>macros that will implement regular expressions, but half the value,
>readability, is likely lost.


Depends on the macro processor, I suppose. HLA, for example, provides
macros that let you easily code up many common context-free patterns.
In theory, just about anything you could do with a recursive-descent
parser could be done with HLA's macros. It's not a trivial matter to
do a complete DSL using those macros, but then, writing a language
processor that is reasonably robust is rarely a trivial matter in any
language.


Granted, the whole push in DSLs (and DSELs, the more appropriate path
when using a macro processor) is to write a custom language as rapidly
as possible so you don't have to amortize compiler development costs.
With DSELs, you can't specify the DSL independently of the embedded
language; but a good macro processor does provide capability to smooth
over a lot of rough edges found in the underlying language. For
example, Dylan's macro facilities are quite impressive, not quite the
perfect tool for creating DSLs, but there are a lot of good ideas
there that should wind up in a macro processor that supports DSELs.


As for C/C++ being too low-level (an inference I made from your post),
my complaint with VHLLs (like Haskell) is that, by their very nature,
tend to limit the applicability of the DSELs you can produce with
them. Of course, I personally tend to work down towards the
lower-level end of the language spectrum, so perhaps it's just my
prejuidices showing through.


Randy Hyde


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.