<struktured>
I know this is a bit OT, but is python a "strongly typed" language?
<Smerdyakov>
Interesting question. Maybe you should define "strongly typed" if you want an answer.
<struktured>
Smerdyakov, I was at a conference today, and some guy pushing his company product described python as such. it annoyed me even though I wasn't sure if he was right
coucou747 has quit [Read error: 113 (No route to host)]
<flux>
for some definition of strong typing he was correct, "4" + 4 is an error in python
<flux>
but for others, python doesn't even have a type system ("typeless" or "unitype" system), so how could it have a strong one is the question..
<tsuyoshi>
I thought it was dynamic typing
<flux>
I do believe in the actual type system research the term "dynamic typing" is nonsensical
<tsuyoshi>
well.. a variable can have different types at different times
<flux>
yes, but there types are something that are in the program even before it is run.
<flux>
iow: static :)
<tsuyoshi>
but at any given time, it is one distinct type
<flux>
a variable can have different tags, sure
<flux>
so it can have an integer tag or a string tag
<flux>
and those tags are checked in runtime
<tsuyoshi>
sounds like a type system to me
<flux>
perhaps so, but it doesn't sound like a type system to everyone ;)
<tsuyoshi>
just.. a really horrible one
<tsuyoshi>
(I hate python)
<flux>
like the term unitype conveyes: there is one type, and all variables are of that type: tag and a value
<struktured>
I actually walked out on this guys talk because of his statement of python being "strongly typed"
<struktured>
not that I cared for his lecture anyway
<tsuyoshi>
maybe he just meant there isn't automatic coercion, like in ruby
smimou has quit ["bli"]
<struktured>
I also don't like the paradigm of writing code in C++, and exposing your API via python.
<struktured>
which is exactly what this guy's company did
<tsuyoshi>
what was the lecture about
<struktured>
well, this guy was the last talk of a "jumpstart" into the software technology produced by a company called numenta. but unlike the previous talks of the day, his felt like a plug for his company's (enthought) software
struktured has quit [Read error: 110 (Connection timed out)]
coucou747 has quit ["bye ca veut dire tchao en anglais"]
coucou747 has joined #ocaml
pango has quit [Remote closed the connection]
Jedai has quit [Read error: 113 (No route to host)]
asmanur has joined #ocaml
hkBst has joined #ocaml
guillem has joined #ocaml
OChameau has joined #ocaml
pango has joined #ocaml
asmanur has quit [Remote closed the connection]
Associat0r has joined #ocaml
yallop1 has left #ocaml []
Yoric[DT] has joined #ocaml
vixey has quit [Read error: 54 (Connection reset by peer)]
OChameau has quit [Read error: 113 (No route to host)]
OChameau has joined #ocaml
yallop has joined #ocaml
<Yoric[DT]>
Does anyone have experience with proving monadic laws in OCaml?
Linktim has quit [Read error: 60 (Operation timed out)]
Linktim has joined #ocaml
<yallop>
Yoric: I have experience proving them in Coq and then extracting OCaml code
<Yoric[DT]>
I've come to wonder if proving monadic laws is possible at all in OCaml.
<Yoric[DT]>
I mean, since OCaml is impure, one may have any sort of un-associative side-effects.
<yallop>
indeed
<Yoric[DT]>
yallop: tell me, do you have any plans on typeclasses?
<yallop>
I think the same is true even in Haskell to some extent, though, due to seq
<yallop>
not too many plans for typeclasses at the moment
<yallop>
except to rewrite deriving to use objects instead of moduels
<yallop>
modules, even
<Yoric[DT]>
:)
<Yoric[DT]>
With the same syntax?
<Yoric[DT]>
Or do you manage something lighter?
<yallop>
perhaps a little lighter
<yallop>
not entirely sure yet
<Yoric[DT]>
Well, if you need help, be sure to tell.
<yallop>
thanks, I might well do that
<Yoric[DT]>
I have the feeling that nice typeclasses are possible in OCaml.
<Yoric[DT]>
And that we're not far from this.
<yallop>
what do you have in mind?
<Yoric[DT]>
I'm not completely sure.
<Yoric[DT]>
I've been toying with so many weird ideas during the past few months that I probably need a reality check.
<Yoric[DT]>
Still, syntactically light operator and function overloading would be great.
<yallop>
I agree: it's one of the things I miss most in OCaml
LordMetroid has joined #ocaml
<Yoric[DT]>
Why do you intend to use objects, btw?
<Yoric[DT]>
I believe it's the right way to go, but I can't put the argument behind that.
<yallop>
there are a few advantages
<Yoric[DT]>
(well, either objets or polymaps or something along these lines)
<yallop>
it makes it easier to write functions which use overloaded operations
<yallop>
e.g. "print :: Show a => a -> unit"
<yallop>
if you're using modules as dictionaries then you have to write such functions as functors, which is a nuisance
<Yoric[DT]>
What would the implementation look like with the next Deriving?
<yallop>
and means that they're not first-class
<yallop>
implementation of print? something like this, although I don't really have the syntax worked out yet
<yallop>
let print<a> v = print_endline (show<a> v)
<yallop>
another advantage of objects is that they have better combination properties than modules: the equivalent of multiple inheritance doesn't work out with modules if you the same type name in each "superclass"
LordMetroid has quit ["Leaving"]
<Yoric[DT]>
Would you have the possibility of writing, say,
<Yoric[DT]>
let ( ++ )<a> x y = <a>#add x y
<Yoric[DT]>
?
<yallop>
I think it'd be difficult to avoid writing the "dictionary" argument at the call site
Jedai has joined #ocaml
<Yoric[DT]>
afk
Maldoror_ has joined #ocaml
* Yoric[DT]
is back.
<Yoric[DT]>
yallop: so you have an optimization of dictionaries already?
<Associat0r>
Yoric[DT]: Still, syntactically light operator and function overloading would be great. << agreed
yallop has left #ocaml []
det_ has quit [Remote closed the connection]
tomh has joined #ocaml
Linktim has quit [Read error: 110 (Connection timed out)]
<Smerdyakov>
Yoric[DT], you should program in Coq to begin with, so that you can have actual useful algebraic rules. :)
filp has quit [Read error: 110 (Connection timed out)]
postalchris has joined #ocaml
<Yoric[DT]>
Quick poll: assuming you were in the program committe of ML Workshop, would you mind if examples in a paper were written in OCaml using the revised syntax?
Linktim is now known as Linktimaw
<Smerdyakov>
I would mind.
<Smerdyakov>
No one knows that stuff but camlp4 users, and there aren't many camlp4 users.
<Yoric[DT]>
ok
<Yoric[DT]>
Point taken.
<Smerdyakov>
ML workshop got desperate this year. That's what "deadline extension" means. ;-)
<Yoric[DT]>
I know.
<Yoric[DT]>
That also means that I have time to proofread my paper :)
<Smerdyakov>
The ICFP workshops besides Haskell and CUFP haven't been doing that well recentl.
<Smerdyakov>
y
<Yoric[DT]>
Haven't they?
<Yoric[DT]>
Well, the Haskell community looks as dynamic as ever.
<Associat0r>
will the revised syntax become standard later on?
<Associat0r>
the standard
<Yoric[DT]>
Somehow, I doubt it.
<Yoric[DT]>
Which is too bad, as in many cases, it's more readable than the original syntax.
<Associat0r>
what do you think of the F# light syntax?
<Associat0r>
nemerle syntax is also nice, since it allows a indent or C syntax
<johnnowak>
Yoric[DT]: is bidimensional a special form of two dimensional?
<Yoric[DT]>
I believe it's the same.
coucou747 has quit [Read error: 113 (No route to host)]
hordf has quit [Connection timed out]
struktured has joined #ocaml
seafood has quit []
pango has quit [Remote closed the connection]
jlouis has joined #ocaml
pango has joined #ocaml
postalchris has quit [Read error: 111 (Connection refused)]
marmotine has joined #ocaml
struktured has quit [Read error: 110 (Connection timed out)]
johnnowak has quit []
marmotine has quit [Remote closed the connection]
struktured has joined #ocaml
hordf has joined #ocaml
hordf has quit [Remote closed the connection]
middayc has joined #ocaml
guillem has quit [Read error: 104 (Connection reset by peer)]
struktured has quit [Read error: 110 (Connection timed out)]
RobertFischer has joined #ocaml
bluestorm has joined #ocaml
johnnowak has joined #ocaml
Jedai has quit [Read error: 113 (No route to host)]
OChameau has quit ["Leaving"]
johnnowak has quit []
guillem has joined #ocaml
coucou747 has joined #ocaml
Jedai has joined #ocaml
kotarak has joined #ocaml
LordMetroid has joined #ocaml
coucou747 has quit [Read error: 110 (Connection timed out)]
coucou747 has joined #ocaml
Axioplase has joined #ocaml
<Yoric[DT]>
mmmhhhh....
<Yoric[DT]>
Does anyone know if there's a way to encode extensible types in OCaml without polymorphic variants?
<Yoric[DT]>
That is, OCaml has one extensible type besides polymorphic variants.
<Yoric[DT]>
(exn)
<Yoric[DT]>
I wonder how hard it would be to use that type to encode several disjoint extensible types.
bluestorm has quit ["Konversation terminated!"]
<Yoric[DT]>
I mean, you can probably get something by mixing exceptions and phantom types but if someone has already tried, I'm interested to know if there are any issues.
Jeff_123 has joined #ocaml
<jlouis>
maybe with a universal embedding and phantoms
<Yoric[DT]>
mmmhhh...
<Yoric[DT]>
type 'a type_1
<Yoric[DT]>
type 'a type_2
<Yoric[DT]>
exception A, exception B, exception C
<Yoric[DT]>
type actual_type_a = type_1 of
<Yoric[DT]>
erf
* Yoric[DT]
is confusing exceptions and polymorphic variants.
<Yoric[DT]>
So no, the solution is not that trivial.
bluestorm has joined #ocaml
<palomer>
is there a way to convert an expression to a string as it would appear in source code?
<palomer>
for example
<palomer>
to_string_verbatim [1,2,3] -> "[1,2,3]"
<Yoric[DT]>
palomer: not out-of-the box, as this would require dynamic typing.
<palomer>
to_string_verbatim (`Foo 3) -> "`Foo 3"
<Yoric[DT]>
But Deriving offers something like this.
pango has quit [Remote closed the connection]
<palomer>
gotcha
<Yoric[DT]>
(of course, it's more complex than "to_string_verbatim")