Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!usenet.ins.cwru.edu!ns.mcs.kent.edu!kira.cc.uakron.edu!malgudi.oar.net!chemabs!lwv26
From: lvirden@cas.org
Subject: Re: Two Dylan Questions
Content-Type: text/plain; charset=US-ASCII
Message-ID: <1995Jan7.102140.14778@chemabs.uucp>
Sender: lwv26@chemabs.uucp (Larry W. Virden)
Reply-To: lvirden@cas.org
Content-Transfer-Encoding: 7BIT
Organization: Nedriv Software and Shoe Shiners, Uninc.
References: <rloD1tKCG.7D6@netcom.com> <CARROLL.95Jan4120858@quadriga.cis.udel.edu> <JRD.95Jan5155003@netcom9.netcom.com> <3eibi0$mo2@cantaloupe.srv.cs.cmu.edu>
Mime-Version: 1.0
Date: Sat, 7 Jan 1995 10:21:40 GMT
Lines: 20


One problem that I have seen in C, Perl and Tcl is how to best handle language
evolution.  As the intrinsics mature, often the functionality changes slightly
- why, even within the operating system we occasionally see new functions,
return codes, and even new arguments or argument types.

One of the stuggles in these languages that I have encountered is trying
to write software which needs to deal with some of the runtime issues
that arise from this.  Source code in C often needs to be 'littered' wit
#ifdef's, etc.  And in perl or tcl, we see code which needs to check
the runtime version info to know which arguments to pass, etc.

What features will be in the Dylan environment to handle this situation?
This is a case where a programmer might _have_ to have different arguments
to the same methods, due to OS or Dylan runtime requirements...
-- 
:s Larry W. Virden                 INET: larry.virden@cas.org
:s <URL:http://www-bprc.mps.ohio-state.edu/cgi-bin/hpp?lvirden_sig.html>
:s Unless explicitly stated to the contrary, nothing in this posting should 
:s be construed as representing my employer's opinions.
