public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Underwood <jonathan.underwood@gmail.com>
To: gsl-discuss@sourceware.org
Subject: Re: containers tentative design summary
Date: Sun, 15 Nov 2009 16:44:00 -0000	[thread overview]
Message-ID: <645d17210911150843h7034c341yb453d3fb3f3fb8cf@mail.gmail.com> (raw)
In-Reply-To: <4AFFC617.9050707@iki.fi>

2009/11/15 Tuomo Keskitalo <Tuomo.Keskitalo@iki.fi>:
> Hello,
>
> On 11/14/2009 04:42 PM, Brian Gough wrote:
>
>> At Mon, 09 Nov 2009 16:07:43 -0700,
>> Gerard Jungman wrote:
>>>
>>> On Fri, 2009-11-06 at 14:42 +0000, Brian Gough wrote:
>>>>
>>>> Ok, I have read the paper now.  I do think the practice of casting
>>>> described there is rather dated.  When people had no viable
>>>> alternative to C, they had to resort to such tricks.  It is not
>>>> something that should be encouraged today -- programs should either be
>>>> written safely, following the rules of type-checking in C, or be
>>>> written in another language.
>>
>> From 1.3 million lines of code they describe only one method which
>> does not use casts, which is the one we use.  I don't think we are
>> going to find anything that is better than the current method for
>> views.
>
> Apparently this is a fundamental question.
>
> Currently GSL uses C in a type-safe manner which forces somewhat complicated
> APIs for everyone but enables users to find some lethal bugs. More
> user-friendly APIs would allow people to silently break their programs if
> they are not careful. And there is no compromise. Does this summarize the
> situation?
>
> I am sure there are users for both approaches. I don't know.. Maybe GSL
> should be the safe, strict library, and there should be another scientific
> library in C which aims towards interoperability between data, libraries and
> languages? This would split forces, but both projects would also benefit
> from each other.
>


I think it would be better if GSL, being written in C,  were to
present the most functional interface at the expense of sacrificing
type safety, and higher level language bindings could then wrap that
API and do type checking as needed. As gerard says, C isn't about type
safety.

Jonathan

  reply	other threads:[~2009-11-15 16:44 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-03 19:44 Gerard Jungman
2009-11-09 20:41 ` Brian Gough
2009-11-09 23:06   ` Gerard Jungman
2009-11-14 15:25     ` Brian Gough
2009-11-15  9:13       ` Tuomo Keskitalo
2009-11-15 16:44         ` Jonathan Underwood [this message]
2009-11-15 18:41           ` Robert G. Brown
2009-11-16 11:56         ` Brian Gough
  -- strict thread matches above, loose matches on Subject: below --
2009-11-20  9:37 Justin Lenzo
2009-10-05 10:12 Gerard Jungman
2009-10-05 14:50 ` James Bergstra
2009-10-05 23:00   ` Gerard Jungman
2009-10-05 23:45     ` James Bergstra
2009-10-06 19:59       ` Gerard Jungman
     [not found]     ` <645d17210910060537s762d6323pfd2bec8590ad28e9@mail.gmail.com>
2009-10-06 20:02       ` Gerard Jungman
2009-10-23 21:28     ` Brian Gough
2009-10-27 23:06       ` Gerard Jungman
     [not found]         ` <7f1eaee30910271628h70785125m68e47c7a7b5c25b7@mail.gmail.com>
2009-10-27 23:49           ` Gerard Jungman
2009-10-29 18:06         ` Brian Gough
2009-10-29 20:41           ` Gerard Jungman
2009-10-29 21:40             ` James Bergstra
2009-10-30 16:54               ` Brian Gough
2009-10-30 16:54             ` Brian Gough

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=645d17210911150843h7034c341yb453d3fb3f3fb8cf@mail.gmail.com \
    --to=jonathan.underwood@gmail.com \
    --cc=gsl-discuss@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).