## merd-devel — about merd development

You can subscribe to this list here.

 2000 2001 2002 2005 2006 2007 2008 2009 Jan Feb Mar Apr May Jun Jul Aug (5) Sep (43) Oct (15) Nov (20) Dec (2) Jan (12) Feb (20) Mar (7) Apr (18) May (23) Jun (4) Jul (2) Aug (19) Sep (3) Oct (19) Nov (27) Dec (23) Jan (2) Feb (16) Mar (18) Apr (16) May (24) Jun (2) Jul (3) Aug (1) Sep (16) Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct (1) Nov Dec (1) Jan Feb (2) Mar Apr May Jun Jul Aug (1) Sep (2) Oct (8) Nov Dec Jan (1) Feb Mar Apr May Jun Jul Aug Sep (1) Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug (1) Sep Oct Nov Dec Jan (1) Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
S M T W T F S

1
(1)
2

3

4

5

6
(7)
7

8

9

10

11

12
(2)
13
(3)
14

15

16

17

18

19

20

21
(3)
22
(1)
23

24

25

26

27

28

29
(3)
30

Showing 20 results of 20

 Re: [merd-devel] OO and covariance From: Pixel - 2000-11-29 12:53:36 ```Yoann Padioleau writes: > if you want the other behaviour simply make > struct bb : aa { > virtual void g(aa *para) { cout << "bb::g" << "\n"; } > }; eg: struct point2d { int x; int y; virtual bool equal(point2d *p) { return x == p->x && y == p->y; } }; struct point3d : point2d { int z; virtual bool equal(point3d *p) { return x == p->x && y == p->y && z == p->z; } }; int main() { point2d *p2d = new point2d(); p2d->x = 1; p2d->y = 2; point3d *p3d = new point3d(); p3d->x = 1; p3d->y = 2; p3d->z = 3; point3d *p3D = new point3d(); p3D->x = 1; p3D->y = 2; p3D->z = 4; point2d *a = p2d; point2d *b = p2d; point2d *c = p2d; cout << a->equal(b) << "\n"; // true cout << b->equal(c) << "\n"; // false } it uses the lowest common type to compare, whereas it would be nice to compare based on the best one. ```
 Re: [merd-devel] OO and covariance From: Yoann Padioleau - 2000-11-29 12:39:31 ```Pixel writes: > This nice paper talks about overloading/specializing: > > http://citeseer.nj.nec.com/castagna95covariance.html > > > The sheer conclusion is that type safeness can be obtained with multiple > dispatch. It explains how to extand the lambda-calculus with overloading. > > Here is what C++ does: > > -------------------------------------------------------------------------------- > /// as C++ doesn't handle multiple dispatch and still wants to be type safe, > /// it ignores the method covariantly defined :-( > > struct aa { > virtual void g(aa *para) { cout << "aa::g" << "\n"; } > }; > > struct bb : aa { > virtual void g(bb *para) { cout << "bb::g" << "\n"; } > }; > > int main() { > aa *p_aa = new aa(); > aa *p_bb = new bb(); > > p_aa->g(p_bb); > p_bb->g(p_aa); > p_bb->g(p_bb); // uh?! calls aa::g :'-( and that's normal. if you want the other behaviour simply make struct bb : aa { virtual void g(aa *para) { cout << "bb::g" << "\n"; } }; I dont really see why it is a pb. > } > -------------------------------------------------------------------------------- > > Java does the same... > _______________________________________________ > Merd-devel mailing list > Merd-devel@... > http://lists.sourceforge.net/mailman/listinfo/merd-devel > -- Yoann Padioleau, INSA de Rennes, France, http://www.irisa.fr/prive/padiolea Opinions expressed here are only mine. Je n'écris qu'à titre personnel. **____ Get Free. Be Smart. Simply use Linux and Free Software. ____** ```
 [merd-devel] OO and covariance From: Pixel - 2000-11-29 11:42:44 ```This nice paper talks about overloading/specializing: http://citeseer.nj.nec.com/castagna95covariance.html The sheer conclusion is that type safeness can be obtained with multiple dispatch. It explains how to extand the lambda-calculus with overloading. Here is what C++ does: -------------------------------------------------------------------------------- /// as C++ doesn't handle multiple dispatch and still wants to be type safe, /// it ignores the method covariantly defined :-( struct aa { virtual void g(aa *para) { cout << "aa::g" << "\n"; } }; struct bb : aa { virtual void g(bb *para) { cout << "bb::g" << "\n"; } }; int main() { aa *p_aa = new aa(); aa *p_bb = new bb(); p_aa->g(p_bb); p_bb->g(p_aa); p_bb->g(p_bb); // uh?! calls aa::g :'-( } -------------------------------------------------------------------------------- Java does the same... ```
 [merd-devel] type inference news From: Pixel - 2000-11-22 01:24:39 ```The new type inference engine is now working on a few test case. It's still very rough, and doesn't scale well for the moment, aka every new tests i add fails and need fixing the engine :-( Anyway, it's getting better and i'll soon be able to link the type inference engine with the interpreter. This will permit overloading, ad'hoc polymorphism, late binding (all this is blurred in merd) For info, the following inferes correctly (or nearly correctly, some InOrOut are still bad, but i don't care them): -------------------------------------------------------------------------------- Main.= :: Out(x),x -> Builtin.Unit Main.== :: Exact(x),x -> Builtin.bool [ l ] = List.list(l) Main.: :: a,[a] -> [a] Builtin.unify :: x,x -> Builtin.bool Builtin.cond :: [ Builtin.bool, b ] -> b Main.== = External("==") Builtin.unify = External("unify") id(x) = x pat = A->B pat2 = (A->B ; C->D) swap(x,y) = y,x set(x,y) = x=y test(x) = x == A apply(f, a) = f(a) match x with f := f(x) #getset(x,y) := x=y ; x if a then b else c := match a with True -> b False -> c aa ?: bb,cc = if aa then bb else cc f(x) := if x then 1 else 2 a ~ b := x -> a(b(x)) g(x) = apply( (A -> B C -> D), x) h(x) = apply(A->B, x) Main.* :: A,a -> a sqr(n) = n*n -------------------------------------------------------------------------------- This needs fixing: - sqr ~ sqr - gset(x,y) := x=y ; x - recursive functions inference ```
 Re: [merd-devel] A Comparison of Programming Languages for Scientific Processing From: Pixel - 2000-11-21 22:06:50 ```Daouda LO writes: [...] > including comparisons of ML with Pascal and C about Strong Typing. yep, nice slides... wondering if that would not be nice for my talk at linuxexpo :) see http://www.linuxexpoparis.com/EN/conferences/, there'll be the guy who wrote ruby ```
 Re: [merd-devel] A Comparison of Programming Languages for Scientific Processing From: Pixel - 2000-11-21 21:35:19 ```Daouda LO writes: > Pixel writes: > > > why coding in C/C++ is still the way to have fastest code, but it won't last > > long :) > > another good site : > http://lambda.weblogs.com/ > > including comparisons of ML with Pascal and C about Strong Typing. thief, announcing the site i've found :'-( special one for fpons: C-- (portable assembly language) A nice idea - if C is the world's most portable assembly language, why not tidy it up (tail recursion; gc) to produce a generic backend for compilers? (An old project, but news to me and apparently still active). ```
 Re: [merd-devel] A Comparison of Programming Languages for Scientific Processing From: Daouda LO - 2000-11-21 21:29:07 ```Pixel writes: > why coding in C/C++ is still the way to have fastest code, but it won't last > long :) another good site : http://lambda.weblogs.com/ including comparisons of ML with Pascal and C about Strong Typing. > > http://www.azstarnet.com/~dmcclain/LanguageStudy.html > _______________________________________________ > Merd-devel mailing list > Merd-devel@... > http://lists.sourceforge.net/mailman/listinfo/merd-devel ```
 [merd-devel] A Comparison of Programming Languages for Scientific Processing From: Pixel - 2000-11-13 18:38:21 ```why coding in C/C++ is still the way to have fastest code, but it won't last long :) http://www.azstarnet.com/~dmcclain/LanguageStudy.html ```
 Re: [merd-devel] news From: Pixel - 2000-11-13 11:07:44 ```Yoann Padioleau writes: > > f ~ g := x -> f(g(x)) > detail : why not . or ° . is used quite a lot already (method call, modules) ° can't be done with a us keyboard (it was my first choice) > > > > fact = > > 0 -> 1 > > x -> x * fact(x-1) > > > > [ 1, 2, 3 ].map(x -> "{x} -> {(fact~fact)x}".print) > detail : this a more a do than a map (it returns a list of unit, > useful ??) yeah, you're right, done too much perl :-( of course, it should be "iter" (name not decided yet) ```
 Re: [merd-devel] news From: Yoann Padioleau - 2000-11-13 10:42:02 ```Pixel writes: > Currently working on the interpreter. The type inference is on hold for the > moment cuz it needs the interpreter. > > The code for type inference must be rewritten as the type-structure is now the > same as value-structure > > I've enhanced the merd-mode. > I've also modified the lexer to handle " ... { code } ... " as it should > (rewritten in String.concat(" ... ", String.concat(code.to_string, " ... "))) > > The following is working: > > ---------- > f ~ g := x -> f(g(x)) detail : why not . or ° > > fact = > 0 -> 1 > x -> x * fact(x-1) > > [ 1, 2, 3 ].map(x -> "{x} -> {(fact~fact)x}".print) detail : this a more a do than a map (it returns a list of unit, useful ??) > ---------- > > To have a look: > - when to transform a function into a closure? > - in merd-mode, colorify "hello {name}" as it should? > _______________________________________________ > Merd-devel mailing list > Merd-devel@... > http://lists.sourceforge.net/mailman/listinfo/merd-devel > -- Yoann Padioleau, INSA de Rennes, France, http://www.irisa.fr/prive/padiolea Opinions expressed here are only mine. Je n'écris qu'à titre personnel. **____ Get Free. Be Smart. Simply use Linux and Free Software. ____** ```
 [merd-devel] [info] A Comparative Overview of C# From: Pixel - 2000-11-12 18:40:51 ```http://www.genamics.com/visualj++/csharp_comparative.htm This article will focus on the new ways of programming C# offers, and how it intends to improve upon its two closest neighbors, Java and C++. C# improves on C++ in a similar way to Java in many respects, so I'm not going to be re-explaining things like the benefits of a single-rooted object hierarchy. This article begins with a brief summary of the similarities between C# and Java, and then goes into exploring the new C# features. ```
 [merd-devel] news From: Pixel - 2000-11-12 01:15:36 ```Currently working on the interpreter. The type inference is on hold for the moment cuz it needs the interpreter. The code for type inference must be rewritten as the type-structure is now the same as value-structure I've enhanced the merd-mode. I've also modified the lexer to handle " ... { code } ... " as it should (rewritten in String.concat(" ... ", String.concat(code.to_string, " ... "))) The following is working: ---------- f ~ g := x -> f(g(x)) fact = 0 -> 1 x -> x * fact(x-1) [ 1, 2, 3 ].map(x -> "{x} -> {(fact~fact)x}".print) ---------- To have a look: - when to transform a function into a closure? - in merd-mode, colorify "hello {name}" as it should? ```
 Re: [merd-devel] typing From: Pixel - 2000-11-06 22:09:13 ```"dam's" writes: > > 2.3. overloading > > For this one, you need to specify types, otherwise the interpreter can't know > > for which type you're defining the function. Solved in object oriented language > > by defining a class for which the functions (methods) are defined. > > > > gni? let's take a nice C++ example: void display(string a); void display(int a); how do you do this in perl? well, you can't! the solution used in OO is: class string { method display(); } class int { method display(); } Because for methods, you know at least the class you're working on. But of course, you can't achieve the following (which works in C++): void foo(string a, string b); void foo(int a, string b); void foo(string a, int b); void foo(int a, int b); because the OO binding is done only on one argument (well kind of, at least if you think the first parameter if the object) ```
 [merd-devel] typing (following) From: Pixel - 2000-11-06 21:14:49 ```5. Subtyping and types With subtyping, a value can belong to many types: { bool => { 0, 1 }, sign => { -1, 0, 1 }, byte => { 0, 1, ..., 255 }, ... } If you reverse this, you get the set of types a value belong to: { 0 => { bool, sign, byte, ... }, -1 => { sign, byte, ... }, ... } Is there a minimal type that is a subset of every other? Well, yes, let's say the type of 0 is 0. That way 0 is compatible with every type which includes 0. 5.1. typeof We can define the typeof function which gives the type of a value: typeof = _ | _ -> Type [ l ] -> [ l.mapt(typeof).unift ] Pattern_match(l) -> l.unift c(l) -> (c.typeof)(l.typeof) c -> c typeof(True) gives True typeof(0) gives 0 typeof(0,1) gives 0,1 # 0,1 is Tuple(A,B) typeof(x->x) gives x->x typeof([0,1,0]) gives [ 0 | 1 ] typeof(A->B ; C->D) gives A|B -> C|D typeof(f,a -> f(a)) gives (a->fo, a) -> fo typeof(x -> x == A) gives A -> True|False typeof(a,b -> x -> a(b(x))) gives (bo->ao, x->bo) -> x -> ao typeof(a,b -> match b with (True -> a ; False -> ())) gives ((), True|False) -> () you can also do typeof(typeof(0)) gives typeof(0) gives 0 typeof(typeof([0,1,0])) gives typeof([ 0 | 1]) gives [ Type ] 5.2. constraints Value and type unification permits design by contract and type constraint unification. 5.2.1. what is design by contract Design by contract is a nice Eiffel feature. It's mainly sugar, except for inheritance. The basic idea is to permit to add predicates on each arguments of functions to ensure the values are ok, aka pre-conditions and post-conditions. The C ``equivalent'' is assert. (see http://www.faqs.org/faqs/eiffel-faq/ LDBC and http://www.elj.com/eiffel/bm/dbc/ for more) 5.2.2. type constraints in haskell elem :: Eq a => a -> [a] -> Bool Here elem works only on types which derives from Eq, where Eq means: class Eq a where (==), (/=) :: a -> a -> Bool 5.2.3. unification The parallelism between the 2 is evident: inv(x != 0 ==> x) = 1 / x elem(eq?(x.typeof) ==> x, l) = ... or elem :: eq?(x) ==> x,l -> bool 5.3 typing The "typeof" function can be seen as the valuation function for a denotational semantic of the language. A similar analysis to type analysis which is needed is the "Lazy or not" analysis. Of course this one is really simple as default is non-lazy, and "lazy" needs a special tag on the arguments. Another analysis is the function ``purity'', aka does it access global variables or not? (eg of use: memoization) ```
 Re: [merd-devel] typing From: Pixel - 2000-11-06 12:36:45 ```Yoann Padioleau writes: > Pixel writes: > > > 4.1. Benefits > > > > - reflexivity: types can be used in lists, keys in hashes... > > you can have typeof: a -> type > > > > - type constructors: > > let flistT a = (list of a) -> (list of a) > > (from a lambda-prolog example which was using a #define) > you dont really need type as first class for flistT > type synonyme do the job in ml: ok, let's find more complicated: tt = a,a -> a a,b -> a,b i haven't found a good example yet though... ```
 Re: [merd-devel] typing From: Pixel - 2000-11-06 12:29:35 ```"dam's" writes: > > 2.1. storing the values > > Types have always been used to store values. In dynamically types languages, > > this is not really true anymore. The language must be prepared to accept every > > values. > > do you have an example? I should have said that no type is associated with the variable, a type is only associated with a value. in C, with ``char *c = "foo"'', you know ``c'' is a pointer to a list of chars null-terminated. in python, with ``c = "foo"'', python stores in variable ``c'' something like: - it is a string - its value is "foo" if afterwards you write ``c = 1'', python is perfectly happy with this. In OO paradigm, you'd say that ``c'' 's type is ``Object'' and every type derives from Object. You can do the same in java (except for basic values which are not objects) ```
 Re: [merd-devel] typing From: dam's - 2000-11-06 10:32:54 ```Pixel writes: > 1.1. storing the values > Knowing the range of values permits nice storage: > - for a "2 value" type, 1 bit is enough to know which value it is (eg: booleans) > - even for "infite set of values" type, you can at least assume things about the > values (eg: strings are build with caracters) > > 1.2. ensuring ``correctness'' > That is, ensure "strong typing", meaning you don't misinterpret a value of being > type "a" whereas it is type "b". This > > This *must* be done at compile-time, otherwise you loose feature 1.1. > > > 1.3. having a function with different semantic based on types > overloading and polymorphism ad'hoc > > eg: based on the type ``+'' behaves differently (addition (numbers), > concatenation (strings, lists)) > > > > 2. Dynamic typing > > Let's see if the previous points still hold: > > > 2.1. storing the values > Types have always been used to store values. In dynamically types languages, > this is not really true anymore. The language must be prepared to accept every > values. do you have an example? > > 2.2. ensuring ``correctness'' > Not needed at compile-time, easily done at run-time > > 2.3. overloading > For this one, you need to specify types, otherwise the interpreter can't know > for which type you're defining the function. Solved in object oriented language > by defining a class for which the functions (methods) are defined. > gni? > > 3. Dynamic/static typing comparison > > In both cases, the interpreter verifies that the types match. Either this check > is done at compile-time or run-time. At run-time, you know the value so the > type. At compile-time, you don't know the value but you know the type. > > Based on this, one can say that the types purpose is to have a compile-time set > of the values a variable can take. > (one could define types that can't be checked at compile-time?) > > > 4. Enhancing ML: types as first-class citizen > > In the following i'll try to unify ``types'' and ``values'' > Let's allow: > > let typ = string > typ : type > > 4.1. Benefits > > - reflexivity: types can be used in lists, keys in hashes... > you can have typeof: a -> type > > - type constructors: > let flistT a = (list of a) -> (list of a) > (from a lambda-prolog example which was using a #define) > > - clean: don't bother with values AND types, it is the same :) you don't bother anyway so... > > 4.2. Problems > > - to keep static typing, the compiler must know every "type" value at compile > time. To do so the compiler must be able to interpret some code while infering > type, eg: > > let t = flistT(flistT(int)) in > let (f : t) = ... > > - overkill? -- dam's ```
 Re: [merd-devel] typing From: Yoann Padioleau - 2000-11-06 10:13:11 ```Pixel writes: > 4.1. Benefits > > - reflexivity: types can be used in lists, keys in hashes... > you can have typeof: a -> type > > - type constructors: > let flistT a = (list of a) -> (list of a) > (from a lambda-prolog example which was using a #define) you dont really need type as first class for flistT type synonyme do the job in ml: > > - clean: don't bother with values AND types, it is the same > > 4.2. Problems > > - to keep static typing, the compiler must know every "type" value at compile > time. To do so the compiler must be able to interpret some code while infering > type, eg: > > let t = flistT(flistT(int)) in > let (f : t) = ... > > - overkill? > > > > 5. Subtyping and types > > to come... > _______________________________________________ > Merd-devel mailing list > Merd-devel@... > http://lists.sourceforge.net/mailman/listinfo/merd-devel > -- Yoann Padioleau, INSA de Rennes, France, http://www.irisa.fr/prive/padiolea Opinions expressed here are only mine. Je n'écris qu'à titre personnel. **____ Get Free. Be Smart. Simply use Linux and Free Software. ____** ```
 [merd-devel] typing From: Pixel - 2000-11-06 01:10:12 ```Ok, now what's a ``type''? I had some pb defining it in the language and had to think about it. Here is the result... def: a "type" is a "set of values" 1. Simple type system with static-typing Without subtyping, you have a set of types having a set of values: { byte => { 0, 1, ..., 255 }, bool => { true, false }, char => { 'a', 'b', ... }, string => { "", "a", ... }, list(byte) => { [], [0], ... }, ... } What is the use of types in a static typed language like java? 1.1. storing the values Knowing the range of values permits nice storage: - for a "2 value" type, 1 bit is enough to know which value it is (eg: booleans) - even for "infite set of values" type, you can at least assume things about the values (eg: strings are build with caracters) 1.2. ensuring ``correctness'' That is, ensure "strong typing", meaning you don't misinterpret a value of being type "a" whereas it is type "b". This This *must* be done at compile-time, otherwise you loose feature 1.1. 1.3. having a function with different semantic based on types overloading and polymorphism ad'hoc eg: based on the type ``+'' behaves differently (addition (numbers), concatenation (strings, lists)) 2. Dynamic typing Let's see if the previous points still hold: 2.1. storing the values Types have always been used to store values. In dynamically types languages, this is not really true anymore. The language must be prepared to accept every values. 2.2. ensuring ``correctness'' Not needed at compile-time, easily done at run-time 2.3. overloading For this one, you need to specify types, otherwise the interpreter can't know for which type you're defining the function. Solved in object oriented language by defining a class for which the functions (methods) are defined. 3. Dynamic/static typing comparison In both cases, the interpreter verifies that the types match. Either this check is done at compile-time or run-time. At run-time, you know the value so the type. At compile-time, you don't know the value but you know the type. Based on this, one can say that the types purpose is to have a compile-time set of the values a variable can take. (one could define types that can't be checked at compile-time?) 4. Enhancing ML: types as first-class citizen In the following i'll try to unify ``types'' and ``values'' Let's allow: let typ = string typ : type 4.1. Benefits - reflexivity: types can be used in lists, keys in hashes... you can have typeof: a -> type - type constructors: let flistT a = (list of a) -> (list of a) (from a lambda-prolog example which was using a #define) - clean: don't bother with values AND types, it is the same 4.2. Problems - to keep static typing, the compiler must know every "type" value at compile time. To do so the compiler must be able to interpret some code while infering type, eg: let t = flistT(flistT(int)) in let (f : t) = ... - overkill? 5. Subtyping and types to come... ```
 [merd-devel] FreshML From: Pixel - 2000-11-01 12:07:25 ```pad, do you know this? is it worth the look? http://www.cl.cam.ac.uk/users/amp12/freshml/ ```

Showing 20 results of 20