let/letn proposal

[Dmi]

From time to time I using the construction

Code Select Expand

(map set '(a b c ...) (something that returns a list))
Unfortunately, the most of such applications (for me) requires predefinition of a, b and c as local scope symbols, i.e.:

Code Select Expand

(let (a nil b nil c nil)
  (map set '(a b c ...) (something that returns a list)))

From this point it seems to be useful to extend let/letn with such rule:

Code Select Expand

(let (sym1 expr1 (sym2 sym3 sym4) expr234)
  body)


will be evaluated as:

Code Select Expand

(let sym1 expr1 sym2 nil sym3 nil sym4 nil)
  (map set '(sym2 sym3 sym4) expr234)
  body)

I.e., if in the declaration part of "let" the interpreter encounters not a symbol, but a list, then it does such expanison.

This can relaitively easy be modelled with some macro, but it seems to be nice standard feature. imho.

[Lutz]

You could also use the following:

Code Select Expand

> ((fn (a b c d) (map set '(a b c d) '(1 2 3 4))))
(1 2 3 4)

> (let ((a)(b)(c)(d)) (map set '(a b c d) '(1 2 3 4)))
(1 2 3 4)



The first one relies on the fact that arguments are optional in lambda/fn expressions. Similar the second, that when no initializer is supplied 'nil' is assumed. These are not exactly what you where proposing but they come close ;)



Lutz

[gcanyon]

From time to time I using the construction

Code Select Expand

(map set '(a b c ...) (something that returns a list))
Unfortunately, the most of such applications (for me) requires predefinition of a, b and c as local scope symbols, i.e.:

(snip)

I'm a newbie, but is there a function to convert a list to an array thus giving you an easy solution to storing the returned results for later use?

[Dmi]

Thanks Lutz, I'll chose somewhat from it.



gcanyon: "arrays" doesn't helps to store a values. U may store a list as well.

This construct is for assigning the list's elements to some sepatate symbols at once. Examine a manual about a "map" function.

[gcanyon]

Thanks Lutz, I'll chose somewhat from it.



gcanyon: "arrays" doesn't helps to store a values. U may store a list as well.

This construct is for assigning the list's elements to some sepatate symbols at once. Examine a manual about a "map" function.

I understand (in a basic way) how map works, but I'm trying to understand what the goal is. Leaving the values in a list, or converting them to an array, both allow you to have a variable number of values. Either way you can still access a particular value using an index. It's just my natural instinct when faced with "I have a variable number of values that I want quick easy individual access to," to put them into an array. It seems like the logical halfway mark between the problem you stated about pre-declaring a, b, c, etc. and simply leaving the values in a (slower) list.



But I'm happy to defer to those who have been using the language longer than I have, which is just about everyone. ;-)

[Lutz]

For random access, jumping around to different places not in sequence, lists are slower than arrays. But for smaller lists, lets say < 100 elements, there is not much of a difference. I always suggest to just start out with lists and then convert bottle necks to arrays. You will see that most of the time lists are doing just fine.



Some list operations are optimized. Pushing to the end of a list: (push item myList -1) is just as fast as pushing in front of a list: (push item myList).



In the past the amount of functions working on arrrays was limited, but that gap has been almost closed now. Since version 8.9.10 'append', 'first', 'last', 'rest', 'slice' are all available for arrays, including the implicit indexed forms of 'rest' and 'slice'.



Personally I use arrays very little, but of course it also depends on the class of problems you are working on.



Lutz