April 21, 2013

Salih hocam demek istediğinizi tam olarak anlayamadım ama 2.işlev çağırmada aşağıdaki gibi bir hata verecektir
Alıntı:

>

'karekök' işlevi çağrılırken hata.
Sayı parametresi sadece int veri türünde veri kabul ediyor.

Tabi isterse kullanıcı şöyle bir şey yapar.

Fn karekök(sayı){
 if(sayı.typid != int)
//veya
 if(sayı.typid != 10.typid)
 fail!("sayı parametresi int veri türünde olmalıdır.")

}

Bu şekilde de yazabilecek.

Ayrıca değişken tanımlamalarında ! ve ? işaretlerini en sona koymak gibi bir imkan sunmayı düşünüyorum.
Mesela
veriVarMı?() gibi bir ifade soru sorduğu için sonuna soru işareti koymak çok hoş duruyor :)
ayrıca uyarı!("Yanlış yoldan gidiyorsun arkadaş") gibi de ! işaretini kullansak çok hoş olur diye düşündüm :)

Ve sanırsam fonksiyon tanımlama, çağırma aynı şekilde sınıf oluşturma, çağırma işlemleri 1.0 a göre oldukça hızlanacak.

Zekeriya

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

April 21, 2013

Belki ben seni yanlış anlamışımdır...:)

Biz burada Java Script veya Matlab'de olduğu gibi değişkenin türünü belirtmeden kullanabilmekten (sanırım otomatik çıkarsama yapabilmesinden) mi bahsediyoruz? Eğer öyleyse duruma göre kullanım kolaylığı var tabii ki...

Bu arada ünlem ve soru işareti kullanımı hoş görünüyor. Ben de bazen kodlama yaparken o soru işaretini koymayı çok istiyorum. Ama uzun vadede ve çok geniş bir vizyon ile olaya bakmalıyız. Bu işaretlerin kullanımını yasal kılmak ileride başımızı ağrıtır mı? Malumunuz, soru işareti üçlü işleçte, ünlem ise değil (1 ise 0 algıla veya tersi) manasında kullanılmakta.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

April 21, 2013

Alıntı:

>

Biz burada Java Script veya Matlab'de olduğu gibi değişkenin türünü belirtmeden kullanabilmekten (sanırım otomatik çıkarsama yapabilmesinden) mi bahsediyoruz? Eğer öyleyse duruma göre kullanım kolaylığı var tabii ki...

Şimdi de ben anlayamadım :) Burada değişken türü tanımlama sadece fonksiyon çağırıldığında o türe uyup uymadığını kontrol ediyor ve uymuyorsa hata vermesini sağlıyor başka hiçbir işlevi yok :)
Fn x(){
a = 10
b = 5
return if a == b true else false
// isterse şöyle yazar
return if (a == b) true else false
}
Gibi bir kullanım olacak yani ? ile üçlü işleç olmayacak :)

Zekeriya

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

April 21, 2013

:)

Şöyle yapalım:

En son bahsettiğim iki konu var ve üçlü işleç diğerine ait. Yani ünlem ve soru işareti ile karışıp karışmaması ile alakalıydı...

İlk konu ise sanırım çok önemli değil. Kimse bir şey anlamadı...:)

Şimdi ise üçüncü bir konuya girelim...

İç içe sınıflar (nested class) imkanımız var mı, düşünüyor musun? Örneğin:

 class outer {
   inner sample;

   this() {
     this.sample = new inner();
   }
   class inner {
     static test = 2013;
   }
 }

 unittest {
   alias outer.inner.test test;
   assert(test == 2013);
   assert(typeid(int) == typeid(test));

   auto deneme = new outer();
        deneme.sample.test--;

   assert(test == 2012);
 }

Bu örneği az önce D'de denedim. Normalde burada bir programcının görmesi gereken sadece bir adet değişken var; hepsi bu. Çünkü statik bir üye var ve unittest dahil her şey bunun farklı bir yansıması. Aslında aynısı ve bir şey de öğrendim! Başına static ifadesi geldiği anda tür otomatik çıkarsanıyor. Bunu istersen "ikibinonüç" olarak eşitleyin. Derleyici bunu sizin yerinize inference yapıyor!

Bu benim ilk 'stress test'im olsun...:)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

April 21, 2013

Evet buna imkan olacak Salih hocam. Bazen ihtiyacım oluyor benim de. RhS de de olması iyi olur :) Tabi 2.0 da yapabilirsem :)

Şimdilik takıldığım 1 nokta var.

Herhangi bir türün içerisindeki bir metoddan operand code işletimi yapılamıyor. Bu ne demek derseniz eğer.

//RhClassC sınıfı içerisindeki kod.
/*
class x ...
print(x())
yazıldığında toString metodu çağırılır ve burada x sınıfı içerisindeki toString işlevi çağırılır tabi buradaki kodlar opcode halinde RhS kodudur artık. Ve aşağıdaki metod üzerinden o opcode leri işletmek gerekecek.
*/
	override string toString(){
		return codes["toString"].call(parameters).toString();
	}

