Re: [TCLCORE] Variable access (was Re: [Tcl9-cloverfield], Parser)
by Rna020 other posts by this author
May 9 2008 10:30AM messages near this date
Re: [TCLCORE] Variable access (was Re: [Tcl9-cloverfield], Parser)
|
Re: [TCLCORE] Variable access (was Re: [Tcl9-cloverfield], Parser)
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:20080509133035.GF18202@bitmover.com" type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta name="Generator" content="MS Exchange Server version 6.5.7653.2">
<title> Re: [TCLCORE] Variable access (was Re: [Tcl9-cloverfield],
Parser)</title>
<!-- Converted from text/plain format -->
<p> <font size="2">> I believe Fr?d?ric is suggesting that it is
equivalent to an implicit<br>
> upvar on the name (in the scope of the called proc), but
guarantees that<br>
> the variable exists. Using upvar currently provides no such
guarantee<br>
> because the variable name is a weak reference.<br>
> > proc foo v { ... }<br>
> > foo $&bar<br>
> ><br>
> > is roughly equivalent to:<br>
> ><br>
> > proc foo vName { upvar 1 $vName v; ... }<br>
> > foo bar<br>
> ><br>
> > Is that correct?<br>
<br>
This is very similar to what we already have implemented in L. The
&var<br>
syntax is just syntatic sugar for the implied upvars as needed in the<br>
callee; the caller, it means pass the name of the variable instead of<br>
the value.<br>
<br>
Seems to work quite well.<br>
--<br>
---<br>
Larry McVoy &nb
sp; lm at bitmover.com <a
moz-do-not-send="true" href="http://www.bitkeeper.com"> http://www.bitkeeper.com</a><br>
</font> </p>
</blockquote>
FWIW - I think "strong references" should be "encapsulated" in a
sub-language (perhaps L) and not included in the primary language (i.e.
Tcl). Programming languages conceptual abstractions of what is going on
in the hardware. It is a fundamental mistake to try to create a
language that spans all levels and types of abstraction (e.g. machine,
assembly, macro, functional/procedural, object, etc). So far the
language community has chose to create only single languages with
complex compilers that can compile languages from different abstraction
levels. In the interpreative languages, however, the push has always
been to add more to the same language. I think this is a mistake.
Instead I think the interpretor should be thought of as a compiler
(that can handle all levels of abstraction) and that there should be a
hierarchy of languages that are designed to interface to lower and
higher levels in the hierarchy.<br>
<br>
Tom K.<br>
</body>
</html>
Thread:
Twylite
Larry McVoy
Rna020
Neil Madden
Twylite
Neil Madden
Twylite
Neil Madden
|
