I know one can use pass-by-reference for getting multiple values back from a function, but is there a language that allows you to actually define multiple outputs seperate from the parameter list for super neatness.
I was thinking it would be super-cool to have an auto-defined struct based on the function return values. so in some pseudo-language it would be like...
>>5
I see all sorts of folks screaming OMG OMG /prog/ is dying.
One, it's always sucked
Two, it's only as good as you make it.
QED: quit your fucking whining and contribute instead of crying like a girl.
Name:
Anonymous2009-10-02 20:51
See the python example above, which has built in tuple packing/unpacking with the comma operator. Even sepplesox has this with tie().
Name:
Anonymous2009-10-02 20:55
Actually most high-level languages have exactly what you want; split() in almost any scripting language returns a list which you index like an array. You just need to get away from sepples and java/.net. People tell you they're high level languages; they're lying.
Name:
Anonymous2009-10-02 20:59
I just reread op and realized how stupid it is. Have I been trolled?
I don't even know what >>1-chan is talking about, so here's some ded dof to tide you over:
Prelude> let foo x y = (div x y, mod x y)
Prelude> :t foo
foo :: (Integral a) => a -> a -> (a, a)
Prelude> :t divMod
divMod :: (Integral a) => a -> a -> (a, a)
Prelude> error "hax my anus"
*** Exception: hax m*** Exception: Stack overflow
Name:
Anonymous2009-10-02 21:28
(multiple-value-bind (a b) (split-string "hello world")
(print a)
(print b))
Implementing SPLIT-STRING left as an exercise for the reader.
You could return a void pointer to memory containing:
a short holding the number of pointers n
n pointers
x bytes, referenced by your pointers.
Is this acceptable?
Name:
Anonymous2009-10-02 22:49
>>1 >>15 knows where's it at. Lisp has multiple return values, and much more.
A somewhat wasteful implementation of split-string would be:
(defun split-string (s)
(values-list (split-sequence s :remove-empty-subseqs t)))
or one could just use destructuring-bind. (SPLIT-SEQUENCE is a tiny CL library.)
>>18
Yes, you can emulate multiple return values using various conventions, but there's huge usability differences between C's out parameters, or returning a pointer to an array/structure/list and Lisp's multiple return values. The first is just a natural consequence of how pointers work, and this allows you to basically get that functionality, while the second is a well-supported part of the language which leads to completly different idioms in writing code. I could explain how this works in detail, but it's best to just see for yourself.
Name:
Anonymous2009-10-04 19:50
>>19
Yes, you can emulate tuple packing/unpacking using various conventions, but there's huge usability differences between Lisp's multiple-value-bind, and Python's tuples. The first is just a natural consequence of how bindings work, and this allows you to basically get that functionality, while the second is a well-supported part of the language which leads to completly different idioms in writing code. I could explain how this works in detail, but it's best to just see for yourself.
Lisp sucks. I've never met a Lisp user who wasn't incredibly pretentious.
Name:
Anonymous2009-10-04 20:00
($x, $y, $z) = &x();
print "$x, $y, $z\n";
sub x()
{
return(1, 2, 3);
}
Lisp is for faggots.
Perl is a REAL man's high level language. [u][b]Accept no substitutes.[b][/u]
>>1
This is a bad idea. It will only confuse things when real programs are to be written. Perhaps it would be a good addition to a toy language, but not a real one. When you call a function, you want to know what the fuck it's returning. Also, if you have some function return two values in (with your proposed idea), then what happens if one of the values depends on the other? It makes it hard as fuck to debug.
It may look like this:
f(x)
{
int a
modify a
IF WE'RE RETURNING FIRST RETURN VALUE:
return a
b = modified a
IF WE'RE RETURNING SECOND RETURN VALUE:
return b
}
One can imagine how hard it would be to debug this when the function gets large. So it's a bad idea because people will write large, unclear function and code will be harder to debug.
Name:
Anonymous2009-10-04 21:09
>>23 large, unclear function
large, unclear functions
fixed
! {
splitstring ->
stef(a,b;s,sep)
staðvær i = 1, l := \lengd s
stofn
meðan i <= l lykkja
ef s[i] = sep þá
a := strdup(;s,1,i-1),
b := strdup(;s,i+1,l),
skila i,
eflok,
lykkjulok,
a := strdup(;s,1,l),
b := "",
skila 0
stofnlok
strdup ->
stef(;s,from,to)
staðvær r, i := 1, l
stofn
l := to - from + 1,
l > 0 eða skila "",
r := \strengur l,
meðan i <= l lykkja
r[i] = s[from+i-1],
lykkjulok,
r
stofnlok
}
This probably doesn't work. Also, I should really find something better to do.
Name:
Anonymous2009-10-04 23:14
>>25
It obviously won't work without *
"GRUNNUR"
;
Name:
Anonymous2009-10-05 1:14
>>20 Lisp sucks. I've never met a Lisp user who wasn't incredibly pretentious.
Typical lower-class sentiment.
WTF is wrong with this thread? Java does this already. Objects have multiple types within them so... you can return an object that has as many variables contained within it that you want.
Name:
Anonymous2009-10-05 3:28
>>19
refer to >>21
holy shit! an imperative language just happens to be able to do it more elegantly and with less effort than your lisp wankery.
>>31
huh? multiple-value-bind and destructuring-bind can do the same things as in that example, only in a cleaner manner. You can also do many other manipulations with multiple return values that are much harder in other languages.
I have little interest to argue with ignoramuses today. Go read a book or stay as you are.
>>33
Allow me to finish your sentence for you: is a joke. >>34 multiple-value-bind and destructuring-bind can do the same things as in that example, only in a cleaner manner
HAR HAR HAR HAR HAR HAR HAR. Very funny. I almost spit coffee onto my monitor.
You know, you're sounding disturbingly like FV. I'm pretty sure he doesn't know Lisp though.
>>34
I have some interesting facts for you.
>>> def f(): return (1, 2), "valid python code"
...
>>> f()
((1, 2), 'valid python code')
>>> t = f()
>>> t
((1, 2), 'valid python code')
>>> x, y = f()
>>> x, y
((1, 2), 'valid python code')
>>> f()
((1, 2), 'valid python code')
>>> (a, b), c = f()
>>> a, b, c
(1, 2, 'valid python code')
>>> def dot((x1, y1), (x2, y2)): return x1 * x2 + y1 * y2
...
>>> p1, p2 = (1, 0), (0, 1)
>>> dot(p1, p2)
0
>>> lst = x, [y, z] = [1, (2, 3)]
>>> lst
[1, (2, 3)]
>>> x, y, z
(1, 2, 3)
As you do indeed resemble the invisible poster in certain respects, I feel I'd save everyone's time by explaining up front: Python has fully functional destructuring bind built in and it works in assignments, on function calls, everywhere. By the way, RHS can be any iterable, not just tuple or list.
There are three differences from the lithtth protheththing language:
1. It's somewhat less powerful -- there are no named/rest arguments. Actually "*xs, x = (1, 2, 3)" works in Py3K, but on the other hand they pulled automatic destructuring in lambda arguments or something because Guido hates lithp weenies and wants to drive them away, no matter the cost.
2. You never need to actually call some macro to have it. It just works.
3. Excessive parentheses do not make you want to gouge your eyes out with a soup ladle.
>>44
Actually, I started using Scheme the other week after lots of time spent with Sepples and FOIC. With proper parenthesis matching as in DrScheme, it's not half bad.
It's hard to explain, but it's almost like demon code. It sort of summons itself to the capable programmer's hands. You should give it a shot if you haven't.
Name:
Anonymous2009-10-05 22:43
>>45
Oh yeah, indentation of code surely makes it hard to read. Idiots. >>44
Only sensible post in this thread.
Name:
Anonymous2009-10-05 23:16
>>51
It has been proven that not only does indentation of code reduce productivity, but that it also reduces readability, especially when there is a rigid implementation which lacks curly brackets, like in languages such as Python and Visual Basic.
int main (int argc, char **argv)
{
int foo = 1;
char bar = 'a';
if (foo == 1)
{
printf("bar: %c", bar);
}
return 0;
}
[code]
or
[code]
foo = 1
bar = '1'
if foo == 1:
print "bar: " + bar
return 0
I can assure you, not only did the second one take longer to write per line (because you have to consciously look at indentation and remember where you are), but it took longer to read (per line). This is a simple program, too. Imagine a full blown program, like an operating system. This is why they don't write operating systems in languages such as Python.
>>56 This is why they don't write operating systems in languages such as Python.
Holy fuck. You honestly believe *indentation* is the only reason they aren't writing operating systems in Python.
You, sir, are completely out to lunch. You must be stoned, or trolling, or something. There's no possible way any serious person in their right mind could make such a statement.