all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Pascal J. Bourguignon" <pjb@informatimago.com>
To: help-gnu-emacs@gnu.org
Subject: Re: why are there [v e c t o r s] in Lisp?
Date: Fri, 16 Oct 2015 05:31:35 +0200	[thread overview]
Message-ID: <87eggvebfs.fsf@kuiper.lan.informatimago.com> (raw)
In-Reply-To: mailman.429.1444962165.7904.help-gnu-emacs@gnu.org

Emanuel Berg <embe8573@student.uu.se> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com>
> writes:
>
>>> Why is there a special syntax for vectors? 
>>
>> To make it easy to introduce literal vectors in
>> your programs.
>
> OK, if you do it all day long that is an advantage
> just as I wouldn't want to do strings as lists, not
> that I use that much strings - however there is a flaw
> to the analogy and that is: having a string instead as
> a list isn't nearly as readable or editable as is
> a string - compare
>
>     (print "message")
>     (print '(m e s s a g e))
>
> while I don't see any such difference with [1 2 3] and
> '(1 2 3)!

This is not what you asked above.  You asked:

     Why is there a special syntax for vectors? 

What you have to compare is:
 
     "message"

with:

     (load-time-value
       (let ((string (make-string 7)))
          (setf (aref string 0) ?m
                (aref string 1) ?m
                (aref string 2) ?m
                (aref string 3) ?m
                (aref string 4) ?m
                (aref string 5) ?m
                (aref string 6) ?m)
          string))



Now, concerning the use of lists vs. strings, you answered the question
of why the special syntax yourself. to make it more readable.

Notice that in early lisp, there was no character and no string, only
lists and symbols.  Characters were represented by single-character
symbols, and strings by symbols.  There were functions implode and
explode:


    (defun implode (charsyms)
      (intern (map 'string (lambda (sym) (aref (symbol-name sym) 0))
                           charsyms)))

    (defun explode (sym)
      (map 'list (lambda (char) (intern (string char))) 
           (symbol-name sym)))

    (explode 'message)                  ; --> (m e s s a g e)
    (implode '(h e l l o \  w o r l d)) ; --> hello\ world


> Perhaps if you did a special syntax highlight for the
> squared vectors that would make them more visible and
> easily detected along with all the other parenthesised
> code - again, only if you have tons of vectors this
> would make for any practical difference. (It might
> look cool tho.)

Vector in general are vectors of t, that is they can take any type of
element.  Strings are vectors of character. Having a distinct syntax
here let you avoid the risk of error introducing a non-character in the
literal vector.


>> Without this syntax, you would only have run-time
>> constructors, and you would have to write more
>> complex code.
>
> ... why? If lists are vectors, which they are in terms
> of what they hold and how they look, then you don't
> need more code compared to vectors, on the contrary
> you need less code!

I'm assumed that you didn't ask the question you wanted to ask too.

There are DIFFERENT TYPES.  

As much as possible, for pre-defined types, lisp provides different
literal syntaxes, so that you can introduce in your programs literal
objects of those different types.  I showed in all my examples why
having such literal syntax is so useful: because constructing objects of
those types yourself takes a lot more of code.


>> For example, the equivalent of:
>>
>>     (defun permut-0213 (x)
>>        (aref [0 2 1 3] x))
>>
>> would have to be written as:
>>
>>    (defun permut-0213 (x)
>>       (aref (load-time-value (vector 0 2 1 3)) x))
>
> What I mean is, the list '(0 2 1 3) is already
> a vector, why not just leave it at that?

Right but this is not the question you asked. You asked about literal
syntax, I'm answering about literal syntax.


>> Therefore a list such as (1 2 3 4 5) will be
>>  actually a cons cell: (1 . (2 . (3 . (4 . (5 .
>>  nil)))))
>
> Indeed, but the same argument as I just made for
> strings can be applied here as well:
>
> 1) Strings and lists are so common so they should look
>    their best, which is why we can't have strings
>    lists or lists cons cells, because then they don't
>    even look like what they are.
>
> 2) Vectors are not that common, but just because
>    something is less common doesn't mean it should be
>    treated worse, fine - still, '(1 2 3) doesn't look
>    any worse than [1 2 3] - even in math books the
>    square brackets are sometimes not square, but
>    parenthesis (denoting lists, ordered n-paris, or
>    vectors!).
>
> The rest of the post I appreciate and especially the
> the ASCII figures.

The rest of the post answers to the question why there are different
types.


Now, nothing prevents you to travel back to 1960, and ignore those
additionnal types, using only lists, symbol and numbers.

Notice by the way that in emacs lisp, we lack structure types.  We can
still implement them using vectors (or lists), and write program using
the structure abstraction.  If you want to write programs using vector
or string abstractions without using actual vector or string type
objects you can do so.  You might have to avoid a few modern libraries,
but it would be no problem to rewrite the required library functions
using only the list type: this is 1960 technology.

    (defstruct point x y)
    (make-point :x 2 :y 3)
    ;; --> [cl-struct-point 2 3]

    (defstruct (vect (:type list)) x y)
    (make-vect :x 2 :y 3)
    ;;  --> (2 3)

    (defstruct (vect3 (:type list) :named) x y z)
    (make-vect3 :x 2 :y 3 :z 4)
    ;; --> (vect3 2 3 4)

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk


  parent reply	other threads:[~2015-10-16  3:31 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.428.1444957396.7904.help-gnu-emacs@gnu.org>
2015-10-16  1:51 ` why are there [v e c t o r s] in Lisp? Pascal J. Bourguignon
2015-10-16  2:31   ` Emanuel Berg
2015-10-16  2:29     ` Random832
2015-10-16  2:51       ` Emanuel Berg
2015-10-16  2:56         ` Random832
2015-10-16 23:30           ` Emanuel Berg
     [not found]           ` <mailman.482.1445037713.7904.help-gnu-emacs@gnu.org>
2015-10-17  1:55             ` Pascal J. Bourguignon
2015-10-17  4:47               ` Emanuel Berg
     [not found]               ` <mailman.494.1445057637.7904.help-gnu-emacs@gnu.org>
2015-10-17 15:25                 ` Pascal J. Bourguignon
2015-10-17 21:12                   ` Emanuel Berg
     [not found]                   ` <mailman.519.1445115776.7904.help-gnu-emacs@gnu.org>
2015-10-18  1:08                     ` Pascal J. Bourguignon
     [not found]         ` <mailman.432.1444964227.7904.help-gnu-emacs@gnu.org>
2015-10-16  3:57           ` Pascal J. Bourguignon
2015-10-16  4:17             ` Random832
     [not found]             ` <mailman.434.1444970033.7904.help-gnu-emacs@gnu.org>
2015-10-16  5:16               ` Pascal J. Bourguignon
     [not found]   ` <mailman.429.1444962165.7904.help-gnu-emacs@gnu.org>
2015-10-16  3:31     ` Pascal J. Bourguignon [this message]
2015-10-16 23:46       ` Emanuel Berg
     [not found]       ` <mailman.483.1445038647.7904.help-gnu-emacs@gnu.org>
2015-10-17  2:04         ` Pascal J. Bourguignon
2015-10-17  4:40           ` Random832
2015-10-17  5:00             ` Emanuel Berg
2015-10-17  4:40           ` Emanuel Berg
2015-10-17  5:56           ` Barry Margolin
2015-10-17 15:06             ` Emanuel Berg
     [not found]           ` <mailman.491.1445056308.7904.help-gnu-emacs@gnu.org>
2015-10-17  5:53             ` Barry Margolin
2015-10-17 15:16             ` Pascal J. Bourguignon
2015-10-17 21:06               ` Emanuel Berg
     [not found]               ` <mailman.518.1445115463.7904.help-gnu-emacs@gnu.org>
2015-10-18  1:07                 ` Pascal J. Bourguignon
2015-10-18 12:32                   ` Emanuel Berg
     [not found]                   ` <mailman.551.1445171034.7904.help-gnu-emacs@gnu.org>
2015-10-18 12:55                     ` Pascal J. Bourguignon
2015-10-18 14:28                       ` Emanuel Berg
2015-10-18 21:17                         ` Robert Thorpe
     [not found]                       ` <mailman.557.1445177952.7904.help-gnu-emacs@gnu.org>
2015-10-18 19:48                         ` Barry Margolin
2015-10-18 21:25                           ` Emanuel Berg
2015-10-18 21:39                             ` Random832
2015-10-19  0:46                         ` Pascal J. Bourguignon
2015-10-16 13:32 ` Barry Margolin
2015-10-16 23:47   ` Emanuel Berg
     [not found] <mailman.581.1445203060.7904.help-gnu-emacs@gnu.org>
2015-10-19  0:45 ` Pascal J. Bourguignon
2015-10-16  1:12 Emanuel Berg
2015-10-17  1:11 ` Aurélien Aptel
2015-10-17  4:22   ` Emanuel Berg
2015-10-17  7:58   ` Jude DaShiell
2015-10-19 16:33     ` Nick Dokos
     [not found]   ` <mailman.490.1445055179.7904.help-gnu-emacs@gnu.org>
2015-10-17 15:09     ` Pascal J. Bourguignon
     [not found] ` <mailman.488.1445044303.7904.help-gnu-emacs@gnu.org>
2015-10-17  2:22   ` Pascal J. Bourguignon
2015-10-17  4:56     ` Emanuel Berg
2015-10-17  5:49       ` Barry Margolin
2015-10-17 15:04         ` Emanuel Berg
     [not found]         ` <mailman.506.1445093727.7904.help-gnu-emacs@gnu.org>
2015-10-17 15:20           ` Pascal J. Bourguignon
2015-10-17 15:38             ` Emanuel Berg
     [not found]             ` <mailman.511.1445095810.7904.help-gnu-emacs@gnu.org>
2015-10-17 16:01               ` Javier
2015-10-17 16:03                 ` Javier
2015-10-17 16:34                 ` Pascal J. Bourguignon
2015-10-17 21:18                   ` Emanuel Berg
2015-10-17 16:15               ` Pascal J. Bourguignon
2015-10-17 21:37                 ` Emanuel Berg
2015-10-17 15:18       ` Pascal J. Bourguignon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87eggvebfs.fsf@kuiper.lan.informatimago.com \
    --to=pjb@informatimago.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.