along the consistency in function naming vein:
file-name-from-path versus filename-extension. is "filename" 1 word or 2?
i prefer 1.
even more tangential, why isn't file-name-from-path "path->filename"
instead? or even "basename"?
On Thu, Mar 29, 2012 at 08:07, David T. Pierson wrote:
> On T
On Thu, Mar 29, 2012 at 12:44:35AM -0400, David T. Pierson wrote:
> (Presumably if equally concise names that better reflected function
> signatures were available, they would have been used in the first
> place.)
Sorry for the double post. I should have added "equally lucid" along
with "equally
On Tue, Mar 27, 2012 at 06:23:16PM -0400, Matthias Felleisen wrote:
> The naming consistency is good, but they aren't really consistent at
> the signature or functionality level:
>
> string->number produces #f when called on "hello world" or "\0"
> string->path fails on "\0"
> string->url succ
On Wed, Mar 28, 2012 at 1:24 PM, Jay McCarthy wrote:
> I see a solution to the string->url to be that the function should
> just throw a contract violation exn internally without specifying the
> contract outside. You could document it as having some
> valid-url-string? that called string->url, bu
On 3/27/12, Matthias Felleisen wrote:
> Q: Would it be worth our while to comb through the libraries and make the
> world consistent, even breaking backwards compatibility? I would be willing
> to run such a project.
I think it would be good. I think we should do it as a new #lang to
preserve bac
This post is minimally related to the topic of this thread.
If you continue discussing this idea, please move it elsewhere.
(I happen to agree with Eli's perspective here, which is why I
started this particular thread. Racket makes it particularly
convenient to avoid contracts here and Typed
Yesterday, Andy Gocke wrote:
> [...] This is especially relevant for functions like string->number
> because the most obvious implementation checks validity during
> parsing -- checking the validity and parsing basically duplicate the
> function.
And that makes most of my point.
The thing is tha
Putting aside the 8 (yeah, really) ways to report errors in Haskell, this
is the option provided by the Maybe (data Maybe a = Something a | Nothing).
While I see many benefits to this approach, I think contracts may provide a
new way out. In most typed languages the major constraint seems to be tha
On Mar 27, 2012, at 8:40 PM, Neil Van Dyke wrote:
> we should consider otherwise simplifying some of these identifiers.
That's very high on my list of goals for another, related experiment I have in
mind. I know that this would remove the title of 'world champion in longest
identifier names'
FWIW...
* I have no strong opinion on whether it would be worthwhile, if done in
a backward-compatible way.
* If done in a *non*-backward-compatible way, it might be a headache. I
know of systems in production with millions of lines of PLT/Racket code,
and -- although PLT/Racket have been p
Bug report 12652 reminded me of a topic that I brought up a while back, that I
tried to incorporate into the Style Guide, and that I forgot to re-introduce
here.
Background: a lot of people think that consistency in naming,
signature/contract, and functionality (for methods and functions) is
11 matches
Mail list logo
