> Maybe it would be clearer if I proposed some other, lesser-used chars, like
> "%(1 2 3 4)" or even "<1 2 3 4>". That is, I'm not so much saying, "this
> needs to be treated as data and not eval'd" as I am simply saying, "this is
> the 'list' data structure as opposed to some other".
A list data structure and a list code structure are the same. The
only difference is that the programmer decides when one should not be
evaluated. By creating separate syntax for a list data structure you
are in essence creating a different structure for lists of data than
lists of code, and you no longer have a straightforwardly homoiconic
language.
> Why is there an assumption that
> code as data means code as lists? Or is there?
This is the key to everything. Code is data, data is code, they are
the same structure. By treating a list of data (integers for example)
differently than a list of code (function and args), you create a
situation where code and data are no longer the same thing. That
trait is a fundamental trait of lisps, and makes things like macros
much simpler. You don't have to call the structure a list, you can
call it something else if you prefer, but whatever it is called, it
must be the same structure that defines code and defines data.
On Thu, Oct 27, 2011 at 6:58 PM, e <evier...@gmail.com> wrote:
>
> On Oct 26, 2011 7:15 PM, "Stuart Halloway" <stuart.hallo...@gmail.com>
> wrote:
>>>
>>> checking out the "Try Clojure":
>>>
>>> if you type the following, you get output that matches what you typed
>>> in every case except for lists.
>>>
>>> Vectors: --> [1 2 3 4]
>>> [1 2 3 4]
>>>
>>> Maps: --> {:foo "bar" 3 4}
>>> {:foo "bar" 3 4}
>>>
>>> Lists: --> '(1 2 3 4)
>>> (1 2 3 4) <----- *INCONSISTENT* why not render this as '(1 2 3 4) ...
>>> this would make much more sense to newbies.
>>>
>>> Sets: --> #{1 2 3 4}
>>> #{1 2 3 4}
>>
>>
>> This is an interesting question. Consistency is important, but consistency
>> with what? Your mental model for what happens at the REPL needs to keep the
>> R, E, and P steps clearly separate.
>>
>> Working backward: the P (Print) prints things in a way that they can be
>> read back, where possible:
>>
>> (read-string "[1 2 3 4]")
>> => [1 2 3 4]
>>
>> (read-string "(1 2 3 4)")
>> => (1 2 3 4)
>>
>> (read-string "#{1 2 3 4}")
>> => #{1 2 3 4}
>>
>> (read-string "{1 2 3 4}")
>> => {1 2, 3 4}
>>
>> If the P part of the REPL put a tick in front of lists, they would not
>> read back correctly:
>>
>> (read-string "'(1 2 3 4)")
>> => (quote (1 2 3 4)) <---- INCONSISTENT
>>
>
> I see the problem that token " ' " is already taken to be short hand for
> "quote" so to be truly consistent, I might be compelled to argue that
> (read-string "'(1 2 3 4)") should, seeing some hypothetical "list start"
> multi-char token " '( " .... just like set-start is " #{ ", be: => '(1 2 3
> 4).
>
> You'd need two single quotes: "''(1 2 3 4) to get "quote '(1 2 3 4)" ...
> Wheras (1 2 3 4) means "call 1 with ..."
>
> I'll have to reread the explanation about the repl phases, but maybe I'm
> wondering if things don't have to be quoted if lists had the syntax I
> describe, and requests for function invocation had a simple paren. Then you
> are not saying, "treat this as data, do not eval". You are just saying,
> "see my single quote paren token? That's for lists".
>
> Maybe it would be clearer if I proposed some other, lesser-used chars, like
> "%(1 2 3 4)" or even "<1 2 3 4>". That is, I'm not so much saying, "this
> needs to be treated as data and not eval'd" as I am simply saying, "this is
> the 'list' data structure as opposed to some other".
>
> Now, if you ever need to read in a program and treat it like "data", well,
> what structure would you like to put it in? A list? A vector? A string? This
> is, indeed, where I am fuzzy on lisps, but it seems like you parse it as
> desired and put it where/how you like it. Why is there an assumption that
> code as data means code as lists? Or is there?
>
>> Now to the R (Reader) part. If, as you suggest, the tick were part of the
>> reader syntax for lists, you could "fix" the inconsistency above:
>>
>> ;; hypothetical Clojure with '(...) list literals
>> (read-string "' '(1 2 3 4)")
>> => (1 2 3 4)
>>
>> Finally, consider the poor E (Evaluator) in this scenario. The evaluator
>> must (1) evaluate lists except (2) *not* evaluate lists that are protected
>> by quote. But now that the tick is part of the syntax you have two
>> challenges:
>>
>> (1) Since the tick no longer prevents evaluation, you have to spell out
>> the quote (and still use the tick!)
>>
>> ;; hypothetical literal list
>> (quote '(1 2 3))
>>
>> (2) Since the tick is required as part of list syntax, your programs have
>> to be written with ticks everywhere like this:
>>
>> '(defn hello-world
>> []
>> '(println "hello")
>>
>> You have to understand R, E and P as separate steps to understand the
>> REPL.
>>
>> As a side note, it is worth mentioning that the REPL is composed of three
>> simple parts, and that interactive shells that do not have this factoring
>> are much less useful. Imagine if your language didn't separate reading and
>> evaluating. You would need JSON or something to serialize data...
>>
>> Stu
>>
>>
>> Stuart Halloway
>> Clojure/core
>> http://clojure.com
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
