I think I understand more now though, everyone. Thanks. clojure chose
lists for the data structure for code so lists sort of have a special place
in the language.
Thanks again.
On Fri, Oct 28, 2011 at 1:13 AM, e <evier...@gmail.com> wrote:
>
>
> On Thu, Oct 27, 2011 at 8:26 PM, Mark Rathwell <mark.rathw...@gmail.com>wrote:
>
>> > 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.
>
>
> why wasn't vector chosen for code?
>
>
>> 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.
>>
> This seems like a hugely important thing for me to grock, but it is easier
> to grock in languages that, say, ONLY have lists. Otherwise it seems like
> code is arbitrarily ONE of the data structures and, therefore is NOT
> homoiconic with respect to any other data structure.
>
>
>>
>> > 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
>
> yes, fine. but "data" doesn't always mean list in *my* mind. But I'm
> starting to get that it was chosen to be the same thing in lisps.
>
>
>> , 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.
>
> no. code and lists are no longer the same thing. I see "data" as a generic
> concept . . .a superset, not a different set. code could be "data" that I
> haven't picked a data structure for, yet.
>
>
>> That
>> trait is a fundamental trait of lisps, and makes things like macros
>> much simpler.
>
> I suspected this, too. ok.
>
>
>
>> 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.
>
> But, again, there are plenty of structures that define "data" differently
> then that which was chosen for code. So why not just have a "code
> structure". Again, it already seems broken with respect to other
> structures. Here's some "data". It's a vector. Here's *more* data. It's a
> chunk of code. Ah but it was arbitrarily decided (more from history and
> evolution) that *that* data is a list. Broken.
>
>
>
>>
>>
>> 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
>>
>
>
--
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
