Menu
▾
▴
sml-implementers — Standard ML implementers
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(127) |
Oct
(37) |
Nov
(4) |
Dec
(1) |
| 2002 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(2) |
Jun
|
Jul
(16) |
Aug
(4) |
Sep
(6) |
Oct
(2) |
Nov
(1) |
Dec
(3) |
| 2003 |
Jan
(1) |
Feb
(3) |
Mar
(1) |
Apr
(1) |
May
(2) |
Jun
(3) |
Jul
(2) |
Aug
(3) |
Sep
(3) |
Oct
(5) |
Nov
(16) |
Dec
(28) |
| 2004 |
Jan
(13) |
Feb
(9) |
Mar
(3) |
Apr
(9) |
May
|
Jun
(10) |
Jul
(2) |
Aug
(3) |
Sep
(3) |
Oct
(4) |
Nov
(6) |
Dec
(7) |
| 2005 |
Jan
|
Feb
(1) |
Mar
(19) |
Apr
(4) |
May
(5) |
Jun
(6) |
Jul
(5) |
Aug
(3) |
Sep
(7) |
Oct
(24) |
Nov
(7) |
Dec
(4) |
| 2006 |
Jan
(11) |
Feb
(3) |
Mar
(9) |
Apr
(7) |
May
(31) |
Jun
(25) |
Jul
(13) |
Aug
(9) |
Sep
(9) |
Oct
(23) |
Nov
(35) |
Dec
(13) |
| 2007 |
Jan
(49) |
Feb
(26) |
Mar
(22) |
Apr
(12) |
May
(24) |
Jun
(34) |
Jul
(42) |
Aug
(75) |
Sep
(52) |
Oct
(35) |
Nov
(41) |
Dec
(36) |
| 2008 |
Jan
(26) |
Feb
(33) |
Mar
(57) |
Apr
(82) |
May
(97) |
Jun
(78) |
Jul
(79) |
Aug
(61) |
Sep
(54) |
Oct
(32) |
Nov
(49) |
Dec
(48) |
| 2009 |
Jan
(54) |
Feb
(32) |
Mar
(59) |
Apr
(65) |
May
(149) |
Jun
(131) |
Jul
(80) |
Aug
(40) |
Sep
(26) |
Oct
(63) |
Nov
(12) |
Dec
(21) |
| 2010 |
Jan
(10) |
Feb
(16) |
Mar
(41) |
Apr
(43) |
May
(53) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Chris <ch...@ev...> - 2002-08-21 01:06:09
|
<HTML> <HEAD> <TITLE>New Position</TITLE> <BODY VLINK="#009999"> <HR> <BASEFONT SIZE="3"> <P><FONT FACE="Arial"><FONT COLOR="#003399"><b>If you are going to find the job you want,</b> it will be here at <A HREF="http://www.everyrecruiter.com">http://www.everyrecruiter.com.</A></p> <P><FONT FACE="Arial"><b>Why?</b> Because it is the only way you can connect with <B>employers</B>...</b>lots of employers.</FONT></P> <P><FONT FACE="Arial">Most jobseekers have come to realize that the old methods of looking for a job no longer work, but they don't know what else to do.</FONT></P> <P><FONT FACE="Arial"><b>A completely different approach is required.</b></FONT></p> <p><FONT FACE="Arial">Fewer and fewer employers are willing to deal with the avalanche of resumes they receive when they advertise an open position.That is why there is a decreasing number jobs advertised in the paper.</FONT></p> <p><FONT FACE="Arial"> Instead, most employers prefer to search for employees at their convenience. And the place where most employers go to search is <A HREF="http://www.everyrecruiter.com">http://www.EveryRecruiter.com.</A></FONT></p> <p><FONT FACE="Arial"><b>Will the employers who look today be able to find you?</b></FONT></p> <p><FONT FACE="Arial"><b> Get connected -- Get the job!</p> <p><A HREF="http://www.everyrecruiter.com">http://www.EveryRecruiter.com</A></b></FONT></p> <HR></Body></Head></html> |
|
From: David M. <Dav...@de...> - 2002-08-02 13:04:27
|
I've been having another look at the Basis library implementation in=20 Poly/ML and in particular the I/O library. I'm still not sure I fully=20= understand the implications of the Stream IO (functional IO) layer and=20= in particular the way "canInput" works and interacts with "input". The definition says that canInput(f, n) returns SOME k "if a call to=20 input would return immediately with at least k characters". =20 Specifically it does not say "if a call to inputN(f, k) would return=20 immediately". Secondly it says that it "should attempt to return as=20 large a k as possible" and gives the example of a buffer containing 10=20= characters with the user calling canInput(f, 15). This suggests that a=20= call to canInput could have the effect of committing the stream since a=20= perfectly good implementation of "input" would be to return what was=20 left of the buffer, i.e. 10 characters, and only read from the=20 underlying stream on a subsequent call to "input". Yet after a call to=20= canInput(f, 15) which returns SOME 15 the call to "input" is forced to=20= return at least 15. In other words a call to canInput changes the=20 behaviour of a subsequent call to "input". Generally, what is the=20 behaviour of canInput with an argument larger than the buffer size? How=20= far ahead is canInput expected to read? A few other notes of things I've discovered, some of which are trivial: The signature for TextIO.StreamIO contains duplicates of =A0=A0where=A0type=A0StreamIO.reader=A0=3D=A0TextPrimIO.reader =A0=A0where=A0type=A0StreamIO.writer=A0=3D=A0TextPrimIO.writer There are declared constants for platformWin32Windows2000 and=20 platformWin32WindowsXP in the Windows structure. When I proposed the=20 Windows.Config structure I didn't include constants for these versions=20= of the OS because the underlying GetVersionEx function returns the same=20= value, VER_PLATFORM_WIN32_NT in the dwPlatformId field for NT, Windows=20= 2000 and XP It is possible to distinguish these but only using the=20 major and minor version fields. Windows CE does give a different value=20= for the platformID. I would say it is confusing to have these here=20 because it implies that it's possible to discriminate on the basis of=20 the platformID field. The example definition of input1 at the bottom of STREAM_IO returns a=20 value of type elem option * instream when the signature says it should=20= be (elem * instream) option. Description of "input" function in STREAM_IO signature. The word "ay"=20= should be "may". -- David. |
|
From: ÀÌ¿£¿¡½º<hyu...@ko...> - 2002-08-01 15:31:38
|
<html> <head> <title>하니잉글리쉬</title> <meta http-equiv="Content-Type" content="text/html; charset=euc-kr"> </head> <body bgcolor="#FFFFFF" text="#000000" leftmargin="0" topmargin="0" marginwidth="0" marginheight="0"> <table width="172" border="0" cellpadding="0" cellspacing="0" height="270"> <tr> <td bgcolor="#CCCCCC"> <table width="172" border="0" cellpadding="0" cellspacing="1" height="270"> <tr> <td bgcolor="#FFFFFF"> <table border="0" cellpadding="0" cellspacing="0" height="567"> <tr> <td><img src="http://www.mailpartner.co.kr/email/0620/1.gif" width="600" height="117"></td> </tr> <tr> <td><img src="http://www.mailpartner.co.kr/email/0620/8.gif" width="600" height="30"></td> </tr> <tr> <td><img src="http://www.mailpartner.co.kr/email/0620/2.gif" width="600" height="94"></td> </tr> <tr> <td><img src="http://www.mailpartner.co.kr/email/0620/3.gif" width="600" height="128"></td> </tr> <tr> <td><img src="http://www.mailpartner.co.kr/email/0620/4.gif" width="600" height="108"></td> </tr> <tr> <td><img src="http://www.mailpartner.co.kr/email/0620/5.gif" width="600" height="112"></td> </tr> <tr> <td><img src="http://www.mailpartner.co.kr/email/0620/6.gif" width="600" height="143"></td> </tr> <tr> <td><img src="http://www.mailpartner.co.kr/email/0620/7.gif" width="600" height="89"></td> </tr> <tr> <td> <table cellspacing=0 cellpadding=0 width="95%" align=center border=0> <tbody> <tr> <td width="19%" height=258> <div align=right><img height=255 src="http://www.mailpartner.co.kr/email/0219/%BC%BC%BD%BA7.green001.gif" width=39></div> </td> <td valign=top width="63%" height=258> <div align=center><img src="http://www.mailpartner.co.kr/email/0620/9.gif" width="136" height="21"><br> <br> <font size="2" color="#333333">상담 신청 시 상담원들이 어학에 대한 전문 컨설팅을<br> 3일 이내에 친절하게 해 드립니다.</font></div> <form name="form1" action="http://www.mailpartner.co.kr/email/0219/email_ok_0620.asp" method="post"> <table cellspacing=0 cellpadding=0 width="90%" align=center border=0> <tbody> <tr> <td valign=top width="62%" height=140> <div align=center> <table cellspacing=0 cellpadding=0 width="90%" border=0> <tbody> <tr> <td valign=top width="36%" height=136> <p><img src="http://www.mailpartner.co.kr/email/0219/email4.gif" width=56 height="114"></p> </td> <td valign=top width="64%" height=136><font size=2> <input maxlength=15 size=10 name="name"> <br> <input maxlength=15 size=10 name="tel1"> <br> <input maxlength=15 size=10 name="tel2"> <br> <input maxlength=30 size=16 name="email"> <br> <input size=16 name="address"> </font></td> </tr> </tbody> </table> </div> </td> <td width="38%" height=140> <div align=center> <input type=image height=100 width=100 src="http://www.mailpartner.co.kr/email/0620/11.gif" align=top border=0 name="image"> </div> </td> </tr> </tbody> </table> </form> <font size=2></font></td> <td width="18%" height=258><img height=255 src="http://www.mailpartner.co.kr/email/0219/%BC%BC%BD%BA8.green002.gif" width=38></td> </tr> </tbody> </table> </td> </tr> <tr> <td> <div align="center"><font size="2" color="#666666">귀하의 승락없이 홍보성 전자 우편을 보내게 된 점 정중히 사과 드립니다.<br> 정보통신망이용촉진법 규정을 준수하여 광고메일임을 표시하였으며, 수신거부장치를<br> 마련하고 있습니다. 귀하의 전자 우편 주소는 인터넷 상의 공개된 장소에서 습득하였으며<br> 저희는 귀하의 전자우편 주소 외 어떠한 개인정보도 가지고 있지 않으므로 안심하시기 바랍니다.<br> 수신을 원치 않으시면 <a href="mailto:hyu...@ko..."><font color="#FF0000">수신거부 (Unsubscribe)</font></a>를 클릭해 주십시요.</font></div> </td> </tr> </table> </td> </tr> </table> </td> </tr> </table> </body> </html> |
|
From: Marketingwap <Mar...@mi...> - 2002-08-01 06:12:05
|
PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5NZXNzYWdlPC9USVRMRT4NCjxNRVRBIGNv bnRlbnQ9Ik1TSFRNTCA2LjAwLjI3MTMuMTEwMCIgbmFtZT1HRU5FUkFUT1I+DQo8TUVUQSBj b250ZW50PUZyb250UGFnZS5FZGl0b3IuRG9jdW1lbnQgbmFtZT1Qcm9nSWQ+DQo8TUVUQSBo dHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMt YXNjaWkiPjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz4NCjxIUj4NCjwvRk9OVD48L0RJ Vj4NCjxESVY+DQo8Q0VOVEVSPg0KPFA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTE+WW91ciBl bWFpbCBhZGRyZXNzIHdhcyBvYnRhaW5lZCBmcm9tIGEgc3Vic2NyaWJlZCANCnNlcnZpY2Us IFJlZmVyZW5jZSAjIDQwNjAtNjEwNjxCUj5JZiB5b3Ugd2lzaCB0byB1bnN1YnNjcmliZSBm cm9tIHRoaXMgbGlzdCwgDQpwbGVhc2UgPEEgDQpocmVmPSJtYWlsdG86bWFya2V0aW5nQG1p bGxlbm5pdW1kYXRhLmNvbT9zdWJqZWN0PVVuU3Vic2NyaWJlIGZyb20gTGlzdCI+PEZPTlQg DQpjb2xvcj0jMDAwMDgwPkNsaWNrIEhlcmU8L0ZPTlQ+PC9BPjwvRk9OVD4gPEZPTlQgZmFj ZT1BcmlhbCBzaXplPTE+PEJSPlRoaXMgDQplbWFpbCB3YXMgaW50ZW5kZWQgdG8gYmUgcmVj ZWl2ZWQgaW4gSFRNTCBmb3JtYXQuIElmIHlvdSBkaWQgbm90IHJlY2VpdmUgdGhpcyANCmVt YWlsIGluIHRoZSBwcm9wZXIgZm9ybSwgPEEgDQpocmVmPSJodHRwOi8vd3d3Lm1pbGxlbm5p dW1kYXRhLmNvbS9idXllcnNhZHZhbnRhZ2UvR3JlYXRfRGVhbHMuaHRtIj48Rk9OVCANCmNv bG9yPSMwMDAwODA+Q2xpY2sgSGVyZTwvRk9OVD48L0E+PC9GT05UPjwvUD4NCjxIUj4NCg0K PFAgYWxpZ249Y2VudGVyPjxJTUcgaGVpZ2h0PTExOSANCnNyYz0iaHR0cDovL3d3dy5taWxs ZW5uaXVtZGF0YS5jb20vYnV5ZXJzYWR2YW50YWdlL2ltYWdlcy9nbG9iYWxfSGVhZGVyLmpw ZyIgDQp3aWR0aD02MjEgYm9yZGVyPTA+PEJSPjxCPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9O VCBzaXplPTQ+PEZPTlQgDQpjb2xvcj0jMDAwMGZmPkNvbXBhcSZuYnNwOyBjb21wdXRlcnMg c3RhcnRpbmcgZnJvbTwvRk9OVD4gPC9GT05UPjxGT05UIA0KY29sb3I9IzgwMDAwMCBzaXpl PTQ+JDEyNSE8QlI+PC9GT05UPjwvRk9OVD48L0I+PFNQQU4gDQpjbGFzcz0zODIxNjI5MjEt MjgwNjIwMDI+PEJSPjxTUEFOIGNsYXNzPTkzMzI3MzYyMS0yMjA3MjAwMj4mbmJzcDs8L1NQ QU4+PEEgDQpocmVmPSJodHRwOi8vd3d3Lm1pbGxlbm5pdW1kYXRhLmNvbS9HcmVhdF9EZWFs cy5odG0iPjxGT05UIGNvbG9yPSNmZjAwMDA+PEZPTlQgDQpzaXplPTM+Jm5ic3A7PEI+Q0xJ Q0sgSEVSRTwvQj48L0ZPTlQ+PC9GT05UPjwvQT48L1NQQU4+PEJSPjxCUj48Qj48Rk9OVCAN CmZhY2U9VmVyZGFuYT5OZXcgSW52ZW50b3J5IEp1c3QgQXJyaXZlZCE8U1BBTiBjbGFzcz05 MzMyNzM2MjEtMjIwNzIwMDI+IGZvciB0aGUgDQptb250aCBvZiA8QlI+QXVndXN0ICAgDQoy MDAyPC9TUEFOPjwvRk9OVD48L0I+PC9QPjwvQ0VOVEVSPjwvRk9OVD48L0RJVj48L0JPRFk+ PC9IVE1MPg0KICAgIA== |
|
From: Martin E. <ma...@di...> - 2002-07-31 21:27:54
|
The ML Kit checks for overflow for operations on values of type Int31.int and Int32.int. Cheers, Martin Dave Berry <dav...@bt...> writes: > Out of interest, which implementations do and do not check for overflow on > integer operations? I know that MLj and SML.NET definitely do not. I've > heard rumours that MLton does not; are these rumours correct? Poly/ML uses > intinf as the default integer type (at least it used to -- I haven't seen > recent versions); does it support any other size of int? > > Yours curiously, > > Dave. > > > ------------------------------------------------------- > This sf.net email is sponsored by: Dice - The leading online job board > for high-tech professionals. Search and apply for tech jobs today! > http://seeker.dice.com/seeker.epl?rel_code=31 > _______________________________________________ > Sml-implementers mailing list > Sml...@li... > https://lists.sourceforge.net/lists/listinfo/sml-implementers |
|
From: Matthias B. <bl...@re...> - 2002-07-31 14:51:59
|
SML/NJ does check for integer overflow (and, AFAIK, alwas has). Cheers, Matthias Dave Berry wrote: >Out of interest, which implementations do and do not check for overflow on >integer operations? I know that MLj and SML.NET definitely do not. I've >heard rumours that MLton does not; are these rumours correct? Poly/ML uses >intinf as the default integer type (at least it used to -- I haven't seen >recent versions); does it support any other size of int? > >Yours curiously, > >Dave. > > >------------------------------------------------------- >This sf.net email is sponsored by: Dice - The leading online job board >for high-tech professionals. Search and apply for tech jobs today! >http://seeker.dice.com/seeker.epl?rel_code=31 >_______________________________________________ >Sml-implementers mailing list >Sml...@li... >https://lists.sourceforge.net/lists/listinfo/sml-implementers > > |
|
From: Andreas R. <ros...@ps...> - 2002-07-31 09:49:08
|
Dave Berry wrote: > > Out of interest, which implementations do and do not check for overflow on > integer operations? Currently, Alice also provides arbitrary precision integers only. - Andreas -- Andreas Rossberg, ros...@ps... "Computer games don't affect kids; I mean if Pac Man affected us as kids, we would all be running around in darkened rooms, munching magic pills, and listening to repetitive electronic music." - Kristian Wilson, Nintendo Inc. |
|
From: Ken F. L. <kf...@it...> - 2002-07-31 06:25:35
|
Dave Berry <dav...@bt...> writes: > Out of interest, which implementations do and do not check for overflow on > integer operations? Moscow ML does (and there is no way to turn it off). Cheers, --Ken |
|
From: David M. <Dav...@pr...> - 2002-07-31 06:09:26
|
On Tuesday, July 30, 2002, at 09:54 , Dave Berry wrote: > Out of interest, which implementations do and do not check for overflow > on > integer operations? I know that MLj and SML.NET definitely do not. > I've > heard rumours that MLton does not; are these rumours correct? Poly/ML > uses > intinf as the default integer type (at least it used to -- I haven't > seen > recent versions); does it support any other size of int? Poly/ML still uses arbitrary precision integer. I've done a few experiments with fixed precision integer and the difference in speed is negligible so it doesn't seem worth adding a separate fixed precision type. David |
|
From: Stephen W. <sw...@sw...> - 2002-07-30 21:44:28
|
> Out of interest, which implementations do and do not check for overflow on > integer operations? I know that MLj and SML.NET definitely do not. I've > heard rumours that MLton does not; are these rumours correct? No. MLton checks for overflow by default, and has since the 20010706 release. MLton has a command-line switch, -detect-overflow, which you can use to turn off overflow checking if you want. |
|
From: Dave B. <dav...@bt...> - 2002-07-30 21:11:35
|
Out of interest, which implementations do and do not check for overflow on integer operations? I know that MLj and SML.NET definitely do not. I've heard rumours that MLton does not; are these rumours correct? Poly/ML uses intinf as the default integer type (at least it used to -- I haven't seen recent versions); does it support any other size of int? Yours curiously, Dave. |
|
From: Andreas R. <ros...@ps...> - 2002-07-29 12:06:20
|
Dave Berry wrote:
>
> Andreas requested "eq" functions for every type. In most cases I believe
> we prefer a "compare" function, as it is can be more efficient (e.g. when
> implementing trees of strings).
There are many types or data structures that support equality but have
no (sensible) ordering. As a uniform convention I would thus like to see
every type allowing equality coming with an eq function. The intention
is to make functor programming more convenient. Consider functors over
hashable keys. A canonical argument signature would be
signature HASHABLE =
sig
type t
val eq : t * t -> bool
val hash : t -> int
end
IMHO it would be highly desirable if the Basis established some useful
conventions along these lines so that every appropriate structure
matches such common signatures. Maybe some alike signatures could even
be part of the basis themselves (ORDERED, PARTIALLY_ORDERED and HASHABLE
come to mind).
But I see that it might not fit the spirit of the current design.
> I don't like the name "subsubstring" that Andreas suggested, as it seems
> clumsy. I can see that there is some confusion between (slice,subslice)
> and (substring,slice), but perhaps it would be better to rename
> Substring.slice to Substring.subslice?
Yes, that's probably a better choice.
- Andreas
--
Andreas Rossberg, ros...@ps...
"Computer games don't affect kids; I mean if Pac Man affected us
as kids, we would all be running around in darkened rooms, munching
magic pills, and listening to repetitive electronic music."
- Kristian Wilson, Nintendo Inc.
|
|
From: Dave B. <da...@ta...> - 2002-07-28 16:08:51
|
I'm impressed at the feedback Andreas and Matthew gave. I have a few comments (which are purely personal opinion)... Organisation: Matthew requested sorting the entries by area. The overview page briefly dicusses the various areas -- perhaps the online version of this page could be extended with a complete list of hyperlinks (as continuous text, not one per line)? I like Andreas's suggestion of a Net.* structure. Andreas requested "eq" functions for every type. In most cases I believe we prefer a "compare" function, as it is can be more efficient (e.g. when implementing trees of strings). I don't like the name "subsubstring" that Andreas suggested, as it seems clumsy. I can see that there is some confusion between (slice,subslice) and (substring,slice), but perhaps it would be better to rename Substring.slice to Substring.subslice? Dave. |
|
From: Andreas R. <ros...@ps...> - 2002-07-25 13:14:27
|
Like Matthew I started implementing the latest version of the Basis spec
for Alice and Hamlet. I'm quite happy with most of the changes. It was a
surprise to discover the presence of a Windows structure, though :-)
Here is my list of comments, some of which may duplicate observations
already made by Matthew. They primarily cover global issues and the
required part of the library, though I haven't looked deeper into the IO
and Posix parts yet. I also included some proposals for modest additions
to the library, which I believe are useful and fit its spirit.
Trivial bugs, typos, cosmetics
------------------------------
* Overview:
- INT_INF appears in the list of required signatures.
- WordArray2 appears under the list of required structures,
instead of optional ones.
* LIST_PAIR:
- Typo in description of allEq: double "the".
* SUBSTRING:
- The scan example uses the deprecated "all" function.
* VECTOR_SLICE:
- Typo in synopsis of subslice: s/opt/sz/.
- Typo in description of subslice: s/|arr|/|sl|/.
- Typo in description of findi: s/appi/findi/.
- Signature sometimes uses Vector.vector instead of plain vector.
- The equation for mapi can be simplified to:
Vector.fromList (foldri (fn (i,a,l) => f(i,a)::l) [] slice)
* MONO_VECTOR_SLICE and ARRAY_SLICE and MONO_ARRAY_SLICE:
- Typo in synopsis of subslice: s/opt/sz/.
- Typo in description of findi: s/appi/findi/.
* BYTE:
- Accidental "val" keyword in synopsis of some functions.
* TEXT_IO:
- The "where" constraints contain erroneously qualified ids.
- The specification of the TEXT_IO signature is not valid SML'97,
since StreamIO is specified twice. You might want to add a
comment regarding that.
- The constraints for types vector and elem are redundant
(in fact, invalid), because the signature TEXT_STREAM_IO
already specifies the necessary equations.
* The use of variable names is sometimes inconsistent:
- Predicate arguments to higher-order functions are usually
named "f" (eg. List.all), sometimes "p" (eg. String.tokens,
StringCvt.splitl), and sometimes even "pred" (eg. ListPair.all).
- Similarly, fold functions mostly use "init" to name initial
accumulators, except in the List and ListPair modules.
Ambiguities / Unclear Details
-----------------------------
* Overview:
- The subsection about dependencies among optional modules has
disappeared. Does that mean that there aren't any anymore?
(The nice subsection about design rules and conventions also
has gone.)
* The intended meaning of opaque signature constraints is not always
clear to me. Sometimes the prose contains remarks about additional
equalities that are not appearent from the signature constraints.
For example, is or isn't
- Text.Char.char = Char.char ? (and so on for the rest of Text)
- LargeInt.int = IntN.int (for some structure IntN) ?
(likewise LargeWord.word, LargeReal.real)
- Char.string = String.string ?
- Math.real = Real.real ?
In particular, the spec sometimes speaks of "equal structures",
which has no real technical meaning in SML'97.
Note that from the opaque matching on the overview page one might
even conclude that General.unit <> {} !
* The type specification of String.string and CharVector.vector
is circular:
structure String :> STRING
where type string = CharVector.vector
structure CharVector :> MONO_VECTOR
where type vector = String.string
Likewise for Substring.substring and CharVectorSlice.slice.
A respective defining structure should be chosen.
* STRING:
- Function fromString has a special case that is not covered by
implementing the function through straight-forward iterative
application of the Char.scan function, namely a trailing gap
escape (\f...f\) as in "foo\\ \\" or "foo\\ \\\000" (where \000
is an non-convertible character). Several implementations I
tried get that detail wrong, so a corresponding note might be
in order. Moreover, it is not completely obvious from the
description what the result should be for strings that contain
a gap escape as the only convertible sequence, e.g. "\\ \\" or
"\\ \\\000" - it is supposed to be SOME "", I guess.
* SUBSTRING:
- Shouldn't span raise Span if i' < i? Otherwise, contrary
to the prose, it in fact accepts arguments where ss' is
left to ss, as long as they overlap (which is rather odd).
- For the curried triml/trimr it is not clear whether an
Subscript exception has to be raised already if k < 0 but no
second argument is applied.
Naming and structuring
----------------------
Its nicely chosen regular naming conventions and structure are two of
the aspects I like most about the Standard Basis. The following list
enumerates the few cases where I feel that the spec violates its own
conventions.
* WORD:
- The fromLargeWord and toLargeWord functions should drop
the "Word" suffix to be consistent with the corresponding
functions in the REAL and INTEGER signatures.
* CHAR:
- The functions contains/notContains should be moved to the
STRING signature, as they are similar to find/exist
operations and thus functionality of the aggregate. The
type string could then be removed from the signature.
* ARRAY_SLICE and MONO_ARRAY_SLICE:
- The function copyVec seems completely out of place: it does
neither operate on array slices, nor on vectors. But honestly
I have got no idea where else to put it :-(
* STRING and SUBSTRING:
- There is a certain asymmetry between slices and substrings
which tends to confuse at least myself when hacking. For more
consistency I propose:
(1) changing the type of Substring.substring to
string * int * int option -> substring
(for consistency with VectorSlice.slice),
(2) renaming Substring.slice to Substring.subsubstring,
(for consistency with VectorSlice.subslice),
(3) removing Substring.{app,foldl,foldr} (there are no similar
functions in the STRING signature, and in both cases they
are available through CharVector/CharVectorSlice),
(4) removing String.extract and Substring.extract (the same
functionality is available through CharVector[Slice]).
- I believe the deprecated Substring.all can be removed for good.
After all, there are more serious incompatible changes being
made (e.g. array copying functions).
* Vectors and arrays:
- While the lib consistently uses the to/from convention for
conversions on basic types, it sometimes uses adhoc conventions
for aggregates. I propose renaming:
(1) Array.vector to Array.toVector
(2) VectorSlice.vector to VectorSlice.toVector,
(3) ArraySlice.vector to ArraySlice.toVector,
(4) Substring.string to Substring.toString,
- Since the copy functions have only 3, mostly distinctly typed
arguments now, there no longer seems to be a strong reason to
require passing those by notationally heavy records.
* INT_INF:
- The presence of bit fiddling operators in that signature is
something that feels exceptionally ad-hoc. Either they should
be available for all integer types, or there should be a
separate WORD_INF, with appropriate conversions, that makes
these available.
* Toplevel:
- Now that there is Word.~ (which is good) it seems rather odd
that the toplevel ~ is not overloaded for words, i.e. does not
have type num-> num.
* Net functionality:
- I really like the idea of structuring the library namespace as
it has been done with the OS and Posix structures. I would
prefer to see something similar being done for the added
network functionality. More precisely, I propose
(1) moving the structures Socket, INetSock, GenericSock, and
the three Net*DB structures into a new wrapper structure
Net (renaming Net*DB to *DB),
(2) defining a corresponding signature NET,
(3) renaming the signatures SOCKET, GENERIC_SOCK and INET_SOCK
to NET_SOCKET, NET_GENERIC_SOCK and NET_INET_SOCK, resp.,
(4) moving UnixSock to the Unix structure (renamed as Socket).
Misc. proposals for additional functionality
--------------------------------------------
Here is a small collection of miscellaneous simple functions which I
believe the library is still lacking, either because they are commonly
useful or because they would make the library more regular.
* LIST and LIST_PAIR:
- The IMHO single most convenient extension to the library would
be indexed morphisms on lists, i.e. adding
val appi : (int * 'a -> unit) -> 'a list -> unit
val mapi : (int * 'a -> 'b) -> 'a list -> 'b list
val foldli : (int * 'a * 'b -> 'b) -> 'b -> 'a list -> 'b
val foldri : (int * 'a * 'b -> 'b) -> 'b -> 'a list -> 'b
val findi : (int * 'a -> bool) -> 'a list -> (int * 'a) option
- Likewise for LIST_PAIR.
- LIST_PAIR does not support partial mapping:
val mapPartial : ('a * 'b -> 'c option) ->
'a list * 'b list -> 'c list
* LIST, VECTOR, ARRAY, etc.:
- Another function on lists that would be very useful from my
perspective is
val appr : ('a -> unit) -> 'a list -> unit
and its indexed sibling
val appri : (int * 'a -> unit) -> 'a list -> unit
which traverse the list from right to left.
- Likewise for all aggregate types.
- All aggregates come with a fromList function. I often feel the
need to have inverse toList functions. Use of foldr is obfuscating.
* OPTION:
- Often using isSome is a bit clumsy. I thus propose adding the dual
val isNone : 'a option -> bool
* STRING and SUBSTRING:
- For historical reasons we have {String,Substring}.size instead
of *.length, which is inconsistent with all other aggregates and
frequently lets me mix them up when I use them side by side.
I propose adding aliases
String.maxLen
String.length
Substring.length
* WideChar and WideString:
- There is no convenient way to convert between the standard and
wide character set. Would it be reasonable to introduce LargeChar
and LargeString structures (and so on) and have the CHAR and
STRING signatures enriched by fromLarge/toLarge functions, as for
numbers? That would also allow a program to select the widest
character set available (which is currently impossible within the
language).
* String conversion:
- I don't quite see the rationale for which signatures contain a
scan function and which don't. I believe it makes sense to have
scan in every signature that has fromString.
- There should be a function
val scanC : (Char.char, 'a) StringCvt.reader
-> (char, 'a) StringCvt.reader
to scan strings as C characters. This would make Char.fromCString
and particularly String.fromCString more modular.
- How about a dual writer abstraction as with
type ('a,'b) writer = 'a * 'b -> 'b option
and supporting fmt functions for basic types? Such a thing might
be useful for writing to streams or buffers.
* Vectors:
For some time now I have been trying to use vectors more often
instead of an often inappropriate list representation. This is
sometimes made more difficult simply because the library support
isn't as good as for lists. It improved in the updated version
but still I miss:
- Array.fromVector,
- Vector.mapPartial,
- Vector.rev,
- Vector.append (though I guess concat is good enough),
- most of all: a VectorPair structure.
* Hash functions:
- Giving every basic type a (default) hash function in addition to
comparison would be quite useful in conjunction with container
libraries.
* There is no defining structure for references. I would like to see
signature REF
structure Ref : REF
where REF contains:
datatype ref = datatype ref
val ! : 'a ref -> 'a
val := : 'a ref * 'a -> unit
val swap : 'a ref * 'a ref -> unit (* or :=: ? *)
val map : ('a -> 'a) -> 'a ref -> 'a ref
You might then consider removing ! and := from GENERAL.
* Signature conventions:
Some additional conventions would make use of Basis types as
functor arguments more convenient:
- Each signature defining an abstract type should make that
type available under the alias "t" as well (this includes
monomorphic types as well as polymorphic ones).
- Every equality type should come with an explicit equality
function
val eq : t * t -> bool
to move away from the reliance on eqtypes.
- There should be a uniform name for canonical constructor
functions, e.g. "new" (or at least an alias).
--
Andreas Rossberg, ros...@ps...
"Computer games don't affect kids; I mean if Pac Man affected us
as kids, we would all be running around in darkened rooms, munching
magic pills, and listening to repetitive electronic music."
- Kristian Wilson, Nintendo Inc.
|
|
From: Emden R. G. <er...@re...> - 2002-07-23 16:07:57
|
Thanks for the comments. Two non-technical responses:
Having used both the grouped and alphabetic organization of the man pages
intensively in hardcopy, I find it much easier to find things in the alphabetic
version. This corresponds to the general experience people had with the
BSD 4.2 manuals, where the library man pages where grouped by area (generic
C library, stdio, math, Fortran, etc.) This was frustrating enough that the
4.3 manuals went back to alphabetic. I'm willing to concede that the
hierarchic organization may be better for the on-line pages.
I am now on the sml-implementers list, so a CC: to me separately is
unnecessary.
Emden
|
|
From: Matthew F. <fl...@CS...> - 2002-07-23 15:54:15
|
As promised, here is a longish look at the types used in Arrays and
Vectors.
Array and Vector design:
* The ARRAY signature includes type 'a vector.
Presumably, type 'a Array.vector = type 'a Vector.vector, but no
constraint makes this explicit.
* MONO_ARRAY_SLICE includes type vector and type vector_slice,
while the ARRAY_SLICE signature explicitly references
'a VectorSlice.slice and 'a Vector.vector.
* VECTOR_SLICE doesn't include 'a vector, but has
val mapi : (int * 'a -> 'b) -> 'a slice -> 'b vector
val map : ('a -> 'b) -> 'a slice -> 'b vector;
On the other hand, full, slice, base, vector, and concat
reference 'a Vector.vector.
For consistency, I'd prefer to see
signature VECTOR =
sig type 'a vector ... end
signature VECTOR_SLICE =
sig type 'a vector type 'a slice ... end
signature ARRAY =
sig type 'a vector type 'a array ... end
signature ARRAY_SLICE =
sig type 'a vector type 'a vector_slice
tyep 'a array type 'a slice ... end
signature MONO_VECTOR =
sig type elem type vector ... end
signature MONO_VECTOR_SLICE =
sig type elem type vector type slice ... end
signature MONO_ARRAY =
sig type elem type vector type array ... end
signature MONO_ARRAY_SLICE =
sig type elem type vector type vector_slice
type array type slice ... end
structure Vector :> VECTOR
structure VectorSlice :> VECTOR_SLICE
where type 'a vector = 'a Vector.vector
structure Array :> ARRAY
where type 'a vector = 'a Vector.vector
structure ArraySlice :> ARRAY_SLICE
where type 'a vector = 'a Vector
where type 'a vector_slice = 'a VectorSlice.slice
where type 'a array = 'a Array.array
structure BoolVector :> MONO_VECTOR
where type elem = bool
structure BoolVectorSlice :> MONO_VECTOR_SLICE
where type elem = bool
where type vector = BoolVector.vector
structure BoolArray :> MONO_ARRAY
where type elem = bool
where type vector = BoolVector.vector
structure BoolArraySlice :> MONO_ARRAY_SLICE
where type elem = bool
where type vector = BoolVector.vector
where type vector_slice = BoolVectorSlice.slice
where type array = BoolArray.array
While semantically, this shouldn't be any different than the
specification, it could effect type-error messages. For example, if I
have the structure Foo:
structure Foo = struct
open BoolArraySlice
val copyVec0 {src: vector_slice,
dst: array} = copyVec {src = src, dst = dst, di = 0}
end
which I decide to generalize to polymorphic array slices, then just
changing BoolArraySlice to ArraySlice will lead to different
type-error messages: either "ubound type constructor: vector_slice"
(under the specification) or "type constructor vector_slice given 0
arguments, wants 1" (under the signatures given above); and an arity
error for array in either case. It's not much of an argument, but I
need to replace vector_slice with 'a VectorSlice.slice under the
specification, while I only need to add 'a under the sigs above.
Array2:
* Why not have an ARRAY2_REGION analagous to ARRAY_SLICE?
Likewise, how about VECTOR2 and VECTOR2_REGION?
I think the decision to separate Arrays and Vectors from
their corresponding slices is a nice design choice, and I'd be in
favor of extending it to multi-dimentional ones.
* Should ARRAY2 have findi/find, exists, all? collate?
|
|
From: Matthew F. <fl...@CS...> - 2002-07-23 15:50:04
|
John and SML implementers,
Here are a loose collection of notes I've taken while starting to
update the MLton implementation of the SML Basis Library to the latest
version. They span quite a range: errata and typos, signature
constraint concerns, and some design questions. Thus far, I've looked
at the structures that had been grouped under the headings General,
Text, Integer, Reals, Lists, and Arrays and Vectors (i.e., excluding
IO, System, and Posix) in the "old" web specification.
A few high level comments:
* As an organizational principal, I liked the grouping of modules into
larger collections used in the "old" web specification better than
the long alphabetical list.
* I'm quite happy to see opaque signature matches for most structures.
In particular, I think it will help avoid porting problems between
implementations that provide different INTEGER structures, especially
when LargeInt = Int in one implementation and LargeInt = IntInf in
another.
Required and optional components, Top-level:
* A number of structures have an opaque signature match in
overview.html, but not in the corresponding structure specific page:
General, Bool, Option, List, ListPair, IntInf,
Array, ArraySlice, Vector, VectorSlice.
* Word8Array2 is listed as required in overview.html,
but its signature, MONO_ARRAY2, is not required.
Furthermore, Word8Array2 is marked optional in mono-array2.html.
I don't quite see a rationale for Word8Array2 being required.
* With the addition of val ~ : word -> word to the WORD signature,
presumably ~ should be overloaded at num, rather than at intreal.
Reals:
* In pack-float.html, the where type clauses are incorrect:
structure PackRealBig :> PACK_REAL
where type PackRealBig.real = Real.real
should be
structure PackRealBig :> PACK_REAL
where type real = Real.real
* Likewise, in most places, references to basic types are unqualifed,
so perhaps the where clause should read
where type real = real
for the PackRealBig and PackRealLittle structures.
Arrays and Vectors:
* In vector-slice.html, the description of subslice references |arr|
when it should reference |sl|.
* In {[mono-]array[-slice],[mono-]vector[-slice]}.html, the
description of findi references appi when it should reference findi.
* In mono-array-slice.html, structure CharArraySlice has the clause
where type array = CharVector.vector
which should be
where type array = CharArray.array.
* In mono-{vector[-slice],array[-slice],array2}.html, there are
Word<N> structures but no (default word) Word structures.
* In mono-vector.html, structure CharVector has the clause
where type elem = Char.char
while the other monomorphic vectors of basic types reference
the unqualified type; i.e. structure BoolVector has the clause
where type elem = bool.
* There are no "See also"'s into MONO_VECTOR_SLICE or MONO_ARRAY_SLICE
from MONO_VECTOR or MONO_ARRAY.
* A long discussion about types defined in
[MONO_]{ARRAY,VECTOR}[_SLICE] signatures; deferred to a separate
email.
Really nit-picky:
* Ordering of comparison functions (>, >=, etc.) and unary negation
are different within INTEGER and WORD.
* Ordering of functions in CHAR seems awkward.
* Ordering of full, slice, subslice different in ARRAY_SLICE and
VECTOR_SLICE.
* Ordering of foldi/fold and modifi/modify different in ARRAY2 and
MONO_ARRAY2.
Top-level and opaque signatures:
* I think it would be useful to see the entire top-level of required
structures written out with their respective signature constraints.
For example, in the description of the Math structure, the spec
reads: "The top-level structure Math provides these functions for
the default real type Real.real." Because the top-level Math
structure has an opaque signature match (in overview.html), then the
sentence above implies that there ought to be the constraint
where type real = real (or Real.real).
Granted, none of the other structures in overview.html have where
clauses, and most type constraints are documented in the structure
specific pages, but the constraint on the top-level Math.real
slipped my mind when I first looked at it.
-Matthew
|
|
From: Marketingwap <Mar...@mi...> - 2002-07-23 08:37:48
|
PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5NZXNzYWdlPC9USVRMRT4NCjxNRVRBIGNv bnRlbnQ9Ik1TSFRNTCA2LjAwLjI3MTMuMTEwMCIgbmFtZT1HRU5FUkFUT1I+DQo8TUVUQSBj b250ZW50PUZyb250UGFnZS5FZGl0b3IuRG9jdW1lbnQgbmFtZT1Qcm9nSWQ+DQo8TUVUQSBo dHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMt YXNjaWkiPjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz4NCjxIUj4NCjwvRk9OVD48L0RJ Vj4NCjxESVY+DQo8Q0VOVEVSPg0KPFA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTE+WW91ciBl bWFpbCBhZGRyZXNzIHdhcyBvYnRhaW5lZCBmcm9tIGEgc3Vic2NyaWJlZCANCnNlcnZpY2Us IFJlZmVyZW5jZSAjIDQwNjAtNjEwNjxCUj5JZiB5b3Ugd2lzaCB0byB1bnN1YnNjcmliZSBm cm9tIHRoaXMgbGlzdCwgDQpwbGVhc2UgPEEgDQpocmVmPSJtYWlsdG86bWFya2V0aW5nQG1p bGxlbm5pdW1kYXRhLmNvbT9zdWJqZWN0PVVuU3Vic2NyaWJlIGZyb20gTGlzdCI+PEZPTlQg DQpjb2xvcj0jMDAwMDgwPkNsaWNrIEhlcmU8L0ZPTlQ+PC9BPjwvRk9OVD4gPEZPTlQgZmFj ZT1BcmlhbCBzaXplPTE+PEJSPlRoaXMgDQplbWFpbCB3YXMgaW50ZW5kZWQgdG8gYmUgcmVj ZWl2ZWQgaW4gSFRNTCBmb3JtYXQuIElmIHlvdSBkaWQgbm90IHJlY2VpdmUgdGhpcyANCmVt YWlsIGluIHRoZSBwcm9wZXIgZm9ybSwgPEEgDQpocmVmPSJodHRwOi8vd3d3Lm1pbGxlbm5p dW1kYXRhLmNvbS9idXllcnNhZHZhbnRhZ2UvR3JlYXRfRGVhbHMuaHRtIj48Rk9OVCANCmNv bG9yPSMwMDAwODA+Q2xpY2sgSGVyZTwvRk9OVD48L0E+PC9GT05UPjwvUD4NCjxIUj4NCg0K PFAgYWxpZ249Y2VudGVyPjxJTUcgaGVpZ2h0PTExOSANCnNyYz0iaHR0cDovL3d3dy5taWxs ZW5uaXVtZGF0YS5jb20vYnV5ZXJzYWR2YW50YWdlL2ltYWdlcy9nbG9iYWxfSGVhZGVyLmpw ZyIgDQp3aWR0aD02MjEgYm9yZGVyPTA+PEJSPjxCPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9O VCBzaXplPTQ+PEZPTlQgDQpjb2xvcj0jMDAwMGZmPkNvbXBhcSZuYnNwOyBjb21wdXRlcnMg c3RhcnRpbmcgZnJvbTwvRk9OVD4gPC9GT05UPjxGT05UIA0KY29sb3I9IzgwMDAwMCBzaXpl PTQ+JDEyNSE8QlI+PC9GT05UPjwvRk9OVD48L0I+PFNQQU4gDQpjbGFzcz0zODIxNjI5MjEt MjgwNjIwMDI+PEJSPjxTUEFOIGNsYXNzPTkzMzI3MzYyMS0yMjA3MjAwMj4mbmJzcDs8L1NQ QU4+PEEgDQpocmVmPSJodHRwOi8vd3d3Lm1pbGxlbm5pdW1kYXRhLmNvbS9HcmVhdF9EZWFs cy5odG0iPjxGT05UIGNvbG9yPSNmZjAwMDA+PEZPTlQgDQpzaXplPTM+Jm5ic3A7PEI+Q0xJ Q0sgSEVSRTwvQj48L0ZPTlQ+PC9GT05UPjwvQT48L1NQQU4+PEJSPjxCUj48Qj48Rk9OVCAN CmZhY2U9VmVyZGFuYT5OZXcgSW52ZW50b3J5IEp1c3QgQXJyaXZlZCE8U1BBTiBjbGFzcz05 MzMyNzM2MjEtMjIwNzIwMDI+IGZvciB0aGUgDQp3ZWVrIG9mPEJSPkp1bHkgMjIsIA0KMjAw MjwvU1BBTj48L0ZPTlQ+PC9CPjwvUD48L0NFTlRFUj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwv SFRNTD4NCiAgICA= |
|
From: John R. <jh...@cs...> - 2002-07-18 18:24:02
|
[Sorry if you get this twice, but I don't think that the first posting worked] I have put the web pages for the latest version of the SML Basis Library specification up on the SML implementers site at sourceforge. The URL is http://SML.sourceforge.net/Basis/index.html The document includes a history of changes since the previous version. There are a couple of outstanding technical issues on our list (e.g., clarifying wide character support and adding a select operation to the Socket structure), but we expect the specification to be pretty stable otherwise. Comments and discussion about the specification should be directed to the SML implementers list (sml...@li...). The HTML linking for identifiers in substructures is currently broken (a bug in the generating tool), but please let me know of any other problems you encounter. - John |
|
From: John R. <jh...@cs...> - 2002-07-18 15:58:59
|
I have put the web pages for the latest version of the SML Basis Library specification up on the SML implementers site at sourceforge. The URL is http://SML.sourceforge.net/Basis/index.html The document includes a history of changes since the previous version. There are a couple of outstanding technical issues on our list (e.g., clarifying wide character support and adding a select operation to the Socket structure), but we expect the specification to be pretty stable otherwise. Comments and discussion about the specification should be directed to the SML implementers list (sml...@li...). The HTML linking for identifiers in substructures is currently broken (a bug in the generating tool), but please let me know of any other problems you encounter. - John |
|
From: ¹ÙÀÌ¿À¾ç¸»<hyu...@ko...> - 2002-05-30 15:30:53
|
<!-- saved from url=(0022)http://internet.e-mail --> <!-- saved from url=(0022)http://internet.e-mail --> <html> <head> <title>제목없음</title> <meta name="generator" content="Namo WebEditor v4.0"> </head> <body bgcolor="white" text="black" link="blue" vlink="purple" alink="red"> <table align="center" border="0" cellpadding="0" cellspacing="0" width="750"> <tr> <td width="750" colspan="3"> <p><a href="http://www.mailpartner.co.kr" target="_blank"><img src="http://www.mailpartner.co.kr/email/0309/img1.gif" width="750" height="155" border="0"></a></p> </td> </tr> <tr> <td width="750" colspan="3"> <p><img src="http://www.mailpartner.co.kr/email/0309/img2.gif" width="750" height="118" border="0"></p> </td> </tr> <tr> <td width="750" colspan="3"> <p><a href="http://www.mailpartner.co.kr" target="_blank"><img src="http://www.mailpartner.co.kr/email/0309/img3.gif" width="750" height="138" border="0"></a></p> </td> </tr> <tr> <td width="360"> <p><img src="http://www.mailpartner.co.kr/email/0309/img4.gif" width="210" height="189" border="0"></p> </td> <td width="360"> <p><img src="http://www.mailpartner.co.kr/email/0309/img5.gif" width="195" height="189" border="0" usemap="#ImageMap1"></p> </td> <td width="360"> <p><img src="http://www.mailpartner.co.kr/email/0309/img6.gif" width="345" height="189" border="0"></p> </td> </tr> <tr> <td width="750" colspan="3"> <p style="line-height:140%; margin-top:0; margin-bottom:0; margin-left:10;"><font face="굴림" color="#666666"><span style="font-size:9pt;">귀하의 승락없이 홍보성 전자우편을 보내게 된점 정중히 사과 드립니다.</span></font></p> <p style="line-height:140%; margin-top:0; margin-bottom:0; margin-left:10;"><font face="굴림" color="#666666"><span style="font-size:9pt;">정보통신망 이용 촉진법 규정을 준수하여 광고메일임을 표시하였으며, 수신거부장치를 마련하고있습니다.</span></font></p> <p style="line-height:140%; margin-top:0; margin-bottom:0; margin-left:10;"><font face="굴림" color="#666666"><span style="font-size:9pt;">귀하의 전자우편주소는 인터넷상의 공개된 장소에서 습특하였으며 저희는 귀하의 전자우편주소외 어떠한 개인정보도 가지고 있지 않으므로 안심하시기 바랍니다. 수신을 원치 않으시면 </font><a href="mailto:hyu...@ko...?subject=수신거부"><font face="굴림"><b>수신거부</b></font></a><font face="굴림" color="#666666">를 클릭해 주십시요</span></font></p> </td> </tr> </table> <map name="ImageMap1"> <area shape="rect" coords="10, 104, 182, 161" href="http://www.mailpartner.co.kr" target="_blank"> </map></body> </html> |
|
From: ÇѰ渮ġ¿þÀÌŬ·´<hyu...@ko...> - 2002-05-19 08:07:50
|
<!-- saved from url=(0022)http://internet.e-mail --> <html> <head> <title>한국경제 리치웨이 클럽</title> <meta name="generator" content="Namo WebEditor v4.0"> </head> <body bgcolor="white" text="black" link="blue" vlink="purple" alink="red"> <table align="center" border="0" cellpadding="0" cellspacing="0" width="658"> <tr> <td> <p><img src="http://www.mailpartner.co.kr/email/0422/image/img_01.gif" width="658" height="102" border="0"></p> </td> </tr> <tr> <td> <p><img src="http://www.mailpartner.co.kr/email/0422/image/img_02.gif" width="658" height="186" border="0"></p> </td> </tr> <tr> <td> <p><img src="http://www.mailpartner.co.kr/email/0422/image/img_03.gif" width="658" height="55" border="0" usemap="#ImageMap1"></p> </td> </tr> <tr> <td> <p><img src="http://www.mailpartner.co.kr/email/0422/image/img_04.gif" width="658" height="138" border="0"></p> </td> </tr> <tr> <td> <p><img src="http://www.mailpartner.co.kr/email/0422/image/img_05.gif" width="658" height="46" border="0"></p> </td> </tr> <tr> <td> <p><img src="http://www.mailpartner.co.kr/email/0422/image/img_06.gif" width="658" height="183" border="0" usemap="#Map"></p> </td> </tr> <tr> <td> <p><img src="http://www.mailpartner.co.kr/email/0422/image/img_07.gif" width="658" height="109" border="0"></p> </td> </tr> <tr> <td> <p><img src="http://www.mailpartner.co.kr/email/0422/image/img_08.gif" width="658" height="114" border="0"></p> </td> </tr> <tr> <td> <p><img src="http://www.mailpartner.co.kr/email/0422/image/img_09.gif" width="658" height="136" border="0"></p> </td> </tr> <tr> <td> <p><img src="http://www.mailpartner.co.kr/email/0422/image/img_10.gif" width="658" height="54" border="0" usemap="#ImageMap2"></p> </td> </tr> <tr> <td> <p><img src="http://www.mailpartner.co.kr/email/0422/image/img_11.gif" width="658" height="38" border="0"></p> </td> </tr> </table> <table width="658" border="0" align="center"> <tr><td bgcolor="#e6e6e6" align="center"><span style="font-size:9pt;"><br>귀하의 승락없이 홍보성 전자 우편을 보내게 된 점 정중히 사과 드립니다.<br> 정보통신망이용촉진법 규정을 준수하여 <b><font color="#FF0000">광고메일</font></b>임을 표시하였으며, 수신거부 장치를 마련하고 있습니다.<br> 귀하의 전자 우편 주소는 인터넷 상의 공개된 장소에서 습득하였으며, 저희는 귀하의 전자우편 주소 외<br> 어떠한 개인정보도 가지고 있지 않으므로 안심하시기 바랍니다.<br> 수신을 원치 않으시면 <a href="mailto:hyu...@ko..."><font color="blue">수신거부</font></a>를 클릭해 주십시요.</span><br> </td></tr></table> <br> <map name="ImageMap1"> <area shape="rect" coords="10, 7, 158, 53" href="http://www.mailpartner.co.kr/email/0422/input.asp" target="_blank"> </map><map name="ImageMap2"> <area shape="rect" coords="502, 3, 653, 49" href="http://www.mailpartner.co.kr/email/0422/input.asp" target="_blank"> </map> <map name="Map"> <area shape="rect" coords="45,3,221,180" href="http://www.mailpartner.co.kr/email/0422/input.asp" target="_blank"> <area shape="rect" coords="240,3,415,180" href="http://www.mailpartner.co.kr/email/0422/input.asp" target="_blank"> <area shape="rect" coords="434,3,610,181" href="http://www.mailpartner.co.kr/email/0422/input.asp" target="_blank"> </map> </body> </html> |
|
From: Peter S. <se...@di...> - 2002-03-31 19:45:30
|
On Sat, 30 Mar 2002, Clark C . Evans wrote: > Hello. I was wondering if anyone has plans to develop an > implementation of SML for parrot, the new opensource VM being > developed as the basis of Perl 6 and written to support Python, > Ruby, etc. =20 Actually, I hadn't noticed the Parrot project. =20 It seems that its raison d'=EAtre is that the JVM and Microsoft CLI/.NET are too biased towards statically typed languages. So it should be a good target for Scheme, and also for ML implementations that do not preserve types in the intermediate code. Another good thing is that Parrot will run on a zillion platforms (because Perl must). But as yet there's no project to make Moscow ML generate Parrot code. Peter -- Department of Mathematics and Physics * http://www.dina.kvl.dk/~sestoft/ Royal Veterinary and Agricultural University * Tel +45 3528 2334 Thorvaldsensvej 40, DK-1871 Frederiksberg C, Denmark * Fax +45 3528 2350= =20 |
|
From: Clark C . E. <cc...@cl...> - 2002-03-30 05:58:33
|
Hello. I was wondering if anyone has plans to develop an implementation of SML for parrot, the new opensource VM being developed as the basis of Perl 6 and written to support Python, Ruby, etc. I noticed that SMLj lacks certain features due to Java bytecode limitations... given that Parrot is still an infant I'm sure it is possible to fix any problems it may have supporting continuations or other ML constructs. I'm asking mostly out of selfishness. I'm using Python, but would like to really start to use ML as well... thus, I see a common bytecode (with perhaps a shared data language, like YAML) to be a very inticing alternative. From what I understand, neither Microsoft's CLI offering nor Java JVM support continuations... and I'd like to see a VM that supports ML so that I can mix-in code and pre-developed libraries from other languages. Yes, I know even with two languages hosted on the same bytecode construct does not mean that language mixing is always possible... but you never know! Thanks! Clark |
|
From: Piyush P K. <pp...@ba...> - 2002-03-03 04:57:29
|
I am a user of the SML/NJ implementation. I would like to know if there is a Curses like library for SML/NJ. ppk -- Computer Science is merely the post-Turing decline in formal system theory today's fortune When among apes, one must play the ape. |
1439 messages has been excluded from this view by a project administrator.
![http://www.mailpartner.co.kr/email/0620/1.gif"](http://www.mailpartner.co.kr/email/0620/1.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0620/8.gif"](http://www.mailpartner.co.kr/email/0620/8.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0620/2.gif"](http://www.mailpartner.co.kr/email/0620/2.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0620/3.gif"](http://www.mailpartner.co.kr/email/0620/3.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0620/4.gif"](http://www.mailpartner.co.kr/email/0620/4.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0620/5.gif"](http://www.mailpartner.co.kr/email/0620/5.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0620/6.gif"](http://www.mailpartner.co.kr/email/0620/6.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0620/7.gif"](http://www.mailpartner.co.kr/email/0620/7.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0219/%BC%BC%BD%BA7.green001.gif"](http://www.mailpartner.co.kr/email/0219/%BC%BC%BD%BA7.green001.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0620/9.gif"](http://www.mailpartner.co.kr/email/0620/9.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0219/email4.gif"](http://www.mailpartner.co.kr/email/0219/email4.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0620/11.gif"](http://www.mailpartner.co.kr/email/0620/11.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0219/%BC%BC%BD%BA8.green002.gif"](http://www.mailpartner.co.kr/email/0219/%BC%BC%BD%BA8.green002.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0309/img1.gif"](http://www.mailpartner.co.kr/email/0309/img1.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0309/img2.gif"](http://www.mailpartner.co.kr/email/0309/img2.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0309/img3.gif"](http://www.mailpartner.co.kr/email/0309/img3.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0309/img4.gif"](http://www.mailpartner.co.kr/email/0309/img4.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0309/img5.gif"](http://www.mailpartner.co.kr/email/0309/img5.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0309/img6.gif"](http://www.mailpartner.co.kr/email/0309/img6.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0422/image/img_01.gif"](http://www.mailpartner.co.kr/email/0422/image/img_01.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0422/image/img_02.gif"](http://www.mailpartner.co.kr/email/0422/image/img_02.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0422/image/img_03.gif"](http://www.mailpartner.co.kr/email/0422/image/img_03.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0422/image/img_04.gif"](http://www.mailpartner.co.kr/email/0422/image/img_04.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0422/image/img_05.gif"](http://www.mailpartner.co.kr/email/0422/image/img_05.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0422/image/img_06.gif"](http://www.mailpartner.co.kr/email/0422/image/img_06.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0422/image/img_07.gif"](http://www.mailpartner.co.kr/email/0422/image/img_07.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0422/image/img_08.gif"](http://www.mailpartner.co.kr/email/0422/image/img_08.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0422/image/img_09.gif"](http://www.mailpartner.co.kr/email/0422/image/img_09.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0422/image/img_10.gif"](http://www.mailpartner.co.kr/email/0422/image/img_10.gif"){kind=link}
![http://www.mailpartner.co.kr/email/0422/image/img_11.gif"](http://www.mailpartner.co.kr/email/0422/image/img_11.gif"){kind=link}