Anlatamadığımı biliyorum o yüzden bir cevap beklemiyorum :)
Ben biraz kafa dinleyeyim çok yoruldum bu gün. Aklıma elbet gelir bir şeyler :)
Çözersem eğer, çözüm yöntemimi anlatırım :)
Zekeriya

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

April 23, 2013

Scala'dan bahsetmiştim; foreach() döngüsünden...

Biraz önce bir tutorial sitesine (-bknz. Scala Quick Guide (http://www.tutorialspoint.com/scala/scala_quick_guide.htm)) denk gelince, şöyle hızlı bir bakış yapmak istedim. Meğer öyle bir komut yokmuş ama for() ile iç içe girmiş. Yani, yine aynı şekilde başlayıp dilersek aralıklarda, dilersek şart(lar) belirleyip bu harika ve esnek yapıyı kullanabiliyormuşuz. Bunu sayfanın ortalarına gelip veya sayfa içi arama (kw: "for(" ) yaparak kolaylıkla bulabilirsiniz.

Gerçi bir de yield olayı var ve D ile benzer olanakları da ama birebir denemediğim için ilerleyen bir zamanda D ile karşılaştırma yapmak üzere bu konuyu rafa kaldırıyorum...:)

Son olarak üzerine basarak (gerçi İstanbul'a geldiğinde konuşacağız inşaallah) belirtmeliyim...

Sözdizimi (syntax) konusunda, RhS'ye özgün bir tarz belirlemek hoş olabilir. Ancak diğer yandan, herkesin alıştığı gibi işlev veya döngü tanımlamak dilin yaygınlaşmasını sağlayacağı su götürmez bir gerçek. Beraberinde D'yi temsil edecek niteliklere (örneğin döngülerde aralıklar, dizilerde dilimler kullanmak gibi olanaklara) yer vermemiz yakışır diye de düşünmeden edemiyorum.

Acaba tıpkı Scala'da olduğu gibi aynı komutu farklı şekillerde kullanabilmemiz mümkünse, dileyen hızlı şekilde (speed mode) yazarken, başka biri ise geleneksel şekilde (classic mode) yazsa ve bunu ilk yorumlanan satırda bir parametre ile RhS'ye bildirse nasıl olur? <---- Çok uzun bir soru ve öneri oldu...:)

Özetle, özgünlükten ve hızdan ödün vermeden bir çözüm öneriyorum...

Hız için ise aklıma sadece 'interpret parameters' geliyor. Böylece yorumlarken daha çok 'parse' işlemi elenmiş olur; ne dersin (?) ya da hiç bulaşmayalım, tek bir düzende olaya devam mı dersin?

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

April 25, 2013

Ben şurada buldum ama?

http://www.artima.com/forums/flat.jsp?forum=283&thread=243570

Alıntı:

>

Son olarak üzerine basarak (gerçi İstanbul'a geldiğinde konuşacağız inşaallah) belirtmeliyim...

İnşallah görüşebiliriz hocam, sizinle ve Ali hocamla görüşmeyi çok istiyorum.

Alıntı:

>

Gerçi bir de yield olayı var ve D ile benzer olanakları da ama birebir denemediğim için ilerleyen bir zamanda D ile karşılaştırma yapmak üzere bu konuyu rafa kaldırıyorum...

yield e pythondan aşinayım çok güzel bir özellik RhS ye katabilirim yield. Hatırlattığınız çok iyi oldu

Alıntı:

>

örneğin döngülerde aralıklar, dizilerde dilimler kullanmak gibi olanaklara

Dilimlemeler olmazsa olmaz doğru diyorsunuz ama döngülerde aralık derken neyi kast ettiniz anlayamadım

Acaba tıpkı Scala'da olduğu gibi aynı komutu farklı şekillerde kullanabilmemiz mümkünse, dileyen hızlı şekilde (speed mode) yazarken, başka biri ise geleneksel şekilde (classic mode) yazsa ve bunu ilk yorumlanan satırda bir parametre ile RhS'ye bildirse nasıl olur? <---- Çok uzun bir soru ve öneri oldu...

Bu ne zamandır aklımda var, fonksiyon çağırma işlemlerinde düşünüyordum bunu. Hızlı ama özelliksiz ve yavaş ama gelişmiş çağırma diye :) Sizin kafanızdaki fikir tam olarak nasıl hocam açabilir misiniz?

Alıntı:

>

Hız için ise aklıma sadece 'interpret parameters' geliyor. Böylece yorumlarken daha çok 'parse' işlemi elenmiş olur; ne dersin (?) ya da hiç bulaşmayalım, tek bir düzende olaya devam mı dersin?

Bunu tam anlayamadım ne demek istediniz?

Bu arada asm deki pop push olaylarını iptal ettim :) bir dizi oluşturdum, asm nin olanaklarını kullanmak çok saçma bir fikir ama olsun test etmiş oldum :) Bir kaç şeyi daha değiştirdim, mesela label adresi alma. Şunu fark ettim label adresi alma çokta fazla etkilemiyor hızı tamam direk adres alsam hızlanır ama çok küçük bir hızlanma bu, bundan ziyade daha farklı şeyler uygulamalıyım hız için. Ayrıca fonksiyon çağırma işlemlerinde ayrı bir interpet işlemi çağrılıyor artık.

