Home > Archive > Scheme > July 2006 > Code is data is code is data is ...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Code is data is code is data is ...
|
|
| Roberto Waltman 2006-06-24, 8:23 am |
| casioculture@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?
| |
| Darren New 2006-06-24, 8:23 am |
| 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.
| |
| Markus Triska 2006-06-24, 8:23 am |
| Roberto Waltman <usenet@rwaltman.net> writes:
> What other languages share this traits?
Prolog
| |
|
|
| phil chastney 2006-06-24, 8:23 am |
| 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
| |
| Jimserac 2006-06-24, 8:23 am |
|
Roberto Waltman wrote:
> casioculture@gmail.com wrote in comp.lang.lisp:
> Re: Is Forth a good complement to Lisp?
>
> 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 s ing 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
| |
| Chris Uppal 2006-06-24, 8:23 am |
| 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
| |
| Martin Neitzel 2006-06-24, 8:23 am |
| phil chastney wrote:
>
>(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
| |
| Chris Uppal 2006-06-24, 8:23 am |
| 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
| |
| David Given 2006-06-26, 8:04 am |
| On Fri, 23 Jun 2006 13:28:45 +0100, Chris Uppal wrote:
> Roberto Waltman wrote:
[...]
[...][color=darkred]
> 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
| dg@cowlark.com | specific things to say about killing?" "Quite
| (dg@tao-group.com) | specific. It is, however, somewhat fuzzier on the
+- www.cowlark.com --+ subject of kneecaps." --- Firefly, _War Stories_
| |
| Andrew Haley 2006-06-26, 7:07 pm |
| In comp.lang.forth David Given <dg@cowlark.com> wrote:
> On Fri, 23 Jun 2006 13:28:45 +0100, Chris Uppal wrote:
> [...]
> [...]
> in a
> [...]
> 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  it was, and never using it.
Andrew.
[1] I mean it's not very useful _in Forth_. I know Smalltalkers love
this stuff.
| |
| Roberto Waltman 2006-06-26, 7:07 pm |
| Andrew Haley wrote:
>In comp.lang.forth David Given <dg@cowlark.com> wrote:
>
>
>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.
;)
>
>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 it was, and never using it.
I did it also, although the rationale was not "the ness 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)
| |
| Trey Boudreau 2006-06-26, 7:07 pm |
| On 2006-06-26, David Given <dg@cowlark.com> wrote:
> On Fri, 23 Jun 2006 13:28:45 +0100, Chris Uppal wrote:
>
> [...]
> [...]
>
> 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
| |
| Albert van der Horst 2006-06-26, 7:07 pm |
| In article <129vrg4olufsi3f@news.supernews.com>,
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>In comp.lang.forth David Given <dg@cowlark.com> wrote:
<SNIP>
[color=darkred]
>
>
>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 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.
albert@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
| |
| Paul Chapman 2006-06-28, 7:03 pm |
| "Chris Uppal" <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
| |
| Rob Thorpe 2006-06-29, 4:03 am |
| David Given wrote:
> On Fri, 23 Jun 2006 13:28:45 +0100, Chris Uppal wrote:
>
> [...]
> [...]
> in a
> [...]
>
> 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.
| |
| Roberto Waltman 2006-06-29, 7:04 pm |
| Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: individual.net VL1Uvbncjk+0YroeEdK9VQaLP/o/jx6aaS8AE+LNxh0vGdzGGT
X-Newsreader: Forte Agent 3.3/32.846
Xref: number1.nntp.dca.giganews.com comp.lang.lisp:208166 comp.lang.scheme:65536 comp.lang.forth:108062 comp.lang.smalltalk:134292
"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?
| |
| Rob Thorpe 2006-06-29, 7:04 pm |
| Roberto Waltman wrote:
> "Rob Thorpe" wrote:
>
> 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.
| |
| Jerry Avins 2006-06-29, 7:04 pm |
| Roberto Waltman wrote:
> "Rob Thorpe" wrote:
>
> 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.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
| |
|
| 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
| |
| Ken Tilton 2006-06-29, 7:04 pm |
|
Jecel wrote:
> Paul Chapman wrote:
>
>
>
> 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
| |
| Pascal Costanza 2006-06-29, 7:04 pm |
| Ken Tilton wrote:
>
>
> Jecel wrote:
>
> 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/
| |
| Paul Chapman 2006-06-30, 7:03 pm |
| 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
| |
| Ibeam2000 2006-07-02, 4:00 am |
| > 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.
| |
| Christopher C. Stacy 2006-07-02, 8:00 am |
| "Ibeam2000" <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...)
|
|
|
|
|