Re: Pragmatic Requirements Summary : update

"Eric Merritt" <cyberlync-/[email protected]> Tue, 05 Aug 2003 20:43:57 -0000
Newsgroups gmane.comp.programming.pragmatic
Message-ID <[email protected]>
--- In [email protected], Brian Hurt <bhurt@s...> wrote: 
> On Tue, 5 Aug 2003, Aryeh M. Friedman wrote: 
>  
> > 	Introspection/reflection/whatever is looking at the metadata for 
> > the code not the code it self... I think a brian storming session 
>                              I'm flattered   ^^^^^ 
> > tonight should resolve much of this (at least at the philosphical if 
> > not "praticle" level [in the case of language design there is not much 
> > difference]). 
>  
> I'd have two concerns with generated code (like LISP): 
>  
> 1) Performance.  Run time translation and hotspot optimization help- but  
> run time optimization is even better when combined with compile-time  
> optimization.  Take a look at HP's Dynamo project for information about  
> this. 
 
 There have and are lisps that perform quite well. As a general rule they do not 
outperform C, however in may contexts they can beat C. In most contexts they 
are only a factor of 2 or 3 slower then C. A good example of this is CMUCL and its 
python compiler (no not python the langauge, python the compiler). It is very good 
at generating efficient code. From my understanding the commercial 
implementations of lisp generate even better code. 
 
Most of this performance penalty can be made up in large programs with using the 
right alsgorithm. You made this point yourself. 
 
>  
> 2) Correctness.  How can you be sure for all inputs that the code  
> generated is correct? 
 
 A program can only modify itself according to its input. If you know the input then 
the output is a foregone conclusion. Not that it cant be complex.  
 
> As a side note, I'd take a look at type inference before abandoning  
> compile time strict type checkings.  I describe it as all the benefits of  
> strict type checking without the bondage and discipline aspects. 
 
 CMUCL's python compiler uses type inference to achieve its goals. Type 
inference and dynamic typing are not mutually exclusive. In fact, I would say they 
complement each other. 
 
Thanks, I will take a look. 
 
> While I'm tossing my $0.02 in, some papers and links to consider: 
> <http://ncstrl.cs.Princeton.EDU/expand.php?id=TR-482-94> 
> 
<http://216.239.53.104/search?q=cache:0UrDfGe1CX4C:research.microsoft.com/~trishulc/papers/ismm_paper.pdf+Cache+copying+garbage+collection&hl=en&ie=UTF-8> 
> <http://supertech.lcs.mit.edu/cilk/> 
> <http://www.arstechnica.com/reviews/1q00/dynamo/dynamo-1.html> 
> <http://lambda.weblogs.com/> 
> <http://lambda.weblogs.com/papers> 
> <http://caml.inria.fr/ocaml/papers.html> 
>  
> Brian 


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/sO0ANB/LIdGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
pragmatic_lang-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/