Zekeriya

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

April 27, 2013

Alıntı (zekeriyadurmus:1366915978):

>

Bu ne zamandır aklımda var, fonksiyon çağırma işlemlerinde düşünüyordum bunu. Hızlı ama özelliksiz ve yavaş ama gelişmiş çağırma diye :) Sizin kafanızdaki fikir tam olarak nasıl hocam açabilir misiniz?

Şöyle düşünüyorum:

Bizim elektronikte, PIC programlarken, başlangıçta bazı compiler parametreleri vardır...
Hemen ilk bulduğum bir örneği yapıştırayım:
'
;Tutorial 1.6 - Nigel Goodwin 2002
LIST p=16F628 ;tell assembler what chip we are using
include "P16F628.inc" ;include the defaults for the chip
__config 0x3D18 ;sets the configuration settings (oscillator type etc.)

cblock 	0x20		;start of general purpose registers
	count1 			;used in delay routine
	counta 			;used in delay routine
	countb 			;used in delay routine
endc

LEDPORT Equ PORTB	  ;set constant LEDPORT = 'PORTB'
LEDTRIS Equ TRISB	  ;set constant for TRIS register

org	0x0000		  ;org sets the origin, 0x0000 for the 16F628,
				       ;this is where the program starts running

'

Yukarıda tek PIC assembly komutu var o da org, diğerleri derleyicinin HEX kodu oluştururken kullandığı kolaylıklar. Ayrıca include (bu "inkulud" olarak telafuz ediliyor değil mi?) bizim C'deki gibi D'deki import karşılığı. Ama o bir kütüphane değil ve içinde assembly komutlarından çok equ'da olduğu tanımlamalar var. Örneğin Carry bayrağı için C harfi 0'a eşitlenmiş, Zerro bayrağı için ise Z harfi 2'ye eşitlenmiş. Hepsi bu gayet net ve açık, gerçi her şey bir büyü de neyse...:)

Şimdi... ( yabancılar so veya now diyor değil mi...:) )

Bir de yukarıda __config isminde özel bir değişken var. Bu da aslında bayrakları barındıran bir enum diyebiliriz. İşte tıpkı bu değer gibi ilk satırda bunu (interpret/configuration parameters) yorumlayıcıya bildirelim. Yorumlayıcı, henüz tüm kodu ayrıştırmadan çok çok basit bir şekilde parametreler ışığında 'mode' değiştirsin. Bu modlar:

  • Speed Mode
  • Classic Mode
  • Stretch Mode

Son sözcük "stretch"den emin değilim. Yani demek istediğim, ufak tefek yazım hatalarında bile zart zurt hata veren bir durumdan bahsediyorum. Böylece yüksek doğrulukta ama biraz daha yavaş (çünkü hatalar derinlemesine denetlenecek) yorumlama elde edilir.

Farz edelim noktalama işaretlerinin fazla olmayacağı ve olası kullanıcı hatalarının önemsenmedi bir web sayfası düşünelim. Amaç hızlı bir şekilde sunum yapmak. Örneğin bir çizelge HTML kodlar ile defalarca tekrar içerdiği için yazılması zordur. Sayfanın tamamı statik HTML kodlar ile bezenmiştir ama hızlı bir şekilde bir foreach() döngüsü ile tekrar ifadelerini ekranda görüp tasarımına devam etmek istiyordur. Karşımıza "Speed Mode" çıkacak ve bunu kodun başlangıcında yorumlayıcıya bildireceğiz.

Varsayılan (default mode) ise klasik, yani C'den alıştığımız şekilde olabilir. İşte bu durumda yorumlayıcı eskisi gibi çalışmasına devam eder. Eğer mode değiştirme yönergesi ile karşılaşırsa bu sefer farklı bir sınıfı (parser'ı) çağırır ve her şey yeni düzene göre ayrıştırılır.

Özetle elimizde birden fazla parser sınıfı olması gerekiyor sanırım. Ayrıca henüz parser işlemine başlamadan evvel HTML kodu filitre eden bir regular expression ile en baştaki configuration bit'leri (mode flag) alırız pat diye. Sonrası bir switch case veya if()'e bakıyor zaten.

Biraz uzun ve geç cevap oldu ama n'olur kusura bakma; ancak...

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

April 27, 2013

Alıntı (Salih Dinçer):

>

include (bu "inkulud" olarak telafuz ediliyor değil mi?)

Evet. Sanki ikincisi biraz daha uzun iki hece gibi: ink-luud.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

April 29, 2013

Ne kusuru hocam olur mu öyle şey :)

Demek istediğinizi çok iyi anladım ancak bu modların işlevleri tam olarak ne olacak birbirinden farkları ne olacak onu tam olarak anlayamadım.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]