Re: Are these all really true ?

Scott Nicol <scott@infoadv.mn.org> writes:
>Better in what sense? There are fewer hidden side-effects, but
>side-effects aren't always a bad thing. It really depends on what
>the language is designed to do. For example, awk would be unusable
>if it were strongly typed.


Oddly enough, I have a paper design for a "Typed AWK" and have tried
rewriting every AWK script I have access to in it. There is in fact
no practical difference at all. There are a couple of ad-hoc rules
that I had to adopt, such as "if $x is statically an operand of an
arithmetic operator, rewrite it to num($x) during parsing", and of
course the traditional "if a regular expression occurs in a Boolean
context, rewrite it as $0 ~ it during parsing", but they occur before
type checking (or would if I implemented the design). You would be
surprised what straightforward type inference can do for you; the
Typed AWK paper design is a strongly typed _language_ but programs
never explicitly indicate types; it's all done by type inference.


This result did not surprise me. J. Nevil Brownlee wrote a compiler
for a subset of SNOBOL called SNOBAL67 back in the 70s; it compiled
the subset into Burroughs Extended Algol and it relied on type inference
to figure out which variables were numbers, which were strings, and
which were patterns. SNOBOL is a dynamically typed language, but the
subset was quite usable; the main restriction was the lack of arrays
and lists, not the typing.


>>* Memory is free, speed is what is worth optimizing.


>OK.


Academic work in databases is based very much on the idea that memory
is not free, that figuring out what to bring into memory when and how
long to keep it is hard but has huge payoffs.


>>* Formal specifications yield correct programs.


>You can't prove correctness for anything other than the smallest
>program. If specifications yield correct programs, there would
>be no need for regression tests.


Nobody said anyting about proving correctness.
_Informal_ specifications sure as heck don't yield correct programs.


>>* WYSIWYG is better for all applications.


>Some call it WYSIAYG (What You See Is All You Get). There are many
>situations where WYSIWYG is an impediment. For example, try globally
>changing the style of section headings in an MS Word document...


I agree what WYSIAYG.
I note that different people have different encoding strategies, if
you believe the Neurolinguistic Programming people, and that for some
people a word may be worth a thousand pictures.


I further note that the Web is _not_ WYSIWYG.
--
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.


--

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