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
