[Gd-hackers] [Gd-chatter] r11662 - trunk/sandbox/cgay

[Carl Gay]

On Feb 5, 2008 10:08 PM, Dustin Voss <d_j_v at mac.com> wrote:
> On Feb 5, 2008, at 11:30 AM, Peter S. Housel wrote:
> > On Mon, 2008-02-04 at 17:16 +0100, cgay at gwydiondylan.org wrote:
> >> Dylan Language
> >> ==============
> >>
> >> + It appears that if you define a sideways method (e.g., as(<string>,
> >>  <character>)) there is no way to avoid importing the definition if
> >>  you use the library (note: not the module) that defines it?  I tried
> >>  not using string-conversions, which defines it.  Is this an Open
> >>  Dylan bug?
> >
> > No, this is just the way GFs in Dylan work.  The as function is a
> > single
> > instance of <generic-function>, with a number of instances of <method>
> > attached to it.  When you load a library, sideways methods defined in
> > the library are attached to their corresponding GFs.  "use module" is
> > just about names, but this behavior relates to the underlying objects
> > they refer to.
>
> I was under the impression that "use module" was about bindings, not
> names. I would think the expected and preferred behavior would work
> like this:
>
> Library LA has module MA and generic GFA. Library LB uses LA and has
> module MB that imports MA. MB has a method MFB congruent to GFA.
> Library LC uses LA & LB and has module MC that uses MA & MB. When LC
> loads LA and LB, I would expect that MFB and GFA would both be visible
> within MC and MFB would be added to GFA.
>
> You are telling me that this only happens if GFA and/or MFB have the
> "sideways" adjective? Why is it desirable to make the behavior I
> describe above a special case?

I'd like to hear the answer to this as well.

> >> + For writing code with a lot of regular expressions in it, Python's
> >>  r"..."  syntax is very nice.  What about adding something similar to
> >>  Dylan?  e.g., #r"...".
> >
> > Or maybe #/.../ would work.  Like element(), it could expand to
> > regular-expression("...") (or regex("...")) in the current scope.

Maybe, but that's not what r"..." does in Python.  It just means "in
the following string constant \ is not special" (more or less) so
instead of "\\w" to match a word character you write r"\w".  That's
all I was proposing.

> No strong opinion, but I prefer #r"..." so that we only have the
> string escaping regimen (i.e. \") to worry about, rather than both the
> string and regex escaping regimens (i.e. \" versus \/).
>
> >> common-dylan
> >> ============
> >>
> >> + What's the reasoning behind the 'skip' parameter to some sequence
> >>  functions, like 'position'?  It seems like it would be less
> >>  efficient to use than 'start' and 'end' parameters since the
> >>  implementation would have to start from the beginning each time.  I
> >>  don't like it being a mandatory keyword in the 'position' generic
> >>  function.  (Other functions that have it: find-element, find-value,
> >>  find-key.)
>
> #"skip" doesn't serve the same purpose as #"start" or #"end". #"start"
> and #"end" seem to be used to restrict the search space, but #"skip"
> restricts the result space. For example,
>
>    find-key(#[0, 1, 2, 3, 4, 5], odd?, skip: 2)
>
> would skip returning keys 1 and 3, and would return key 5, whereas
>
>    find-key(#[0, 1, 2, 3, 4, 5], odd?, start: 2)
>
> would operate on #[2..5] and therefore return key 3 (that is, if find-
> key took #"start").

Yes, I guess i'm conflating skip and start/end because the only way
to use the skip parameter to get what I want seems very inefficient
because it will scan from the beginning each time.

The thing is that I can't remember EVER wanting skip, whereas I
frequently want start/end.  Also you can implement skip efficiently
in terms of start and end, but the reverse isn't true.  Maybe this
really isn't about skip so much as the lack of start/end.  They could
coexist nicely.  But do others find skip very useful?

Thanks for your comments.  Peter also.

-Carl