On 2006-06-21 02:39:06 +0100, ············@gmail.com said:
> I'm learning both these days.
It probably depends what you mean by "complement".
You can create embedded languages in both
You've got powerful macros/defining words in both
But the similarities don't probably go much beyond
that point.
I have writtem, in years past, my own Forth interpreter.
But I wouldn't even contemplate writing a serious Lisp
system.
Also, the minimalist resource requirement of Forth
are much less of an advantage now (unless you work
in embedded systems), and the price to pay are many-fold:
- no heap allocation (hence, no garbage collection)
- no fixnums or arbitray size
- no namespace (even if Lisp packages are a bit cumbersome
to use, they're far better than ... nothing)
In what way to you see them "complement" each other?
I used to be fond of Forth, but I fail to remember any
feature that I don't have an at least as good (or better)
equivalent in CL. Could you mention one?
--
JFB
verec wrote:
> On 2006-06-21 02:39:06 +0100, ············@gmail.com said:
>
> [snipped]
>
> Also, the minimalist resource requirement of Forth
> are much less of an advantage now (unless you work
> in embedded systems), and the price to pay are many-fold:
> - no heap allocation (hence, no garbage collection)
Standard ANS forth provides the equivalent of C malloc and free
(allocate/free). Apparently there are some garbage collected
libraries, although I can't quite see how a gc can be seemlessly
integrated into a non-gc language.
> - no fixnums or arbitray size
Integers on the stack are usually the equivalent of a C int. Of course
there are certain words (similar to functions in other languages) which
operate on 8-bit range, for example string operations.
Arbitrary size arithmetic is not standard and would require a library.
To be quite honest I've rarely had the need for arbitrary size
arithmetic over the years. In the cases where I have, using a library
hasn't been too much of an inconvenience. 64-bit integer arithmetic
gives quite a large range.
I think I would miss the Lisp Rational type more. On the other hand
the Lisp numerical tower is impressive.
> - no namespace (even if Lisp packages are a bit cumbersome
> to use, they're far better than ... nothing)
Many Forth's provide the equivalent of namespaces in vocabularies. ANS
Forth has further refined the concept into word lists.
Cheers,
Mike
verec <·····@mac.com> writes:
> In what way to you see them "complement" each other?
Prefix vs postfix?
--
The lithobraker. Zero distance stops at any speed.
ATGATT: Because stone is harder than flesh.
············@gmail.com wrote:
> I'm learning both these days.
As others have pointed out they are similar in their use of extending
the base language to
solve problems and different in thier scope and use of memory.
You really want to read the following no matter what langauge you use,
it's one of the best
books ever written on thinking like a programmer:
http://thinking-forth.sourceforge.net/
···@itasoftware.com wrote:
> ············@gmail.com wrote:
> > I'm learning both these days.
>
> As others have pointed out they are similar in their use of extending
> the base language to
> solve problems and different in thier scope and use of memory.
What other languages use extending the base language to solve problems
like forth does? I really like this bottom-up thinking of small,
immediately-testable functions/procedures and then combining those. Has
anyone tried Joy? It's said to be a functional forth. Is it usable and
worth learning now or should I wait a much longer while and concentrate
on established languages?
>
> You really want to read the following no matter what langauge you use,
> it's one of the best
> books ever written on thinking like a programmer:
>
> http://thinking-forth.sourceforge.net/
That's an excellent book. I already read half of it a couple of weeks
ago and skimmed the rest. I plan to read it again, and again. It's such
a light, interesting, and amusing read. I couldn't put it down. I guess
it was one of the reasons I'm so drawn to forth. The other is its
seeming simplicity. Though I know I should perhaps spend time on lisp,
on an OO language, and perhaps the relational model, I nonetheless feel
compelled to read forth and play with it. Perhaps if I become
indoctrinated in this bottom-up model of forth it'll be nonetheless
useful for other languages. I know that's how I want things to be for
me, this bottom-up model of extending a base language.
On Thu, 22 Jun 2006 09:20:59 -0700, dlp wrote:
> As others have pointed out they are similar in their use of extending
> the base language to solve problems and different in their scope and use
> of memory.
>
> You really want to read the following no matter what language you use,
> it's one of the best books ever written on thinking like a programmer:
>
> http://thinking-forth.sourceforge.net/
I've read the first chapter. Pages 25-26 are particularly interesting:
We've noted two inventions of Forth that make possible the methodology
we've described--implicit calls and implicit data passing. A third
feature allows the data structures within a component to be described
in terms of previously-defined components. This feature is direct
access memory.
Suppose we define a variable called APPLES, like this:
VARIABLE APPLES
We can store a number into this variable to indicate how many apples we
currently have:
20 APPLES !
We can display the contents of the variable:
APPLES ? 20 ok
We can up the count by one:
1 APPLES +!
(The newcomer can study the mechanics of these phrases in Appendix A.)
The word APPLES has but one function: to put on the stack the address
of the memory location where the tally of apples is kept. The tally can
be thought of as a "thing," while the words that set the tally, read
the tally, or increment the tally can be considered as "actions."
Forth conveniently separates "things" from "actions" by allowing
addresses of data structures to be passed on the stack and providing
the "fetch" and "store" commands.
We've discussed the importance of designing around things that may
change. Suppose we've written a lot of code using this variable APPLES.
And now, at the eleventh hour, we discover that we must keep track of
two different kinds of apples, red and green!
We needn't wring our hands, but rather remember the function of APPLES:
to provide an address. If we need two separate tallies, APPLES can
supply two different addresses depending on which kind of apple we're
currently talking about. So we define a more complicated version of
APPLES as follows:
VARIABLE COLOR ( pointer to current tally)
VARIABLE REDS ( tally of red apples)
VARIABLE GREENS ( tally of green apples)
: RED ( set apple-type to RED) REDS COLOR ! ;
: GREEN ( set apple-type to GREEN) GREENS COLOR ! ;
: APPLES ( -- adr of current apple tally) COLOR @ ;
Here we've redefined APPLES. Now it fetches the contents of a variable
called COLOR. COLOR is a pointer, either to the variable REDS or to the
variable GREENS. These two variables are the real tallies.
If we first say RED, then we can use APPLES to refer to red apples. If
we say GREEN, we can use it to refer to green apples (Figure 1.10).
We didn't need to change the syntax of any existing code that uses
APPLES. We can still say
20 APPLES !
and
1 APPLES +!
Look again at what we did. We changed the definition of APPLES from
that of a variable to a colon definition, without affecting its usage.
Forth allows us to hide the details of how APPLES is defined from the
code that uses it. What appears to be "thing" (a variable) to the
original code is actually defined as an "action" (a colon definition)
within the component.
Forth encourages the use of abstract data types by allowing data
structures to be defined in terms of lower level components. Only
Forth, which eliminates the CALLs from procedures, which allows
addresses and data to be implicitly passed via the stack, and which
provides direct access to memory locations with @ and !, can offer this
level of information-hiding.
[...]
If one wants a global value *APPLES* in Common Lisp one may be tempted to
define it as (DEFPARAMETER *APPLES* 20) and refer to it as *APPLES*. But
then one cannot change *APPLES* from a number value to a function
definition without affecting its use (one must replace all references to
*APPLES* with function calls). A code rewrite could have been avoided if
*APPLES* was initially defined as (DEFUN *APPLES* () 20) and always
referred to as (*APPLES*). A similar issue in Java is whether to expose
the fields of an object or only expose functional getters and setters.
In this respect Forth may be more abstract than any language that makes a
syntactic distinction between looking up the value of a variable slot and
calling a function.
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> If one wants a global value *APPLES* in Common Lisp one may be tempted to
> define it as (DEFPARAMETER *APPLES* 20) and refer to it as *APPLES*. But
> then one cannot change *APPLES* from a number value to a function
> definition without affecting its use (one must replace all references to
> *APPLES* with function calls). A code rewrite could have been avoided if
> *APPLES* was initially defined as (DEFUN *APPLES* () 20) and always
> referred to as (*APPLES*). A similar issue in Java is whether to expose
> the fields of an object or only expose functional getters and setters.
This is not exact. You can define a symbol macro by the same name.
Of course, if you originally named it with the *convention*, you might
want to implement in the symbol macro code the dynamic behavior.
> In this respect Forth may be more abstract than any language that makes a
> syntactic distinction between looking up the value of a variable slot and
> calling a function.
Lisp doesn't make this distinction, thanks to symbol-macros and macros.
(defvar function-made-variable )
(defmacro function-made-variable () 'function-made-variable)
(setf (function-made-variable) 1)
(print (function-made-variable))
(defvar the-value-of-the-\"variable\")
(defun variable-made-function ()
(return-from variable-made-function the-value-of-the-\"variable\"))
(defun (setf variable-made-function) (value)
(setf the-value-of-the-\"variable\" value))
(define-symbol-macro variable-made-function (variable-made-function))
(setf variable-made-function 1)
(print variable-made-function)
--
__Pascal Bourguignon__ http://www.informatimago.com/
"What is this talk of "release"? Klingons do not make software
"releases". Our software "escapes" leaving a bloody trail of
designers and quality assurance people in its wake."
············@gmail.com wrote in comp.lang.lisp:
Re: Is Forth a good complement to Lisp?
>I'm learning both these days.
For an appropriate definition of "complement", yes. ;)
In spite of their obvious differences I tend to see them on "the same
side of the fence" compared with other languages.
What sets them apart, in my view, is the following:
(a) The ability to dynamically create both new functions and data at
run time.
Among the few languages I know, Forth, Lisp and their extended
families are the only ones that do not draw an impassable line between
code and data, as languages in the Algol tradition do. This can lead
to a programming style with an expressiveness and conciseness very
difficult to achieve with conventional languages.
(b) A development environment open for inspection and modification
while running. The speed of compilation in modern computers has
covered much of the "advantage gap" between interpreted / interactive
environments over "compile only" ones. (I is not longer necessary to
came back to the computing center the following day to get the
printout of your Fortran program.)
But even if it takes just a few seconds to rebuild complex systems
from scratch, most of the environment in which they run remains a
"black box", impenetrable and untouchable. Not so with
Lisp/Scheme/Forth.
What other languages share this traits? APL & Smalltalk come to mind,
(never used them, always planning to.) Others?
Roberto Waltman wrote:
> What other languages share this traits? APL & Smalltalk come to mind,
> (never used them, always planning to.) Others?
Well, some languages (C#, Java) allow you to create new code at runtime,
but the process is between painful and excrutiating. I don't know if
that counts. I've also found that the more a language allows for
exploration (in the way being discussed here), the more it tends to work
on an "image" basis and the less it tends to play nicely with other
systems (other languages or the operating system). Not as a
hard-and-fast rule, but in general.
--
Darren New / San Diego, CA, USA (PST)
Native Americans used every part
of the buffalo, including the wings.
> Well, some languages (C#, Java) allow you to create new code at runtime,
> but the process is between painful and excrutiating. I don't know if
> that counts.
Painful: I've seen "dynamic" code creation done in VB.Net. The point
was to produce something like a desk calculator. The application had
to read the code snippet from the window, wrap something like a
function and a class around it, compile it, call it, then get the
result and display the answer.
Excrutiating: I also did something like dynamic code creation in C in
the mid 1970s. I had a machine language code fragment in a char array
and managed to call it. Arguably, the latter does not count.
I would argue that APL has a clear distinction between code and data,
it's just that converting from code to data and vice-versa tends to be
trivial. APL statements tend to be compact, which has the side effect
of making code-building programs that much easier. I would not say
that Function Arrays change much, if you consider that an "array" is an
arbitrary container.
From: Christopher C. Stacy
Subject: Re: Code is data is code is data is ...
Date:
Message-ID: <yzlzmfsxmes.fsf@OSX663.local>
"Ibeam2000" <·········@gmail.com> writes:
> I would argue that APL has a clear distinction between code and data,
> it's just that converting from code to data and vice-versa tends to be
> trivial. APL statements tend to be compact, which has the side effect
> of making code-building programs that much easier. I would not say
> that Function Arrays change much, if you consider that an "array" is an
> arbitrary container.
For those who are not familiar:
* APL has EVAL, which is called "execute".
* APL also has functions that convert a function into a character matrix,
and also to convert a character matrix to a function. These are the
{quad}CR ("canonical representation") and {quad}FX operators.
* There are also what languages today refer to as "introspection" functions,
which return information about functions in the workspace.
(At least, that's how it was back around 1974 when I was hacking APL,
a few years before I discovered Lisp...)
From: Markus Triska
Subject: Re: Code is data is code is data is ...
Date:
Message-ID: <87hd2chc72.fsf@gmx.at>
Roberto Waltman <······@rwaltman.net> writes:
> What other languages share this traits?
Prolog
http://jsoftware.com/
http://groups.google.com/group/J-Programming
Markus Triska wrote:
> Roberto Waltman <······@rwaltman.net> writes:
>
> > What other languages share this traits?
>
> Prolog
Roberto Waltman wrote:
> ············@gmail.com wrote in comp.lang.lisp:
> Re: Is Forth a good complement to Lisp?
> >I'm learning both these days.
>
> For an appropriate definition of "complement", yes. ;)
>
> In spite of their obvious differences I tend to see them on "the same
> side of the fence" compared with other languages.
> What sets them apart, in my view, is the following:
>
> (a) The ability to dynamically create both new functions and data at
> run time.
> Among the few languages I know, Forth, Lisp and their extended
> families are the only ones that do not draw an impassable line between
> code and data, as languages in the Algol tradition do. This can lead
> to a programming style with an expressiveness and conciseness very
> difficult to achieve with conventional languages.
>
> (b) A development environment open for inspection and modification
> while running. The speed of compilation in modern computers has
> covered much of the "advantage gap" between interpreted / interactive
> environments over "compile only" ones. (I is not longer necessary to
> came back to the computing center the following day to get the
> printout of your Fortran program.)
> But even if it takes just a few seconds to rebuild complex systems
> from scratch, most of the environment in which they run remains a
> "black box", impenetrable and untouchable. Not so with
> Lisp/Scheme/Forth.
>
> What other languages share this traits? APL & Smalltalk come to mind,
> (never used them, always planning to.) Others?
There is only one answer particularly with regard to your item (b),
In the early 90's, the Lisp Machines and Symbolics Lisp workstations
had the
features that you desire. So great has the desire apparently been to
bury these concepts, that modern listings of nearly every conceivable
Emacs editor and variant seem to somehow overlook the famous Zmacs
editor on the workstations, which had some self modifying ability and
worked directly with the development environment, unlike the modern
version of emacs which requires a primitive shell interface.
APL, with its archaic mainframe bound "workspace" concept, lacks the
ability to significantly alter the development environment, other than
perhaps building a more clever editor or debugger, which hardly count
towards what you are seeking in (b). IBM, STSC and others, all had the
opportunity to "open up" their workspace documentation and some, such
as IBM produced elaborate documentation for "interface" but, nobody
gives the user control over this most secret and propietary part of the
vendors' usually unjustifiably overpriced "system". It almost seems as
though the power of APL must be carefully reigned in within strict
limits.
The newer "J" language has correctly eliminated the traditional
workspace and perhaps offers more opportunities to do what you want.
Jim
Roberto Waltman wrote:
>
> (a) The ability to dynamically create both new functions and data at
> run time.
>
> (b) A development environment open for inspection and modification
> while running.
>
> What other languages share this traits?
(a) Snobol
actually, lots of languages can write external text files, which
can then be invoked as procedures, later in the execution -- this
was common practice with SQL, before "dynamic" SQL was generally available
maybe you want to restrict that definition to strings (or functions,
or objects?) which are never externally visible?
(b) not Snobol, when I last used it -- maybe times have changed?
Spitbol? Icon, perhaps?
regards . . . /phil
phil chastney wrote:
>> (a) The ability to dynamically create both new functions and data at
>> run time.
>>
>> (b) A development environment open for inspection and modification
>> while running.
>>
>> What other languages share this traits?
>
>(a) Snobol [...]
>(b) not Snobol, when I last used it -- maybe times have changed?
> Spitbol? Icon, perhaps?
(a): Icon can not create new functions at runtime. However, one can
invoke any function by computing its name as a string and calling that
with an argument list. (Most of my uses of APL's Execute came down
to compute identifiers such as "cmd , '_FUNCTION'" or "cmd , '_HELP'"
in standard command interpreters, without having to register each
new command function in some switch table etc. The Icon facility
allows this approach, too, without requiring a general expression
interpreter at runtime.)
(b): Icon allows you to activate traces of procedure calls/returns,
lets you inspect the call stack in limited ways, and provides a
list of optional features that may or may not be available in your
specific Icon installation.
Martin Neitzel
Roberto Waltman wrote:
> (a) The ability to dynamically create both new functions and data at
> run time.
[...]
> (b) A development environment open for inspection and modification
> while running.
[...]
> What other languages share this traits? APL & Smalltalk come to mind,
> (never used them, always planning to.) Others?
PostScript has (a).
Smalltalk certainly has (b), but I would say that it only has (a) in a weak
sense. That's to say that although you can create new classes and methods at
runtime (indeed that's the only way to create new classes or methods), and
classes definitely have an object nature that reflects their structure /as/
classes (you can ask a class for its current methods, for instance), the same
is not true of methods. The compiled form of a method is an object, but not
one which is not related to its source form in any transparent way.
Several of the scripting languages (e.g Ruby) have the dynamic semantics needed
for (b), but (at least in comparison with Smalltalk) lack the interactive
execution environments to allow access to that dynamism.
-- chris
Chris Uppal wrote:
> Smalltalk certainly has (b), but I would say that it only has (a) in a weak
> sense. That's to say that although you can create new classes and methods at
> runtime (indeed that's the only way to create new classes or methods), and
> classes definitely have an object nature that reflects their structure /as/
> classes (you can ask a class for its current methods, for instance), the same
> is not true of methods. The compiled form of a method is an object, but not
> one which is not related to its source form in any transparent way.
The first two versions of Smalltalk did have a code representation that
directly matched the source code - vectors of tokens and subvectors.
This feature was eliminated from Smalltalk-76 in favor of bytecodes
since it wasn't used enough to justify the cost. Though practically all
current Smalltalk implementations are like -76 I don't consider that a
characteristic of the language itself.
-- Jecel
Jecel wrote:
> The first two versions of Smalltalk did have a code representation that
> directly matched the source code - vectors of tokens and subvectors.
Intesting. I hadn't known that. Thanks.
> This feature was eliminated from Smalltalk-76 in favor of bytecodes
> since it wasn't used enough to justify the cost. Though practically all
> current Smalltalk implementations are like -76 I don't consider that a
> characteristic of the language itself.
I agree. Such an implementation would be unusual but definitely not "not
Smalltalk".
-- chris
On Fri, 23 Jun 2006 13:28:45 +0100, Chris Uppal wrote:
> Roberto Waltman wrote:
[...]
>> (b) A development environment open for inspection and modification
>> while running.
[...]
> Smalltalk certainly has (b), but I would say that it only has (a)
in a
> weak sense. That's to say that although you can create new classes and
> methods at runtime (indeed that's the only way to create new classes or
> methods), and classes definitely have an object nature that reflects
> their structure /as/ classes (you can ask a class for its current
> methods, for instance), the same is not true of methods. The compiled
> form of a method is an object, but not one which is not related to its
> source form in any transparent way.
[...]
Actually, nearly all Smalltalks store the source code for the method along
with the method; you can ask the method object for its source, modify it,
and then recompile it. Given that the byte code is merely an
implementation detail --- you could write a standards-compliant Smalltalk
that parsed and executed the source code directly --- I reckon this gives
you (b).
I'm going to get flamed for this, but I also reckon that Forth *doesn't*
have (b). While it will let you create new words and run time, it doesn't
let you modify old ones. The best you can do (disregarding anything
involving indirections, which is cheating) is to either define a new word
that will override the old one *for subsequent compilations only*, or
unwind the dictionary stack past the old word and replace it --- which in
real life isn't terribly useful, because this requires you to FORGET lots
of stuff you may have wanted to keep.
--
+- David Given --McQ-+ "Preacher, don't the Bible have some pretty
| ··@cowlark.com | specific things to say about killing?" "Quite
| (··@tao-group.com) | specific. It is, however, somewhat fuzzier on the
+- www.cowlark.com --+ subject of kneecaps." --- Firefly, _War Stories_
In comp.lang.forth David Given <··@cowlark.com> wrote:
> On Fri, 23 Jun 2006 13:28:45 +0100, Chris Uppal wrote:
>> Roberto Waltman wrote:
> [...]
>>> (b) A development environment open for inspection and modification
>>> while running.
> [...]
>> Smalltalk certainly has (b), but I would say that it only has (a)
> in a
>> weak sense. That's to say that although you can create new classes and
>> methods at runtime (indeed that's the only way to create new classes or
>> methods), and classes definitely have an object nature that reflects
>> their structure /as/ classes (you can ask a class for its current
>> methods, for instance), the same is not true of methods. The compiled
>> form of a method is an object, but not one which is not related to its
>> source form in any transparent way.
> [...]
> I'm going to get flamed for this, but I also reckon that Forth *doesn't*
> have (b). While it will let you create new words and run time, it doesn't
> let you modify old ones.
Well, I'm not going to flame you, but I will disagree! The
development environment certainly is open for inspection and
modification while running.
> The best you can do (disregarding anything involving indirections,
> which is cheating) is to either define a new word that will override
> the old one *for subsequent compilations only*, or unwind the
> dictionary stack past the old word and replace it --- which in real
> life isn't terribly useful, because this requires you to FORGET lots
> of stuff you may have wanted to keep.
That's the way it's supposed to work. It's fairly easy on many
implementations to add the capability to redefine words "on the fly"
without recompiling their callers. It's not provided as standard
because in practice it's not very useful to do so, not because it's
all that difficult to do. [1]
I quite well remember adding this feature to a Forth system, thinking
how cool it was, and never using it.
Andrew.
[1] I mean it's not very useful _in Forth_. I know Smalltalkers love
this stuff.
Andrew Haley wrote:
>In comp.lang.forth David Given <··@cowlark.com> wrote:
>> On Fri, 23 Jun 2006 13:28:45 +0100, Chris Uppal wrote:
>>> Roberto Waltman wrote:
>> [...]
>>>> (b) A development environment open for inspection and modification
>>>> while running.
>> [...]
>>> Smalltalk certainly has (b), but I would say that it only has (a)
>> in a
>>> weak sense. That's to say that although you can create new classes and
>>> methods at runtime (indeed that's the only way to create new classes or
>>> methods), and classes definitely have an object nature that reflects
>>> their structure /as/ classes (you can ask a class for its current
>>> methods, for instance), the same is not true of methods. The compiled
>>> form of a method is an object, but not one which is not related to its
>>> source form in any transparent way.
>> [...]
>
>> I'm going to get flamed for this, but I also reckon that Forth *doesn't*
>> have (b). While it will let you create new words and run time, it doesn't
>> let you modify old ones.
>
>Well, I'm not going to flame you, but I will disagree! The
>development environment certainly is open for inspection and
>modification while running.
Disagree also. The jury is still delivering on the flaming sentence.
;)
>> The best you can do (disregarding anything involving indirections,
>> which is cheating) is to either define a new word that will override
>> the old one *for subsequent compilations only*, or unwind the
>> dictionary stack past the old word and replace it --- which in real
>> life isn't terribly useful, because this requires you to FORGET lots
>> of stuff you may have wanted to keep.
>
>That's the way it's supposed to work. It's fairly easy on many
>implementations to add the capability to redefine words "on the fly"
>without recompiling their callers. It's not provided as standard
>because in practice it's not very useful to do so, not because it's
>all that difficult to do. [1]
>
>I quite well remember adding this feature to a Forth system, thinking
>how cool it was, and never using it.
I did it also, although the rationale was not "the coolness factor"
but an attempt to implement a simple virtual memory system, were Forth
words could be removed from memory and loaded back at a different
address. At the end I though it was not worth it, except for
(relatively) large data structures, were it was better handled in a
per case basis.
>Andrew.
>
>[1] I mean it's not very useful _in Forth_. I know Smalltalkers love
>this stuff.
(Removed comp.lang.apl, I believe this is still marginally on topic
for the other groups)
From: Albert van der Horst
Subject: Re: Code is data is code is data is ...
Date:
Message-ID: <j1hmqj.4t7@spenarnc.xs4all.nl>
In article <···············@news.supernews.com>,
Andrew Haley <········@littlepinkcloud.invalid> wrote:
>In comp.lang.forth David Given <··@cowlark.com> wrote:
>> On Fri, 23 Jun 2006 13:28:45 +0100, Chris Uppal wrote:
<SNIP>
>
>> The best you can do (disregarding anything involving indirections,
>> which is cheating) is to either define a new word that will override
>> the old one *for subsequent compilations only*, or unwind the
>> dictionary stack past the old word and replace it --- which in real
>> life isn't terribly useful, because this requires you to FORGET lots
>> of stuff you may have wanted to keep.
>
>That's the way it's supposed to work. It's fairly easy on many
>implementations to add the capability to redefine words "on the fly"
>without recompiling their callers. It's not provided as standard
>because in practice it's not very useful to do so, not because it's
>all that difficult to do. [1]
It is, if it is not possible to recompile the callers, in particular
if the callers are within the Forth kernel.
For example, if you want to allow use of forward labels in an
assembler, you can modify an ``on error'' routine to accomodate
this. The detection of the not-yet-defined label takes place
in the Forth kernel.
I don't understand why Chris calls indirection ``cheating''.
Obviously always some kind of indirection is going on.
>I quite well remember adding this feature to a Forth system, thinking
>how cool it was, and never using it.
I still want to use it in a persistent Forth system, where the
kernel is recompiled bit by bit, and stored back on the boot-disk
after each session. Kind of colorforth-with-readable-source-and-comment.
This is the model of a computer intelligence. After a certain stage
modification would take place on protection level 2, leaving the
kernel robust.
Then the ci could write programs in level 3 herself, which models
the programmable hardware in our vision system and muscles.
>Andrew.
>
>[1] I mean it's not very useful _in Forth_. I know Smalltalkers love
>this stuff.
I think if you measure by how hard you need it, instead of how many
times, it _is_ useful.
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
······@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
On 2006-06-26, David Given <··@cowlark.com> wrote:
> On Fri, 23 Jun 2006 13:28:45 +0100, Chris Uppal wrote:
>
>> Roberto Waltman wrote:
> [...]
>>> (b) A development environment open for inspection and modification
>>> while running.
> [...]
>
> I'm going to get flamed for this, but I also reckon that Forth *doesn't*
> have (b). While it will let you create new words and run time, it doesn't
> let you modify old ones. The best you can do (disregarding anything
> involving indirections, which is cheating) is to either define a new word
> that will override the old one *for subsequent compilations only*, or
> unwind the dictionary stack past the old word and replace it --- which in
> real life isn't terribly useful, because this requires you to FORGET lots
> of stuff you may have wanted to keep.
>
In just about any language, wether you can do this or not comes down to
an implementation detail. Holon Forth, http://www.holonforth.com , you
can modify a word and it will overwrite the old code if it fits or put a
jump from the old code to the new if it doesn't. As far as I know Wolf
Wejgaard doesn't provide source for the Holon environment, but I suspect
that he builds new versions of Holon by editing them on older versions
of Holon. One could argue this works better than introspection because
you can't modify yourself into a unusable configuration.
-- Trey
David Given wrote:
> On Fri, 23 Jun 2006 13:28:45 +0100, Chris Uppal wrote:
>
> > Roberto Waltman wrote:
> [...]
> >> (b) A development environment open for inspection and modification
> >> while running.
> [...]
> > Smalltalk certainly has (b), but I would say that it only has (a)
> in a
> > weak sense. That's to say that although you can create new classes and
> > methods at runtime (indeed that's the only way to create new classes or
> > methods), and classes definitely have an object nature that reflects
> > their structure /as/ classes (you can ask a class for its current
> > methods, for instance), the same is not true of methods. The compiled
> > form of a method is an object, but not one which is not related to its
> > source form in any transparent way.
> [...]
>
> Actually, nearly all Smalltalks store the source code for the method along
> with the method; you can ask the method object for its source, modify it,
> and then recompile it. Given that the byte code is merely an
> implementation detail --- you could write a standards-compliant Smalltalk
> that parsed and executed the source code directly --- I reckon this gives
> you (b).
>
> I'm going to get flamed for this, but I also reckon that Forth *doesn't*
> have (b). While it will let you create new words and run time, it doesn't
> let you modify old ones. The best you can do (disregarding anything
> involving indirections, which is cheating) is to either define a new word
> that will override the old one *for subsequent compilations only*, or
> unwind the dictionary stack past the old word and replace it --- which in
> real life isn't terribly useful, because this requires you to FORGET lots
> of stuff you may have wanted to keep.
As others have said, some Forths have it done properly some don't.
Modification of the runtime, adding or changing code is a feature that
sometimes languages have, eg Common Lisp, or just specific extended
implementations of them. It's most useful of-course when the language
itself has it because it can be relied upon, used in portable code,
etc. Otherwise there's less incentive to learn how to use it.
I've actually come across a C interpreter that had this feature. I
never learnt to use it though because almost every other C
implementation is a compiler.
"Rob Thorpe" wrote:
>...
>Modification of the runtime, adding or changing code is a feature that
>sometimes languages have, eg Common Lisp, or just specific extended
>implementations of them. It's most useful of-course when the language
>itself has it because it can be relied upon, used in portable code,
>etc. Otherwise there's less incentive to learn how to use it.
>
>I've actually come across a C interpreter that had this feature. I
>never learnt to use it though because almost every other C
>implementation is a compiler.
Interesting. Can you provide a name or web site?
Roberto Waltman wrote:
> "Rob Thorpe" wrote:
> >...
> >Modification of the runtime, adding or changing code is a feature that
> >sometimes languages have, eg Common Lisp, or just specific extended
> >implementations of them. It's most useful of-course when the language
> >itself has it because it can be relied upon, used in portable code,
> >etc. Otherwise there's less incentive to learn how to use it.
> >
> >I've actually come across a C interpreter that had this feature. I
> >never learnt to use it though because almost every other C
> >implementation is a compiler.
>
> Interesting. Can you provide a name or web site?
Cint does it:
http://root.cern.ch/root/Cint.html
But I think the one I used was called EiC. I can't find it anymore.
Roberto Waltman wrote:
> "Rob Thorpe" wrote:
>> ...
>> Modification of the runtime, adding or changing code is a feature that
>> sometimes languages have, eg Common Lisp, or just specific extended
>> implementations of them. It's most useful of-course when the language
>> itself has it because it can be relied upon, used in portable code,
>> etc. Otherwise there's less incentive to learn how to use it.
>>
>> I've actually come across a C interpreter that had this feature. I
>> never learnt to use it though because almost every other C
>> implementation is a compiler.
>
> Interesting. Can you provide a name or web site?
InstantC ?
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
"Chris Uppal" <···········@metagnostic.REMOVE-THIS.org> wrote
> Smalltalk certainly has (b), but I would say that it only has (a) in a
> weak
> sense. That's to say that although you can create new classes and methods
> at
> runtime (indeed that's the only way to create new classes or methods), and
> classes definitely have an object nature that reflects their structure
> /as/
> classes (you can ask a class for its current methods, for instance), the
> same
> is not true of methods. The compiled form of a method is an object, but
> not
> one which is not related to its source form in any transparent way.
Some Smalltalks even forbid the distribution of the incremental compiler
with runtime applications, since this would effectively mean distributing
the "language" itself. However, it is relatively trivial to
reverse-engineer Smalltalk bytecode, and write one's own compiler. (I did
it for fun, once.) The incremental compiler is a trivial part of Smalltalk
compared with the VM and foundation classes and methods.
The same might be said for Java, especially considering the size of the
foundation class library and the complexity of modern dynamic optimizing
bytecode-to-native-machine-code recompilers (eg Java's HotSpot). There is
some effort involved in runtime compilation of Java source, but for some
kinds of application it would be well worth it.
The cost of "compiling" at runtime in Smalltalk is that the message/method
cache has to be managed more carefully, even cleared, slowing down overall
performance. Languages like Smalltalk and Java call this "reflection", and
while it is part of the langauge proper, it is usually best left for
development systems. The VM is generally not optimised for frequent
reflection operations.
Self also has a very well-defined reflection system, and again the
philosophy is that is should mostly be used for development. However, Self
has the interesting additional non-reflective property of allowing the
"class" of an object to be changed at runtime (that is to say the
correspondence between names used within that object and the objects or
methods to which those names refer - not by reassigning one-by-one, but by
complately changing the name-lookup rule). I haven't used Self, but I
understand that this gives a great deal of cheap flexibility somewhat short
of being able to alter code itself.
Cheers, Paul
Paul Chapman wrote:
> Self also has a very well-defined reflection system, and again the
> philosophy is that is should mostly be used for development. However, Self
> has the interesting additional non-reflective property of allowing the
> "class" of an object to be changed at runtime (that is to say the
> correspondence between names used within that object and the objects or
> methods to which those names refer - not by reassigning one-by-one, but by
> complately changing the name-lookup rule). I haven't used Self, but I
> understand that this gives a great deal of cheap flexibility somewhat short
> of being able to alter code itself.
I think I might have been the only person to use this "dynamic
inheritance" seriously in an application (a CMOS circuit simulator in
Self 1.0), though there is one cute example in the standard collections
library. Since current implementations don't handle this very well it
could be the case of everyone avoiding it due to performance reasons,
but my guess is that it is a feature that simply looks better on paper
than it does in practice. Which is often the case for run time
manipulation of code, to get back to the origin of this thread. So I
eliminated dynamic inheritance from Neo Smalltalk (my language derived
from Self).
-- Jecel
From: Ken Tilton
Subject: Re: Code is data is code is data is ...
Date:
Message-ID: <c%Uog.209$a23.40@fe10.lga>
Jecel wrote:
> Paul Chapman wrote:
>
>>Self also has a very well-defined reflection system, and again the
>>philosophy is that is should mostly be used for development. However, Self
>>has the interesting additional non-reflective property of allowing the
>>"class" of an object to be changed at runtime (that is to say the
>>correspondence between names used within that object and the objects or
>>methods to which those names refer - not by reassigning one-by-one, but by
>>complately changing the name-lookup rule). I haven't used Self, but I
>>understand that this gives a great deal of cheap flexibility somewhat short
>>of being able to alter code itself.
>
>
> I think I might have been the only person to use this "dynamic
> inheritance" seriously in an application ...
There used to be a CL "Capabilities" package from a gentleman at
Northwestern IIRC, but Google suggests not. Add/remove superclasses on
the fly.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
>
>
> Jecel wrote:
>> Paul Chapman wrote:
>>
>>> Self also has a very well-defined reflection system, and again the
>>> philosophy is that is should mostly be used for development.
>>> However, Self
>>> has the interesting additional non-reflective property of allowing the
>>> "class" of an object to be changed at runtime (that is to say the
>>> correspondence between names used within that object and the objects or
>>> methods to which those names refer - not by reassigning one-by-one,
>>> but by
>>> complately changing the name-lookup rule). I haven't used Self, but I
>>> understand that this gives a great deal of cheap flexibility somewhat
>>> short
>>> of being able to alter code itself.
>>
>>
>> I think I might have been the only person to use this "dynamic
>> inheritance" seriously in an application ...
>
> There used to be a CL "Capabilities" package from a gentleman at
> Northwestern IIRC, but Google suggests not. Add/remove superclasses on
> the fly.
ContextL totally depends on changing/creating inheritance hierarchies on
the fly, with no loss in efficiency as far as I can tell at the moment.
(We have a paper on ContextL at this year's Joint Modular Languages
Conference where the implementation and a benchmark is described.)
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Jecel,
I didn't realize you lurked here (as you may not have realized I lurk in
[self-interest]). I hope I did not misrepresent Self too badly.
> Since current implementations don't handle [parent changing] very well it
> could be the case of everyone avoiding it due to performance reasons,
> but my guess is that it is a feature that simply looks better on paper
> than it does in practice.
Many beginner (and some intermediate!) APLers write loops instead of finding
array-primitive solutions. That's natural when coming from a scalar
language. Maybe coming from a class-based language like Smalltalk one
doesn't immediately see applications for changing the parent ("class") of an
object.
I find that the way an application programmer (who has already overcome
habits learned in other languages) uses a language depends strongly on the
way the supplied libraries (and other "found" code) have been written. In
Smalltalk, for example, adding methods to UndefinedObject could remove a lot
of conditionals from a lot of code, but it is "not done". If it *had* been
done in the early Smalltalk kernels, I think it would now be common
elsewhere.
The Self kernel probably doesn't use parent-changing very much (presumably
because of the performance problems you cite), and so sets the example that
it is "not done". Yet I liked (reading about) the pattern in Self of
defining "nil-like" behaviour for an object by changing its parent(s).
Perhaps nil could be done away with altogether. :)
Cheers, Paul