<CosmicRay>
the first works, but the second yields complaints in the sprintf area when compiling
<CosmicRay>
I am confused!
Jaundice has joined #ocaml
<Smerdyakov>
Silly CosmicRay.
<Smerdyakov>
This isn't C.
<Smerdyakov>
Format strings must all be constant.
<Smerdyakov>
So the compiler can check them and determine what arguments to take.
<CosmicRay>
argh.
<CosmicRay>
so Printf.sprintf is not a regular function call?
<CosmicRay>
the compiler is doing something funky with it somehow?
Jaundice has quit [Client Quit]
<CosmicRay>
this is the first time I've seen a string not just being a string in OCaml
demitar_ is now known as Demitar
<Smerdyakov>
Look at the type of the function.
<Smerdyakov>
The first parameter is NOT of type string.
<CosmicRay>
I have done that and must admit I am totally confused by it.
malte has joined #ocaml
<CosmicRay>
I have tried to construct a 3-tuple "format" type but have failed
<CosmicRay>
and I don't know how my string and float arguments get converted either
<Demitar>
Well what are your formatting needs really?
<Demitar>
Could you get away with (Printf.sprintf "%s%0f%s" a b c)?
<CosmicRay>
No; this is generic code that prints out some (messaged) data from a database....
<CosmicRay>
what's happening is that in some cases I may need to generate output with say %0.3f and in other cases %0g
<Demitar>
Except that you'd probably use three print calls there...
<CosmicRay>
so I really do need a different format string to be able to be passed in
<Demitar>
You can build a function calling *printf internally.
<CosmicRay>
how might I do that?
<Demitar>
The trivial case could be: `PFFloat ((fmt:(float -> string)), (x:float))
phj has quit [Remote closed the connection]
<Demitar>
and `PFFloat (Printf.sprintf "%0g", 0.4)
<CosmicRay>
Ahh.
<Demitar>
You might be able to do some kprintf magic but I doubt you have much use for it's functionality.
Jaundice has joined #ocaml
<CosmicRay>
that trick of passing a function works fine
<CosmicRay>
thanks
<Demitar>
That's the kind of tricks you learn after a while with a functional language. ;-)
matata has joined #ocaml
matata has left #ocaml []
Jaundice has quit [Client Quit]
<Nutssh>
Ocaml has a few cheats in its type system (=) (==), compare, hash, and printf.
* Demitar
ponders = =. =^ =* ... and shudders.
LordJ|m has quit [Read error: 104 (Connection reset by peer)]
LordJ|m has joined #ocaml
<Nutssh>
ocaml is much nicer with that. You can define your own operators. It would be nice if you could choose their precedence and associativity rather than the syntax explicitly encoding associativity.
<Smerdyakov>
Demitar, there's no need to shudder if you use type classes, which are a much nicer solution than the hacks in OCaml.
<Demitar>
Yes, being able to do that natively would be really nice.
<Smerdyakov>
Defining operator precedence is a parsing nightmare!
<Smerdyakov>
SML allows it, and it is a pain for compilers.
<Demitar>
Smerdyakov, I'll add type classes onto my to-read list then. ;-)
<Demitar>
Smerdyakov, ah, I guess it really does belong in caml4p then?
<Smerdyakov>
Mebs
<Nutssh>
It is?
<Smerdyakov>
Nutssh, yes. You can't use a standard yacc grammar, for instance.
<Nutssh>
Ah, I think I see.
<indigo>
what would be nice is a grammar that's unambigious, reguardless of operator precidence
<indigo>
or in other words, all operators have the same precidence
<indigo>
dare i say it...
<indigo>
a purely prefix grammar
<Smerdyakov>
I think prefix doesn't take advantage of inherent human linguistic abilities.
<indigo>
you should tell that to the japanese
<indigo>
it's actually postfix, but that's nearly the same thing
<indigo>
the guys in #lojban would like to argue otherwise :)
<indigo>
lojban is a strictly prefix language
<Smerdyakov>
Postfix needn't be nearly the same thing in terms of human cognitive capabilities.
<indigo>
and there are purely inflicted languages, such as russian and hungarian
<indigo>
you said linguistic...
<indigo>
if you think prefix is bad, talk to the owner of an hp calculator
<indigo>
human language uses prefix or postfix far more than infix
<indigo>
verbs are infix in english, but nearly everything else is prefix
<Smerdyakov>
Likewise in OCaml!
<indigo>
and many languages don't have infix verbs
<indigo>
so, what's your point?
<Smerdyakov>
OCaml is like English. :)
<indigo>
and is that good or bad?
<indigo>
you said prefix doesn't take advantage of inherent human linguistic abilities
<Smerdyakov>
Maybe there is something to the necessity of always indicating precedence in Lisp code.
<Smerdyakov>
Do you know of any analogue in natural language?
<Smerdyakov>
(Should probably have said "grouping" instead of "precedence.")
<indigo>
i'm not sure what you mean, as i'm not that familar with lisp
<indigo>
or
<indigo>
oh
<indigo>
you mean the need to do (+ 1 2) instead of just + 1 2
<indigo>
yes?
<Smerdyakov>
Yes
<indigo>
well, that's lisp grammar, not prefix notation
<Smerdyakov>
But also (+ 1 (* 2 6)) instead of + 1 * 2 6
<indigo>
natural languages deal with the problem by leaving it ambigious usually
<indigo>
if i say "time flies like an arrow", which word is the verb?
<indigo>
it's impossible to say, without some rule for grouping
<Smerdyakov>
Right, and we have these fancy grouping rules in our heads.
<Smerdyakov>
It's a shame not to apply them in programming.
<indigo>
are you saying programming languages should be ambigious?
<Smerdyakov>
No. I'm saying that it is good to rely on rules for disambiguation.
<indigo>
perhaps a better solution would be to make natural languages unambigious, so our heads would be less cluttered with funny rules
Tachyon76 has quit [Remote closed the connection]
<indigo>
and tell me, what rule is there for "time flies like an arrow"?
<Smerdyakov>
I think we'd lose communication efficiency if we got rid of ambiguity.
<Smerdyakov>
"time flies like an arrow" is a noun "time" verb "flies" prep phrase "like an arrow"
<indigo>
you are just making assertions and not arguing anything
<indigo>
what if time were the verb?
<indigo>
or perhaps like?
<Smerdyakov>
That's right, though we can draw _some_ conclusions from evolutionary argument, where we assume that much better linguistic mechanisms would have won out.
<indigo>
the fact is that there is no rule, you just assume one of three possible parsings because the others don't make sense in this context
<indigo>
or, we could assume that languages developed long ago, and are resistant to change because an altered language is less efficient at commuinication
Nutssh has quit ["Client exiting"]
<indigo>
if you want to make that arguement, you should at least study other natural language grammars
<Smerdyakov>
I have, a bit, in a linguistics class.
<indigo>
japanese does not have ambiguity as to what is the verb as english does
<indigo>
so, you are then saying that all natural languages are ambigious, this promotes efficiency, and we should make programming languages ambigious as well?
<Smerdyakov>
No, I'm saying that there is good evidence that people have inherent ability to disambiguate, so we should use that ability in programming language design to encourage brevity.
<indigo>
but the abilty of the human isn't what matters, it's the ability of the computer in question here
<indigo>
i write lotts of programs that i think make sense
<indigo>
to me, it's obvious that float should be rounded before trying to compare it...duh
<indigo>
but the computer doesn't think so
<Smerdyakov>
Why doesn't the ability of the human matter? I think it matters because humans are the bottleneck in software development.
<indigo>
if computers could do what we ment, and not what we said, we wouldn't need programmers
<indigo>
how do you propose such an ambigious grammar be parsed?
<Smerdyakov>
I'm talking about OCaml, for instance. No technical ambiguity. Just a less homogenous way of indicating grouping.
<indigo>
so you are advocating syntatic sugar
<Smerdyakov>
Define that precisely and I'll tell you if I am.
<indigo>
syntax sugar is syntatic elements defined for the purpose of making two ways to do the same thing
<indigo>
for example, (+) 1 2 and 1 + 2
<Smerdyakov>
OK, then I am advocating syntactic sugar.
<indigo>
well, nothing wrong with that
<indigo>
personally i don't like it, but syntatic sugar allows choice, which i do like
<indigo>
i'd rather type + 1 2 than 1+2
<Smerdyakov>
I'm not advocating duplicate means.
<Smerdyakov>
I'm talking about ways that we can make ideas easy to express.
<Smerdyakov>
Perhaps other concerns mean that certain ways of doing that lead to duplication.
<indigo>
what's so much harder about + 1 2 than 1 + 2 ?
<Smerdyakov>
The operation is separated from one of the operands. In a linear scan, there is no place you can start looking and see both operator and operands within a constant amount of space.
<indigo>
that's not true
<indigo>
+ 1 2
<indigo>
1 + 2
<indigo>
both the same size
<Smerdyakov>
Consider numbers of arbitrary length.
<indigo>
+ 321897312 129783
<indigo>
321897312 + 129783
<indigo>
still the same size
<Smerdyakov>
As they grow, you will need to include a larger and larger area of the expression to get a contiguous span that includes operator and both operands.
<indigo>
no
<Smerdyakov>
Small bits of operands can give all the information you need for a given purpose.
<Smerdyakov>
"No"? How can you disagree with that? It's just a mathematical fact.
<indigo>
oki, mathmatically
<indigo>
let a = the length of operand 1
<indigo>
let b = the length of operant 2
<indigo>
let c = the leng of the operator
<indigo>
with prefix, the length of the entire expression is c+a+b
<indigo>
infix = a+c+b
<indigo>
is c+a+b=a+c+b ?
<indigo>
my the comunitive property of addition, yes
<Smerdyakov>
I am not talking about the length of the expression.
<Smerdyakov>
I am talking about complexity of computing statistics about it.
<indigo>
you were talking about "a contiguous span that includes operator and both operands"
<indigo>
that's the expression
maihem has joined #ocaml
<Smerdyakov>
Right. The length of a _sub_expression.
<indigo>
statistics? such as what?
<Smerdyakov>
"Am I adding two variables?"
<Smerdyakov>
Infix: Pick out the addition operator. Scan one character to each side, modulo whitespace.
<indigo>
oki, so say i have this
<Smerdyakov>
Prefix: Scan the whole of the first operand and then the first character of the second, when you find where it starts.
<indigo>
(a * 3) + (7 / b)
<indigo>
by your method, you have ")+("
<indigo>
is that enough to answer your question?
<Smerdyakov>
Nope. We'll look a little further. When we see the 3 and 7, we know we aren't adding variables.
<Smerdyakov>
We've avoided looking at about half of the expression.
<indigo>
oh, so you have to look beyond the operator
<indigo>
well, for one, to see "a" i don't need to read " * 3)"
<Smerdyakov>
Sure, but the total span is asymptotically less than for prefix, with families of expressions of increasing size.
<indigo>
eyes don't move like a linear scanner
<Smerdyakov>
Mine do.
<indigo>
well then, the solution is to allow for syntatic sugar, that allows you to have your way, and I mine
<indigo>
because mine don't
<indigo>
the solution is choice
<Smerdyakov>
I don't believe you.
<indigo>
you believe a better solution is to make those who have tastes different than yours suffer by forcing your personal preferences upon them?
<indigo>
or do you think that if anyone has different preferences than yours, he is broken?
<Smerdyakov>
I don't believe in the relevance of "tastes" to engineering.
<indigo>
obviously you do, because you value your tastes over mine
<indigo>
if you thought they were irrelant, then you wouldn't be making an arguement for infix notation
<indigo>
irrelevant*
<Smerdyakov>
I'm not making an argument over _tastes_.
<Smerdyakov>
I'm marking an argument about which techniques best take advantage of innate human capabilities.
<indigo>
it's an arguement over quality
<indigo>
by using the word "tastes", i have implied that some people have different preferences
<indigo>
as some people prefer dark coffee, and others light, some prefer infix, and some postfix
<indigo>
you don't like that idea, aparrently
<indigo>
tell me, how do you get your caffene, if at all?
<indigo>
i like tea, personally
<indigo>
do you agree?
<Smerdyakov>
I have a negative view of people who use stimulants. :)
<indigo>
so, you prefer no caffene
<indigo>
i prefer tee
<indigo>
tea
<indigo>
so, we have established that people have preferences
<mellum>
Big news.
<Smerdyakov>
Yes, and not that they are relevant to determining optimal engineering practice.
<indigo>
now, don't you think a good solution is that i can drink tea, and you can not?
<Smerdyakov>
Sure, that doesn't bother me.
<indigo>
so then, why does it bother me that i could use prefix and you could use infix?
<indigo>
err
<indigo>
so then, why does it bother you that i could use prefix and you could use infix?
<Smerdyakov>
Unless you are working on a project whose completion is of value to me, and I believe using stimulants impairs your ability to complete it efficiently.
wazze has quit ["--- reality is that which, when you stop believing in it, doesn't go away ---"]
<indigo>
i'll grant you that there is merit to standardization of practice in a colaborative effort
<indigo>
but to argue that other people's tastes are unacceptable, and should be nonexistant, is another matter
<indigo>
if both prefix and infix were allowed, you could allow only infix in your corporation, and only infix in mine
<indigo>
only prefix in mine, rather
<Smerdyakov>
I am not making an argument based on standardization.
<Smerdyakov>
I am making a statement based on maximizing collective efficiency by maximizing individual efficiency.
<mattam>
is + + + 1 2 3 4 more clear than 1 + 2 + 3 + 4, is that the question ?
<Smerdyakov>
mattam, yes, from a cognitive perspective. I discuss it in terms of complexity of extracting statistics about code.
<indigo>
mattam: right now i'm trying to discover why he doesn't like syntatic sugar
<indigo>
no, wait
<indigo>
you are avoiding the point
<Smerdyakov>
indigo, what point am I avoiding?
<indigo>
i suggested that both should be allowed
<indigo>
such as ocaml does
<indigo>
(+) 1 2 and 1 + 2 are both legal
wazze has joined #ocaml
<Smerdyakov>
(+) 1 2 is not idiomatic, however.
<indigo>
i don't see how 1+2 is either
<indigo>
they are two ways to express the same thing, provided for convienence
<Smerdyakov>
It is based on statistics on how people code OCaml.
<indigo>
they are syntatic sugar
<Smerdyakov>
"Idiomatic" is a purely social notion.
<Smerdyakov>
And I say that people who would use (+) 1 2 will tend to produce less working software per unit time.
<Smerdyakov>
So, if I care about what they are working on, I want to discourage them from doing it.
<indigo>
that's not the same as saying that (+) 1 2 should be impossible
<indigo>
if i wanted a language where + 1 2 was how one and two were added, what would you do?
<indigo>
have me shot?
<indigo>
or would you grant that choice is a good solution?
<Smerdyakov>
I have no problem with allowing it to be possible. I'm talking about idiomatic usage; what is considered "good coding style," and so what people will be encouraged to do and tend to do.
<indigo>
so then, why do you not like syntatic sugar?
<Smerdyakov>
I said I _did_ like syntatic sugar.
<indigo>
you did say "I'm not advocating duplicate means."
<indigo>
syntatic sugar is duplicate means, by definition
<Smerdyakov>
I did not say "I am advocating against duplicate means."
<Smerdyakov>
I support introducing them where helpful.
<Smerdyakov>
But they are not a goal in themselves.
<indigo>
that sounds reasonable
<indigo>
so now, can we conclude that i think prefix notation is optimal for my preferences, and infix for yours, and a good solution is to allow both?
<Smerdyakov>
No. "Preferences" is a meaningless term in a discussion on engineering practice.
<indigo>
didn't we just finish discussing that?
slashvar[lri] has quit ["fuck nvidia"]
<Smerdyakov>
Yes, and I believe I expressed my view adequately.
<Smerdyakov>
I care about your efficiency. If your "preferences" impair your effiency, I don't want you to follow them.
<indigo>
so you think you should be the one to decide the preferences of others?
<Smerdyakov>
No. I think empirical investigation of human thought universals should do that.
<mattam>
if asked for, why not ?
<indigo>
mattam: huh?
<indigo>
i think the real issue here is just what is universal, and what is not
<indigo>
i believe that the quality of infix and prefix notation is not universal
<indigo>
if you disagree, that only proves my point
<indigo>
we don't agree, and we can't, because we have preferences
<Smerdyakov>
Untrue. If we accept the scientific method, we can settle this with enough time.
<mattam>
i mean, if you have authority on someone or if you are directly asked, you obviously will try to express your opinion, and the point of discussions if to convince the others that your solution is the more well thought etc.
<indigo>
have you ever read "zen and the art of motorcycle maintenance"?
<Smerdyakov>
Sure have.
<indigo>
and i assume you disagree...
<Smerdyakov>
You'll have to explain what you mean by "disagree."
<indigo>
do you believe that the scientific method is able to solve all problems?
<Smerdyakov>
No, I don't.
<mattam>
but engineering ones....
<indigo>
then what makes you think that the scientific method can determine if prefix or infix is superior?
<Smerdyakov>
Prior success of cognitive science in related problems.
<indigo>
such as?
<Smerdyakov>
Understanding how people learn, etc..
<Smerdyakov>
I'll know more once I read a book on the cognitive aspects of programming that someone recommended. :)
<indigo>
can you give a more exact example?
<Smerdyakov>
No, I can't.
<indigo>
well, it's a very weak point then
<Smerdyakov>
That doesn't bother me.
<mattam>
we know a lot about how our eyes react, it's used to place(?) graphical objects in publicity a lot.
<Banana>
hi all.
<indigo>
hi :)
<mattam>
and it works whether or not you know it.
<indigo>
and it is?
<mattam>
sort of rules
<indigo>
...
<indigo>
I don't agree that infix is easier to read. I prefer prefix or postfix because it's unambigious, and I value purity of form
<mattam>
i don't know a lot of them (i'm no expert at it)
<Banana>
just my 2 cents but.... when I read an infix expression i can forget subexpresion as I read (a linear lecture) and yet have some understanding of what it does. with a prefix notation i've got to go back to the begining every time... (and i'm not talking about nesting and parenthesis).
<Smerdyakov>
Banana, that is very close to what I argued earlier.
<indigo>
well, i think most of this is due to lack of practice
<Banana>
indigo: no.
<indigo>
subexpressions can be eliminated with prefix notation as well
<Banana>
i got an HP calculator ;)
<Banana>
and I can speak a little Japanese.
<Banana>
:p
<Banana>
I'm just speaking for myself though.
<indigo>
well, that's nothing compared to the infix notation you have been using since first grade
<Banana>
I mean my brain is not a stack ;)
<mattam>
hopefully
<Banana>
indigo: maybe there are good reasons why prefix isn't taught in first grade....
<indigo>
i think it's largely tradition
<indigo>
postfix notation developed in other parts of the world independantly
<Banana>
but another thing...
<Banana>
you need the proper tool to input efficiently...
<Banana>
why you can go fast in RPN with an HP calculator is because you inpu directly in a stack and it's very 'user friendly'.
<Banana>
you can't do the same with emacs.
<Banana>
(you need a bunch of parenthesis and so on...)
<indigo>
parenthesis are not a requirement of prefix notation
<indigo>
in fact, they are totally unneeded, unlike infix
<Banana>
so maybe, if you have an appropriate input device (or editor) prefix might be usable.
<indigo>
the reason they are present in lisp is because operators take any number of arguements
<Banana>
indigo: parenthesis are necessary to HUMAN understanding.
<indigo>
not so
<indigo>
but they can be helpful
<indigo>
as can whitespace
<indigo>
for example...
<indigo>
+ a
<indigo>
- c
<indigo>
d
<Banana>
that dosen't count.
<Banana>
this is a small expression.
<Banana>
with infix you have locality.
<indigo>
i dispute the value of locality
<Banana>
do so.
<indigo>
are you familiar with python syntax?
<Banana>
a bit.
<Banana>
( mattam don't say it to the others;)
<indigo>
note this is only an explanition of my preference
<indigo>
i still advocate choice
shawn has quit [Read error: 104 (Connection reset by peer)]
<indigo>
as with any programming language, python has deeply nested, long strings of expressions caused by control structures such as "if", "for", etc...
<indigo>
because of the indentation, it's easy to find the end of a block, by scanning down for a matching indentation
<indigo>
this isn't required in many other languages, but it's often done anyway, to make things more clear
<indigo>
computer programs can assist this process
<indigo>
vim and emacs have such features
<Banana>
(and it's easy to have a syntax error if your editor doesn't have a python mode...)
<indigo>
it's easy to have a syntax error in any language
<Banana>
(but I use emacs, so we can go forth).
<Banana>
indigo: yes but not due to a lack of ' ' or tab ...
<Banana>
but that's not our point.
<indigo>
exactly :)
<indigo>
btw...i use vim :)
<indigo>
BUT THAT'S NOT OUR POINT EITHER! :)
<Banana>
to much....
<Banana>
must troll....
<Banana>
haaaaaaaaaaaaaa
* Banana
segfaults.
<indigo>
heh
<mattam>
indigo: how surprised am i!
_JusSx_ has joined #ocaml
<indigo>
mattam: it's all about choice...
<mattam>
exact
<Banana>
you think people should have the choice to use only prefix in ocaml ?
<indigo>
well, they already do
<Banana>
no.
<indigo>
by (+)
<Banana>
yeah,
<indigo>
and all function calls are prefix
<Banana>
but only for a few operators.
<Banana>
and if then else ?
<Banana>
and match with ?
<Banana>
and try catch ?
<indigo>
if all that were changed, it would be another language
<indigo>
or it would just be really ugly
<Banana>
besides (+) induce using 2 extra parenthesis which are A WASTE OF DISK SPACE.
<Banana>
</joke>
<indigo>
:imap + (+) :)
<indigo>
i'm inclined to use the prefix notation when adding two very large subexpressions