Hi,
1. What could be another example of a language which provide such an
interactive development environment ? (better if examples are from
procedural / OO programming languages).
2. Does the full lisp implementation (by implementation I mean 1. the
compiler/interpreter 2. packages) is being integrated with the
compiled standalone application which is ready to be executed from
UNIX shell?
3. I came to know that LISP is not pure functional programming
language. Is this true? If yes, can we write procedural oriented
programs in LISP ?
4. Do we have all the features of a procedural oriented programming
language built into LISP ?
5. In what way LISP is different from Haskell(which is a pure
functional language)?
6. Do all functional programming languages provide interactive working
environment? Is there any functional language which provides same kind
of environment as a procedural language?
7. When we say some LISP implementations provide options to compile a
stand alone LISP application to byte code, do we think of a Java kind
of environment there? That means, we have a LISP Virtual Machine and
our code (which has been compiled to byte code) runs on top of it ?
Thanks a lot.
Srinu.
Srinu wrote:
> 1. What could be another example of a language which provide such an
> interactive development environment ? (better if examples are from
> procedural / OO programming languages).
Well the environment provided for Eiffel is interactive in a similar
way. See: www.eiffel.com for details.
Eiffel is a static typed fully OO language that has a family resemblance
to ADA and Pascal.
Ts
On Aug 20, 6:41 am, Srinu <··············@gmail.com> wrote:
> Hi,
>
> 1. What could be another example of a language which provide such an
> interactive development environment ? (better if examples are from
> procedural / OO programming languages).
There are none. Ruby comes a little close.
> 2. Does the full lisp implementation (by implementation I mean 1. the
> compiler/interpreter 2. packages) is being integrated with the
> compiled standalone application which is ready to be executed from
> UNIX shell?
Most Common Lisp systems have a way to save an image, which you've
presumably prepared with everything you want loaded (including your
"program"), and most have a way of loading a saved image from the
command line so that it immediately starts in whatever state you've
saved it. Some systems have a way of creating a stand-alone executable
as well, usually as a simple executable wrapper around loading the
saved image. (Note that the concept of a "stand alone executable" is
not something Common Lisp is directly concerned with. This takes a
little getting used to when coming from a C/C++/whatever-compiled-
language background. IMHO the Lisp way is vastly superior when
developing code.)
> 3. I came to know that LISP is not pure functional programming
> language. Is this true? If yes, can we write procedural oriented
> programs in LISP ?
Yes. You can write relatively pure functional programs in Common Lisp
if you want, and you can write "pure" (*cough*) procedural programs in
Lisp if you want. You can write heavily object-oriented code in Common
Lisp (see CLOS), or you can avoid object-oriented programming entirely
if you don't want to use it. Common Lisp gives you the flexibility to
use just about any coding style you prefer.
> 4. Do we have all the features of a procedural oriented programming
> language built into LISP ?
Yes, and more. Much more.
> 5. In what way LISP is different from Haskell(which is a pure
> functional language)?
See the answer to number 3.
> 6. Do all functional programming languages provide interactive working
> environment? Is there any functional language which provides same kind
> of environment as a procedural language?
The development environment provided by a Common Lisp system is light
years ahead of the write-code/save-file/compile-file/make-and-link-
project/debug/repeat "environment"... I don't think I understand the
question.
> 7. When we say some LISP implementations provide options to compile a
> stand alone LISP application to byte code, do we think of a Java kind
> of environment there? That means, we have a LISP Virtual Machine and
> our code (which has been compiled to byte code) runs on top of it ?
>
Many (most?) Common Lisp systems compile to machine code (with the
exception of CLIPS which only compiles to byte code). Corman Lisp for
Windows, for instance, *only* compiles to machine code, there isn't
even an option to compile to byte code (which admittedly makes
following a backtrace a little difficult sometimes in that system).
This compiled code is usually every bit as fast as the compiled code
of traditional procedural languages, and much faster than the byte-
code of, say, Python and Ruby, or even the Java VM (note however that
Java can also be compiled to machine code in certain circumstances).
However, this compilation to machine code is done interactive. It's
not the same as compiling your C/C++ program (again, I know this
concept takes a little getting used to).
> Thanks a lot.
> Srinu.
You're welcome!
Srinu wrote:
> Hi,
>
> 1. What could be another example of a language which provide such an
> interactive development environment ? (better if examples are from
> procedural / OO programming languages).
all the smalltalks, ruby, python
> 2. Does the full lisp implementation (by implementation I mean 1. the
> compiler/interpreter 2. packages) is being integrated with the
> compiled standalone application which is ready to be executed from
> UNIX shell?
Yes it is. For small utilities i believe there was a recent discussion
on c.l.l. about keeping the lisp running and executing the
scripts/programs via a local socket. Also some lisps allow for so called
"tree shacking" which will remove most useless code from the executable
being created.
> 3. I came to know that LISP is not pure functional programming
> language. Is this true? If yes, can we write procedural oriented
> programs in LISP ?
Lisp allows for procedural/oo/functional. It is very very very good at
procedural programming, as well as oo. My personal feeling is that it's
not the very best when doing purely functional (they'll flame me to
death now). For dynamic fp use scheme (also impure though) or erlang,
for statically typed fp use haskell.
> 4. Do we have all the features of a procedural oriented programming
> language built into LISP ?
All the usual features, and way more.
> 5. In what way LISP is different from Haskell(which is a pure
> functional language)?
Haskell is a pure functional language, with lazy evaluation. Lisp is
impure (allows for a function to return different values when being
called with same parameters) and like for C evaluation is strict.
> 6. Do all functional programming languages provide interactive working
> environment? Is there any functional language which provides same kind
> of environment as a procedural language?
Not all functional languages allow interactive development. Many of them
have a REPL though, but few have it so well integrated as lisp.
Haskell and OCaml (hello Jon) have the same kind of development cycle as
C. Their type system is pretty hairy though.
> 7. When we say some LISP implementations provide options to compile a
> stand alone LISP application to byte code, do we think of a Java kind
> of environment there? That means, we have a LISP Virtual Machine and
> our code (which has been compiled to byte code) runs on top of it ?
>
CLisp (own byte code) and Armed bear CL (java byte code) are the two CLs
compiling to byte code, they indeed have a VM. Other implementations
are compiling to native (lispworks, allegro, sbcl, cmucl). These last 4
allow for creating standalone executables, I'm not sure about the first 2.
Sacha
Sacha <····@address.spam> writes:
> Srinu wrote:
>> Hi,
>> 1. What could be another example of a language which provide such an
>> interactive development environment ? (better if examples are from
>> procedural / OO programming languages).
>
> all the smalltalks, ruby, python
>
>> 2. Does the full lisp implementation (by implementation I mean 1. the
>> compiler/interpreter 2. packages) is being integrated with the
>> compiled standalone application which is ready to be executed from
>> UNIX shell?
>
> Yes it is. For small utilities i believe there was a recent discussion
> on c.l.l. about keeping the lisp running and executing the
> scripts/programs via a local socket. Also some lisps allow for so
> called "tree shacking" which will remove most useless code from the
> executable being created.
>
>> 3. I came to know that LISP is not pure functional programming
>> language. Is this true? If yes, can we write procedural oriented
>> programs in LISP ?
>
> Lisp allows for procedural/oo/functional. It is very very very good at
> procedural programming, as well as oo. My personal feeling is that
> it's not the very best when doing purely functional (they'll flame me
> to death now). For dynamic fp use scheme (also impure though) or
> erlang, for statically typed fp use haskell.
>
>> 4. Do we have all the features of a procedural oriented programming
>> language built into LISP ?
>
> All the usual features, and way more.
>
>> 5. In what way LISP is different from Haskell(which is a pure
>> functional language)?
>
> Haskell is a pure functional language, with lazy evaluation. Lisp is
> impure (allows for a function to return different values when being
> called with same parameters) and like for C evaluation is strict.
>
>> 6. Do all functional programming languages provide interactive working
>> environment? Is there any functional language which provides same kind
>> of environment as a procedural language?
>
> Not all functional languages allow interactive development. Many of
> them have a REPL though, but few have it so well integrated as lisp.
>
> Haskell and OCaml (hello Jon) have the same kind of development cycle
> as C. Their type system is pretty hairy though.
>
>> 7. When we say some LISP implementations provide options to compile a
>> stand alone LISP application to byte code, do we think of a Java kind
>> of environment there? That means, we have a LISP Virtual Machine and
>> our code (which has been compiled to byte code) runs on top of it ?
>>
>
> CLisp (own byte code) and Armed bear CL (java byte code) are the two
> CLs compiling to byte code, they indeed have a VM. Other
> implementations are compiling to native (lispworks, allegro, sbcl,
> cmucl). These last 4 allow for creating standalone executables, I'm
> not sure about the first 2.
clisp indeed can create standalone executables (IIRC sbcl even copied
the code from clisp to implement its own standalone executables).
For ABCL, I don't know, but I'd bet you can create jar files from CL
code with ABCL as with any other JVM compiler.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Pascal Bourguignon <···@informatimago.com> wrote:
> clisp indeed can create standalone executables (IIRC sbcl even copied
> the code from clisp to implement its own standalone executables).
IIRC, you have made that claim earlier, and been told that it's not
true. Could you please remember better the next time around?
The license that clisp uses is viral, and derivative works of it may
not be redistributed except under certain terms that are more
restrictive than the ones in the sbcl license. If code were copied
from clisp to sbcl, people distributing sbcl would thus be infringing
on the copyright of Sam or Bruno. I hope that you see that accusations
like these are potentially harmful.
If you truly believe that the code in question has been copied from
clisp to sbcl (it should be obvious from inspecting the code that this
is not the case), please contact the sbcl-devel mailing list about the
matter so that it can be resolved. If not, it'd be great if you
stopped spreading the rumour.
--
Juho Snellman
Juho Snellman <······@iki.fi> writes:
> Pascal Bourguignon <···@informatimago.com> wrote:
>> clisp indeed can create standalone executables (IIRC sbcl even copied
>> the code from clisp to implement its own standalone executables).
>
> IIRC, you have made that claim earlier, and been told that it's not
> true. Could you please remember better the next time around?
>
> The license that clisp uses is viral, and derivative works of it may
> not be redistributed except under certain terms that are more
> restrictive than the ones in the sbcl license. If code were copied
> from clisp to sbcl, people distributing sbcl would thus be infringing
> on the copyright of Sam or Bruno. I hope that you see that accusations
> like these are potentially harmful.
>
> If you truly believe that the code in question has been copied from
> clisp to sbcl (it should be obvious from inspecting the code that this
> is not the case), please contact the sbcl-devel mailing list about the
> matter so that it can be resolved. If not, it'd be great if you
> stopped spreading the rumour.
Right, it wasn't the code, but the idea. I remember that standalone
executables were implemented in clisp before sbcl, and this is what I
meant to express.
I don't mean to spread any rumor, it's only that I don't make a lot of
difference between idea and code, and despise license questions in general.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Pascal Bourguignon <···@informatimago.com> wrote:
> Right, it wasn't the code, but the idea. I remember that standalone
> executables were implemented in clisp before sbcl, and this is what I
> meant to express.
Ok. That's not really correct either.
There was an earlier standalone executable patch for sbcl, made months
before the feature was added to clisp. This was done by Timmy Douglas
and basically worked by storing the core in an elf segment using
libelf. This was largerly a port of an earlier experimental cmucl
path by Fred Gilham from years earlier. Timmy's patch wasn't merged
for complexity reasons. James Bielman then implemented a fresh set of
changes which worked by appending the core to the executable file. He
attributed this implementation strategy to OpenMCL, where it had also
been used for years.
So there's not really a case to be made for tracing the idea to clisp.
--
Juho Snellman
On Aug 21, 11:03 am, Juho Snellman <······@iki.fi> wrote:
> Pascal Bourguignon <····@informatimago.com> wrote:
> > Right, it wasn't the code, but the idea. I remember that standalone
> > executables were implemented in clisp before sbcl, and this is what I
> > meant to express.
>
> Ok. That's not really correct either.
>
> There was an earlier standalone executable patch for sbcl, made months
> before the feature was added to clisp. This was done by Timmy Douglas
> and basically worked by storing the core in an elf segment using
> libelf. This was largerly a port of an earlier experimental cmucl
> path by Fred Gilham from years earlier. Timmy's patch wasn't merged
> for complexity reasons. James Bielman then implemented a fresh set of
> changes which worked by appending the core to the executable file. He
> attributed this implementation strategy to OpenMCL, where it had also
> been used for years.
>
> So there's not really a case to be made for tracing the idea to clisp.
>
> --
> Juho Snellman
Hi All,
It is so nice to have gathered a lot of information about Lisp. I
thank all of you for your valuable time to gather them and write it
down. With best regards.
Srinu
(message (Hello 'Pascal)
(you :wrote :on '(Tue, 21 Aug 2007 05:11:49 +0200))
(
PB> For ABCL, I don't know, but I'd bet you can create jar files from CL
PB> code with ABCL as with any other JVM compiler.
it's not possible -- ABCL is very unusual JVM compiler :).
for each compiled file it creates Java class file for each function/closure
(yes, that's overkill..) and Lisp "loader" file -- that loads those class
files, binds functions to names, defines variables etc (Java classes are
unusable without that loader)..
then it packs all that stuff into a zip file -- certainly zip with Java
classes looks like jar, but Java won't be able to load it directly. it's
just a FASL file.
however, i think it would be easy to include compiled user files into
abcl.jar with ABCL runtime, and make user init file autoloadable -- that
will create directly launchable jar file. there was just not enough interest
in such stuff so far..
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"choose no life")
Sacha <····@address.spam> wrote:
+---------------
| CLisp (own byte code) and Armed bear CL (java byte code) are the two CLs
| compiling to byte code, they indeed have a VM. Other implementations
| are compiling to native (lispworks, allegro, sbcl, cmucl). These last 4
| allow for creating standalone executables, I'm not sure about the first 2.
+---------------
Slight correction: CMUCL can *also* compile to byte codes as well as
machine code, and single programs can contain mixtures of functions
that are interpreted (not compiled[1]), byte-compiled, or fully compiled
to machine code. There is automatic conversion of the calling sequences
as necessary.
-Rob
[1] Or rather, only minimally compiled, in the sense of CLHS
3.2.2.2 "Minimal Compilation". That is, even in CMUCL
interpreted code, macros are only expanded once, the first
time the interpreted function is called. [CMUCL internally
calls this process "conversion".] For example:
cmu> (defmacro foo (x)
(format *debug-io* "; FOO expanded~%")
`(+ ,x 3))
FOO
cmu> (defun bar (y)
(+ 5 (foo y)))
BAR
cmu> (bar 10)
; FOO expanded
18
cmu> (bar 15)
23
cmu>
Note that no "FOO expanded" message was printed on the
second call to BAR.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
P� Mon, 20 Aug 2007 13:41:54 +0200, skrev Srinu <··············@gmail.com>:
> Hi,
>
> 1. What could be another example of a language which provide such an
> interactive development environment ? (better if examples are from
> procedural / OO programming languages).
Smalltalk (Squeak)
> 2. Does the full lisp implementation (by implementation I mean 1. the
> compiler/interpreter 2. packages) is being integrated with the
> compiled standalone application which is ready to be executed from
> UNIX shell?
Not sure what you mean but I would guess CLisp
> 3. I came to know that LISP is not pure functional programming
> language. Is this true? If yes, can we write procedural oriented
> programs in LISP ?
Yes
> 4. Do we have all the features of a procedural oriented programming
> language built into LISP ?
setf, defvar, defparameter
> 5. In what way LISP is different from Haskell(which is a pure
> functional language)?
It has free variables and does not need Curry and Monads
> 6. Do all functional programming languages provide interactive working
> environment? Is there any functional language which provides same kind
> of environment as a procedural language?
dylan
> 7. When we say some LISP implementations provide options to compile a
> stand alone LISP application to byte code, do we think of a Java kind
> of environment there? That means, we have a LISP Virtual Machine and
> our code (which has been compiled to byte code) runs on top of it ?
Clisp implemetation provide a lisp spesific byte code
Armered bear CL compiles to Java bytecode.
>
> Thanks a lot.
> Srinu.
Hope that gives you a few hints.
P� Mon, 20 Aug 2007 14:01:38 +0200, skrev John Thingstad
<··············@chello.no>:
>
> Clisp implemetation provide a lisp spesific byte code
> Armered bear CL compiles to Java bytecode.
I should add that most other compilers compile to machine code.
(message (Hello 'Srinu)
(you :wrote :on '(Mon, 20 Aug 2007 11:41:54 -0000))
(
S> 2. Does the full lisp implementation (by implementation I mean 1. the
S> compiler/interpreter 2. packages) is being integrated with the
S> compiled standalone application which is ready to be executed from
S> UNIX shell?
most UNIX programs link with libc. does this mean that full C runtime is
integrated with it?
it would be a waste of resources to link everything statically, so typically
dynamical linking is used -- libs are already installed in UNIX system, and
program itself just has a pointers what to load and use.
it would be even more waste of resources to include whole Lisp runtime into
each compiled application. (yes, typically it would include compiler and
everything)
thus, it's better not to use "compiled standalone applications" unless
absolutely required.
so, if you're targeting UNIX systems, you'd better assume that Lisp
implementation and libraries are already installed into system as
dependencies (as do most C programs assume that libc and other libraries are
installed), and have your program just as a small script.
it can be implemented in various ways -- either you package most your
applications as a "library", and script itself just loads that library and
callls "entry point". or it could be compiled "FASL" file -- but it would
contain only stuff you have compiled and require working Lisp runtime.
this depends on your goals and nature of your application a lot. if you will
be shipping some product, you'd prefer whole Lisp system to be included in
it -- but typically product is not just a small script anyway, so that
wouldn't matter much.
S> 3. I came to know that LISP is not pure functional programming
S> language. Is this true?
yeah, because it encourages mutating data and does not guarantee tail call
optimization
S> If yes, can we write procedural oriented programs in LISP ?
"procedural-oriented" is a very weird term, basically meaning nothing.
you can think that most programs in Common Lisp are "procedural oriented" :)
S> 4. Do we have all the features of a procedural oriented programming
S> language built into LISP ?
can you list such features?
i know only one -- you can define procedures. indeed, you can define
procedures in Lisp and even call them. so, i think, it supports all feature.
i suspect you actually was going to ask if you can programm in Lisp as you
do in C.
yes, basically it could be very close to C/C++, and even closer to
Python/JavaScript.
there are just additional features, but you're free not to use them.
S> 5. In what way LISP is different from Haskell(which is a pure
S> functional language)?
in all ways.
Lisp is known not for it functional features (although there were times when
it was one of rare functional-oriented languages), but for macro facilities.
Haskell is very good functional languages, but it has almost no macro
facilities.
S> 6. Do all functional programming languages provide interactive working
S> environment?
no
S> Is there any functional language which provides same kind
S> of environment as a procedural language?
you mean where programs are compiled, and then executed? there are such.
"functional programming languages" label doesn't have certain meaning too.
there are some features that are associated with functional programming, but
not all languages have them.
for example, first-class functions/higher-order functions and closures were
once a cool "functional programming" feature. but now widely used JavaScript
language has them. so, millions of web developers using JavaScript are doing
functional programming? that's nonsense.
S> 7. When we say some LISP implementations provide options to compile a
S> stand alone LISP application to byte code, do we think of a Java kind
S> of environment there? That means, we have a LISP Virtual Machine and
S> our code (which has been compiled to byte code) runs on top of it ?
no, sometimes it can work in Java way, sometimes it compiles to native
code -- so you can even get your segfault :).
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"choose no life")
On Mon, 20 Aug 2007 11:41:54 -0000, Srinu <··············@gmail.com>
wrote:
>Hi,
>
>1. What could be another example of a language which provide such an
>interactive development environment ? (better if examples are from
>procedural / OO programming languages).
Smalltalk is probably the best current example. Active Oberon is
another example (albeit an offbeat one).
Have you ever heard of Rational-C? It was a C-with-objects (not C++)
development system in the 1980's that featured function level
incremental compiling and provided a REPL for fully interactive
exploration and debugging. It died out as C++ became more popular and
Borland and Microsoft flooded the market with cheap compilers.
There are C/C++ interpreters, "Ch" for example, which have interactive
programming and function level interactive debugging.
>2. Does the full lisp implementation (by implementation I mean 1. the
>compiler/interpreter 2. packages) is being integrated with the
>compiled standalone application which is ready to be executed from
>UNIX shell?
Not generally. While you program, the Lisp image includes the entire
language, your code and the code for any additional packages you may
have loaded. The Lisps that create "normal" executables typically
determine what functions your program actually uses and strip out
everything else to produce a smaller deliverable image. The
deliverable image is then bound to a small runtime/support program
that sets up the environment and launches the image.
>3. I came to know that LISP is not pure functional programming
>language. Is this true? If yes, can we write procedural oriented
>programs in LISP ?
>4. Do we have all the features of a procedural oriented programming
>language built into LISP ?
You can write mostly procedural code, but most code is a mix of
functional and procedural style. OO code in Lisp (CLOS) is based on
generic functions so it is also mainly functional/procedural.
FWIW, Common Lisp has assignment, nested block structure, labels and
goto, non-local goto, non-local return, etc. Many high level control
structures (including loops) are actually macros built from these
procedural primitives.
>5. In what way LISP is different from Haskell(which is a pure
>functional language)?
Lisp has both lexically and dynamically scoped variables. Lisp
functions are variadic, Haskell internally curries everything to
single parameter functions. Lisp permits side effecting code
anywhere, Haskell restricts side effecting code to monads.
>6. Do all functional programming languages provide interactive working
>environment?
Most have a REPL but the level of integration and ease of use varies.
In most languages (including Lisp), coding is done in an editor and
the REPL tends to be used mainly for debugging and exploration because
REPLs are typically command oriented rather than code oriented.
However, Lisp's REPL is code oriented and tightly integrated with the
system. While it is not easy to edit complex code using it, complex
code can easily be fed to it. What makes Lisp unique among the
interactive languages is the availability of IDEs that integrate code
editing with access to the interactive facilities of the REPL.
Emacs/SLIME can work with almost any Lisp and the commercial Lisps
have their own GUI based IDEs. Eclipse has some Lisp integration
plug-ins of various quality. There are also some good commercial code
editors (e.g., Codewright, CodeWarrior) that can be configured to
integrate with external interactive tools.
>Is there any functional language which provides same kind
>of environment as a procedural language?
Almost all provide some kind of batch compile mode - you can
deliberately choose not to use them interactively. In some the
compiler is only available in batch mode, the REPL being only
interpretive or only for exploring and debugging already compiled
code.
>7. When we say some LISP implementations provide options to compile a
>stand alone LISP application to byte code, do we think of a Java kind
>of environment there? That means, we have a LISP Virtual Machine and
>our code (which has been compiled to byte code) runs on top of it ?
Yes. Some, like CLisp, use a proprietary VM. Others, like ABCL,
target the Java VM. Eventually there may be a CL that targets .NET.
There are some good open source VMs available and probably there exist
Lisps or Schemes (though not Common Lisps) that target some of them.
BTW: Lisp is spelled "Lisp". "LISP" is deprecated.
George
--
for email reply remove "/" from address
George Neuner <·········@comcast.net> writes:
> On Mon, 20 Aug 2007 11:41:54 -0000, Srinu <··············@gmail.com>
> wrote:
>
>>Hi,
>>
>>1. What could be another example of a language which provide such an
>>interactive development environment ? (better if examples are from
>>procedural / OO programming languages).
>
> Smalltalk is probably the best current example. Active Oberon is
> another example (albeit an offbeat one).
FORTH is another good example.
>>6. Do all functional programming languages provide interactive working
>>environment?
>
> Most have a REPL but the level of integration and ease of use
> varies. In most languages (including Lisp), coding is done in an
> editor and the REPL tends to be used mainly for debugging and
> exploration because REPLs are typically command oriented rather than
> code oriented.
That is true *most* of the time, though not always.
The notable counterexample is Siskind's "STALIN" compiler, which takes
Scheme --> C --> object code, with no REPL in the way.
--
"cbbrowne",·@","cbbrowne.com"
http://linuxdatabases.info/info/unix.html
If the FreeBSD team could get away with it, they would probably use
warnings like "Contains live plague bacteria. Beware the Rabid
Hippopotami. May cause nausea and vomiting."
-- Michael Lucas, re: FreeBSD-CURRENT
On Mon, 20 Aug 2007 22:57:27 GMT, Christopher Browne
<········@ca.afilias.info> wrote:
>George Neuner <·········@comcast.net> writes:
>> On Mon, 20 Aug 2007 11:41:54 -0000, Srinu <··············@gmail.com>
>> wrote:
>
>>>6. Do all functional programming languages provide interactive working
>>>environment?
>>
>> Most have a REPL but the level of integration and ease of use
>> varies. In most languages (including Lisp), coding is done in an
>> editor and the REPL tends to be used mainly for debugging and
>> exploration because REPLs are typically command oriented rather than
>> code oriented.
>
>That is true *most* of the time, though not always.
>
>The notable counterexample is Siskind's "STALIN" compiler, which takes
>Scheme --> C --> object code, with no REPL in the way.
There are always counter-examples.
The native compilers for Ocaml, Chicken, Bigloo and Dylan are batch
mode only. Ocaml has a separate interactive bytecode compiler and
Chicken has a separate interpreter. Dylan and Bigloo both have
built-in functions for providing user mode REPLs but their compilers
do not use them.
And as I said in the other post, most interactive implementations also
have a command line, batch compile mode (it's immaterial whether that
might internally involve a REPL - the user doesn't see it).
George
--
for email reply remove "/" from address
On Mon, 20 Aug 2007 22:57:27 GMT, Christopher Browne
<········@ca.afilias.info> wrote:
Post got lost somehow ... trying again.
>George Neuner <·········@comcast.net> writes:
>> On Mon, 20 Aug 2007 11:41:54 -0000, Srinu <··············@gmail.com>
>> wrote:
>>
>>>1. What could be another example of a language which provide such an
>>>interactive development environment ? (better if examples are from
>>>procedural / OO programming languages).
>>
>> Smalltalk is probably the best current example. Active Oberon is
>> another example (albeit an offbeat one).
>
>FORTH is another good example.
I thought about Forth. It's a great example of a powerful interactive
development language, but I consider Forth more functional than
procedural. Rightly or wrongly, I tend to place Forth very close to
Lisp in the spectrum of languages because they have similar
capabilities. I don't really consider Lisp as procedural either
although one can write procedural code with it.
George
--
for email reply remove "/" from address
On Mon, 20 Aug 2007 22:57:27 +0000, Christopher Browne wrote:
>>>1. What could be another example of a language which provide such an
>>>interactive development environment ? (better if examples are from
>>>procedural / OO programming languages).
>>
>> Smalltalk is probably the best current example. Active Oberon is
>> another example (albeit an offbeat one).
>
> FORTH is another good example.
Bourne shell? Tclsh/wish? Old-school BASIC?
--
Andrew
On Tue, 21 Aug 2007 13:43:53 +1000, Andrew Reilly
<···············@areilly.bpc-users.org> wrote:
>On Mon, 20 Aug 2007 22:57:27 +0000, Christopher Browne wrote:
>
>>>>1. What could be another example of a language which provide such an
>>>>interactive development environment ? (better if examples are from
>>>>procedural / OO programming languages).
>
>Bourne shell? Tclsh/wish? Old-school BASIC?
Old school (aka Dartmouth) BASIC was edit-compile-run. IIRC, the
first interactive BASICs were for the Intel 8080 (and no, Bill Gates's
version was not the first).
But yes, micro BASIC is a good example.
George
--
for email reply remove "/" from address