On Nov 8, 8:52 am, Chouser <[EMAIL PROTECTED]> wrote:
> Attached is an updated patch. Instead of using "for" in the
> implementation of "doseq", this has a "doseq" that uses loop/recure.
> The interface is the same, but it should run faster. This also means
> "doseq" is only defined once (nor redefined as in the earlier patch).
>
> This patch is against 1089, the "Interim checkin - DO NOT USE!!" version of
> SVN.
>
Patch applied - many thanks!!
Rich
>
> On Sat, Nov 8, 2008 at 7:42 AM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> > On Nov 7, 5:09 pm, James Reeves <[EMAIL PROTECTED]> wrote:
> >> On Nov 7, 9:32 pm, Chouser <[EMAIL PROTECTED]> wrote:
>
> >> > > And in which case, your vector syntax could be misleading, because it
> >> > > seems to imply you're assigning i to 10:
>
> >> > > (dotimes [i 10]
> >> > > (prn i))
>
> >> > Vectors are also used for "for":
>
> >> > (for [i (range 10)]
> >> > (* 2 i))
>
> >> > Here i is not bound to the seq (range 10) but to each of the numbers
> >> > in turn.
>
> >> I'm still not convinced on this one. Currently, you have single
> >> assignments, where a value is assigned to a symbol as in let and
> >> binding, and sequence assignments, where each item in the sequence is
> >> assigned to a symbol. Adding a vector to dotimes would add a third
> >> type, and I don't think it's obvious what the [i 10] does. I mean, you
> >> originally put it down as [i (range 10)], so you were thinking in
> >> terms of [symbol sequence] too.
>
> > The general idea behind this patch is that all macros that introduce
> > names will do so in vector syntax. The nature of the bindings is going
> > to be open, as is the set of macros - doseq/dotimes/let/loop all have
> > different semantics. As it stands, it is confusing for people because
> > they don't know if they need a vector or not, for each macro.
>
> >> > > Second, with your patch, is the following valid:
>
> >> > > (doseq [i (range 10)
> >> > > j (range 10)]
> >> > > (prn i)
> >> > > (prn j))
>
> >> > It behaves the same as "for" does, that is with j in an inner loop.
> >> > It also supports :while and :when as "for" does.
>
> >> Well, not that my opinion matters ;) - but you've sold me on this one.
> >> Consistency with the for macro seems reasonable.
>
> > This is a much-needed enhancement, as so many people use for for side-
> > effects and forget dorun. Plus it will be faster for that use.
>
> >> > My first inclination is to disallow it -- add a check to make sure
> >> > only one binding pair is given. Alternatively it could act as if it
> >> > were nested, as "for" (and now "doseq") do, in which case it would act
> >> > like an "and", and both x and y would be bound to non-false values.
>
> >> Hm. A nested if would be consistent with the nested for and doseq
> >> macros. If this is implemented, nesting ifs would be my preference for
> >> this.
>
> > I'd like to see this patch limit its enhancements to "doseq a la for",
> > and otherwise just be a syntax change for all the others.
>
> > Rich
>
>
>
> doseq-vector-2.patch
> 27KViewDownload
--~--~---------~--~----~------------~-------~--~----~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
