request for a new function, say, `sequence'

request for a new function, say, `sequence'

[Kenichi Handa]

In the Indian languages support, we use this kind of
function repeatedly.  But, the function itself is generic
enough to be used in the other cases.  Can I install it in
subr.el (or simple.el)?

(defun sequence (from to type)
  "Return a sequence of type TYPE that contains numbers FROM to TO (inclusive).
TYPE must `list', `vector', or `string'.
If TYPE is `string', all numbers between FROM and TO must be valid
characters."
  (let ((len (1+ (- to from)))
	val)
    (if (>= len 0)
	(cond ((eq type 'list)
	       (while (>= to from)
		 (setq val (cons to val)
		       to (1- to))))
	      ((eq type 'vector)
	       (setq val (make-vector len 0))
	       (while (>= to from)
		 (aset val (- to from) to)
		 (setq to (1- to))))
	      ((eq type 'string)
	       (setq val (make-string len 0))
	       (while (>= to from)
		 (aset val (- to from) to)
		 (setq to (1- to))))
	      (t
	       (error "Invalid type: %s" type))))
    val))

---
Ken'ichi HANDA
handa@m17n.org

Re: request for a new function, say, `sequence'

[Stefan Monnier]

> In the Indian languages support, we use this kind of
> function repeatedly.  But, the function itself is generic
> enough to be used in the other cases.  Can I install it in
> subr.el (or simple.el)?

The only place where I see something like that is in devan-util.el
and it's only using the `list' case.
Am I missing something ?


	Stefan

Re: request for a new function, say, `sequence'

[Kenichi Handa]

In article <200303241541.h2OFfbpa011227@rum.cs.yale.edu>, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
>>  In the Indian languages support, we use this kind of
>>  function repeatedly.  But, the function itself is generic
>>  enough to be used in the other cases.  Can I install it in
>>  subr.el (or simple.el)?

> The only place where I see something like that is in devan-util.el
> and it's only using the `list' case.
> Am I missing something ?

Oops, I should have written "we'll use".  Kawabata-san is
now working on improving Indian language support (including
tamil and malayalam), and in the comming code, the same
functionality is required in many other files.

And, even if it is used just in devan-util.el, it's too
generic to fit in there.

---
Ken'ichi HANDA
handa@m17n.org

Re: request for a new function, say, `sequence'

[Kenichi Handa]

In article <200303250015.JAA06592@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes:
> Oops, I should have written "we'll use".  Kawabata-san is
> now working on improving Indian language support (including
> tamil and malayalam), and in the comming code, the same
> functionality is required in many other files.

> And, even if it is used just in devan-util.el, it's too
> generic to fit in there.

Another possible usage of `sequence' is this.

Currently, in lisp/international/characters.el, we have this
kind of code repeatedly.

(setq c X)
(while (<= c Y)
  ..operate-on-C
  (setq c (1+ c)))

We can change it to this:

(dolist (c (sequence #X #Y 'list))
  ..operate-on-C)

It may be slower but it doesn't matter here.  The latter
code is more concise and easier to read.

---
Ken'ichi HANDA
handa@m17n.org

Re: request for a new function, say, `sequence'

[Stefan Monnier]

> > Oops, I should have written "we'll use".  Kawabata-san is
> > now working on improving Indian language support (including
> > tamil and malayalam), and in the comming code, the same
> > functionality is required in many other files.
> 
> > And, even if it is used just in devan-util.el, it's too
> > generic to fit in there.
> 
> Another possible usage of `sequence' is this.
> 
> Currently, in lisp/international/characters.el, we have this
> kind of code repeatedly.
> 
> (setq c X)
> (while (<= c Y)
>   ..operate-on-C
>   (setq c (1+ c)))
> 
> We can change it to this:
> 
> (dolist (c (sequence #X #Y 'list))
>   ..operate-on-C)

I agree that such code is pretty common, but I'd rather extend dotimes
to allow something like (dotimes (c (cons X Y)) BODY).


	Stefan

Re: request for a new function, say, `sequence'

[Kenichi Handa]

In article <200303250057.h2P0vBj6016367@rum.cs.yale.edu>, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
>>  (dolist (c (sequence #X #Y 'list))
>>    ..operate-on-C)

> I agree that such code is pretty common, but I'd rather extend dotimes
> to allow something like (dotimes (c (cons X Y)) BODY).

I'm not sure it is a good idea to extend dotimes and make it
different from Commong Lisp.  And, using `sequence' is more
flexible, for instance, in the following case.

  ;; Combining diacritics
  (setq c #x300)
  (while (<= c #x362)
    (modify-category-entry (decode-char 'ucs c) ?^)
    (setq c (1+ c)))

  ;; Combining marks
  (setq c #x20d0)
  (while (<= c #x20e3)
    (modify-category-entry (decode-char 'ucs c) ?^)
    (setq c (1+ c)))

can be:

  (dolist (c (append (sequence #x0300 #x0362 'list)
                     (sequence #x20d0 #x20e3 'list)))
    (modify-category-entry (decode-char 'ucs c) ?^)

Of course, in this specific case, allowing FROM and TO in
modify-category-entry is better.

---
Ken'ichi HANDA
handa@m17n.org

Re: request for a new function, say, `sequence'

[Luc Teirlinck]

Kenichi Handa wrote:
   
   I'm not sure it is a good idea to extend dotimes and make it
   different from Commong Lisp.

I agree that this would be a bad idea.

I find the name `sequence' for the new function confusing, however,
since it looks so analogous to `list', `string' and `vector', 'making 
(sequence from to type) look like a synonym for:
(type from to).  Would the name `interval' not be better?  After all,
an interval is exactly what the function returns.

Sincerely,

Luc.

Re: request for a new function, say, `sequence'

[Luc Teirlinck]

Or `range' might be a good name too.

Sincerely,

Luc.

Re: request for a new function, say, `sequence'

[Kenichi Handa]

In article <200303250147.TAA24995@eel.dms.auburn.edu>, Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> I find the name `sequence' for the new function confusing, however,
> since it looks so analogous to `list', `string' and `vector', 'making 
> (sequence from to type) look like a synonym for:
> (type from to).  Would the name `interval' not be better?  After all,
> an interval is exactly what the function returns.
[...]
> Or `range' might be a good name too.

I don't have a strong opinion about the function name, and
as English is not my native language, I can't tell how each
word fits with the functionality.  But, I like `range'
because it is the shortest.  :-)

---
Ken'ichi HANDA
handa@m17n.org

Re: request for a new function, say, `sequence'

[Luc Teirlinck]

Ken'ichi HANDA wrote:
   
   I don't have a strong opinion about the function name, and
   as English is not my native language, I can't tell how each
   word fits with the functionality.  But, I like `range'
   because it is the shortest.  :-)

It seems to me now that `range' is indeed better.  Range seems better
suited for an integer range, interval sound more like an interval of
real numbers (and hence may not have been that good of an idea).

Sincerely,

Luc.

Re: request for a new function, say, `sequence'

[Satyaki Das]

Kenichi Handa <handa@m17n.org> writes:

>   ;; Combining diacritics
>   (setq c #x300)
>   (while (<= c #x362)
>     (modify-category-entry (decode-char 'ucs c) ?^)
>     (setq c (1+ c)))

If I were you I would be using loop as follows:

   ;; Combining diacritics
   (loop for c from #x300 to #x362
         do (modify-category-entry (decode-char 'ucs c) ?^))

Is there any particular reason for loop to be avoided? It is a
macro in CL, so it gets expanded at compile time. I ask since I
have used it in MH-E.

Thanks,
Satyaki

Re: request for a new function, say, `sequence'

[Kenichi Handa]

In article <32627.1048557446@theforce.Stanford.EDU>, "Satyaki Das" <satyakid@stanford.edu> writes:

> Kenichi Handa <handa@m17n.org> writes:
>>    ;; Combining diacritics
>>    (setq c #x300)
>>    (while (<= c #x362)
>>      (modify-category-entry (decode-char 'ucs c) ?^)
>>      (setq c (1+ c)))

> If I were you I would be using loop as follows:

>    ;; Combining diacritics
>    (loop for c from #x300 to #x362
>          do (modify-category-entry (decode-char 'ucs c) ?^))

> Is there any particular reason for loop to be avoided? It is a
> macro in CL, so it gets expanded at compile time. I ask since I
> have used it in MH-E.

The above is an example usage of `sequence' (or `range'),
not the reason of requesting this function.  The original
reason is that there are cases that we need a list generated
by this function.

And, as far as I remember, it should be avoided to require
`cl' in a preloaded file if possible.  Is this rule changed
now?

---
Ken'ichi HANDA
handa@m17n.org

Re: request for a new function, say, `sequence'

[Satyaki Das]

Kenichi Handa <handa@m17n.org> writes:

> In article <32627.1048557446@theforce.Stanford.EDU>, "Satyaki Das" <satyakid@stanford.edu> writes:
> 
> > If I were you I would be using loop as follows:
> 
> >    ;; Combining diacritics
> >    (loop for c from #x300 to #x362
> >          do (modify-category-entry (decode-char 'ucs c) ?^))
> 
> > Is there any particular reason for loop to be avoided? It is a
> > macro in CL, so it gets expanded at compile time. I ask since I
> > have used it in MH-E.
> 
> The above is an example usage of `sequence' (or `range'),
> not the reason of requesting this function.  The original
> reason is that there are cases that we need a list generated
> by this function.

The examples in this thread have all created a list (or vector)
and then iterated over the elements. The loop macro is ideal for
this (and more efficient since it doesn't cons up a list -- though
efficiency shouldn't be an issue). That is why I suggested this.

Are there lots of places where just a list of ascending numbers
needs to be returned?

> And, as far as I remember, it should be avoided to require
> `cl' in a preloaded file if possible.  Is this rule changed
> now?

Using `loop' requires cl at compile time only. So adding the
following line is sufficient:

  (eval-when-compile (require 'cl))

If the preloaded file is compiled then 'cl isn't actually loaded
at run time.

Satyaki

Re: request for a new function, say, `sequence'

[Kenichi Handa]

In article <1191.1048560083@theforce.Stanford.EDU>, "Satyaki Das" <satyakid@stanford.edu> writes:
> The examples in this thread have all created a list (or vector)
> and then iterated over the elements. 

The original version of `sequence' is `devanagari-range',
and it it used as below.

(defun dev-charseq (from &optional to)
  (if (null to) (setq to from))
  (mapcar (function (lambda (x) (indian-glyph-char x 'devanagari)))
          (devanagari-range from to)))

(defvar dev-glyph-cvn
  (append
   (dev-charseq #x2b)
   (dev-charseq #x3c #xc1)
   (dev-charseq #xc3))

(defvar dev-glyph-space
  (dev-charseq #xf0 #xfe)
  "Devanagari Spacing Glyphs")
[...]

> Using `loop' requires cl at compile time only. So adding the
> following line is sufficient:

>   (eval-when-compile (require 'cl))

> If the preloaded file is compiled then 'cl isn't actually loaded
> at run time.

Yes, I know that.  So, I understood that not requiring cl is
a kind of coding convention.  If there's no such convention
now, that ok, but still loop doesn't work for iterating over
dev-glyph-cvn in the above example.

---
Ken'ichi HANDA
handa@m17n.org

Re: request for a new function, say, `sequence'

[Satyaki Das]

Kenichi Handa <handa@m17n.org> writes:

> In article <1191.1048560083@theforce.Stanford.EDU>, "Satyaki Das" <satyakid@stanford.edu> writes:
> > The examples in this thread have all created a list (or vector)
> > and then iterated over the elements. 
> 
> The original version of `sequence' is `devanagari-range',
> and it it used as below.
> 
> (defun dev-charseq (from &optional to)
>   (if (null to) (setq to from))
>   (mapcar (function (lambda (x) (indian-glyph-char x 'devanagari)))
>           (devanagari-range from to)))

I would have written it as follows:

(defun dev-charseq (lower &optional upper)
  (if (null upper) (setq upper lower))
  (loop for x from lower to upper
        collect (indian-glyph-char x 'devanagiri)))

I changed "from" to "lower" and "to" to "upper" since the loop
looks sort of funny otherwise.

> > If the preloaded file is compiled then 'cl isn't actually loaded
> > at run time.
> 
> Yes, I know that.  So, I understood that not requiring cl is
> a kind of coding convention.  If there's no such convention
> now, that ok, but still loop doesn't work for iterating over
> dev-glyph-cvn in the above example.

I did a grep through the sources and there are 118 files that
already contain the line,
  (eval-when-compile (require 'cl))

So I hope adding another of these won't be a problem.

Satyaki

Re: request for a new function, say, `sequence'

[Kenichi Handa]

In article <4946.1048568708@theforce.Stanford.EDU>, "Satyaki Das" <satyakid@stanford.edu> writes:
>>  (defun dev-charseq (from &optional to)
>>    (if (null to) (setq to from))
>>    (mapcar (function (lambda (x) (indian-glyph-char x 'devanagari)))
>>            (devanagari-range from to)))

> I would have written it as follows:

> (defun dev-charseq (lower &optional upper)
>   (if (null upper) (setq upper lower))
>   (loop for x from lower to upper
>         collect (indian-glyph-char x 'devanagiri)))

> I changed "from" to "lower" and "to" to "upper" since the loop
> looks sort of funny otherwise.

It's not the point.  How to use a list returned by `range'
(or `sequence') and how to make such a list is a different
thing.

Of course, we can implement the functionality of `range' by
using loop, while, dotimes, etc.  But, it doesn't mean that
we don't need a simpler/convenient function `range'.

> I did a grep through the sources and there are 118 files that
> already contain the line,
>   (eval-when-compile (require 'cl))

How many of them are preloaded?

---
Ken'ichi HANDA
handa@m17n.org

Re: request for a new function, say, `sequence'

[Satyaki Das]

Kenichi Handa <handa@m17n.org> writes:

> In article <4946.1048568708@theforce.Stanford.EDU>, "Satyaki Das" <satyakid@stanford.edu> writes:
> >>  (defun dev-charseq (from &optional to)
> >>    (if (null to) (setq to from))
> >>    (mapcar (function (lambda (x) (indian-glyph-char x 'devanagari)))
> >>            (devanagari-range from to)))
> 
> > (defun dev-charseq (lower &optional upper)
> >   (if (null upper) (setq upper lower))
> >   (loop for x from lower to upper
> >         collect (indian-glyph-char x 'devanagiri)))
> 
> It's not the point.  How to use a list returned by `range'
> (or `sequence') and how to make such a list is a different
> thing.

I am trying to show that by using existing macros and functions we
can express the algorithms as clearly and succintly as with the
new `range'. Do you have a counter-example to this?

> Of course, we can implement the functionality of `range' by
> using loop, while, dotimes, etc.  But, it doesn't mean that
> we don't need a simpler/convenient function `range'.

IMO, a new builtin function is needed if and only if it makes
writing code easier or makes it simpler.

I think calling the new function `sequence' or `range' is a
mistake. Lisp already has the functions `string' and `vector'
which are data type constructors. Either of the suggested names
sound like a new data type (in fact there is already a data type
called sequence and a predicate sequencep) and so inconsistent
with the current naming conventions.

So I suggest that a more descriptive name be chosen -- for
instance something like `make-sequence-of-numbers'.

Thanks,
Satyaki

Re: request for a new function, say, `sequence'

[Kenichi Handa]

In article <24784.1048623017@theforce.Stanford.EDU>, "Satyaki Das" <satyakid@stanford.edu> writes:
>>  >>  (defun dev-charseq (from &optional to)
>>  >>    (if (null to) (setq to from))
>>  >>    (mapcar (function (lambda (x) (indian-glyph-char x 'devanagari)))
>>  >>            (devanagari-range from to)))
>>  
>>  > (defun dev-charseq (lower &optional upper)
>>  >   (if (null upper) (setq upper lower))
>>  >   (loop for x from lower to upper
>>  >         collect (indian-glyph-char x 'devanagiri)))
>>  
>>  It's not the point.  How to use a list returned by `range'
>>  (or `sequence') and how to make such a list is a different
>>  thing.

> I am trying to show that by using existing macros and functions we
> can express the algorithms as clearly and succintly as with the
> new `range'.

In your example code, you united the implementaion of range
and usage of the returned list.  In such a way, of course,
it is natural that we can make a function that uses `range'
more concise and efficient.

> Do you have a counter-example to this?

How about the code something like this.

(defvar dev-consonants
  (append (range (decode-char 'ucs #x0915) (decode-char 'ucs #x0939))
	  (range (decode-char 'ucs #x0958) (decode-char 'ucs #x095F))))

(defun dev-looking-at-syllable ()
  (and (memq (following-char) dev-consonants)
       (looking-at dev-syllable-pattern)))

The first `memq' is to avoid the heavy `looking-at' in an
unnecessary case.

The defvar part can be written as:

(defvar dev-consonants
  (append (loop for x from (decode-char 'ucs #x0915) to (decode-char 'ucs #x0939)
		collect x)
	  (loop for x from (decode-char 'ucs #x0958) to (decode-char 'ucs #x095F)
		collect x)))

but using `range' is much more handy and easier to read.

> IMO, a new builtin function is needed if and only if it makes
> writing code easier or makes it simpler.

I'm not requesting a builtin function.  And, `range' surely
makes writing code easier and makes the code simpler as well
as dolist, dotimes, while, and etc. do.

> I think calling the new function `sequence' or `range' is a
> mistake. Lisp already has the functions `string' and `vector'
> which are data type constructors. Either of the suggested names
> sound like a new data type (in fact there is already a data type
> called sequence and a predicate sequencep) and so inconsistent
> with the current naming conventions.

I see your point.

> So I suggest that a more descriptive name be chosen -- for
> instance something like `make-sequence-of-numbers'.

I don't insist on having TYPE argument, always returning a
list is ok.  So, for instance, make-number-list, is also
acceptable.

---
Ken'ichi HANDA
handa@m17n.org

Re: request for a new function, say, `sequence'

[Satyaki Das]

Kenichi Handa <handa@m17n.org> writes:

> In your example code, you united the implementaion of range
> and usage of the returned list.  In such a way, of course,
> it is natural that we can make a function that uses `range'
> more concise and efficient.

This should be done only if it doesn't affect the readability and
simplicity of the code.

> > Do you have a counter-example to this?
> 
> How about the code something like this.
> 
> (defvar dev-consonants
>   (append (range (decode-char 'ucs #x0915) (decode-char 'ucs #x0939))
> 	  (range (decode-char 'ucs #x0958) (decode-char 'ucs #x095F))))
> 
> (defun dev-looking-at-syllable ()
>   (and (memq (following-char) dev-consonants)
>        (looking-at dev-syllable-pattern)))
> 
> The first `memq' is to avoid the heavy `looking-at' in an
> unnecessary case.

This seems like a reasonable usage scenario for `range'. However
since you are doing this for efficiency reasons, isn't it more
efficient to compare with <= than to use memq to to compare it
with 45 separate integers?

> The defvar part can be written as:
> 
> (defvar dev-consonants
>   (append (loop for x from (decode-char 'ucs #x0915) to (decode-char 'ucs #x0939)
> 		collect x)
> 	  (loop for x from (decode-char 'ucs #x0958) to (decode-char 'ucs #x095F)
> 		collect x)))

Or you could do it in one loop and collect with a when. But I
agree that this could easily get quite hairy if there are lots of
ranges to consider.

> but using `range' is much more handy and easier to read.

Agreed.

> > IMO, a new builtin function is needed if and only if it makes
> > writing code easier or makes it simpler.
> 
> I'm not requesting a builtin function.

Sorry about the bad terminology. I meant a library function.

>                                         And, `range' surely
> makes writing code easier and makes the code simpler as well
> as dolist, dotimes, while, and etc. do.

Agreed. But I would be careful in its use, since it can
potentially cons a lot (if used inside of a loop for instance).

> > So I suggest that a more descriptive name be chosen -- for
> > instance something like `make-sequence-of-numbers'.
> 
> I don't insist on having TYPE argument, always returning a
> list is ok.  So, for instance, make-number-list, is also
> acceptable.

Yes, this seems reasonable if you don't want the vectors and
string types.

Satyaki

Re: request for a new function, say, `sequence'

[Luc Teirlinck]

Ken'ichi HANDA wrote:

   > I think calling the new function `sequence' or `range' is a
   > mistake. Lisp already has the functions `string' and `vector'
   > which are data type constructors. Either of the suggested names
   > sound like a new data type (in fact there is already a data type
   > called sequence and a predicate sequencep) and so inconsistent
   > with the current naming conventions.

   I see your point.

   > So I suggest that a more descriptive name be chosen -- for
   > instance something like `make-sequence-of-numbers'.

   I don't insist on having TYPE argument, always returning a
   list is ok.  So, for instance, make-number-list, is also
   acceptable.

While I agree that `sequence' would be confusing, I personally do not
believe that `range' would be.  If it is, then I would prefer
something like `range-list' or something else with range in the name.
We are not talking about an arbitrary sequence or list of numbers, but
about a consecutive range.

Sincerely,

Luc.

Re: request for a new function, say, `sequence'

[Edward O'Connor]

> While I agree that `sequence' would be confusing, I personally do not
> believe that `range' would be.

I believe this is called `range' in Python, which perhaps lends
something (else) to that name over using `sequence'.


Ted

-- 
Edward O'Connor
ted@oconnor.cx

Ense petit placidam sub libertate quietem.

Re: request for a new function, say, `sequence'

[Thien-Thi Nguyen]

"Edward O'Connor" <ted@oconnor.cx> writes:

   I believe this is called `range' in Python, which perhaps lends
   something (else) to that name over using `sequence'.

as far as name preferences, my 2c: `iota'.

thi

Re: request for a new function, say, `sequence'

[Kenichi Handa]

In article <jk4r5qwm20.fsf@glug.org>, Thien-Thi Nguyen <ttn@glug.org> writes:

> "Edward O'Connor" <ted@oconnor.cx> writes:
>    I believe this is called `range' in Python, which perhaps lends
>    something (else) to that name over using `sequence'.

> as far as name preferences, my 2c: `iota'.

Richard suggested `sequential-list' which, I think, is also
a good name.  And as far as he suggested it, I think he
admitted to install than function.  So, I'll install it this
weekend if there aren't any more strong objections.

By the way, `iota' and Python's `range' are slightly
different from what I want.  I think we should avoid to have
a function of the same name but slightly different from that
of the other language unless there's a strong reason.

  range(10) => [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
  range(5, 10) => [5, 6, 7, 8, 9]
  range(0, 10, 3) => [0, 3, 6, 9]
  range(-10, -100, -30) => [-10, -40, -70]

If range is used on simple numbers, this spec is not bad.
But, I'd like to use it also for character codes and glyph
codes as below:
  (sequential-list ?a ?z) => (?a ?b ... ?z)
It seems strange to write
  (sequential-list ?a ?{)
or
  (sequential-list ?a (1+ ?z))
to get (?a ?b ... ?z).

---
Ken'ichi HANDA
handa@m17n.org

Re: request for a new function, say, `sequence'

[Richard Stallman]

    Richard suggested `sequential-list' which, I think, is also
    a good name.

Thinking about it again, I think number-sequence might be a better name.

Re: request for a new function, say, `sequence'

[Kenichi Handa]

In article <E18yO5o-0007VM-00@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
>     Richard suggested `sequential-list' which, I think, is also
>     a good name.

> Thinking about it again, I think number-sequence might be a better name.

I've just installed it in subr.el.  I implemented it as below.

(defun number-sequence (from &optional to)
  "Return a sequence of numbers from FROM to TO (both inclusive) as a list.
The Nth element of the list is (+ FROM N) where N counts from zero.
If TO is nil, it defaults to FROM.
If TO is less than FROM, the value is nil."
  (if to
      (if (< to from)
	  (setq to (1- from)))
    (setq to from))
  (let* ((list (make-list (- (1+ to) from) from))
	 (tail list))
    (while (setq tail (cdr tail))
      (setcar tail (setq from (1+ from))))
    list))

If you think there's a better implementation, please improve
the code.

As for the spec of the function, I still have these
questions.

In Emacs, the word "number" includes a floating number.
Should we make number-sequence work also for floating
numbers?
Ex.  (number-sequence 1.5 4.4) => (1.5 2.5 3.5)
or
Ex.  (number-sequence 1.5 4.4) => (2 3 4)

Is it better to have the optional arg INC which specifies
how much to increment numbers.

---
Ken'ichi HANDA
handa@m17n.org

Re: request for a new function, say, `sequence'

[Miles Bader]

Kenichi Handa <handa@m17n.org> writes:
> I've just installed it in subr.el.  I implemented it as below.

The interface looks good.

How about the following implementation:

   (defun number-sequence (from &optional to)
     "Return a sequence of numbers from FROM to TO (both inclusive) as a list.
   The Nth element of the list is (+ FROM N) where N counts from zero.
   If TO is nil, it defaults to FROM.
   If TO is less than FROM, the value is nil."
     (unless to
       (setq to from))
     (let ((seq nil))
       (while (>= to from)
         (push to seq)
         (setq to (1- to)))
       seq))

> In Emacs, the word "number" includes a floating number.  Should we
> make number-sequence work also for floating numbers?

Well, it will already, as long as TO and FROM differ by an integral amount...

-Miles
-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: request for a new function, say, `sequence'

[Richard Stallman]

    How about the following implementation:

       (defun number-sequence (from &optional to)
	 "Return a sequence of numbers from FROM to TO (both inclusive) as a list.
       The Nth element of the list is (+ FROM N) where N counts from zero.
       If TO is nil, it defaults to FROM.
       If TO is less than FROM, the value is nil."
	 (unless to
	   (setq to from))
	 (let ((seq nil))
	   (while (>= to from)
	     (push to seq)
	     (setq to (1- to)))
	   seq))

That is much cleaner.  However, to do the right thing with floats,
it should count up from FROM and then call nreverse.

Re: request for a new function, say, `sequence'

[Thien-Thi Nguyen]

here's another implementation that builds the list from the end.
also, the individual input conditions are handled directly.

thi

________________________________________________
(defun number-sequence (from &optional to)
  (cond ((not to) (list from))
        ((< to from) nil)
        (t (let ((ans (list to)))
             (while (< from to)
               (setq ans (cons (setq to (1- to)) ans)))
             ans))))

Re: request for a new function, say, `sequence'

[Vinicius Jose Latorre]

Here is another implementation of number-sequence.
It takes in consideration that the number can be an integer or float.
Also have an INC argument.

(defun number-sequence (from &optional to inc)
  (if (not to)
      (list from)
    (or inc (setq inc 1))
    (let (seq)
      (while (<= from to)
        (setq seq (cons from seq)
              from (+ from inc)))
      (nreverse seq))))

Re: request for a new function, say, `sequence'

[Richard Stallman]

Your code looks the cleanest; please install it.

Has someone updated etc/NEWS?

Re: request for a new function, say, `sequence'

[Vinicius Jose Latorre]

Richard Stallman wrote:

>Your code looks the cleanest; please install it.
>
>Has someone updated etc/NEWS?
>

Done.  See the doc associated:

(defun number-sequence (from &optional to inc)
  "Return a sequence of numbers from FROM to TO (both inclusive) as a list.
INC is the increment used between numbers in the sequence.
So, the Nth element of the list is (+ FROM (* N INC)) where N counts from
zero.
If INC is nil, it defaults to 1 (one).
If TO is nil, it defaults to FROM.
If TO is less than FROM, the value is nil.
Note that FROM, TO and INC can be integer or float."
  (if (not to)
      (list from)
    (or inc (setq inc 1))
    (let (seq)
      (while (<= from to)
    (setq seq (cons from seq)
          from (+ from inc)))
      (nreverse seq))))

Re: request for a new function, say, `sequence'

[Richard Stallman]

Has someone updated etc/NEWS about number-sequence?

Re: request for a new function, say, `sequence'

[Kenichi Handa]

In article <3E8E3B13.2060805@ig.com.br>, Vinicius Jose Latorre <viniciusjl@ig.com.br> writes:

> Richard Stallman wrote:
>> Your code looks the cleanest; please install it.
>> 
>> Has someone updated etc/NEWS?
>> 

> Done.  See the doc associated:

Thank you for it.

The intention of using make-list in my version was to avoid
repeated call of cons.  But, I found that Fmake_list
actually calls Fcons repeatedly.  I was wrongly thiking that
there's a premitive that makes a list at once.

---
Ken'ichi HANDA
handa@m17n.org

Re: request for a new function, say, `sequence'

[Richard Stallman]

    In Emacs, the word "number" includes a floating number.
    Should we make number-sequence work also for floating
    numbers?
    Ex.  (number-sequence 1.5 4.4) => (1.5 2.5 3.5)
    or

It is probably not very important, but if you want to do it,
that behavior is clearly right.

    Ex.  (number-sequence 1.5 4.4) => (2 3 4)

That behavior is wrong.

Re: request for a new function, say, `sequence'

[Stefan Monnier]

> > The examples in this thread have all created a list (or vector)
> > and then iterated over the elements. 
> 
> The original version of `sequence' is `devanagari-range',
> and it it used as below.
> 
> (defun dev-charseq (from &optional to)
>   (if (null to) (setq to from))
>   (mapcar (function (lambda (x) (indian-glyph-char x 'devanagari)))
>           (devanagari-range from to)))

But in this example as well a variant of `dotimes' would work just as well
and would avoid the unnecessary consing.  Emacs is not very good at
efficiently consing+GCing, so it's good to avoid such things when
it can be done without impacting the readbility (Emacs-21 is dog slow
on my 266Mhz machine).

Also, all the examples I've seen use lists.  Given my background in
type-systems, I must say that I don't like functions that returns either
a list or a vector or a string depending on some extra arg.  If we
want a function for convenience (rather than performance), then
returning a list is good enough.  You can always pass the result
to `string' or to `vector' if you want something else.

Anyway, blue is the color for my bykeshed, what is yours ?

> > If the preloaded file is compiled then 'cl isn't actually loaded
> > at run time.
> 
> Yes, I know that.  So, I understood that not requiring cl is
> a kind of coding convention.  If there's no such convention
> now, that ok, but still loop doesn't work for iterating over

	grep 'require .cl' lisp/**/*.el

will show you that CL is used all over the place, including in files that
are pre-loaded (though fewer of them, admittedly).  As long as CL is only
needed when byte-compiling the file, it's OK (i.e. if it's wrapped in
`eval-when-compile').  At least that was RMS' official position last time
this was brought up.


	Stefan

Re: request for a new function, say, `sequence'

[Kenichi Handa]

In article <200303251527.h2PFR0lO018653@rum.cs.yale.edu>, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
>>  (defun dev-charseq (from &optional to)
>>    (if (null to) (setq to from))
>>    (mapcar (function (lambda (x) (indian-glyph-char x 'devanagari)))
>>            (devanagari-range from to)))

> But in this example as well a variant of `dotimes' would work just as well
> and would avoid the unnecessary consing.

Modify the resulting list of devanagari-range destructively
will also avoid the unnecessary consing.

> Emacs is not very good at efficiently consing+GCing, so
> it's good to avoid such things when it can be done without
> impacting the readbility (Emacs-21 is dog slow on my
> 266Mhz machine).

Yes, I know.  But the main reason for my proposal is for
readability.  Currently, the above function is used mainly
for defining a data in defvar, so the speed is not that
important.  On the other hand, XXX-util.el (especially the
data definition parts) must be read and modified by native
XXX users who may not be familiar with lisp.  So, it's very
important to provide easy-to-understand data definition
parts.

> Also, all the examples I've seen use lists.  Given my background in
> type-systems, I must say that I don't like functions that returns either
> a list or a vector or a string depending on some extra arg.  If we
> want a function for convenience (rather than performance), then
> returning a list is good enough.  You can always pass the result
> to `string' or to `vector' if you want something else.

As far as I see the current usage, a function returning a
list is enough.  So, I don't insist on having TYPE argument.

> Anyway, blue is the color for my bykeshed, what is yours ?

What is "bykeshed"?  My dictionary doesn't have that word.

> will show you that CL is used all over the place, including in files that
> are pre-loaded (though fewer of them, admittedly).  As long as CL is only
> needed when byte-compiling the file, it's OK (i.e. if it's wrapped in
> `eval-when-compile').  At least that was RMS' official position last time
> this was brought up.

Thank you for clarifying that.  Ok, I'll use 
    (eval-when-compile (require 'cl)
in a place that is appropriate.

---
Ken'ichi HANDA
handa@m17n.org

Re: request for a new function, say, `sequence'

[Miles Bader]

On Wed, Mar 26, 2003 at 08:11:37AM +0900, Kenichi Handa wrote:
> > Anyway, blue is the color for my bykeshed, what is yours ?
> 
> What is "bykeshed"?  My dictionary doesn't have that word.

I guess he meant `bikeshed' (I've never seen it spelled `byke'), which is a
reference to the tendency of people to argue more vociferously over minor
issues than major ones.

BTW, pale blue-green: I keep wanting to suggest that this function be called
`iota', after the APL function with similar functionality.  I think various
common-lisp/schemes versions of this function use this name (though I seem to
recall that the function signature is usually
  (iota COUNT &optional START INTERVAL)

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: request for a new function, say, `sequence'

[Luc Teirlinck]

Miles Bader wrote:

   BTW, pale blue-green: I keep wanting to suggest that this function
   be called `iota', after the APL function with similar
   functionality.  I think various common-lisp/schemes versions of
   this function use this name (though I seem to recall that the
   function signature is usually (iota COUNT &optional START INTERVAL)

I do not believe that Common Lisp has this function.  Does Guile?

You did not describe the actual behavior.  Guess:

(iota 3) returns (0 1 2) and:
(iota 3 7 -5) returns (7 2 -3)

To get the effect of (range a b):

(iota (1+ (- b a)) a 1)

Correct?

Probably not what Ken'ichi wants.

Sincerely,

Luc.

Re: request for a new function, say, `sequence'

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
>    BTW, pale blue-green: I keep wanting to suggest that this function
>    be called `iota', after the APL function with similar
>    functionality.  I think various common-lisp/schemes versions of
>    this function use this name (though I seem to recall that the
>    function signature is usually (iota COUNT &optional START INTERVAL)
> 
> I do not believe that Common Lisp has this function.  Does Guile?

It's not a standard common-lisp function.  However, I think the way I
expressed it is a common formulation for this particular functionality
(I've seen it pop up numerous times).

-Miles
-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: request for a new function, say, `sequence'

[Kenichi Handa]

In article <20030326001145.GA16603@gnu.org>, Miles Bader <miles@gnu.org> writes:
> On Wed, Mar 26, 2003 at 08:11:37AM +0900, Kenichi Handa wrote:
>>  > Anyway, blue is the color for my bykeshed, what is yours ?
>>  
>>  What is "bykeshed"?  My dictionary doesn't have that word.

> I guess he meant `bikeshed' (I've never seen it spelled `byke'), which is a
> reference to the tendency of people to argue more vociferously over minor
> issues than major ones.

Ah, I see.  I'm also not that happy about this dicussion.  I
haven't expected that my proposal meet such a big objection
(apart from the naming).  To me, the usefullness of the
functionality itself was apparent. 

Anyway, it seems that the further discussion is a waste of
our time.  I'd like to ask Richard to decide it.  For the
moment, I'll put `indian-range' in lisp/language/ind-util.el
with autoload cookie.

> BTW, pale blue-green: I keep wanting to suggest that this function be called
> `iota', after the APL function with similar functionality.  I think various
> common-lisp/schemes versions of this function use this name (though I seem to
> recall that the function signature is usually
>   (iota COUNT &optional START INTERVAL)

Ah, it's more general, but not convenient for the current
situation where we want to specify START and END
explicitely.  Otherwise, the code gets difficult to read.

---
Ken'ichi HANDA
handa@m17n.org

PS.  May I ask the nuance of the color "pale blue-green"?

Re: request for a new function, say, `sequence'

[Miles Bader]

Kenichi Handa <handa@m17n.org> writes:
> > recall that the function signature is usually
> >   (iota COUNT &optional START INTERVAL)
> 
> Ah, it's more general, but not convenient for the current
> situation where we want to specify START and END
> explicitely.  Otherwise, the code gets difficult to read.

I think this is a rather minor issue.  After all, the whole point of
this dicussion is whether it's a good idea to add a general function
rather than keeping the current specific one; if you want maximum
convenience, obviously the latter is the right way to go.

-Miles
-- 
自らを空にして、心を開く時、道は開かれる

Re: request for a new function, say, `sequence'

[Stefan Monnier]

> Yes, I know.  But the main reason for my proposal is for
> readability.  Currently, the above function is used mainly
> for defining a data in defvar, so the speed is not that
> important.  On the other hand, XXX-util.el (especially the
> data definition parts) must be read and modified by native
> XXX users who may not be familiar with lisp.  So, it's very
> important to provide easy-to-understand data definition
> parts.

Makes sense.

> As far as I see the current usage, a function returning a
> list is enough.  So, I don't insist on having TYPE argument.

Good.

> > Anyway, blue is the color for my bykeshed, what is yours ?
> What is "bykeshed"?  My dictionary doesn't have that word.

Sorry, typo.  See http://www.unixguide.net/freebsd/faq/16.19.shtml.

So, please go ahead and install that function, whatever its name is
going to be.  I still hope we'll get a chance to change dotimes since
it is frequent to need something like dotimes but that starts at
something else than 0.


	Stefan

Re: request for a new function, say, `sequence'

[Luc Teirlinck]

Stefan Monnier wrote:

   I still hope we'll get a chance to change dotimes since
   it is frequent to need something like dotimes but that starts at
   something else than 0.

What exactly do you propose:

(1) Extend dotimes to accept syntax like

(dotimes (var (start end) [result]) body...)

or:

(2) Have a new macro named dorange, dofor, for (or whatever) with
   syntax like:

(dorange (var start end [result]) body...)

It would seem like either would be easy to implement, the only
question for (2) is the exact need.  For (1) there is the extra
problem of messing with the syntax of a well known Common Lisp
function, although the fact that any valid CL syntax would still be
valid and have the exact same effect makes the problem less bad.

Sincerely,

Luc.
'

Re: request for a new function, say, `sequence'

[Stefan Monnier]

> What exactly do you propose:
> (1) Extend dotimes to accept syntax like
> (dotimes (var (start end) [result]) body...)
> (2) Have a new macro named dorange, dofor, for (or whatever) with
>    syntax like:
> (dorange (var start end [result]) body...)

How about

	(dotimes (VAR [START END] RESULT) BODY...)


-- Stefan

Re: request for a new function, say, `sequence'

[Luc Teirlinck]

Stefan Monnier wrote:

   How about

	   (dotimes (VAR [START END] RESULT) BODY...)

I do not completely understand this.  You do not really mean to make
END optional and have dotimes loop forever unless the loop is exited
by a catch-throw or similar?  Your proposal also seems to be violating
Elisp practice of putting optional arguments at the end (except for
&rest).  Or do you mean to specify [START END] as a vector?

I believe

(dotimes (VAR COUNT [RESULT START]) BODY...)) might be less confusing
(making the syntax more like iota).  

At the limit, one could even do

(dotimes (VAR COUNT [RESULT START INTERVAL]) BODY...) to make the iota
analogy complete, but I doubt that would be needed sufficiently often
to make it worthwhile.

Sincerely,

Luc.

Re: request for a new function, say, `sequence'

[Stefan Monnier]

>    How about
> 
> 	   (dotimes (VAR [START END] RESULT) BODY...)
> 
> I do not completely understand this.

[...] is Elisp notation for vectors.  I see that it is ambiguous
because [...] is also used in such contexts to denote optional
arguments.


	Stefan

Re: request for a new function, say, `sequence'

[Luc Teirlinck]

Stefan Monnier wrote:

   >    How about
   > 
   > 	   (dotimes (VAR [START END] RESULT) BODY...)
   > 
   > I do not completely understand this.

   [...] is Elisp notation for vectors.  I see that it is ambiguous
   because [...] is also used in such contexts to denote optional
   arguments.

So, unless START and END are constants, a typical usage would be:

(dotimes (var (vector start end) result) body...)

(if I now understand correctly).

Seems OK, but 

(dotimes (VAR COUNT [RESULT START]) BODY...))

would have the double advantage of keeping the meaning of the second
argument of dotimes (and of the name dotimes) as doing something COUNT
times and of allowing evaluation without an extra call to vector,
list, cons or whatever.  On the other hand, the semantics you proposed
would be more convenient for things like:

(dotimes (var [?a ?z] result) body...)

So if we expect a lot of uses of that type, it would be preferable.

Anyway, the first decision to be made is whether there is a sufficient
need for the functionality.  If yes, we can discuss the semantics.
(And then both of the above, as well as some semantics suggested
earlier seem OK to me.)

Sincerely,

Luc.

Re: request for a new function, say, `sequence'

[Stefan Monnier]

> Stefan Monnier wrote:
> 
>    >    How about
>    > 
>    > 	   (dotimes (VAR [START END] RESULT) BODY...)
>    > 
>    > I do not completely understand this.
> 
>    [...] is Elisp notation for vectors.  I see that it is ambiguous
>    because [...] is also used in such contexts to denote optional
>    arguments.
> 
> So, unless START and END are constants, a typical usage would be:
> 
> (dotimes (var (vector start end) result) body...)
> 
> (if I now understand correctly).

No.  Example usage would be:

	(dotimes (x [(1+ prev) (+ prev 13)])
	  (blabla x))


-- Stefan

Re: request for a new function, say, `sequence'

[Richard Stallman]

    And, as far as I remember, it should be avoided to require
    `cl' in a preloaded file if possible.  Is this rule changed
    now?

I don't see a problem with using cl at compile time only
in a preloaded file.