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

[Dustin Voss]

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:
>> Author: cgay
>> Date: Mon Feb  4 17:16:14 2008
>> New Revision: 11662
>>
>> Modified:
>>   trunk/sandbox/cgay/dylan-notes.txt
>> Log:
>> job: minor
>> a few updates
>
> A few comments:
>
>> 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?


>> + How do you create Unicode string constants if they only contain
>>  characters that can be expressed in a <byte-string>?  e.g., in
>>  Python u"foo".  Does "\<60>" create a unicode string or a byte
>>  string?  Is this even useful?  How about #u"..."?
>
> I think it would make a lot of sense for <unicode-string> to be the  
> only
> string type, as Bruce Hoult has suggested in the past.   Even if we do
> provide a more space-efficient <byte-string> class (with an encoding
> slot telling how to obtain Unicode characters from it), it might make
> sense for literal strings to always be <unicode-string> since most
> programs don't take up a lot of space with literal strings.

I suspect you do not mean that <unicode-string> and <byte-string>  
should go away, but rather that an instantiation of <string> should  
result in a <unicode-string> rather than <byte-string>. (I agree.)

>> + 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.

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
>> ============
>>
>> + Has float-to-string but no string-to-float.
>
> My proposed floating-point changes to common-dylan (implemented in GD)
> has string-to-float:
>
> define method string-to-float
>    (string :: <byte-string>,
>     #key _start :: <integer> = 0,
>          end: _end :: <integer> = size(string),
>          default-class :: subclass(<float>) = <double-float>)
> => (result :: <float>, next-key :: <integer>);
>
> I'll implement this in OD as soon as I have <extended-integer> working
> in OD, hopefully in March.

Should string-to-float deal with precision, or should a programmer use  
format-to-string if such control is needed?

>> + 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").

>> String Hacking
>> ==============
>>
>> + I don't like the way the string-extensions library is broken up  
>> into modules. I don't see the need for more than one module there,  
>> and their names are odd. Could just add a string-extensions module  
>> that uses all the others and exports all.
>>
>> + The OD and GD string-extensions libraries have diverged enough to  
>> be disturbing. Re-unify them?

Agreed.
>> + Would there be any name conflicts if common-dylan exported all  
>> the string-extensions bindings?
The common-dylan module exports "integer-to-string" and "string-to- 
integer," which are also in the string-conversions module of the  
string-extensions library. I don't know if common-dylan just re- 
exported these from the string-conversions module or not.

I'd prefer that some of the string-extensions library be added to a  
string-extensions module in the common-dylan library, rather than the  
common-dylan module in the common-dylan library.

>> regular-expressions
>> ===================
>>
>> * key-exists? needs to be in common-dylan? Not sure where it's  
>> coming from in GD, and OD defined it directly in regular-expressions.

In Gwydion Dylan, there are two implementations of key-exists? — one  
in the extensions module of the dylan library, and one in the  
collection-utilities module of the collection-extensions library. Not  
sure which is used by the regex code; probably the extensions module  
one.

http://www.opendylan.org/gdref/gdcore/html/files/name-key-existsQ-txt.html#key-exists