home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.edu:1556 comp.lang.fortran:3451 comp.lang.misc:2953 comp.arch:9252 sci.math:11051
- Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
- Path: sparky!uunet!das.wang.com!wang!news
- From: amos@huji.ac.il (amos shapir)
- Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
- Reply-To: amos@cs.huji.ac.il
- Organization: Mail to News Gateway at Wang Labs
- Date: 6 Sep 92 13:37:15 GMT
- Message-ID: <amos.715786635@shum>
- Followup-To: comp.edu
- References: <1992Sep3.020355.20338@u.washington.edu> <2!ln9fc@lynx.unm.edu> <1992Sep3.112944.20996@dbsun.uucp> <Bu08uF.HBC@mentor.cc.purdue.edu>
- Sender: news@wang.com
- Lines: 25
-
- hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
-
- >The present compilers translate such things as +, *, &, etc., into
- >some version of assembler. Why not allow the user to say how other
- >operations will be similarly translated, and add them to the list?
- >These operations often produce temporaries; why not tell the user
- >how this is done, and let them be added to the list? These would
- >not really complicate the language design or the compiler, except
- >insofar as precedence is affected.
-
- You want C++, then; or the GNU compilers, which do allow you to dive
- into the compiler's source and create whatever language extensions you
- wish to. The problem is, you'll have no time left in which to do the
- job originally intended...
-
- The point is, we can use very simple and flexible meta-tools like
- assembler or FORTH to create our own tools - and end up each using a
- personal hand-tailored language, unique and non portable; or use a
- standard tool which does implement some constructs efficiently and
- portably, but never all we'd ever need.
- --
- Amos Shapir Net: amos@cs.huji.ac.il
- Paper: The Hebrew Univ. of Jerusalem, Dept. of Comp. Science.
- Givat-Ram, Jerusalem 91904, Israel
- Tel: +972 2 585706 GEO: 35 11 46 E / 31 46 21 N
-