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

[Peter S. Housel]

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.

> + What's the reasoning behind not having format-string and
>   format-arguments slots in <error>, but rather putting them in
>   <simple-error>?  This is a wart on the language.  (And why not just
>   make it error-message instead of two separate slots?  You probably
>   don't want to risk caching the format arguments anyway, most of the
>   time.  [later] Is it to prevent everyone from having to import
>   format-to-string?  Or to prevent having to do the formatting unless
>   the error is actually signalled?)

I think there's sufficient call for <error> objects that don't have
human-readable strings.  Leaving the format in two separate components
does indeed prevent having to do the formatting unless somebody actually
wants to see it printed out.  If you're just going to re-throw some
other condition then there's no point in doing the formatting.

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

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

> testworks
> =========
> 
> + It would be cool if there were support for not-yet-implemented in
>   testworks-specs.  I.e., when a module spec is first generated it
>   could fill in each test with a call to
>   test-not-implemented(test-name) so you could see in the results what
>   percentage of the spec is covered (roughly).  Or perhaps it could
>   automatically do this if the body of the test is empty (i.e., only
>   hase "// Fill me in ...").

Seems like a good idea.

> + my-test-suite-app --list-tests and/or --list-suites and/or
--list-all  

Ditto.

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

>   Has number-to-string but no string-to-number.

My proposal does not have this, maybe because (1) I never use
number-to-string and (2) I didn't bother coming up with rules for how it
should work.  Presumably it would do the same thing as the Dylan parser.

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

position() is weird.  I think there are even different versions in
common-dylan and in duim-utilities.

http://www.lispworks.com/documentation/HyperSpec/Body/f_pos_p.htm is the
reference for CL's POSITION.

> String Hacking
> ==============

Haven't looked at any of this in detail.  My string handling needs are
usually specialized enough that I end up rolling my own.

> regular-expressions
> ===================

Ditto here.  I've also rolled my own regex engine, at least twice,
though I've used the regular-expressions one too.

> Koala
> =====

Haven't looked at Koala much either.

> General
> =======
> 
> + Is there a good way to browse the DRM directly from the source?  It
links to
>   pages without ".html" appended.

I started to write a Perl script to fix this (using Perl's HTML::Parser
module) but never finished it.  I never understood the philosophical
reasons for doing it this way.

> Projects
> ========
> 
> Things I'd like to work on if time permits.
> 
> + Logging library.  Generalize the Koala logging code and separate
>   it out.

Sadly, I've never seen a logging library I really liked.

> + Rename some locators classes::
> 
>       use locators,
>         rename: {<http-server> => <http-server-url>,
>                  <ftp-server> => <ftp-server-url>,
>                  <file-server> => <file-server-url>};

Seems sensible.

-Peter-