why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Gregor Zattler]

Dear emacsophiles,

ATM i read "An Introduction to Programming in Emacs Lisp".  In
the section where the let function is explained in detail the
author, Robert J. Chassell, uses this "silly" example:

     (let ((zebra 'stripes)
           (tiger 'fierce))
       (message "One kind of animal has %s and another is %s."
                zebra tiger))

which when evaluated produces "One kind of animal has stripes and
another is fierce." as output.

The thing which makes me wonder is why he uses   'stripes   instead
of "stripes" in this example.  In the output of the message
function it makes no difference but to me it seems more natural
to use strings here since they are part of a string in the output...

I do not really understand how the   'stripes   are different
to   "stripes".  Isn't   'stripes   a notation for the symbol
stripes?   This would mean there is the notion of a symbol which
is bound to noting?

Could somebody please enlighten me as to what the differences
between "stripes" and 'stripes are

and

in which cases which notation is more useful/natural?

Thanks, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

RE: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Drew Adams]

> ATM i read "An Introduction to Programming in Emacs Lisp".  In
> the section where the let function is explained in detail the
> author, Robert J. Chassell, uses this "silly" example:
> 
>      (let ((zebra 'stripes)
>            (tiger 'fierce))
>        (message "One kind of animal has %s and another is %s."
>                 zebra tiger))
> 
> which when evaluated produces "One kind of animal has stripes and
> another is fierce." as output.
> 
> The thing which makes me wonder is why he uses   'stripes   instead
> of "stripes" in this example.

Either is OK.  They both produce the same effect here.
Use `C-h f format' to see what %s does (versus %S).

> In the output of the message function it makes no difference but
> to me it seems more natural to use strings here since they are
> part of a string in the output...

The beauty of %s is that you can print any Lisp object.  For a
symbol, its `symbol-name' is printed with %s.

> I do not really understand how the   'stripes   are different
> to   "stripes".  Isn't   'stripes   a notation for the symbol
> stripes?   This would mean there is the notion of a symbol which
> is bound to noting?

Yes, and yes.  Here it is irrelevant whether the symbol `stripes'
is bound to a value.

A symbol can be used for various things in Lisp.  For one thing,
It can act as a variable, having a `symbol-value'.  For another,
it can act as a function, having a `symbol-function'.

It can also act as a (rudimentary) OO object, having "slots" or
"attributes", called its symbol "properties".  These are stored
on its `symbol-plist', and are accessed using `get' and `put'.

And it need not have a non-nil value for any of these things,
in which case it at least acts as an identity, having a
`symbol-name'.

Unlike strings "stripes" and "stripes", which might be `eq' but
at least are `equal', (if in the same obarray) two symbols
`stripes and `stripes are `eq'.  They are the same Lisp object.
For one thing, that generally saves space and makes comparison
quicker.

> Could somebody please enlighten me as to what the differences
> between "stripes" and 'stripes are in which cases which notation
> is more useful/natural?

Natural is in the eye of the beholder.  But symbols are powerful
and easy to use in Lisp.  They are used a lot.

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Emanuel Berg]

Gregor Zattler <telegraph@gmx.net> writes:

> ATM i read "An Introduction to Programming in Emacs
> Lisp".  In the section where the let function ...

Well, the purpose of that chapter is to introduce
`let', which is sort of like defining a bunch of
variables in other programming languages, but more
powerful as you can bind lots of things, and without
having to worry about type, and the scope (the
parenthesis) is explicit, as always -- apart from some
more subtle differences which you will get to (depends
what you compare to as well).

Also note the `let*' if you want one definition to be
based on a previous one (i.e., get a predator zebra). I
guess `let' is a "function" (but written in C, a
so-called special form) but to me it is just how you
accomplish good code in Lisp. So use it as much as
possible!

> I do not really understand how the 'stripes are
> different to "stripes".  Isn't 'stripes a notation
> for the symbol stripes?  This would mean there is the
> notion of a symbol which is bound to noting?

Yes, I guess - a "string" is a string, and 'stripes is
- 'stripes. When you quote 'something, this is accepted
as it is. In this case, as it "not is" is a variable,
so if it is not quoted, Lisp would look for a value to
replace it with. If you quote a '(left parenthesis),
instead of a function to be evaluated, you get a list.

There is also the backtick, which gets you a list *but*
with a comma, you can evaluate part(s) of the list -
compare:

`(all list (+ 1 2 3))
`(all list but last ,(+ 1 2 3))

(Try to evaluate those.)

All this is due to the nature of Lisp and the mix of
data and code in a shared data structure (the list) and
even using the same syntax.

But there are guys on this list who could explain this
much more accurate than I (and I hope they will).

> Could somebody please enlighten me as to what the
> differences between "stripes" and 'stripes are and in
> which cases which notation is more useful/natural?

In this, case, strings would be more natural what I can
see. That's why you should avoid "silly" examples, I
guess, to you future writers. But, check out the
documentation for `message' - and then hit RET on
`format' - and check out "%s":

%s means print a string argument.  Actually, prints any
   object, with `princ'.

So though 'stripes is not a string it works.

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

() Gregor Zattler <telegraph@gmx.net>
() Sun, 29 Dec 2013 15:23:32 +0100

   [...] differences between "stripes" and 'stripes are and in which
   cases which notation is more useful/natural?

A string is not atomic.  It is most natural to use atoms at the base.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Damien Wyart]

* Thien-Thi Nguyen <ttn@gnu.org> in gnu.emacs.help:
> A string is not atomic.

I don't understand, the elisp reference says that strings are atoms:
http://www.gnu.org/software/emacs/manual/html_node/eintr/Lisp-Atoms.html

and that the only type not being an atom is the cons cell, and AFAIK,
strings are not cons cells.

As a quick test, evaling
(atom "mystring")
returns t.

-- 
DW

RE: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Drew Adams]

> * Thien-Thi Nguyen <ttn@gnu.org> in gnu.emacs.help:
> > A string is not atomic.
> 
> I don't understand, the elisp reference says that strings are atoms:
> http://www.gnu.org/software/emacs/manual/html_node/eintr/Lisp-Atoms.html
> 
> and that the only type not being an atom is the cons cell, and AFAIK,
> strings are not cons cells.
> 
> As a quick test, evaling (atom "mystring") returns t.

Yes, a string is a Lisp atom.  This meaning of atomic says only that
it is not a cons.

I think what TTN meant perhaps is that a string is also a sequence
(an array) of characters, i.e., a collection.
See (elisp) `String Basics'.

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Barry Margolin]

In article <mailman.10627.1388327081.10748.help-gnu-emacs@gnu.org>,
 Gregor Zattler <telegraph@gmx.net> wrote:

> Dear emacsophiles,
> 
> ATM i read "An Introduction to Programming in Emacs Lisp".  In
> the section where the let function is explained in detail the
> author, Robert J. Chassell, uses this "silly" example:
> 
>      (let ((zebra 'stripes)
>            (tiger 'fierce))
>        (message "One kind of animal has %s and another is %s."
>                 zebra tiger))
> 
> which when evaluated produces "One kind of animal has stripes and
> another is fierce." as output.
> 
> The thing which makes me wonder is why he uses   'stripes   instead
> of "stripes" in this example.  In the output of the message
> function it makes no difference but to me it seems more natural
> to use strings here since they are part of a string in the output...

It may be a (very) old habit. Early versions of Lisp didn't have 
strings. To do what we do now with strings, they would typically use a 
symbols whose print-name is the string, or a list of single-character 
symbols (depending on whether they needed to refer to the string as a 
whole, or needed to extra substrings from it).

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Rustom Mody]

 On Sunday, December 29, 2013 7:53:32 PM UTC+5:30, Gregor Zattler wrote:
> Dear emacsophiles,

> ATM i read "An Introduction to Programming in Emacs Lisp".  In
> the section where the let function is explained in detail the
> author, Robert J. Chassell, uses this "silly" example:

>      (let ((zebra 'stripes)
>            (tiger 'fierce))
>        (message "One kind of animal has %s and another is %s."
>                 zebra tiger))

> which when evaluated produces "One kind of animal has stripes and
> another is fierce." as output.

> The thing which makes me wonder is why he uses   'stripes   instead
> of "stripes" in this example.  In the output of the message
> function it makes no difference but to me it seems more natural
> to use strings here since they are part of a string in the output...

> I do not really understand how the   'stripes   are different
> to   "stripes".  Isn't   'stripes   a notation for the symbol
> stripes?   This would mean there is the notion of a symbol which
> is bound to noting?

> Could somebody please enlighten me as to what the differences
> between "stripes" and 'stripes are

> and

> in which cases which notation is more useful/natural?

 In http://www.catb.org/esr/faqs/hacker-howto.html Eric Raymond says:

 LISP is worth learning for a different reason — the profound
 enlightenment experience you will have when you finally get it. That
 experience will make you a better programmer for the rest of your
 days, even if you never actually use LISP itself a lot.

 So...
 You are almost there... at the Zen of Lisp!
 And getting lisp symbols is an important part of that

 Lisp is a completely bizarre language because unlike most others its
 primary data structure -- S-exp -- is identical to that used for (lisp) code.

 Very key to that is that symbols do double duty
 - they are variables like in other languages
 - they are data like strings in other languages

 For more on this look up homoiconicity
 Also Ive a blog post on that
http://blog.languager.org/2013/08/applying-si-on-sicp.html
 But for that you need to know scheme

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]

() Damien Wyart <damien.wyart@free.fr>
() Mon, 30 Dec 2013 14:19:47 +0100

   I don't understand, the elisp reference says that strings are atoms:
   http://www.gnu.org/software/emacs/manual/html_node/eintr/Lisp-Atoms.html

   and that the only type not being an atom is the cons cell, and AFAIK,
   strings are not cons cells.

   As a quick test, evaling
   (atom "mystring")
   returns t.

Right.  Emacs knows only ‘atom’, but programmers know concepts beyond
those strict definitions.  That's why it's fun and confusing.  :-D

In this case, the tutorial is from one programmer to another, and i
imagine that if i were trying to communicate foundational concepts, i
would also choose an indivisible type (to start).  Calling it "atomic"
is simply ignorant post-facto rationalization of yet another programmer
trying to be concise and appear "wise" (hee hee).  Oh well, better luck
next time!

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Emanuel Berg]

Thien-Thi Nguyen <ttn@gnu.org> writes:

>> differences between "stripes" and 'stripes are and
>> in which cases which notation is more
>> useful/natural?
>
> A string is not atomic.

I don't think a string is atomic either. I always
thought a "string" was syntax for a list of chars:

'(?s ?t ?r ?i ?n ?g)

But *no*,

(listp "string") ; nil
(car   "string") ; error on `listp'
(cdr   "string") ; same error
(first "string") ; same
(last  "string") ; works (?), "string"
(nth 0 "string") ; same error

But I guess, the only thing that is truly atomic is *a
single bit* - even a bit-pattern representing a char is
a representation that can be tampered with.

What is an object in C++? A bit-pattern in memory...

When computer languages are designed (or evolve into
maturity) perhaps it makes sense to draw the line
somewhere a bit (pun) "up" from that (the binary
integer) - it depends what precision the language
offers to manipulate data on the hardware level - just
*where* it makes sense to say that something is atomic
and something not so.

Or perhaps the definition is: a data structure that
cannot be updated without destroying it and setting it
up anew: lots of atoms around, if so.

Well, what do you mean by

> It is most natural to use atoms at the base.

But I agree that it sounds very natural :)

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

> LISP is worth learning for a different reason — the
> profound enlightenment experience you will have when
> you finally get it. That experience will make you a
> better programmer for the rest of your days, even if
> you never actually use LISP itself a lot.

To learn Lisp and then to never use it sounds like
something the landed aristocracy could do just before
they get executed by a bunch of revolutionaries.

But I too suspect that Lisp is special.

You know when a bunch of kids get together and start
discussing what computer language is "the best". Those
morons can well be very good programmers but they have
zero overview and experience so they obviously think
that their respective languages are "the best" (and in
a sense that is correct, and most definitively the
correct attitude).

So, without doing that, if it could somehow be
quantified and measured what language is the most
expressive, I say Lisp would score very high.

The only thing I can think of that I saw in other
languages and not in Lisp is *pattern matching*:
branching straight off the functions' heads, like it is
possible to do (and a very common practice) in
languages like Erlang, SML, and Haskell. But I suppose
it could be implemented as a Lisp macro if you really
cared for it.

The history of Lisp would be interesting to know in
some detail. I know it came from the US AI/university
world. Which makes sense because AI is basically
searching and modifying data structures. So the
data/code blend fits well, though I don't know if that
is a coincidence or genius or a bit of both. And though
Lisp has university history, it doesn't feel that
"mathy" as for example Haskell and the other stuff
those puritans use. Then there were the "Lisp wars"
with several competing dialects, and finally some
unification efforts with Common Lisp. Today Lisp seems
marginalized apart from the university world, but there
it is treated as a language within the "functional"
paradigm where they are neurotic about
"side-effects". It is not my experience that Lisp is
like that. If you want to do everything with recursion
and set functions no one is stopping you, but I don't
do that, and besides when I write C, I use functions
as well! So while there is truth to both the AI and the
functional approach to Lisp, to me Lisp is a tool that
can be used in many ways, none of which is more
precious than the other.

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Evans Winner]

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

    The only thing I can think of that I saw in other
    languages and not in Lisp is *pattern matching*:
    branching straight off the functions' heads, like it is
    possible to do (and a very common practice) in
    languages like Erlang, SML, and Haskell. But I suppose
    it could be implemented as a Lisp macro if you really
    cared for it.

For what it's worth, you might find Shen interesting --

    shenlanguage.org

From the "Shen in 15 Minutes" page:

(define factorial
  0 -> 1  
  X -> (* X (factorial (- X 1))))

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Rustom Mody]

Emanuel Berg writes:
> Rustom Mody writes:
>
> > LISP is worth learning for a different reason — the
> > profound enlightenment experience you will have when
> > you finally get it. That experience will make you a
> > better programmer for the rest of your days, even if
> > you never actually use LISP itself a lot.
>
> To learn Lisp and then to never use it sounds like
> something the landed aristocracy could do just before
> they get executed by a bunch of revolutionaries.

When I was in school I was training for cycling races -- used to
get up every morning and 'practice' (which means cycle) for
almost an hour.

One day my mother discovered through a friend a national level
cycling champ. We went to him for advice.

"Ok lets see you cycle" the champ asked me.
After a minute or two of such checking me out, this was his advice:
"Stop your cycling and do weight training. You need to do squats."

I protested: "Look! I am not into weight training, I want to be a cyclist!"
He shrugged: "Yeah I know. You can follow my advice and come back
after 3 weeks of weight training... Or do what you like..."

After 3 weeks, I had so much more power in my legs, I did not need to
go back and got the prizes I had set out to.

So...

If you think our field is about technology, the above is irrelevant.
If on the other hand you understand that the brain is
a muscle, the question will naturally arise: How do I train?

Yes as a technology, Lisp is mostly irrelevant, as an ideology its
doing great guns. Just look past the fashion-fad names like
'functional programming'
Some more on my blog:
http://blog.languager.org/2012/10/functional-programming-lost-booty.html

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

> When I was in school I was training for cycling races
> -- used to get up every morning and 'practice' (which
> means cycle) for almost an hour. ...

Cool story!

Of course: the brain is part of the body, and the body
is a brain. A much better brain than lots of smart guys
tend to reckon, I reckon.

When you go to sleep, try memorizing a castle with 10
rooms, and in each room: 10 items.

If you can't do it, there are tricks like having the
rooms and items in ABC order, and having each room
stick to a *theme*:

A (the first room) is the *armory* - items:
a - armor, b - bow, c - cloak, d - dagger, ...
B (the second room) is the *bakery* - items: ...

Now, try doing this exercise after 1) being frustrated
at your fast food job, and 2) after doing something
pleasant with Lisp and then digging a trench somewhere
in the forest until you hands hurt. After doing 2),
you can ace the entire exercise but after 1), your
thoughts will be messy with bling-blong, stress,
customers flashing back and fourth...

To be a good programmer, you need to program yourself
as much as the software. I am very disappointed with
the computer industry, which I think is a bunch of
idiots (mostly, those I met anyway) but since
programming gave me a clear head, I still don't regret
doing it so much, even though I don't think I'll be a
rich superstar anytime soon the way the industry looks.

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Emanuel Berg]

Evans Winner <ego111@gmail.com> writes:

>> The only thing I can think of that I saw in other
>> languages and not in Lisp is *pattern matching*:
>> branching straight off the functions' heads, like it
>> is possible to do (and a very common practice) in
>> languages like Erlang, SML, and Haskell. But I
>> suppose it could be implemented as a Lisp macro if
>> you really cared for it.
>
> For what it's worth, you might find Shen interesting
>
>     shenlanguage.org
>
> From the "Shen in 15 Minutes" page:
>
> (define factorial 0 -> 1 X -> (* X (factorial (- X
> 1))))

Yes, that's exactly what I meant, and that looks like a
mix of Lisp and Erlang.

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Emanuel Berg]

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

>>> The only thing I can think of that I saw in other
>>> languages and not in Lisp is *pattern matching*:
>>> branching straight off the functions' heads, like
>>> it is possible to do (and a very common practice)
>>> in languages like Erlang, SML, and Haskell. But I
>>> suppose it could be implemented as a Lisp macro if
>>> you really cared for it.
>>
>> For what it's worth, you might find Shen interesting
>>
>> shenlanguage.org
>>
>> From the "Shen in 15 Minutes" page:
>>
>> (define factorial 0 -> 1 X -> (* X (factorial (- X
>> 1))))
>
> Yes, that's exactly what I meant, and that looks like
> a mix of Lisp and Erlang.

I just read on the Shen page that

> Shen began many years ago in 1989 when Dr. Mark
> Tarver was working at the Laboratory for the
> Foundations of Computer Science at Edinburgh.  The
> original idea was to bring to the Lisp environment
> many of the advantages of ML; specifically
> pattern-matching and later type checking.

So they did a new language just to get pattern-matching
in Lisp! I'm unsure if that is sheer folly *or*
dedication that should be admired. Anyway, "ML" is
probably the progenitor of the "SML" that I mentioned -
I also remember a "MosML" - Moscow ML - probably just
another dialect.

As for the type checking, I remember you could do that
in ML, only you didn't have to. I am unsure what perk
that would bring except for the occasional bug that
could be found prior to run-time. But testing is so
essential to software anyway so I can't see any real
advantage of that. When you are used to not thinking
about types (as in Lisp) you don't want to do that
again. At least I don't. But please fill me in what the
fuss is about.

Also, when you think about how many Lisp dialects there
are - the Wikipedia article for "LISP" lists these -

Arc, AutoLISP, Clojure, Common Lisp, Emacs Lisp,
EuLisp, Dialects Franz Lisp, Interlisp, ISLISP, LeLisp,
Maclisp, MDL, Newlisp , NIL, Picolisp, Portable
Standard Lisp, Racket, Scheme, SKILL, Spice Lisp, T,
XLISP, Zetalisp

- you kind of wonder if there is no pattern matching or
"type check" (?) in any of those?

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Stefan Monnier]

> advantage of that. When you are used to not thinking
> about types (as in Lisp) you don't want to do that
> again. At least I don't. But please fill me in what the
> fuss is about.

Similarly to learning Lisp, learning to use a typed functional language
like SML, is very useful to help you structure your thought process,
even if you never use it,


        Stefan

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Yuri Khan]

On Thu, Jan 2, 2014 at 2:02 AM, Emanuel Berg <embe8573@student.uu.se> wrote:
> Emanuel Berg <embe8573@student.uu.se> writes:
>
> […] When you are used to not thinking
> about types (as in Lisp) you don't want to do that
> again. At least I don't. But please fill me in what the
> fuss is about.

When you are used to thinking about types and to the compiler checking
them and not letting you do anything that is not type-safe, getting
out in the type-unchecked territory becomes a very frightening
experience. Like walking over a bridge with no safety rail in sight.
You don’t want to do that again.

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Rustom Mody]

Emanuel Berg writes:

> > The original idea was to bring to the Lisp environment
> > many of the advantages of ML; specifically
> > pattern-matching and later type checking.

> So they did a new language just to get pattern-matching
> in Lisp! I'm unsure if that is sheer folly *or*
> dedication that should be admired.

I wrote a destruct macro in scheme -- gives most of what pattern
matching gives in the SML language family -- all of 91 lines.  So much
for lisp not having pattern matching.

Type-discipline is very different issue altogether.  I dont believe
that any macro (system) can do that for lisp.
The issue is that in CS one can choose structuring or universality.
Some of the most powerful ideas in CS come from universality considerations, eg
- von Neumann machines equivalencing data and code
- Turing machine -> universal turing machine
- Unix -- the byte stream as able to carry any and all data
[How much we take for granted the last will be clear if you see what a
file meant
to an earlier generation:
http://en.wikipedia.org/wiki/Data_set_%28IBM_mainframe%29   ]

However at some point people become frightened of what Yuri describes
> Like walking over a bridge with no safety rail in sight.
and start putting up railings -- structurings.

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

>> So they did a new language just to get
>> pattern-matching in Lisp! I'm unsure if that is
>> sheer folly *or* dedication that should be admired.
>
> I wrote a destruct macro in scheme -- gives most of
> what pattern matching gives in the SML language
> family -- all of 91 lines.  So much for lisp not
> having pattern matching.

Yes, if you recall, I mentioned the possibility of
solving that with a macro. Although I couldn't do it (I
never did any macros, perhaps I should), I suspected it
was possible and it is impressive that you pulled that
off. *Much* better than doing a whole new language,
though I also suspect (certainly hope!) that Shen
(apparently "spirit" in Chinese) brings something else
to the table as well. But pattern matching is the first
thing they mention (twice), so perhaps it is just
another case of a bunch of techno-science guys who did
a language just for the challenge and sweet science to
it. Again, if so, I say it is a bit aristocratic but
there is no denying cred to people who do stuff they
love at a very advanced level.

> Type-discipline is very different issue altogether.
> I dont believe that any macro (system) can do that
> for lisp.

Couldn't you somehow annotate data: '('integer 1) and
then prior to assignment run an appropriate test:
(integerp ... )

But I still don't understand the benefit of having the
types explicit in code, apart from the mentioned
compiler type-check - is there anything else to it?
Could you overload functions based on types? (And: do
you *want* to do that?) Could the compiler perform
optimizations if there are, for example, only integer
(and no float) arithmetic? Or is it just a safety-net
so you don't get overflows and truncations and thus
bugs that are very difficult to track? Why is this not
an issue in Lisp? Is Lisp and C very different in this
respect, and if so, how?

> The issue is that in CS one can choose structuring or
> universality.  Some of the most powerful ideas in CS
> come from universality considerations, eg - von
> Neumann machines equivalencing data and code - Turing
> machine -> universal turing machine - Unix -- the
> byte stream as able to carry any and all data.

Yes, this is concepts of the CS curriculum but you'll
have to explain how it applies to the discussion about
types.

> and start putting up railings -- structurings

I think there are more down-to-earth and
implementation-specific reasons - that people in
general are "afraid to fly" might be part of it on a
more philosophical level, though.

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Yuri Khan]

On Thu, Jan 2, 2014 at 9:31 PM, Emanuel Berg <embe8573@student.uu.se> wrote:
> Rustom Mody <rustompmody@gmail.com> writes:
>
> Couldn't you somehow annotate data: '('integer 1) and
> then prior to assignment run an appropriate test:
> (integerp ... )

You could but it becomes unwieldy pretty soon. One does not simply
tell programmers “instead of literal 1, you have to write '('integer
1)”. You also incur run-time tests at each use.

> But I still don't understand the benefit of having the
> types explicit in code, apart from the mentioned
> compiler type-check - is there anything else to it?
> Could you overload functions based on types? (And: do
> you *want* to do that?)

In C++, we do that a lot. We have an operation to write an object into
a text stream that’s written as “stream << object”, where stream is a
special class type representing a file opened for text output, and
object is anything for which operator<< is overloaded. This allows us
to define streaming separately for each type, not in a single
universal function with a gargantuan type-switch on the outermost
level. (The closest lispic solution that springs to my mind would be
to annotate each object with its type and then have an alist mapping
types to functions, but this incurs the cost of run-time type
information and the dynamic alist lookup, whereas C++ type-based
overloading is resolved at compilation time.)


> Could the compiler perform
> optimizations if there are, for example, only integer
> (and no float) arithmetic?

Could, and can, and routinely does. It is, in fact, a form of function
overloading — just that the functions being overloaded happen to
reside in the standard library and compiled to inline code rather than
a function call.

> Or is it just a safety-net
> so you don't get overflows and truncations and thus
> bugs that are very difficult to track? Why is this not
> an issue in Lisp?

It is. The Emacs Lisp manual specifies that integers are at least 30
bits long and that overflow is not checked. The syntax parser (reader)
automatically parses integral literals bigger than the machine integer
as floats (which may lead to silent loss of precision).

Also, when a library changes the type of some variable (e.g. in v1 it
was an integer, in v2 it is *either* an integer *or* an alist mapping
mode symbols to integers), the clients of that library break at run
time, possibly in the middle of some involved operation, with half of
its side effects already applied and an obscure error message to the
end user’s face. With type checking, they would break at compile or
link time.

Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Emanuel Berg]

Yuri Khan <yuri.v.khan@gmail.com> writes:

>> Couldn't you somehow annotate data: '('integer 1)
>> and then prior to assignment run an appropriate
>> test: (integerp ... )
>
> You could but it becomes unwieldy pretty soon. One
> does not simply tell programmers “instead of literal
> 1, you have to write '('integer 1)”. You also incur
> run-time tests at each use.

For sure, if anyone actually did that, just plain with
no automatizing or preprocessing, it would be
grotesque.

But let's think about how Lisp processing is often
illustrated, not as an endless list but as nested lists
that folds into a tree, with the functions (the first
element of each list) as root or parent (inner) nodes,
and with data as leaves.

If every function node was annotated with argument
types, and a return type, then the whole tree (list)
could be fed to a type checker to see if all input
types are consistent with the output types
(i.e., the return values and argument types all match).

The types of data could be checked at the leaves,
because there it is known what type is expected, so a
single check would be enough.

What would complicate matters is for example the
addition function (+), as

(floatp   (+ 1.0 1)) ; t
(integerp (+ 1   1)) ; t

So such cases would have to be replaced by one-type
equivalents unless the uncertainty could somehow be
"bounded", I suppose by "mixed" types, as in 'number'
(integer *or* float, etc.).

If I would ever use it though, I doubt. I just never
felt the need to think about types in Lisp.

>> But I still don't understand the benefit of having
>> the types explicit in code, apart from the mentioned
>> compiler type-check - is there anything else to it?
>> Could you overload functions based on types? (And:
>> do you *want* to do that?)
>
> In C++, we do that a lot. We have an operation to write
> an object into a text stream that’s written as “stream
> << object”, where stream is a special class type
> representing a file opened for text output, and object
> is anything for which operator<< is overloaded. This
> allows us to define streaming separately for each type,
> not in a single universal function with a gargantuan
> type-switch on the outermost level. (The closest lispic
> solution that springs to my mind would be to annotate
> each object with its type and then have an alist
> mapping types to functions, but this incurs the cost of
> run-time type information and the dynamic alist lookup,
> whereas C++ type-based overloading is resolved at
> compilation time.)

That's true, in C++ it is a very vivid concept. You can
have two classes and then overload the + function, and
then have to instances seemingly "added" but in fact
that operator is setup to whatever turn of events or
data change the programmer sees fit.

I remember they didn't want to allow that in Java
because they were afraid over-creative programmers
would setup all kinds of overloads that would sooner
rather than later render unreadable code. (But Java has
overload, just not down to the bare bones like C++.)

-- 
underground experts united:
http://user.it.uu.se/~embe8573