Custom Search
|
Date: December 31, 2006
From: Eric Gouriou <eric.gouriou@xxxxxxxxx>
In-reply-to:
<1167535636.12983.12.camel@xxxxxxxxxxxxxxxxx>
References:
<20061226073930.C81A81AC018@xxxxxxxxxxxxxxxxxxxxxxxx> <1167535636.12983.12.camel@xxxxxxxxxxxxxxxxx>
On Dec 30, 2006, at 19:27 , Peter S. Housel wrote: > On Tue, 2006-12-26 at 08:39 +0100, agent@xxxxxxxxxxxxxxxx wrote: >> Author: agent >> Date: Tue Dec 26 08:39:29 2006 >> New Revision: 11101 >> >> Modified: >> trunk/src/d2c/runtime/dylan/tests/collections.dylan >> Log: >> Job: gd >> Corrected invalid test. Test did ensure that element(..., default: >> x) errors >> if x is of the wrong element type. According to DRM, the >> restriction on >> return value of element() doesn't apply if default: is supplied, >> so it should >> not error. > > Where do you get that? As I read it, the DRM doesn't explicitly say > whether or not default: values that aren't instances of the > collection's > element type are permitted. For performance reasons, it seems > perfectly > reasonable that a particular element() method would declare a > particular > return type, and that the default: value would be subject to the > declared type restriction. This would forbid code like element(index-not-present, #f) for limited collections on types that do not include #f (or element(index-not-present, #()), etc.). I believe it is fairly common idiom to use a default value which cannot be part of the collection itself, instead of relying on conditions to catch an invalid/not-present index. element() may need to be treated specially by the compiler as returning' type-union(element-type-of-collection(coll), singleton(default-value)) (I hope you'll get my meaning, my Dylan is very rusty). Eric -- Eric Gouriou eric.gouriou@xxxxxxxxx -- Gd-hackers mailing list Gd-hackers@xxxxxxxxxxxxxxxx https://www.opendylan.org/mailman/listinfo/gd-hackers
Date: December 31, 2006
From: "Peter S. Housel" <housel@xxxxxxx>
In-reply-to:
<20061226073930.C81A81AC018@xxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061226073930.C81A81AC018@xxxxxxxxxxxxxxxxxxxxxxxx>
On Tue, 2006-12-26 at 08:39 +0100, agent@xxxxxxxxxxxxxxxx wrote: > Author: agent > Date: Tue Dec 26 08:39:29 2006 > New Revision: 11101 > > Modified: > trunk/src/d2c/runtime/dylan/tests/collections.dylan > Log: > Job: gd > Corrected invalid test. Test did ensure that element(..., default: x) errors > if x is of the wrong element type. According to DRM, the restriction on > return value of element() doesn't apply if default: is supplied, so it should > not error. Where do you get that? As I read it, the DRM doesn't explicitly say whether or not default: values that aren't instances of the collection's element type are permitted. For performance reasons, it seems perfectly reasonable that a particular element() method would declare a particular return type, and that the default: value would be subject to the declared type restriction. -- Peter S. Housel <housel@xxxxxxx> -- Gd-hackers mailing list Gd-hackers@xxxxxxxxxxxxxxxx https://www.opendylan.org/mailman/listinfo/gd-hackers
Date: December 15, 2006
From: Hannes Mehnert <hannes@xxxxxxxxxxx>
In-reply-to:
<457827B4.3000102@xxxxxxxxx>
References:
<457827B4.3000102@xxxxxxxxx>
Hi, On 07.12.2006, at 15:39, Michael Mustun wrote: > Gibt es wxDylan? Ich meine, einen Anbindung des wxWiget GUI Toolkits > (http://www.wxwidgets.org/). No, there's no wxWidget-Interface for Dylan. (gd-hackers@xxxxxxxxxxxxxxxx is an international mailing list, that's why I answer in english to you). Best regards, Hannes -- Gd-hackers mailing list Gd-hackers@xxxxxxxxxxxxxxxx https://www.opendylan.org/mailman/listinfo/gd-hackers
Date: December 14, 2006
From: "Bruce Hoult" <bruce@xxxxxxxxx>
In-reply-to:
<A130E4A4-FCBE-431D-BAFB-A8F00D4B105C@xxxxxxxxxxxxx>
References:
<391c06200612131403s321f7687ld94b0ec2eaf6981a@xxxxxxxxxxxxxx> <A130E4A4-FCBE-431D-BAFB-A8F00D4B105C@xxxxxxxxxxxxx>
On 12/14/06, Dustin Voss <d-j-v@xxxxxxxxxxxxx> wrote: > No problem. Per discussion on IRC, I'm rolling back the check-in and > moving it to table-extensions (with possible name change to avoid OD > conflicts) in a few days. Thanks :-) -- Gd-hackers mailing list Gd-hackers@xxxxxxxxxxxxxxxx https://www.opendylan.org/mailman/listinfo/gd-hackers
Date: December 14, 2006
From: Dustin Voss <d-j-v@xxxxxxxxxxxxx>
In-reply-to:
<391c06200612131403s321f7687ld94b0ec2eaf6981a@xxxxxxxxxxxxxx>
References:
<391c06200612131403s321f7687ld94b0ec2eaf6981a@xxxxxxxxxxxxxx>
No problem. Per discussion on IRC, I'm rolling back the check-in and moving it to table-extensions (with possible name change to avoid OD conflicts) in a few days. On 13 Dec 2006, at 2:03 PM, Bruce Hoult wrote: > I'd like to thank |agent for writing the table() macro: > > http://www.opendylan.org/cvszilla/transaction.cgi?id=11064 > > It looks quite useful in a lot of code. > > > Unfortunately I see a number of problems with this which together make > me quite unhappy. > > - the checkin comment says it is in common-extensions but it would > appear to be in common-dylan, based on the number of files checked in > that say "use common-dylan, exclude: { table };" > > - common-dylan should be quite stable, only one step below the DRM > itself, and modified only on the basis of consensus, after a proposal > and discussion. > > - common-dylan should be the same between GD and OD. The checkin > comment admits that this can not be implemented in OD at present. > > - the name choosen is highly likely to conflict with existing Dylan > code, and these days common-dylan is *the* standard import, replacing > the older "use dylan". > > - That conflict is likely is evidenced by six of the nine files > touched by the transaction being modified PURELY to resolve name > conflicts with the new macro, either by renaming existing variables or > by excluding "table" from the imports. > - there is no way to know how much user-written code will conflict. > My guess is: a lot > > > I would like to see some or all of the following done: > > - the macro renamed to something less likely to conflict, such as > make-table. > > - the macro removed from common-dylan and put into common-extensions, > or table-extensions, or contributions. > > - changes to common-dylan, if they met general approval, should be > implemented simultaneously in Gwydion 2.4 and 2.5 branches, and in > OpenDylan. > > > I'm really happy that Agent is working on improving Dylan and I'd like > to encourage this. We sorely need many improvements to the compiler, > libraries and documntation. > > I just don't think we should make incompatable changes to the language > itself quite so casually. > > Best regards, > Bruce > -- > Gd-hackers mailing list > Gd-hackers@xxxxxxxxxxxxxxxx > https://www.opendylan.org/mailman/listinfo/gd-hackers -- Gd-hackers mailing list Gd-hackers@xxxxxxxxxxxxxxxx https://www.opendylan.org/mailman/listinfo/gd-hackers
Date: December 13, 2006
From: "Bruce Hoult" <bruce@xxxxxxxxx>
I'd like to thank |agent for writing the table() macro: http://www.opendylan.org/cvszilla/transaction.cgi?id=11064 It looks quite useful in a lot of code. Unfortunately I see a number of problems with this which together make me quite unhappy. - the checkin comment says it is in common-extensions but it would appear to be in common-dylan, based on the number of files checked in that say "use common-dylan, exclude: { table };" - common-dylan should be quite stable, only one step below the DRM itself, and modified only on the basis of consensus, after a proposal and discussion. - common-dylan should be the same between GD and OD. The checkin comment admits that this can not be implemented in OD at present. - the name choosen is highly likely to conflict with existing Dylan code, and these days common-dylan is *the* standard import, replacing the older "use dylan". - That conflict is likely is evidenced by six of the nine files touched by the transaction being modified PURELY to resolve name conflicts with the new macro, either by renaming existing variables or by excluding "table" from the imports. - there is no way to know how much user-written code will conflict. My guess is: a lot I would like to see some or all of the following done: - the macro renamed to something less likely to conflict, such as make-table. - the macro removed from common-dylan and put into common-extensions, or table-extensions, or contributions. - changes to common-dylan, if they met general approval, should be implemented simultaneously in Gwydion 2.4 and 2.5 branches, and in OpenDylan. I'm really happy that Agent is working on improving Dylan and I'd like to encourage this. We sorely need many improvements to the compiler, libraries and documntation. I just don't think we should make incompatable changes to the language itself quite so casually. Best regards, Bruce -- Gd-hackers mailing list Gd-hackers@xxxxxxxxxxxxxxxx https://www.opendylan.org/mailman/listinfo/gd-hackers
Date: December 08, 2006
From: Michael Mustun <michael@xxxxxxxxx>
Hallo! Gibt es wxDylan? Ich meine, einen Anbindung des wxWiget GUI Toolkits (http://www.wxwidgets.org/). Für andere Programmiersprachen wie z.B. "D" wurde das schon gemacht, siehe http://wxd.sourceforge.net/. Bis jetzt konnte ich Dylan nocht nicht ausprobieren. (Soll einen Garbage Collection GCC verwenden. Habe Cygwin installiert, und MinGW. -- Ob das auch mit diesen läuft, darüber schweigt sich die Doku auf der Homepage aus.) Ich hörte aber den Vortrag auf http://chaosradio.ccc.de/cre031.html ( Tim Pritlove im Gespräch mit Andreas Bogk). Da ich die EMail von Andreas Bogk nicht gefunden habe, können sie mir vielleicht weiterhelfen. Dylan scheint eine echte Alternative bzw. Zukunft zu C/C++ zu sein, da echt Object-Orientiert. Primär würd mich aber interssieren, ob object-orientiert oder nicht, ob damit wirklich so einfach z.b. ein Basic-Interpreter geschrieben werden kann. Ich sah sehr einfache Beispiele, wie Ehternet(?) Fragmente? überprüft werden konnten. Ein immer wiederkehrendes Problem ist ja, dass solcher Code sehr schnell "abstürzt"; und man sich beim Implementieren auf alle Eventualitäten konzentrieren muss; nur, das soll bei Dylan deutlich besser sein. Bye Michael -- Neu: FreeBible2004 - http://www.freebible2004.ch.vu -------------------------------------- Michael Mustun <michael@xxxxxxxxx> http://www.mustun.ch/michael Important Note: This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. -- Gd-hackers mailing list Gd-hackers@xxxxxxxxxxxxxxxx https://www.opendylan.org/mailman/listinfo/gd-hackers
Date: December 05, 2006
From: Andreas Bogk <andreas@xxxxxxxxxxx>
In-reply-to:
<0FB50249-BF5D-49F0-807B-F63AC0826546@xxxxxxxxxxxxxx>
References:
<ekcvfv$241$1@xxxxxxxxxxxxx> <456A3EB9.7040609@xxxxxxxxxxx> <ekfbvf$ko5$1@xxxxxxxxxxxxx> <456C1D50.4060903@xxxxxxxxxxx> <eki0kq$4tj$1@xxxxxxxxxxxxx> <eki63q$r4u$1@xxxxxxxxxxxxx> <456CA790.7050907@xxxxxxxxxxx> <A0BE6547-24B7-42A8-BF91-8D2302364307@xxxxxxxxxxxxxx> <391c06200612031659v1daef341ha5aaa1f03fedc968@xxxxxxxxxxxxxx> <0FB50249-BF5D-49F0-807B-F63AC0826546@xxxxxxxxxxxxxx>
Chris Page schrieb: > The same way it works in some other languages. The function name plus > the supplied arguments determine which actual (generic) function is > being called. But it's primarily a conceptual distinction whether you > consider it to be one generic function or several, the semantics > could be defined to be the same (or different, if that would offer > some advantage). Generic functions are first class objects. You'd have to implement dispatch over number of arguments in one generic function, or else code like: method(#rest args) apply(foo, args) end with foo being multiple generic functions will be incredibly undefined. Having said that, I think dispatch over number of arguments sounds useful to me. Andreas -- Gd-hackers mailing list Gd-hackers@xxxxxxxxxxxxxxxx https://www.opendylan.org/mailman/listinfo/gd-hackers
Date: December 05, 2006
From: Chris Page <chris@xxxxxxxxxxxxxx>
In-reply-to:
<391c06200612031640r534b8f14o1224e6900ad913c@xxxxxxxxxxxxxx>
References:
<ekcvfv$241$1@xxxxxxxxxxxxx> <456A3EB9.7040609@xxxxxxxxxxx> <ekfbvf$ko5$1@xxxxxxxxxxxxx> <456C1D50.4060903@xxxxxxxxxxx> <eki0kq$4tj$1@xxxxxxxxxxxxx> <eki63q$r4u$1@xxxxxxxxxxxxx> <391c06200611281254n67c59221nec039ee106ba0a87@xxxxxxxxxxxxxx> <ekje63$4ub$1@xxxxxxxxxxxxx> <4B85A84D-773C-4F16-BD04-22DF252BED65@xxxxxxxxxxxxxx> <391c06200612031640r534b8f14o1224e6900ad913c@xxxxxxxxxxxxxx>
On Dec 3, 2006, at 16:40 PM, Bruce Hoult wrote:
> On 12/4/06, Chris Page <chris@xxxxxxxxxxxxxx> wrote:
>> As it happens, I'd rather lose this feature of Dylan and make it
>> so that window.foo(1, 2, 3) is equivalent to foo(window, 1, 2, 3),
>> which I think would be much more useful and widely applicable (no
>> pun intended).
>
> I guess you could still write (window.foo)(1,2,3) if that's what
> you wanted.
Though, given the current Dylan language I might expect that to
evaluate identically to window.foo(1,2,3) -- I'm not sure whether the
additional parenthesis change the evaluation at all in this case.
Instead, I think you'd write either of
foo(window)(1, 2, 3)
window.foo()(1, 2, 3)
> That would be ok, as long as window.foo still meant foo(window).
> Which isn't terribly consistent, syntactically, as window.foo()
> would mean the same thing. But I've seen worse.
I can easily see it making sense if we view it starting from the
general function call syntax:
foo(window, 1, 2, 3)
can also be written
window.foo(1, 2, 3)
and
foo(window)
can also be written
window.foo()
in which case you can omit the redundant parenthesis
window.foo
Just a progression from the more general syntax to the more specific.
--
Chris Page - Software Wrangler
That’s “Chris” with a silent *and* invisible “3”.
--
Gd-hackers mailing list
Gd-hackers@xxxxxxxxxxxxxxxx
https://www.opendylan.org/mailman/listinfo/gd-hackers
Date: December 05, 2006
From: Chris Page <chris@xxxxxxxxxxxxxx>
In-reply-to:
<391c06200612031659v1daef341ha5aaa1f03fedc968@xxxxxxxxxxxxxx>
References:
<ekcvfv$241$1@xxxxxxxxxxxxx> <456A3EB9.7040609@xxxxxxxxxxx> <ekfbvf$ko5$1@xxxxxxxxxxxxx> <456C1D50.4060903@xxxxxxxxxxx> <eki0kq$4tj$1@xxxxxxxxxxxxx> <eki63q$r4u$1@xxxxxxxxxxxxx> <456CA790.7050907@xxxxxxxxxxx> <A0BE6547-24B7-42A8-BF91-8D2302364307@xxxxxxxxxxxxxx> <391c06200612031659v1daef341ha5aaa1f03fedc968@xxxxxxxxxxxxxx>
On Dec 3, 2006, at 16:59 PM, Bruce Hoult wrote: > On 12/4/06, Chris Page <chris@xxxxxxxxxxxxxx> wrote: >> I've often thought that we should consider either adding >> overloading--meaning that different numbers of required args would >> simply create different generic functions with the same user- >> visible name > > How on earth would the compiler know which generic function to use? The same way it works in some other languages. The function name plus the supplied arguments determine which actual (generic) function is being called. But it's primarily a conceptual distinction whether you consider it to be one generic function or several, the semantics could be defined to be the same (or different, if that would offer some advantage). >> --or allow methods to require different numbers of required args >> as long as they require at least as many as the generic function, >> which must accept #rest, e.g.: >> >> define generic foo(req1, req2, #rest optional); >> define method foo(req1, req2, #rest optional) ... end; >> define method foo(req1, req2, req3, #rest optional) ... end; >> define method foo(req1, req2, req3, req4, #rest optional) ... >> end; >> >> These would be considered congruent and the number of arguments >> passed in would be considered when dispatching. > > Doesn't seem very clean ... In what way? Today you have to distinguish with explicit generic functions with different names, which seems very awkward to me, e.g.: define generic foo-1(req1); define generic foo-2(req1, req2); define generic foo-3(req1, req2, req3); define generic foo-4(req1, req2, req3, req4); The OpenGL API provides an example of how noisy this can make the code. For some cases, turning them into #rest or optional keyword arguments doesn't help much, as they don't participate in method dispatch and they introduce a layer of overhead in which, say, a method on foo(req1, #rest others) has to explicitly check the number of arguments and apply() the appropriate GF. At the very least, I would expect integrating this idiom into the (compile-time and runtime) dispatcher could be more efficient. > ... and I really don't see how you'd implement it to be fast unless > the compiler exmapded it out to different GFs internally depending > on how many arguments were passed, with the functions with fewer > "required" arguments having implicit <object> specializations in > the GFs for 3 or 4 arguments. Something like that, which I expect is about the same as dispatching on the other arguments. Consider this example: define generic foo(arg-count, req1, req2, #rest optional); define method foo(arg-count == 2, req1, req2, #rest optional) ... end; define method foo(arg-count == 3, req1, req2, #rest optional) ... end; define method foo(arg-count == 4, req1, req2, #rest optional) ... end; If the caller implicitly passed the number of supplied arguments to arg-count, I should think this is about as efficient as dispatching without that parameter (assuming the specializers of req1 and req2 are actually different in a real-world case). What's lacking here, though, is the ability to also dispatch on the other argument types, like so: define method foo(req1, req2 :: <baz>, #rest optional) ... end; define method foo(req1, req2 :: <bar>, #rest optional) ... end; define method foo(req1, req2 :: <bar>, req3 :: <quux>, #rest optional) ... end; define method foo(req1, req2 :: <baz>, req3 :: <quux>, #rest optional) ... end; As a practical point, I think it would be cleaner to omit the explicit #rest args for methods that handle a specific, fixed number of arguments. In fact, it probably makes sense to introduce a new #- word to indicate parameters whose types and count participate in dispatch: define generic foo(req1, #optional req2, req3, req4); define method foo(req1) ... end; define method foo(req1, req2) ... end; define method foo(req1, req2, req3) ... end; define method foo(req1, req2, req3, req4) ... end; and then you can write: define method foo(req1 :: <integer>) ... end; define method foo(req1 :: <sequence>) ... end; define method foo(req1 :: <integer>, req2 :: <integer>) ... end; define method foo(req1 :: <integer>, req2 :: <sequence>) ... end; and so on. > This could be done with macros right now. I'd love to see a rough outline of the macro call syntax and what the implementation would look like. Can you elaborate? How would you implement it, generally speaking? Would what you are imagining require the number of arguments to be known statically? Would it work with apply()? -- Chris Page - Retrospective Electrical Engineer Never attach a 12V/1A power supply to a 3V/5mA chip; that releases the magic smoke that makes it go. -- Gd-hackers mailing list Gd-hackers@xxxxxxxxxxxxxxxx https://www.opendylan.org/mailman/listinfo/gd-hackers
Date: December 05, 2006
From: Chris Page <chris@xxxxxxxxxxxxxx>
In-reply-to:
<el34ht$4f1$1@xxxxxxxxxxxxx>
References:
<ekcvfv$241$1@xxxxxxxxxxxxx> <456A3EB9.7040609@xxxxxxxxxxx> <ekfbvf$ko5$1@xxxxxxxxxxxxx> <456C1D50.4060903@xxxxxxxxxxx> <eki0kq$4tj$1@xxxxxxxxxxxxx> <eki63q$r4u$1@xxxxxxxxxxxxx> <456CA790.7050907@xxxxxxxxxxx> <A0BE6547-24B7-42A8-BF91-8D2302364307@xxxxxxxxxxxxxx> <el34ht$4f1$1@xxxxxxxxxxxxx>
On Dec 4, 2006, at 22:45 PM, Mike Austin wrote: > The first option sounds pretty nifty. I guess it could get tricky > with keyword and rest args, but I don't know the internals of the > Dylan runtimes. Keyword and #rest arguments aren't used for method dispatch--only the required args are--so I don't think they complicate this issue. -- Chris Page - Dylan Pundit Open Source Dylan Compilers: <http://www.gwydiondylan.org/> Dylan Blogging: <http://homepage.mac.com/chrispage/iblog/> Dylan Stuff: <http://www.cafepress.com/chrispage> -- Gd-hackers mailing list Gd-hackers@xxxxxxxxxxxxxxxx https://www.opendylan.org/mailman/listinfo/gd-hackers
Date: December 05, 2006
From: Mike Austin <mike_ekim@xxxxxxxxx>
In-reply-to:
<A0BE6547-24B7-42A8-BF91-8D2302364307@xxxxxxxxxxxxxx>
References:
<ekcvfv$241$1@xxxxxxxxxxxxx> <456A3EB9.7040609@xxxxxxxxxxx> <ekfbvf$ko5$1@xxxxxxxxxxxxx> <456C1D50.4060903@xxxxxxxxxxx> <eki0kq$4tj$1@xxxxxxxxxxxxx> <eki63q$r4u$1@xxxxxxxxxxxxx> <456CA790.7050907@xxxxxxxxxxx> <A0BE6547-24B7-42A8-BF91-8D2302364307@xxxxxxxxxxxxxx>
Chris Page wrote: > On Nov 28, 2006, at 13:18 PM, Andreas Bogk wrote: > >> Now for a generic function, all methods of that function need to >> have congruent argument lists, which means: same number of parameters. > > Minor clarification: The rules of congruency are more involved, of > course, but you should at least be aware that the basic rule is "same > number of *required* parameters". > > I've often thought that we should consider either adding overloading-- > meaning that different numbers of required args would simply create > different generic functions with the same user-visible name--or allow > methods to require different numbers of required args as long as they > require at least as many as the generic function, which must accept > #rest, e.g.: > > define generic foo(req1, req2, #rest optional); > define method foo(req1, req2, #rest optional) ... end; > define method foo(req1, req2, req3, #rest optional) ... end; > define method foo(req1, req2, req3, req4, #rest optional) ... end; > > These would be considered congruent and the number of arguments > passed in would be considered when dispatching. The first option sounds pretty nifty. I guess it could get tricky with keyword and rest args, but I don't know the internals of the Dylan runtimes. Mike -- Gd-hackers mailing list Gd-hackers@xxxxxxxxxxxxxxxx https://www.opendylan.org/mailman/listinfo/gd-hackers
Date: December 05, 2006
From: Mike Austin <mike_ekim@xxxxxxxxx>
In-reply-to:
<391c06200612031640r534b8f14o1224e6900ad913c@xxxxxxxxxxxxxx>
References:
<ekcvfv$241$1@xxxxxxxxxxxxx> <456A3EB9.7040609@xxxxxxxxxxx> <ekfbvf$ko5$1@xxxxxxxxxxxxx> <456C1D50.4060903@xxxxxxxxxxx> <eki0kq$4tj$1@xxxxxxxxxxxxx> <eki63q$r4u$1@xxxxxxxxxxxxx> <391c06200611281254n67c59221nec039ee106ba0a87@xxxxxxxxxxxxxx> <ekje63$4ub$1@xxxxxxxxxxxxx> <4B85A84D-773C-4F16-BD04-22DF252BED65@xxxxxxxxxxxxxx> <391c06200612031640r534b8f14o1224e6900ad913c@xxxxxxxxxxxxxx>
Bruce Hoult wrote: > On 12/4/06, Chris Page <chris@xxxxxxxxxxxxxx> wrote: >> As it happens, I'd rather lose this feature of Dylan and make it so >> that window.foo(1, 2, 3) is equivalent to foo(window, 1, 2, 3), which >> I think would be much more useful and widely applicable (no pun >> intended). > > I guess you could still write (window.foo)(1,2,3) if that's what you wanted. > > That would be ok, as long as window.foo still meant foo(window). > Which isn't terribly consistent, syntactically, as window.foo() would > mean the same thing. But I've seen worse. But in this case "foo" is still a global binding, and will require the same number of required arguments as the generic function. What I was getting at was being able to write functions with the same name with different number of required arguments. Mike -- Gd-hackers mailing list Gd-hackers@xxxxxxxxxxxxxxxx https://www.opendylan.org/mailman/listinfo/gd-hackers
Date: December 04, 2006
From: "Bruce Hoult" <bruce@xxxxxxxxx>
In-reply-to:
<A0BE6547-24B7-42A8-BF91-8D2302364307@xxxxxxxxxxxxxx>
References:
<ekcvfv$241$1@xxxxxxxxxxxxx> <456A3EB9.7040609@xxxxxxxxxxx> <ekfbvf$ko5$1@xxxxxxxxxxxxx> <456C1D50.4060903@xxxxxxxxxxx> <eki0kq$4tj$1@xxxxxxxxxxxxx> <eki63q$r4u$1@xxxxxxxxxxxxx> <456CA790.7050907@xxxxxxxxxxx> <A0BE6547-24B7-42A8-BF91-8D2302364307@xxxxxxxxxxxxxx>
On 12/4/06, Chris Page <chris@xxxxxxxxxxxxxx> wrote: > I've often thought that we should consider either adding overloading-- > meaning that different numbers of required args would simply create > different generic functions with the same user-visible name How on earth would the compiler know which generic function to use? > --or allow > methods to require different numbers of required args as long as they > require at least as many as the generic function, which must accept > #rest, e.g.: > > define generic foo(req1, req2, #rest optional); > define method foo(req1, req2, #rest optional) ... end; > define method foo(req1, req2, req3, #rest optional) ... end; > define method foo(req1, req2, req3, req4, #rest optional) ... end; > > These would be considered congruent and the number of arguments > passed in would be considered when dispatching. Doesn't seem very clean and I really dont' see how you'd implement it to be fast unless the compiler exmapded it out to different GFs internally depending on how many arguments were passsed, with the functions with fewer "required" arguments having implicit <object> specializations in the GFs for 3 or 4 arguments. This could be done with macros right now. -- Gd-hackers mailing list Gd-hackers@xxxxxxxxxxxxxxxx https://www.opendylan.org/mailman/listinfo/gd-hackers
Date: December 04, 2006
From: "Bruce Hoult" <bruce@xxxxxxxxx>
In-reply-to:
<4B85A84D-773C-4F16-BD04-22DF252BED65@xxxxxxxxxxxxxx>
References:
<ekcvfv$241$1@xxxxxxxxxxxxx> <456A3EB9.7040609@xxxxxxxxxxx> <ekfbvf$ko5$1@xxxxxxxxxxxxx> <456C1D50.4060903@xxxxxxxxxxx> <eki0kq$4tj$1@xxxxxxxxxxxxx> <eki63q$r4u$1@xxxxxxxxxxxxx> <391c06200611281254n67c59221nec039ee106ba0a87@xxxxxxxxxxxxxx> <ekje63$4ub$1@xxxxxxxxxxxxx> <4B85A84D-773C-4F16-BD04-22DF252BED65@xxxxxxxxxxxxxx>
On 12/4/06, Chris Page <chris@xxxxxxxxxxxxxx> wrote: > As it happens, I'd rather lose this feature of Dylan and make it so > that window.foo(1, 2, 3) is equivalent to foo(window, 1, 2, 3), which > I think would be much more useful and widely applicable (no pun > intended). I guess you could still write (window.foo)(1,2,3) if that's what you wanted. That would be ok, as long as window.foo still meant foo(window). Which isn't terribly consistent, syntactically, as window.foo() would mean the same thing. But I've seen worse. -- Gd-hackers mailing list Gd-hackers@xxxxxxxxxxxxxxxx https://www.opendylan.org/mailman/listinfo/gd-hackers
Date: December 04, 2006
From: Chris Page <chris@xxxxxxxxxxxxxx>
In-reply-to:
<456CA790.7050907@xxxxxxxxxxx>
References:
<ekcvfv$241$1@xxxxxxxxxxxxx> <456A3EB9.7040609@xxxxxxxxxxx> <ekfbvf$ko5$1@xxxxxxxxxxxxx> <456C1D50.4060903@xxxxxxxxxxx> <eki0kq$4tj$1@xxxxxxxxxxxxx> <eki63q$r4u$1@xxxxxxxxxxxxx> <456CA790.7050907@xxxxxxxxxxx>
On Nov 28, 2006, at 13:18 PM, Andreas Bogk wrote: > Now for a generic function, all methods of that function need to > have congruent argument lists, which means: same number of parameters. Minor clarification: The rules of congruency are more involved, of course, but you should at least be aware that the basic rule is "same number of *required* parameters". I've often thought that we should consider either adding overloading-- meaning that different numbers of required args would simply create different generic functions with the same user-visible name--or allow methods to require different numbers of required args as long as they require at least as many as the generic function, which must accept #rest, e.g.: define generic foo(req1, req2, #rest optional); define method foo(req1, req2, #rest optional) ... end; define method foo(req1, req2, req3, #rest optional) ... end; define method foo(req1, req2, req3, req4, #rest optional) ... end; These would be considered congruent and the number of arguments passed in would be considered when dispatching. -- Chris Page - Rhetor Statements are closer than they appear. -- Gd-hackers mailing list Gd-hackers@xxxxxxxxxxxxxxxx https://www.opendylan.org/mailman/listinfo/gd-hackers
Date: December 04, 2006
From: Chris Page <chris@xxxxxxxxxxxxxx>
In-reply-to:
<ekje63$4ub$1@xxxxxxxxxxxxx>
References:
<ekcvfv$241$1@xxxxxxxxxxxxx> <456A3EB9.7040609@xxxxxxxxxxx> <ekfbvf$ko5$1@xxxxxxxxxxxxx> <456C1D50.4060903@xxxxxxxxxxx> <eki0kq$4tj$1@xxxxxxxxxxxxx> <eki63q$r4u$1@xxxxxxxxxxxxx> <391c06200611281254n67c59221nec039ee106ba0a87@xxxxxxxxxxxxxx> <ekje63$4ub$1@xxxxxxxxxxxxx>
On Nov 28, 2006, at 23:51 PM, Mike Austin wrote: > Now define a generic function which dispatches on one argument, and > return the actual curried function you want to call: > > define method foo(window :: <window>) > return curry(window-foo, window); > end method; > > window.foo returns the curried function you want to call, and > > window.foo(1, 2, 3); > > calls it. Clever, but ugly, and likely inefficient to use by default. May be a good solution for some dynamic situations. > The above is the same as window(foo)(1, 2, 3). Minor correction: window.foo(1, 2, 3) is equivalent to foo(window)(1, 2, 3) And it's worth noting that they're not strictly identical, because the order of evaluation is different, since "window" and "foo" are referenced in different order. As it happens, I'd rather lose this feature of Dylan and make it so that window.foo(1, 2, 3) is equivalent to foo(window, 1, 2, 3), which I think would be much more useful and widely applicable (no pun intended). -- Chris Page - Super Happy Fun Engineer Do not taunt Super Happy Fun Engineer. -- Gd-hackers mailing list Gd-hackers@xxxxxxxxxxxxxxxx https://www.opendylan.org/mailman/listinfo/gd-hackers