Excerpts from Maxence Guesdon's message of Wed Nov 19 21:11:24 +0100 2008:
On Wed, 19 Nov 2008 10:46:24 +0100
Paolo Donadeo [EMAIL PROTECTED] wrote:
Couldn't we take inspiration from the Python standard library [1]?
Python hasn't namespace but is provided with a module system similar
to
On Thu, Nov 20, 2008 at 10:28:07AM +0100, Nicolas Pouillard wrote:
No one (I guess) would recommend you to use fully qualified paths as in
Data.Containers.List.length of course. Data.Containers.List.length is the
external name, made to be well organized not to be quick to type, the way
to use
On Thu, Nov 20, 2008 at 10:33:03AM +, Richard Jones wrote:
Encouraging developers to open modules is also usually a bad idea,
except in very limited circumstances (hello Printf).
Why? You and others failed me to convince of this. Or, better, I'm
sure there are problems with that, but they
On 20 November 2008 10:49, Stefano Zacchiroli wrote:
On Thu, Nov 20, 2008 at 10:33:03AM +, Richard Jones wrote:
Encouraging developers to open modules is also usually a bad idea,
except in very limited circumstances (hello Printf).
Why? You and others failed me to convince of this. Or,
Le 20 nov. 08 à 11:49, Stefano Zacchiroli a écrit :
Problem 1) once you open you loose the information where an identifier
comes from. True, but it is a tool deficiency, not an intrinsic
deficiency.
I disagree. Having to invoke a tool to know where an identifier comes
from when I read
On Thu, Nov 20, 2008 at 11:49:14AM +0100, Stefano Zacchiroli wrote:
On Thu, Nov 20, 2008 at 10:33:03AM +, Richard Jones wrote:
Encouraging developers to open modules is also usually a bad idea,
except in very limited circumstances (hello Printf).
Why? You and others failed me to
On Thu, Nov 20, 2008 at 11:29:44AM -, David Allsopp wrote:
Consider
open Array;;
open List;;
(* Hundreds of lines of code *)
length [];;
Oh god yes, I was bitten by almost this just a few days ago, except my
code was:
open Printf
open Format
(*...*)
printf I'm trying to
Excerpts from Richard Jones's message of Thu Nov 20 11:33:03 +0100 2008:
On Thu, Nov 20, 2008 at 10:28:07AM +0100, Nicolas Pouillard wrote:
No one (I guess) would recommend you to use fully qualified paths as in
Data.Containers.List.length of course. Data.Containers.List.length is the
Excerpts from David Allsopp's message of Thu Nov 20 11:29:44 UTC 2008:
On 20 November 2008 10:49, Stefano Zacchiroli wrote:
On Thu, Nov 20, 2008 at 10:33:03AM +, Richard Jones wrote:
Encouraging developers to open modules is also usually a bad idea,
except in very limited
Excerpts from Nicolas Pouillard's message of Thu Nov 20 14:01:53 +0100 2008:
Excerpts from David Allsopp's message of Thu Nov 20 11:29:44 UTC 2008:
On 20 November 2008 10:49, Stefano Zacchiroli wrote:
On Thu, Nov 20, 2008 at 10:33:03AM +, Richard Jones wrote:
Encouraging developers
Consider
open Array;;
open List;;
I doubt anyone is recommending this. The module design dictates, to some
extent, whether the module should be opened. Array and List clearly should
not since they have commonly used function names. However, the proposed
Data.Containers certainly should be
PhD POSITION:
Trust and Authority in an Open Web Environment
at the VU University Amsterdam, Department of Computer Science
Deadline for applications: December 15, 2008
THE POSITION
This PhD position is concerned with management of trust and authority
for accessing, integrating and
On Thu, Nov 20, 2008 at 02:41:12PM +0100, Nicolas Pouillard wrote:
Given the crowd of people wanting it, I've added a link [1] to the
camlp4 wiki [2] :)
Erm, given the crowd of people wanting it, what about including it in
legacy camlp4? :-)
--
Stefano Zacchiroli -o- PhD in Computer Science \
On Thu, Nov 20, 2008 at 11:29:44AM -, David Allsopp wrote:
Why? You and others failed me to convince of this. Or, better, I'm
sure there are problems with that, but they just show deficiencies
inherited from other parts of the language.
Consider
open Array;;
open List;;
You are
On Thu, Nov 20, 2008 at 11:48:57AM +, Richard Jones wrote:
open Printf
open Format
Let me stress once more that the Batteries hierarchy is not
advertising anything like that. What is advertising (modulo syntax
extensions helping out) is to open partial module paths which just
contain
Dear list,
Feedback from active members of the list (and a few other shy people
who seem to prefer answering off-list:)) seems to indicate that
Batteries shouldn't have a general hierarchies of modules but rather a
flat list of modules with a few submodules here and there, along with a
At the moment, there is no difference between modules and namespaces.
Among other things, this means that if I write an extension MyList to
List and someone else writes and extension HisList to List, there is no
automated way to merge these, I need to write yet another module
LatestList to be able
And what about include (it is your import) ? It allows what you want and
is short ?
module Mylist = struct
let id x = x
end
module Hislist = struct
let id2 x = x
end
module Alllist = struct
include Mylist
include Hislist
end
What is really missing is renaming when opening or doing
Le 20 nov. 08 à 22:12, David Teller a écrit :
If anyone is willing to work on a solution for linking documentation
from third-party libraries into one transparent source, as suggested
by Richard Jones, please contact me.
I'm not sure I understand what you want to acheive. If it is only a
In order to catch array access violations, it seems necessary to do
something like this:
exception Array_access of int
let test i =
try
[||].(i)
with
Invalid_argument index out of bounds - raise (Array_access i)
The problem is that this test is dependent on a literal
Le 21 nov. 08 à 03:56, Eliot Handelman a écrit :
In order to catch array access violations,
Don't do that. This was already raised on the list but I cannot find
the reference anymore. One argument that comes to mind is if one day
you need optimal performance you won't be able to compile
21 matches
Mail list logo
