On Feb 11, 2:24 pm, gavino <·········@gmail.com> wrote:
> http://en.wikipedia.org/wiki/REBOL
REBOL is a great language. While I wish it was more "open" like
Python, there are advantages to it being closed as well. Carl's done a
great job, just the development is slow. I use it regularly - almost
every day - at work and home, and it's incredibly productive.
It follows the same principles of Lisp (code is data) and Forth
(highly factored, simple code). It's focus is primarily around the
internet and admin/IT scripting. In fact, I tend to laugh at PG's Arc
code examples as an example of "terse, out-of-the-box, simple code"
when REBOL had that years ago - and with a *MUCH* smaller footprint.
Probably the biggest difference between Lisp and REBOL - from a simple
perspective, is that arguments to a REBOL function are known ahead of
time, making the parens just visual help for the reader (and there are
no macros, even though code is data). For example, using pseudo-code
Lisp for ease of comparing...
Lisp: (print (join "Hello" "world"))
REBOL: print join "Hello" "world"
Blocks in REBOL are like lists in Lisp, where they aren't actually
evaluated until requested. For example:
Lisp: (eval '(print "Hello, world!"))
REBOL: do [print "Hello, world!"]
And blocks can be passed around. This is similar to Smalltalk as well.
Under the hood, I have no idea if REBOL has roots in Lisp or not, but
as a medium for getting work done efficiently, REBOL is fantastic! I
do recommend taking a closer look at it, even if you don't need it
yourself.
Jeff M.
On Mon, 11 Feb 2008 14:21:47 -0800, Jeff M. wrote:
> On Feb 11, 2:24 pm, gavino <·········@gmail.com> wrote:
>> http://en.wikipedia.org/wiki/REBOL
>
> REBOL is a great language. While I wish it was more "open" like Python,
> there are advantages to it being closed as well. Carl's done a great
> job, just the development is slow. I use it regularly - almost every day
> - at work and home, and it's incredibly productive.
I've been using rebol for 8 years now, I do my development about 50/50
rebol and python, but the rebol development team's seeming indifference
to making the current version of rebol compatible with 64-bit GNU linux
systems platforms makes me *very* nervous. :-) Actually using rebol has
gotten me more interested in lisp......
Tim
"Jeff M." <·······@gmail.com> writes:
> On Feb 11, 2:24 pm, gavino <·········@gmail.com> wrote:
>> http://en.wikipedia.org/wiki/REBOL
>
> REBOL is a great language. While I wish it was more "open" like
> Python, there are advantages to it being closed as well. Carl's done a
> great job, just the development is slow. I use it regularly - almost
> every day - at work and home, and it's incredibly productive.
>
> It follows the same principles of Lisp (code is data) and Forth
> (highly factored, simple code). It's focus is primarily around the
> internet and admin/IT scripting. In fact, I tend to laugh at PG's Arc
> code examples as an example of "terse, out-of-the-box, simple code"
> when REBOL had that years ago - and with a *MUCH* smaller footprint.
>
> Probably the biggest difference between Lisp and REBOL - from a simple
> perspective, is that arguments to a REBOL function are known ahead of
> time, making the parens just visual help for the reader (and there are
> no macros, even though code is data). [...]
Could you prove to us that code is data in REBOL?
Just write a defmacro function in REBOL ;-)
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Could you prove to us that code is data in REBOL?
> Just write a defmacro function in REBOL ;-)
defmacro is not needed in rebol. I'm guessing that is
because rebol is a scripting language only.
Here is a function that I use, followed by an implementation:
It's a very simple usage of 'do
forline: func["For each line in file do code"
'line[word!] "word set to succesive lines in 'file"
file[file! string!] "file to read" code[block!] "code to execute"
/nobuffer "use unbuffered for speed"
][
either nobuffer[ ;; based on suggestion by Anton Reisacher
inf: open/direct/lines file
while [L: pick inf 1] [
set line L
do code
]
close inf
][
foreach l read/lines to-file file[
set line l
do code
]
]
]
;; implementation
;; iterate thru 'data-file, automatically initializing 'L
;; file I/0, iteration and code-block handled by forline
forline L data-file[
configure-line L pl ln
++ ln
]
;; I've studied common lisp some, in preperation for implementing some kind
of lisp if clients need such, I can tell by "Practical Common Lisp" that
CL is much more advanced in this area .... Not sure if this 'proves'
anything, but it works for me.
cheers
tim
In article <···············@news.supernews.com>,
Tim Johnson <···@johnsons-web.com> wrote:
> Pascal J. Bourguignon wrote:
>
>
> > Could you prove to us that code is data in REBOL?
> > Just write a defmacro function in REBOL ;-)
>
> defmacro is not needed in rebol. I'm guessing that is
> because rebol is a scripting language only.
> Here is a function that I use, followed by an implementation:
> It's a very simple usage of 'do
> forline: func["For each line in file do code"
> 'line[word!] "word set to succesive lines in 'file"
> file[file! string!] "file to read" code[block!] "code to execute"
> /nobuffer "use unbuffered for speed"
> ][
> either nobuffer[ ;; based on suggestion by Anton Reisacher
> inf: open/direct/lines file
> while [L: pick inf 1] [
> set line L
> do code
> ]
> close inf
> ][
> foreach l read/lines to-file file[
> set line l
> do code
> ]
> ]
> ]
> ;; implementation
> ;; iterate thru 'data-file, automatically initializing 'L
> ;; file I/0, iteration and code-block handled by forline
> forline L data-file[
> configure-line L pl ln
> ++ ln
> ]
> ;; I've studied common lisp some, in preperation for implementing some kind
> of lisp if clients need such, I can tell by "Practical Common Lisp" that
> CL is much more advanced in this area .... Not sure if this 'proves'
> anything, but it works for me.
> cheers
> tim
I would think that this is due to blocks being 'thunks'.
In Lisp a macro version would look similar to:
(defmacro with-lines (line file &body body)
(let ((stream (gensym)))
`(with-open-file (,stream ,file)
(loop for ,line = (read-line ,stream nil nil)
while line
do (progn
,@body)))))
A functional version would be like:
(defun call-with-lines (file block)
(with-open-file (stream file)
(loop for line = (read-line stream nil nil)
while line
do (funcall block line))))
(call-with-lines
"foo.text"
(lambda (line)
(blabla ...))))
The latter is a bit similar to the Rebol version. The way
how variables are resolved maybe a bit different. But
DO in Rebol would be then similar to FUNCALL in Lisp
and Rebol blocks would be anonymous functions in Lisp.
DO takes a block and forces the evaluation. That's
like FUNCALL applied to a function. Note that
this version of delayed blocks and forced execution
is different from what macros are doing. Macros
are source transformers that create new code and thus
can do much more. Compare also other languages which are
doing lazy evaluation by default.
Cool! I must save that for when I tackle CL.
thnx
tj
Rainer Joswig wrote:
> (defmacro with-lines (line file &body body)
> (let ((stream (gensym)))
> `(with-open-file (,stream ,file)
> (loop for ,line = (read-line ,stream nil nil)
> while line
> do (progn
> ,@body)))))
>
> A functional version would be like:
>
> (defun call-with-lines (file block)
> (with-open-file (stream file)
> (loop for line = (read-line stream nil nil)
> while line
> do (funcall block line))))
>
> (call-with-lines
> "foo.text"
> (lambda (line)
> (blabla ...))))
>
> The latter is a bit similar to the Rebol version. The way
> how variables are resolved maybe a bit different. But
> DO in Rebol would be then similar to FUNCALL in Lisp
> and Rebol blocks would be anonymous functions in Lisp.
> DO takes a block and forces the evaluation. That's
> like FUNCALL applied to a function. Note that
> this version of delayed blocks and forced execution
> is different from what macros are doing. Macros
> are source transformers that create new code and thus
> can do much more. Compare also other languages which are
> doing lazy evaluation by default.
On Feb 12, 1:26 pm, Rainer Joswig <······@lisp.de> wrote:
> In article <···············@news.supernews.com>,
>
> .... But
> DO in Rebol would be then similar to FUNCALL in Lisp
> and Rebol blocks would be anonymous functions in Lisp.
> DO takes a block and forces the evaluation. That's
> like FUNCALL applied to a function.
I'd equate DO in REBOL to be like EVAL in Lisp, because block
arguments aren't actually reduced until you ask them to be (much like
lists in Lisp). Consider:
--
'(progn
(setf msg "Hello, world!")
(format t msg))
msg ==> unbound variable
(eval '(progn
(setf msg "Hello, world!")
(format t msg)))
msg ==> "Hello, world!"
--
In REBOL, that would be very similar to this:
[msg: "Hello, world!" print msg]
msg ==> unbound variable
do [msg: "Hello, world!" print msg]
msg ==> "Hello, world!"
DO in REBOL, however, happens to allow you to pass many different
arguments to it, like a function and then consume the arguments it
needs to execute it.
do :print "Hello, world!"
So it can _act_ like FUNCALL, but is probably closer to EVAL in
implementation.
Jeff M.
In article
<····································@l32g2000hse.googlegroups.com>,
"Jeff M." <·······@gmail.com> wrote:
> On Feb 12, 1:26 pm, Rainer Joswig <······@lisp.de> wrote:
> > In article <···············@news.supernews.com>,
> >
> > .... But
> > DO in Rebol would be then similar to FUNCALL in Lisp
> > and Rebol blocks would be anonymous functions in Lisp.
> > DO takes a block and forces the evaluation. That's
> > like FUNCALL applied to a function.
>
> I'd equate DO in REBOL to be like EVAL in Lisp, because block
> arguments aren't actually reduced until you ask them to be (much like
> lists in Lisp). Consider:
The evaluation model is probably a bit different from current
Common Lisp, right.
>
> --
> '(progn
> (setf msg "Hello, world!")
> (format t msg))
>
> msg ==> unbound variable
>
> (eval '(progn
> (setf msg "Hello, world!")
> (format t msg)))
>
> msg ==> "Hello, world!"
>
>
>
> --
> In REBOL, that would be very similar to this:
>
> [msg: "Hello, world!" print msg]
>
> msg ==> unbound variable
>
> do [msg: "Hello, world!" print msg]
>
> msg ==> "Hello, world!"
That would be no different from a lambda version in most Lisps:
(lambda ()
(setf msg "Hello, world!")
(format t msg))
msg -> unbound variable
(funcall
(lambda ()
(setf msg "Hello, world!")
(format t msg)))
msg -> "Hello, world!"
> DO in REBOL, however, happens to allow you to pass many different
> arguments to it, like a function and then consume the arguments it
> needs to execute it.
>
> do :print "Hello, world!"
>
> So it can _act_ like FUNCALL, but is probably closer to EVAL in
> implementation.
>
> Jeff M.
Joe Marshall has a little text about Rebol 1.0 evaluation:
http://ll1.ai.mit.edu/marshall.html
There even is some Scheme code on his homepage:
http://code.google.com/p/jrm-code-project/wiki/BitsAndPieces
The code also works in MzScheme (as some other recently
popular languages ;-) ).
Though, no Rebol 2.0 .