<Snark>
just use the automatic indenting of your editor
<mauke>
huhu, then it's obvious
<er>
my editor places it with the second.
<mrvn_>
match ... with acts as implizit ()
<mrvn_>
just like let
tautologico has joined #ocaml
<ulfdoz_>
cya
Snark has quit ["Leaving"]
angagon has joined #ocaml
<mflux>
hm, on c.l.f someone uses pseudo syntax (x, y) -> x * 2 + y.. would this collide with current ocaml language definition?
<mflux>
as I do see value in having as concise as possible syntax for lambda ;)
<mrvn_>
# let a = fun (x, y) -> x * 2 + y;;
<mrvn_>
val a : int * int -> int = <fun>
<mrvn_>
# a (1,2);;
<mrvn_>
- : int = 4
<mflux>
yes, yes
<mrvn_>
nothing pseudo about it.
<mflux>
well the actual pseudo code was ((x, y) -> ..) (2, 1)
<mflux>
which is not valid ocaml, or any other language I know
<mflux>
(I do know only a few fpl's though)
<mflux>
iow, I think haskell's \x is a great idea, of course that has the idea of \ being similar to the lambda symbol
<mrvn_>
# (fun (x, y) -> x * 2 + y) (2, 1);;
<mrvn_>
- : int = 5
<mrvn_>
nearly correct code
<mflux>
and again, I know that that can be written, I'm just wondering if getting rid of the keyword would be proplematic for ocaml syntax definition
<mflux>
s/prop/prob/ even
<mrvn_>
it would certainly hurt readability.
<mflux>
well, I suppose it would be similar to using 'function'
<mflux>
as that syntax cannot support more than one argument
<mflux>
otoh x -> y -> z -> wouldn't imo be that either
<mrvn_>
a -> b -> a+b
<mflux>
I'm not sure how it would hurt readibility; one would need to see actual code using it before deciding it ;)
<tautologico>
what about the reverse question:
<mflux>
but then again, I believe most languages have some symbol or keyword before the parameters to indicate that a lambda function is beginning
<tautologico>
why getting rid of a 3-letter keyword would improve readability ?
<mrvn_>
The fun/function is needed to tell ocaml if it is creating or using a binding.
<tautologico>
(or a slash in the case of haskell)
<mflux>
let's say you want to abstract 'for'-like functionality to a function
<mrvn_>
tautologico: xemacs tuarge uses a lambda symbol.
<mflux>
mrvn_, hmm, where does it use it?
<mflux>
haskell's \x -> .. is quite concise, typing out 'fun ...' seems excessively verbose for simple cases
<mrvn_>
mflux: for 'fun'
<mflux>
oh
<mflux>
I haven't notice that, and I use tuareg and xemacs ;)
<mflux>
maybe it's something I've disabled
<mflux>
or not enabled, or I have an older version
<mrvn_>
used to have a symbol for "unit" too. I guess my config changed.
<mflux>
any idea how to enable that? I would atleast like to try it
<mflux>
well, maybe now that I know it I'll find it, I'm not at home at the moment though
<mrvn_>
mflux: not sure. I have the default config of debian.
<mflux>
I use debian too ;)
<mflux>
unstable
<mflux>
so..
<tautologico>
you could maybe specify -> as an operator to create a closure
<tautologico>
but I have doubts about that being more readable
<mflux>
it would be a special closure though
<tautologico>
why ?
<mflux>
hm, special operator I mean
<mflux>
as it would bind a new symbol from rhs to lhs expression
<mflux>
actually swap those
<tautologico>
yes
<mflux>
well, I suppose some day I could try out how the language extension mechanism works and try writing that out
<mflux>
although I imagine this is not the kind of language extension ocaml designers had in mind
<tautologico>
I'm thinking if there's anything about the syntax that creates trouble with that notation... I can't think of any problem now
<tautologico>
yes, this is a job for camlp4
<mflux>
hmm
<mflux>
fun x -> z -> x + z, should be nonambigious
<tautologico>
but you can't do fun x -> z -> in the current syntax
<mflux>
that's what I tried to say ;)
<tautologico>
oh
<tautologico>
the problem is
<mrvn_>
# fun x z -> x+z;;
<mrvn_>
- : int -> int -> int = <fun>
<mrvn_>
no need to.
<tautologico>
you'd have ambiguity
<tautologico>
and there's function too
<mrvn_>
you only need multiple -> for something with fun x -> ... calculate something ... z -> x+z;;
<tautologico>
function x -> function z -> x + z;;
<mflux>
the x -> y -notation would not support pattern matching I suppose
<mflux>
but fun x y -> z could be replaced with x -> y -> z - nad still win 1 character ;)
<mflux>
oh, maple is the one with (x, y)->x+y -syntax
NathanJY has joined #ocaml
<NathanJY>
hey
<NathanJY>
is caml a dynamically typed language?
<mflux>
no
<tautologico>
nop
<mflux>
but it has type inferring system, with makes dealing with types more convenient than in 'traditional' staticly typed languages, such as (well..) C or Java
<NathanJY>
so it's somewhere inbetween?
<NathanJY>
or it's entirely static, jsut implemented differently?
<tautologico>
it's static
<tautologico>
but most of the time you don't need to write the types
<NathanJY>
ahh ok
<tautologico>
because de compiler infers the types of variables and expressions
<tautologico>
so it's much more efficient than Java-style static typing,
vodka-goo has quit []
<tautologico>
well, not only regarding types, Java is a very verbose language
<mrvn_>
javas typesystem is also conceptualy buggy and undermins the security model through that.
<tautologico>
well, especially considering the new generics based on erasure
epichrom has joined #ocaml
<NathanJY>
it's conceptually buggy?
<NathanJY>
how can a very explicit type system be conceptually buggy and undermine the security model?
<tautologico>
well
<tautologico>
are you familiar with the generic types in java 5 ?
<NathanJY>
not in java specifically, but I'm afamiliar with C++ template,s which I'm assuming they're base don
<tautologico>
actually generic types in java are quite different from templates
<tautologico>
(C++ templates)
<NathanJY>
oh
<NathanJY>
no idea then
<tautologico>
they're based on type erasure: the compiler verifies correct use of the generic types, and then "erase" the extra typing information, using the non-generic class with appropriate casts
<NathanJY>
why does it erase the type information?
<NathanJY>
that sounds very strange
<mauke>
for backwards compatibility with the vm
<tautologico>
the erasure model was chosen because it's easier to maintain backwards compatibility
<NathanJY>
oh
<tautologico>
with the old code at least
<NathanJY>
well that's sucky
<tautologico>
old vms will not run the new compiled classes, because the version changes
<tautologico>
* changed
<NathanJY>
oh so they're not compatible anyway?
<NathanJY>
what's the point?
<tautologico>
to avoid breaking old code, I guess
<NathanJY>
hm
<NathanJY>
well poo on that
<tautologico>
in java 5 you can still use the so-called "raw types"
<tautologico>
that is, non-generic versions of the generic container classes
<NathanJY>
5 = 1.5 ?
<NathanJY>
ahh
<NathanJY>
hm
<tautologico>
yep
<tautologico>
5 is the name the marketing guys came with :)
<NathanJY>
someone really needs to put effort into an open vm standard that has a lot more foresight put into it
<NathanJY>
too lazy to do anything more than skim it now
<NathanJY>
but I'll read it later
<tautologico>
Java 5 can cause expressions without casts to produce ClassCastExceptions. That's an invariant that every other java version preserved, now broken. And the place where the exception is thrown is *not* the incorrect code.
<tautologico>
this is from the thread
<NathanJY>
o_O?
<NathanJY>
wow
<NathanJY>
now I'm going to have to go laugh at java people now
<tautologico>
but mind that this is not a common case
<NathanJY>
oh ok
<tautologico>
in ocaml there are ways to wreak havoc too
<mauke>
you should still laugh at java
<tautologico>
using Obj.magic for instance
<NathanJY>
I always do
<tautologico>
as people say
<tautologico>
Java is the new Cobol :)
<NathanJY>
well you can wreack havoc intentionally in any language
<tautologico>
true
<NathanJY>
it's just a question of whether or not it'd unintetnioanlly happen with a basic feature
Skal has quit ["Client exiting"]
<NathanJY>
I just find it funny that sun caved into pressure for generics and now they fucked it up
<mauke>
well, if you define "wreak havoc" as infinite loops
er has quit [Read error: 113 (No route to host)]
<tautologico>
with Obj.magic you can get segfaults, core dumps, etc
<tautologico>
the original GJ proposal hadn't this problems, but they added raw types and unchecked conversions
_JusSx_ has joined #ocaml
_JusSx__ has quit [Read error: 110 (Connection timed out)]
_JusSx_ has quit ["leaving"]
dxlvi has joined #ocaml
NathanJY has left #ocaml []
dxlvi has left #ocaml []
angagon has quit [Read error: 110 (Connection timed out)]