Re: Pragmatic Requirements Summary : update

--- In [email protected], "joelneely" <joel.neely@f...> wrote: 
> Could I (as a newbie/outsider) ask for clarification, or is it 
> premature? 
>  
> --- In [email protected], "Aryeh M. Friedman" 
> <[email protected]> wrote: 
> > ... 
> > 1) How to seperate code from data in a clean generic paradigm 
> > neutral manner 
> > 
>  
> Why?  One of the nicer aspects of LISP and FORTH (and Perl, Python, 
> and even xBase) is the ability to construct code on the fly and 
> evaluate the constructed code/expressions within the current 
> computation.  Admittedly this is not for beginners, but is a very 
> powerful (pragmatic ;-) tool for some purposes.  Introspection is 
> another such tool that blurs the code/data boundary. 
 
  This is an discussion that is ongoing between me and Aryeh. I agree with you, 
code is data and data is code. Its too useful to just toss out. 
 
>  
> >  
> > 2) How to handle situations where the syntax/semantics of one 
> > paradigm clashs with that of an other 
> >  
>  
> The REBOL language addresses this via the concept of "dialects", 
> in which a structure (e.g. block) is explicitly supplied to a 
> handler which implements the syntax/extensions used in that part. 
>  
> This makes very clear the scope and intent of the extended region. 
 
 Thats true. Although we are taking a different path we want a similar result.  
The issue arises when various 'dialects', as rebol puts it, interact with one 
another. Making sure this interaction is clean and consistant is important. 
 
>  
> > 
> > 3) Exactly where to artifically draw the line between HW ("language 
> > atomic") and SW (implimented "in" Pragmatic) 
> >  
>  
> That strikes my ear as an implementation issue rather than a 
> language definition issue.  A quick-bootstrap implementation (back 
> to the FORTH tradition again) might opt for the smallest possible 
> core language, with all of the rest implemented as "high-level" 
> definitions/extensions, while a performance-tuned implementation 
> might opt for highly-tweaked versions of many of the so-called 
> higher features.  This provokes me to the question: 
>  
>   Wouldn't it be better to have a precise definition of the 
>   notation and semantics of language features and leave it to 
>   the discretion of the implementor(s) how to make the 
>   bootstrap-versus-performance tradeoffs? 
 
 I tend to agree with all of your points here. This is an argument that 
has been ongoing for a week or two now. 
 
>  
> I apologize in advance if I'm retracing old discussions with these 
> thoughts! 
>  
 
 Thats ok, we like this kind of discussion ;) 
> -jn- 


------------------------ 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/