Lazyness

[Serge Wroclawski]

I want to work on some code but I feel like I need to make sure I
understand the lazyness model a bit better.

I also see evidence it's changed or changing. Is this page:

http://clojure.org/lazy

The way it works going forward?

Maybe I'm wrong about this, but my understanding is that many
components will be taking one sequence and returning a new lazy
sequence?

So I'm working through a simple function that takes a text file and
returns it as a sequence, one character at a time.

Then a transformation function (not using the framework yet) that
turns the char into moorse code, and then finally one that prints.

Then when I'm comfortable with that, I'll write these out as
components and the character will come in as {:char "c"} and be
transformed as {:char "c" :morse "_._."}.

When I'm comfortable with that, I'll be comfortable enough to write
real functions to do transformations and have all kinds of substantive
questions.

- Serge

[Luke VanderHart]

Yup.

Actually, to clarify, the semantics of seqs themselves have not
changed. Rather, it is mainly the semantics of the "seq" and "rest"
functions, and in how they are constructed, using "lazy-seq" instead
of "lazy-cons". But if you're not using those functions, then it
doesn't even matter.

Thanks,
-Luke

[Serge Wroclawski]

On Tue, Apr 21, 2009 at 7:33 PM, Luke VanderHart
<luke.va...@gmail.com> wrote:
>
> Yup.
>
> Actually, to clarify, the semantics of seqs themselves have not
> changed. Rather, it is mainly the semantics of the "seq" and "rest"
> functions, and in how they are constructed, using "lazy-seq" instead
> of "lazy-cons". But if you're not using those functions, then it
> doesn't even matter.

Well I'll go through the book again.

Once that's done I have a bunch of components that I think need
writing early on.

The first is a sorted? component which would take an order (ascending
or descending) and a keyword and tell you if the data is sorted or
not.

I don't think anyone will use this by itself, but I can well imagine
wanting to use this during the development phase of a project.

This did get me thinking about output though. I know we've talked
about functions only having one output. I think we may want to think a
little about that... While I agree 100% that functions should only
return a single value, I think data to stdout or stderr might make
sense for use in debugging. I think even Yahoo Pipes does this with a
little console on the screen, and that marries somewhat into what
Conrad was saying. I don't think you want this as part of your
production project, but you'll want to be able to figure some things
out during the development process.

So I'm going to take a crack at this lazy-seq. Any help would be appreciated.

- Serge

[Luke VanderHart]

>The first is a sorted? component which would take an order (ascending
>or descending) and a keyword and tell you if the data is sorted or
>not.

I thought the typical model was that normal components would always
return a seq of maps, not a boolean value? So how would you integrate
this into the pipe? I can understand what would flow to it, but what
would flow from it? Or is this an outputter that just returns a
boolean value?

Not meaning to nitpick, at all, I just want to understand if we have a
different conception of the types of component that are possible.

Thanks,
-Luke

On Apr 21, 7:58 pm, Serge Wroclawski <emac...@gmail.com> wrote:
> On Tue, Apr 21, 2009 at 7:33 PM, Luke VanderHart
>

[Luke VanderHart]

Oh, and also, regarding "multiple outputs" - I think the best way to
think of it is that component only has one formal output, but may
absolutely have any number side effects - they could print to
system.out, or a log file, or modify the pipe state, etc.

Thanks,
-Luke

[Serge Wroclawski]

On Wed, Apr 22, 2009 at 9:52 AM, Luke VanderHart
<luke.va...@gmail.com> wrote:
>
>>The first is a sorted? component which would take an order (ascending
>>or descending) and a keyword and tell you if the data is sorted or
>>not.
>
> I thought the typical model was that normal components would always
> return a seq of maps, not a boolean value?  So how would you integrate
> this into the pipe? I can understand what would flow to it, but what
> would flow from it? Or is this an outputter that just returns a
> boolean value?
>
> Not meaning to nitpick, at all, I just want to understand if we have a
> different conception of the types of component that are possible.

To answer both questions:

Right now we're working on the components from the command line, so
things that print to stdout seem to be the right way to have answers
to boolean questions.

Zooming ahead to the future with, for example, a web gui- I imagine an
example a component being able to output to a console.

We'll probably want some kind of mechanism to capture output (eg
stdout) and put it to a file, or logs or whatever, but for now it's
println :)

To answer your question- I'd planned on returning a true or false-
basically it's an outputter- useful only for debugging.

- Serge

- Serge

[Michael Harrison (goodmike)]

You know, there may be room for specialized components that serve as
predicates or fulfill other uses -- following on the pipes within
pipes illustration we put on the whiteboard Sunday, I can imagine a
"pipe" that combines components and presents a single interface to its
"consumer" (the component that pulls on the pipe). I imagine it by
analogy to a procedure: instead of always having a nested structure
like this...

(z (y (x)))

..you could imagine something more like...

(z (if (p? w) (y) (x)))

...where p? is some kind of specialized predicate component.

I bring this up because I'm looking at coding twitter builders, and
the first step will be calling twitter's API and parsing something
like RSS or JSON. So actually, I could use the RSS reader and the use
that as an input to some twitter component. But if I imagine using the
twitter component, I don't want to explicitly configure an RSS or JSON
reader: depending on what info I want from twitter.com, the twitter
component should just "know" what URL to call with what format (some
twitter services are available as RSS, some only in XML or JSON). It
may be entirely possible to handle this without specialized components
-- I'll try it that way first.

mh

On Apr 22, 10:27 am, Serge Wroclawski <emac...@gmail.com> wrote:
> On Wed, Apr 22, 2009 at 9:52 AM, Luke VanderHart
>