begin vs. do
-
- Posts: 608
- Joined: Mon Feb 05, 2007 1:04 am
- Location: Abbotsford, BC
- Contact:
begin vs. do
I was just reading the wikipedia article on REXX tonight, after reading their article on COBOL. I was struck with how elegant REXX is. Not as LISP, mind you, but it had a couple nice things. I believe the (begin... construct came from the BASIC language. Right? In REXX, "do" serves the same role. If it isn't a reserved word, (I believe it isn't) I will start doing (constant 'do begin) and starting using (do...) in my code instead of (begin...)
Lutz, thanks for incorporating those $prefix type changes! In the next couple months I will try to implement an OpenBSD "port", or "package", of newlisp. There used to be one, I don't know why it was dumped.
Ted
Lutz, thanks for incorporating those $prefix type changes! In the next couple months I will try to implement an OpenBSD "port", or "package", of newlisp. There used to be one, I don't know why it was dumped.
Ted
-
- Posts: 388
- Joined: Thu May 08, 2008 1:24 am
- Location: Croatia
- Contact:
"begin" is used in many very descriptive languages (even ada, modula2 and modula3, and even other "modern" language like pl/sql (oracle) based on ada, use that so long construct).
I agree with you, "do" fits better, but warning: it could be "confused" with something like "eval". In fact there are other functional languages that use it in this way (see Rebol at:
http://www.rebol.com/docs/words/wdo.html)
I agree with you, "do" fits better, but warning: it could be "confused" with something like "eval". In fact there are other functional languages that use it in this way (see Rebol at:
http://www.rebol.com/docs/words/wdo.html)
--
I think do is ambiguous. In some languages like Lua, Euphoria it is used to begin a block but it probably evals the block too. In any rate one would think so.
dotimes and dolist (in NewLISP) gives me the same impression. I think that begin is more expressive even if we don't find the correlated end, useless in NewLISP because of the (closing/ending) brackets.
We could say "block" instead of "begin" but IMHO it's not a very pretty word
;-)
P.S.: finally a block with begin is evaluated too. So ... do or begin ?
dotimes and dolist (in NewLISP) gives me the same impression. I think that begin is more expressive even if we don't find the correlated end, useless in NewLISP because of the (closing/ending) brackets.
We could say "block" instead of "begin" but IMHO it's not a very pretty word
;-)
P.S.: finally a block with begin is evaluated too. So ... do or begin ?
Bertrand − newLISP v.10.7.6 64-bit on Linux (Linux Mint 20.1)
This is an important point: even if newLisp is not Lisp, I think if there are some "compatibilities" they could simplify user "migration".HPW wrote:And people coming from autolisp use (constant 'progn begin)!
;-)
"block" could fit very well, but if the starting point of this discussion was finding a shorter word than "begin", I think "block" will cause incompatibilities but will not give a big benefit.
I think we could really round the corner with a hard solution: why don't we try to use a symbol like "^^" (or any other), or we could find a single word token like "b".
C language is good even for its code, and they use "{"
See here:
Code: Select all
(if (= 1 1)
(begin
(println "This is a test")
) )
Code: Select all
(if (= 1 1)
(b
(println "This is a test")
) )
(if (= 1 1)
(^^
(println "This is a test")
) )
(if (= 1 1)
(::
(println "This is a test")
) )
--
I have no problem, that newLISP does have 'begin' for blocking code.This is an important point: even if newLisp is not Lisp, I think if there are some "compatibilities" they could simplify user "migration".
For me it is in the best sense of 'bottom-up design' described by Paul Graham in one of his essays:
http://www.paulgraham.com/progbot.html
So I am sure every newLISP'er user uses newLISP to make his own special language which gets the best fit to solve his own programming task.
So when I want to have 'progn' or 'do' what's the problem to switch to them with a one-liner?
Hans-Peter
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
I think the only typographical asset currently under-utilized in newLISP is the opening square bracket... Perhaps, one day, in Lutz' careful hands, it could do something wonderful or surprising on its own, not just introducing [ text ], [ cmd ]. But it would be a shame to see a valuable resource used just to provide a simple synonym for 'begin'...think we could really round the corner with a hard solution: why don't we try to use a symbol like "^^" (or any other), or we could find a single word token like "b".
Oh, it also lets you do those weird symbol names:
Code: Select all
(constant (sym "[Please do all the following expressions in order:]") begin)
...
([Please do all the following expressions in order:] (println "hi" ) (println "there"))
hi
there
Basically I agree with you cormullion, in fact I don't like to find matching "end" from "begin".
I think Lutz could find a "special" symbol (not like open/close). Close must be like the standard: ")" (as every other function).
I really like newLisp for functions usage, symbols usage, etc... (against imperative languages).
SO if we want (Lutz wants!) to find an alternative, we MUST avoid to break newLisp fashion/magic :-)
I think Lutz could find a "special" symbol (not like open/close). Close must be like the standard: ")" (as every other function).
I really like newLisp for functions usage, symbols usage, etc... (against imperative languages).
SO if we want (Lutz wants!) to find an alternative, we MUST avoid to break newLisp fashion/magic :-)
--
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
thanks ;) and you could use this:newLISP is fine the way it is (*)!
*edit: named parameters would be nice, though... :)
http://www.newlisp.org/newlisp_manual.html#bind
scroll down to the last example.
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
Yes, it's almost what I want, but:Lutz wrote:scroll down to the last example.
Code: Select all
(context 'My-cool-context)
(define-macro (foo)
(local (len width height)
(bind (args) true)
(println "len:" len " width:" width " height:" height)))
(context MAIN)
(My-cool-context:foo (My-cool-context:width (+ 15 5)) (My-cool-context:height 30) (My-cool-context:len 10))
-
- Posts: 388
- Joined: Thu May 08, 2008 1:24 am
- Location: Croatia
- Contact:
Cormullion, I think you can find some ways around it. This is "proof of the concept" code only:
Code: Select all
(define (decontext-AL x)
(list (sym (slice (string (first x))
(+ (or (find ":"
(string (first x)))
-1)
1)))
(last x)))
(context 'My-cool-context)
(define-macro (foo)
(local (len width height)
(bind (map MAIN:decontext-AL (args)) true) ; nil for macro!
(println " len: " len " width: " width " height: " height)))
(foo (width (+ 15 5)) (height 30) (len 10))
; len: 10 width: 20 height: 30
(context MAIN)
(My-cool-context:foo (width (+ 15 5)) (height 30) (len 10))
; len: 10 width: 20 height: 30
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
Thanks, Kazimir!
There are indeed many workrounds, and yours is more excellent than most of those, but it remains a workround nonetheless.
This (now becoming off topic, sorry! :)) issue isn't really related to functionality, because there are many ways to pass some kind of label with arguments to functions. It's mostly - for me at least - related to readability. So workrounds aren't that important; they don't make things much more readable, and introduce more code (and presumably slow down execution speed).
There are indeed many workrounds, and yours is more excellent than most of those, but it remains a workround nonetheless.
This (now becoming off topic, sorry! :)) issue isn't really related to functionality, because there are many ways to pass some kind of label with arguments to functions. It's mostly - for me at least - related to readability. So workrounds aren't that important; they don't make things much more readable, and introduce more code (and presumably slow down execution speed).